Совместное использование IDEF0, DFD и IDEF3

При решении практических задач построения функциональных моделей, предназначенных как для проектирования ИС, так и для анализа некоторых процессов, обычно используются несколько методов. Если говорить о рассмотренных выше подходах, то наибольшее распространение получила трехступенчатая схема разработки и представления функциональных моделей. Внешний (концептуальный) уровень создается с помощью IDEF0. На этом этапе определяются базовые функции, основные передаваемые и используемые объекты (как информационные, так и материальные). Дальнейшая детализация производится с помощью средств DFD. На этом уровне большее внимание уделяется структуре передаваемых и хранимых данных, топологии сети информационного обмена. Детальная спецификация состава и порядка выполнения отдельных функций производится с помощью IDEF3. Если разрабатываемая модель предназначена для нужд проектирования и разработки ИС, то вместо IDEF3 часто используют такие визуальные средства спецификации передач управления как блок-схемы и FLOW-формы (см. ниже).

В качестве CASE-средства, поддерживающего создание гибридных моделей IDEF0+DFD+IDEF3, можно указать пакет BPWin (текущее официальное наименование AllFusion Process Modeler).

Раздел 4. Моделирование данных

Цель моделирования данных состоит в обеспечении разработчика ИС схемой базы данных (БД). Схема может состоять из одной или нескольких моделей данных.

Наиболее распространенным способом моделирования данных является подход с использованием диаграмм «сущность-связь» (Entity Relationship Diagrams, ERD), ориентированных на разработку реляционных БД.

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

IDEF1X

Метод IDEF1X первоначально был разработан для Министерства обороны США и ныне широко используется как в государственных учреждениях, так и в частных фирмах США. Метод отличается ясной и недвусмысленной графической нотацией.

Основными элементами диаграмм сущность-связь являются:

- сущности;

- свойства сущностей (атрибуты);

- отношения (связи) между сущностями.

В общем случае разработка модели по IDEF1X включает следующие шаги:

1. определяются и детализируются цели проекта, составляется план сбора информации, необходимой для модели;

2. выявляются и описываются основные сущности; в дальнейшем сущности будут представлены как таблицы РБД, хранящие значимые для системы данные;

3. выявляются и описываются основные отношения; основные сущности и отношения отображаются на так называемой концептуальном – наименее детальном – уровне модели;

4. раскрываются нестандартные отношения (типа «многие ко многим»), определяются ключевые и наиболее важные с функциональной точки зрения атрибуты сущностей; данная информация отображается на логическом уровне модели (или, в терминах IDEF1X, "key-based view");

5. полностью определяются все атрибуты сущностей, все элементы модели получают непротиворечивые физические имена; получаемый в результате физический уровень модели (в терминах IDEF1X "fully attributed view") может быть отображен в РБД с точно соответствующей ему структурой.

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

Сущность

Сущность (entity) — это описание множества реальных или воображаемых объектов, сходных между собой и имеющих существенное значение для рассматриваемой предметной области, так что информация об объектах подлежит хранению.

Отдельное свойство объекта выражает атрибут. Сущность включает определение одного и более атрибутов.

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

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

Если рассматривать эти элементы с точки зрения конечной РБД, то сущности соответствует таблица, экземпляру сущности – строка, атрибуту – колонка таблицы.

Основные свойства сущности:

1. наличие уникального имени и одинаковой семантики (смысла) во всей модели, т.е., например, сущность «Чек» должна иметь одинаковый смысл на всех диаграммах модели – описание информационного объекта, хранящего параметры кассового чека;

2. наличие одного или нескольких атрибутов;

3. наличие одного или нескольких атрибутов, однозначно идентифицирующих любой экземпляр сущности; эти атрибуты составляют уникальный идентификатор, или первичный ключ (primary key);

4. сущность может иметь любое количество отношений с другими сущностями.

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

Пример отображения сущности "Сотрудник" на разных уровнях модели:

1. концептуальный:

2. логический:

3. физический:

Более детальное рассмотрение свойств сущности требует определения понятия «связь» и дается ниже.

Атрибут

Атрибут (attribute) — любая характеристика сущности, значимая для рассматриваемой проблемной области и предназначенная для квалификации, идентификации, классификации количественной оценки характеристики или выражения состояния сущности.

Экземпляр атрибута — это значение атрибута. С позиции конечного представления в РБД атрибуту соответствует колонка таблицы.

Атрибуты бывают обязательными и необязательными. Если атрибут необязателен, то он может принимать неопределенное значение (NULL).

Атрибуты также бывают описательными и ключевыми, т.е. входящими в состав первичного ключа — уникального идентификатора. Все ключевые атрибуты являются обязательными.

Атрибуты изображаются в виде списка имен внутри блока сущности, при этом каждый атрибут занимает отдельную строку. Атрибуты, входящие в первичный ключ, размещаются в верхней части прямоугольника. Например, для сущности "Сотрудник" первичный ключ состоит из атрибута "Табельный номер" (см. рисунок выше).

Необязательные атрибуты помечаются буквой “O” (optional). Например, пусть атрибут "Телефон" не является обязательным, тогда:

Если, кроме первичного ключа, для сущности можно указать еще несколько атрибутов (групп атрибутов), уникально определяющих экземпляр сущности, то такие атрибуты называются альтернативными ключами. Альтернативные ключи помечаются аббревиатурой AK (от alternate key):

Основные свойства атрибута:

1. принадлежит только одной сущности;

2. имеет уникальное имя в пределах своей сущности;

3. первичный ключ не может принимать неопределенные значения;

4. атрибут принимает одно конкретное значение для каждого экземпляра сущности.

Ряд характеристик, определяемых через связь, рассматриваются в тексте ниже.

Связь (отношение)

Связь (отношение, relationship) — поименованная ассоциация между двумя сущностями, определяющая некоторое логическое соотношение между сущностями.

Каждая связь может именоваться глаголом или глагольной конструкцией. Связь определяет логическое ограничение или бизнес-правило.

На уровне конечной БД связи соответствует ограничение целостности.

Наименование связи уникально для связываемых сущностей и состоит обычно из глагола. Наименование формируется с точки зрения родителя (например, «группа–состоит<из>–студентов»). Смысл наименования связи определяет ролевое имя внешних ключей (см. ниже).

В зависимости от характера связи, соединяющей сущности, в IDEF1X выделяются зависимые и независимые сущности. С этой точки зрения связи делятся на идентифицирующие и неидентифицирующие.

Полная идентификация: каждый экземпляр полностью идентифицируется своими собственными ключевыми атрибутами.

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

В случае связи «один ко многим» экземпляру родительской сущности соответствует произвольное, в том числе нулевое, количество экземпляров потомков, а экземпляр сущности-потомка ассоциирован с одним экземпляром родительской сущности:

При использовании отношения «один ко многим» может устанавливаться идентифицирующая (identifying) связь между одной независимой (родительской) и одной зависимой (дочерней) сущностью. Это означает, что экземпляр дочерней сущности не может существовать, если нет соответствующего ему экземпляра родительской сущности. Это достигается путем так называемой миграции атрибутов первичного ключа родительской сущности в состав первичного ключа дочерней сущности. Первичный ключ родительской сущности становится так называемым внешним ключом (foreign key) для дочерней сущности. При этом атрибуты первичного ключа родительской сущности становятся связанными с соответствующими им атрибутами первичного ключа дочерней сущности: удалением экземпляра родительской сущности приводит к принятию атрибутами внешнего ключа неопределенных значений и, соответственно, фактическому удалению тех экземпляров дочерней сущности, которые были связаны с удаленным экземпляром родительской. Действительно, внешний ключ входит в состав первичного ключа дочерней сущности и его атрибуты не могут принимать неопределенные значения без потери свойства однозначной идентифицируемости сущности.

Таким образом, идентифицирующая связь обязательно делает дочернюю сущность зависимой. Пример идентифицирующей связи:

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

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

Все мигрировавшие атрибуты помечаются аббревиатурой FK (foreign key). Например, из отображения сущности "Игрок" видно, что атрибут "Наименование" является внешним ключом.

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

Наименование внешнего ключа его должно соответствовать его наименованию в родительской или родовой сущности, либо необходимо использовать так называемое ролевое имя (role name). Ролевое имя отражает отношение между дочерней и родительской сущностью с точки зрения дочерней. Пример использования ролевого имени:

Ролевое имя логически обратно наименованию связи, которое формируется с точки зрения родителя.

При использовании отношения «один ко многим» неидентифицирующая (non- identifying) связь позволяет оставить дочернюю сущность независимой. В этом случае атрибуты первичного ключа родительской сущности мигрируют в состав описательных (неключевых) атрибутов дочерней сущности. Неидентифицирующая связь показывается пунктиром, и, как и для идентифицирующей, на дочернем конце связи рисуется жирная точка.

Например:

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

Значение необязательной (optional) неидентифицирующей связи принципиально отличается о значения обязательной: экземпляр дочерней сущности должен соответствовать одному экземпляру родительской только тогда, когда соответствующие внешние ключи имеют определенное значение (не NULL).

Изображение необязательной неидентифицирующей связи отличается наличием ромба на родительском конце связи.

Пример:

Такая диаграмма означает, что экземпляр сущности "Игрок" может существовать вне зависимости от наличия какого-либо экземпляра "Команда". Иначе говоря, игрок может не числиться в составе ни одной команды.

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

Для более точного описания отношения «один ко многим» можно указывать число экземпляров дочерней сущности, соответствующих экземпляру родительской. Это соотношение называется мощностью (cardinality) связи.

В IDEF1X определено 4 типа мощности:

1. вариант по умолчанию, когда одному экземпляру родительской сущности соответствует 0, 1 или более экземпляров дочерней; этот случай никак не описывается графически на диаграмме;

2. одному экземпляру родительской сущности соответствует более нуля экземпляров дочерней; помечается символом P (positive — положительное количество);

3. одному экземпляру родительской сущности соответствует ноль или один экземпляр дочерней; помечается символом Z (zero — возможен ноль);

4. одному экземпляру родительской сущности всегда соответствует заданное количество экземпляров дочерней; помечается соответствующим числом, равным количеству экземпляров дочерней сущности;

5. одному экземпляру родительской сущности всегда соответствует от min до max экземпляров дочерней; помечается через диапазон min…max;