Моделирование данных и XML

Этап 4. Описание свойств

Типы объектов и связи формируют скелет статической информационной модели; свойства можно сравнить с плотью на костях. Свойства представляют собой простые значения, ассоциированные с объектами. У человека можно определить рост, вес, национальность и род занятий; отель имеет определенное количество комнат, этажность и ценовую категорию.

Не следует снова включать связи в список свойств объекта: расположение отеля не является его свойством, если мы уже промоделировали его как связь с курортом.

Главное, что нам надо знать о свойствах, - это тип их данных. Определен ли для них фиксированный диапазон значений, являются ли они числовыми, в каких единицах выражаются? Является ли свойство обязательным и есть ли у него значение по умолчанию?

В конце этапа 4 мы завершили формирование статической информационной модели: получили полное описание типов объектов в системе, их связей друг с другом и их свойств.

Динамическая информационная модель

Динамические модели описывают, что происходит с информацией: примерами таких моделей являются диаграммы рабочих процессов, потоков данных и жизненных циклов объектов. Динамические модели состоят примерно из таких утверждений: "Отделение патологии отправит результаты теста консультанту, отвечающему за пациента". Динамические модели описывают процесс обмена информацией: данные отправляются из одного места в другое с конкретной целью.

Для построения динамической модели можно воспользоваться различными программными системами (например, диаграммы рабочих процессов и диаграммы потоков данных можно построить, воспользовавшись программой BPWin ).

Существует несколько подходов к динамическому моделированию:

• Модели рабочих процессов
• Модели потоков данных
• Объектные модели
• Жизненные циклы объектов
• Варианты использования
• Диаграммы взаимодействия объектов

Модели рабочих процессов

Модели рабочих процессов заостряют внимание на роли людей и организаций в выполнении работы, хранение и обработка информации играют в них вторичную роль. Модель процесса описывает, например, что будет с путешественником, если на отдыхе с ним произойдет несчастный случай. Она определяет, за какие действия отвечает локальный представитель на курорте, агент в стране, где находится курорт и главный офис. В результате становится ясно, кто должен отвечать за организацию медицинской помощи, за перевозку туриста домой и за информирование родственников. Она может описывать различные формы, заполняемые и пересылаемые между участниками, и вообще не привлекать компьютерные системы. Модель процесса обычно фокусирует внимание на ролях, обязанностях и задачах каждого действующего лица системы ( actor ), а workflow -модель имеет дело с документами, передаваемыми между действующими лицами.

Модели потоков данных

Модели потоков данных очень напоминают предыдущий тип, но в них основное внимание уделено информационным системам. Эта модель описывает хранилища данных (data stores), где информация находится постоянно (это может быть база данных в компьютере или просто кабинет с папками), процессоры, манипулирующие с этими данными, и потоки данных, передающие данные от одного процессора другому. Она активно использует статическую информационную модель: последняя описывает, что означают такие концепции, как путешественник или отель, но ничего не сообщает о том, где содержится информация. Напротив, из модели потоков данных становится ясно, что информация о туристической поездке находится в базе данных покупок до завершения поездки и оплаты всех счетов, после чего резюме этой информации передается в маркетинговую информационную систему, а все остальное - в архив.

Объектные модели

Объектные модели содержат как динамический, так и статический компоненты. Динамическая или поведенческая часть определения объекта сосредоточена на том, что может делать или делал каждый объект, представляя для этого набор операций или методов, описывающих его действия.

Жизненные циклы объекта

Жизненные циклы объекта (на языке UML это называется линиями жизни объекта) также заостряют внимание на индивидуальных объектах, но придерживаются более целостного подхода. Они описывают, что происходит с объектом на протяжении его жизни: как он создается, какие события с ним происходят, как он реагирует на эти события и какие условия приводят в конце к его разрушению.

Жизненные циклы объекта очень полезны для тестирования завершенности модели. Часто наблюдается тенденция к акцентированию внимания только на некоторых событиях за счет остальных. Пока мы не определим, каким образом каждый объект попадает в систему и как он удаляется из нее, полного понимания не будет.

Варианты использования

Варианты использования ( use cases ) анализируют выполнение специфических задач пользователя (например, человек, купивший туристическую поездку, отменяет свой заказ). Вариант использования напоминает модель процесса, но в общем случае заостряет внимание на деятельности одного конкретного пользователя.

Варианты использования могут быть полезны как на этапе моделирования деловой активности, так и при описании внутреннего поведения информационных систем. Одна из опасностей заключается в смешении двух уровней. Лучше этого не делать, поскольку они представляют интерес для различных аудиторий.

Представленный в виде варианта использования диалог пользовательского интерфейса описывает, какой информацией пользователи обмениваются с системой, а не то, как она представлена на экране. Это естественным образом приводит к реализации XML, в которой информационное содержание отделено от особенностей представления.

Диаграммы взаимодействия объектов

Диаграммы взаимодействия объектов позволяют проанализировать обмен сообщениями между объектами на более тонком уровне детализации, чем модель потока данных.

Диаграммы взаимодействия объектов неоценимы, если требуется описать взаимодействие между различными системами. Они позволяют определить, какая информация содержится в каком сообщении. Поскольку эти сообщения написаны на языке XML, диаграммы взаимодействия объектов дают нам контекст, требуемый для начала проектирования структуры XML каждого индивидуального сообщения.

Выбор подхода к динамическому моделированию

Модели нужны только как рабочие инструменты, дающие возможность при встрече с пользователями прийти к соглашению по вопросу о том, как она должна работать. Поэтому не нужно рассматривать все модели. Достаточно рассмотреть только те, которые действительно дадут необходимую информацию о разрабатываемой проблеме. Эти диаграммы самостоятельно появятся в проекте XML, когда начнется описание сообщения между подсистемами.

Проектирование документов XML

Существует два типа данных: информационные хранилища, предназначенные для долговременного хранения данных, и потоки сообщений, передающие временную информацию из одной подсистемы в другую.

Язык XML применим в обоих случаях, но подходы к проектированию различны.

Использование языка XML для сообщений

Использование языка XML для работы с сообщениями системы представляет меньше связанных с проектированием проблем, чем использование его для постоянных данных. Это связано с тем, что каждое сообщение обычно бывает сравнительно автономным, и вопрос о том, что в него включить, естественным образом выпадает из модели обработки.

Разумеется, термин "сообщение" мы используем в широком смысле. Эти сообщения могут быть составлены в стиле электронного обмена данными. Или это могут быть данные, которыми обмениваются подсистемы в форме сообщения XML. Кроме того, сообщение может быть предназначено для отображения на экране. В таком случае, ответ на запрос вернется из базы данных в виде сообщения XML, но клиентская система (или браузер) преобразует его в видимую страницу с помощью соответствующей таблицы стилей.

Существуют некоторые общие принципы проектирования, применимые ко всем сообщениям XML, независимо от их роли:

• Проект сообщения должен отражать содержание информации, а не предполагаемое ее использование.
• Проект должен поддерживать будущие изменения. Составление проекта на языке XML позволяет избежать таких традиционных подводных камней, как фиксированная ширина полей или фиксированный порядок столбцов. Однако проектировщик документа также отвечает за разработку такой структурной информации, которая могла бы предугадать будущие изменения.
• Для сообщений лучше использовать стандартный тип (если он имеется), а не выдумывать новый. В настоящее время доступно большое количество стандартизированных сообщений, например созданных в рамках инициативы BizTalk.
• Кодирование данных должно быть настолько близко к принятым кодировкам, насколько это возможно в рамках существующих ограничений производительности. Не стоит создавать идентификаторы, формирующие внутренние зависимости между сообщением и имеющейся базой данных. Сообщения должны быть автономными.

Надо ли включать ненужную в настоящий момент информацию, которая может потребоваться в дальнейшем? На этот вопрос нет универсального ответа. С одной стороны, легче включить все свойства проекта, а не выбирать те, в которых заинтересован реципиент. Затем можно передать все эти свойства получателю и дать ему возможность проигнорировать ненужные. С другой стороны, глупо посылать лишние данные, учитывая еще проблемы безопасности или секретности. Принимаемое решение должно диктоваться прагматическими соображениями.

Имеет смысл включить в сообщение некоторую официальную информацию, даже если она дублирует доступную из других систем передачи сообщений. Очевидно, это дата и время, личность отправителя и получателя; с помощью серийного номера можно проконтролировать, что сообщение не было утеряно при передаче или отправлено дважды. Для включения всего этого в сообщения XML существуют две причины: реципиенту проще прочитать информацию из сообщения, а не извлекать ее откуда-то еще с помощью специального интерфейса API ; и что более важно при архивировании сообщений для последующего аудита, - всю информацию легче сохранять в одном месте.