Сравнительный анализ IDEFO-моделей и диаграмм потоков данных

Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:

· функциональные диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или IDEF0;

· диаграммы, моделирующие данные и их отношения (ERD-диаграммы). Данные диаграммы будут рассмотрены в 5.8.

Таким образом, различие между разновидностями структурного анализа заключается в средствах функционального моделирования. С этой точки зрения все разновидности структурного анализа могут быть разбиты на две группы - использующие DFD (в различных нотациях) и использующие IDEF0-модели. Соотношение применения этих двух разновидно­стей структурного анализа в существующих CASE-средствах составляет 90% для DFD и 10% для IDEF0.

Сравнительный анализ этих двух разновидностей методов структурного анализа проводится по следующим параметрам:

· адекватность средств решаемым задачам;

· согласованность с другими средствами структурного анализа;

· интеграция с последующими стадиями ЖЦ ИС (прежде всего со
стадией проектирования).

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

Согласованность с другими средствами структурного анализа. В данном случае речь идет о согласованности функциональных моделей со средствами моделирования данных. Согласование IDEFO-модели с ERD практически невозможно или носит искусственный характер. В свою очередь, DFD и ERD взаимно дополняют друг друга и являются согласованными, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERD.

Интеграция с последующими стадиями ЖЦ ИС. DFD могут быть преобразованы в модели проектируемой системы, что обеспечивает логичный и безболезненный переход от формирования требований к проектированию системы. С другой стороны, формальные методы преобразования IDEFO-диаграмм в проектные решения ИС отсутствуют.

 

Рекомендации по применению методологий функционального моделирования

IDEF0 лучше всего применять как средство анализа и логического моделирования систем, что, как правило, выполняется на ранних стадиях работы над проектом. Данные анализа, полученные с использованием моделирования IDEF0, обычно используются на стадии разработки моделей IDEF3 и диаграмм потоков данных DFD.

Пример временной шкалы (данные Computer Associates) использования разных методологий моделирования приведен на рис. 5.33.

Рис. 5.33. Временная шкала использования разных методологий моделирования

Помимо DFD, IDEF0, IDEF3 могут использоваться и другие диаграммы, отражающие системную пень их детализации определяются необходимой полнотой описания системы для непосредственного перехода к ее последующей реализации (программированию).

Иерархия экранных форм моделируется с помощью диаграмм последовательностей экранных форм. Построение диаграмм последовательностей экранных форм выполняется следующим образом:

· на DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в ПИ, поэтому можно определить экранную форму для каждого такого процесса;

· форма диаграммы изображается в виде прямоугольника для каждого интерактивного процесса на нижнем уровне диаграммы;

· определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же, как в модели процессов, либо другим способом - по функциональным признакам или в зависимости от принадлежности к определенным объектам);

· формы с меню изображаются над формами, соответствующими интерактивным процессам, и соединяются с ними переходами в виде стрелок, направленных от меню к формам;

· определяется верхняя форма (главная форма приложения), связывающая все формы с меню.

 

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

Рассмотрим вопросы моделирования данных и основы методологии IDEF1X.

Основные понятия

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

Наиболее распространенным средством моделирования данных являются диаграммы ERD (диаграммы «сущность-связь»), нотация которых была впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERD являются:

Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области. Каждая сущность должна обладать некоторыми свойствами:

· иметь уникальное имя;

· обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

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

Атрибут (Attribute) - любая характеристика сущности.

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

Связь (Relationship) - поименованная ассоциация между двумя сущностями, при которой каждый экземпляр одной сущности (сущности-родителя) ассоциирован с произвольным количеством экземпляров второй сущности (сущности-потомка).

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

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

 

Основы методологии IDEF1X

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

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

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

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

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

В IDEF1X могут быть выражены следующие мощности связей:

· каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

Неидентифицирующая связь изображается пунктирной линией (рис.5.34). Сущность-потомок в неидентифицирующей связи будет независимой, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

При установлении неидентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют (переносятся автоматически) в состав неключевых атрибутов дочерней сущности. Так на рис.5.34 первичный ключ «Номер отдела» родительской сущности «Отдел» мигрировал в состав неключевых атрибутов дочерней сущности «Сотрудник».

Для неидентифицирующей связи можно указать обязательность. В случае обязательной связи (No Nulls) неключевые атрибуты дочерней сущности, мигрировавшие из родительской сущности, не могут принимать пустых (NULL) значений. В случае необязательной связи (Nulls Allowed) эти атрибуты могут принимать пустые значения. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны роди­тельской сущности (рис. 5.34а).

Рис. 5.34. Независимые сущности, соединенные неидентифицирующей связью

(а - необязательная, б - обязательная)

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

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют в состав первичного ключа дочерней сущности. На рис. 5.35 показана идентифицирующая связь между независимой сущностью «Клиент» (родительская сущность) и зависимой сущностью «Заказ» (дочерняя сущность). При установлении данной связи первичный ключ «Номер клиента» мигрировал в состав первичного ключа дочерней сущности.

Рис. 5.35. Идентифицирующая связь между независимой и зависимой сущностью

Мигрировавшие при установлении связи атрибуты помечаются как внешние ключи буквами FK (Foreign Key) в скобках (см. рис. 5.34, 5.35).

 

 

Правила ссылочной целостности

Правила ссылочной целостности (RI - referential integrity) представляют собой правила вставки (INSERT), замены (UPDATE) и удаления (DELETE). На их основе генерируются триггеры - программы, выполняемые всякий раз при поступлении команд вставки, замены или удаления экземпляра некоторой сущности.

Рассмотрим правила ссылочной целостности на примерах. В модели данных, представленной на рис. 5.36, экземпляр сущности «Игрок» не может существовать без соответствующего экземпляра сущности «Команда». То есть значение атрибута «Номер команды» в экземпляре сущности «Игрок» не может принимать пустое значение (NULL).

Рис. 5.36.Пример для демонстрации правил удаления экземпляров сущности

В этом случае удаление экземпляра сущности «Команда» (удаление команды) можно организовать по двум правилам:

1. командой Запретить удаление команды, пока в ней числится хотя бы один игрок, т.е. пока есть экземпляры сущности «Игрок», имеющие внешний ключ «Номер команды», совпадающий с первичным ключом «Номер команды» в удаляемом экземпляре сущности «Команда». При таком запрете для удаления команды сначала нужно удалить всех ее игроков.

2. Вместе с удалить всех ее игроков.

Первое правило удаления называется ограничением (RESTRICT), второе - каскадом (CASCADE).

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

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

Иногда более удобно считать, что при удалении отдела, все сотрудники переведены в некоторый отдел по умолчанию. В этом случае вместо правила SET NULL нужно использовать правило установки по умолчанию SET DEFAULT.

Иногда в качестве правила ссылочной целостности применяют правило NONE. В этом случае при удалении экземпляра родительской сущности значение внешнего ключа в экземплярах дочерней сущности не меняется.

При использовании правила NONE в рассматриваемом примере (рис.5.34а) после удаления отдела у всех сотрудников, которые относились к данному отделу, значение атрибута «Номер отдела» не изменится. Таким образом, появляются экземпляры сущности «Сотрудник», которые ссылаются на несуществующий отдел.

Правило NONE используется в настольных или файл-серверных БД. В таких БД правила ссылочной целостности реализуются в клиентском приложении.

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

1. Задать мощность связи между сущностями «Команда» и «Игрок» типа «один или более» (One or more).

2. Действию INSERT присвоить правило CASCADE. В этом случае при создании нового экземпляра сущности «Команда» автоматически будет создаваться новый связанный экземпляр сущности «Игрок».

3. Действию DELETE присвоить правило CASCADE для того, чтобы при удалении экземпляра сущности «Команда» удалялись все связанные экземпляры сущности «Игрок».

 

Иерархия наследования

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

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

Иерархия наследования подразделяется на две категории: полная и неполная.

В полной категории одному экземпляру родового предка обязательно соответствует экземпляр в каком-либо потомке. В рассмотренном примере (рис. 5.37а) иерархия наследования относится к полной категории.

Если иерархия еще не полностью определена и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая иерархия относится к неполной категории. Пример неполной категории иерархии наследования показан на рис. 5.37б. Сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность «Консультант» еще не внесена в данную иерархию наследования.

Обратите внимание, что для обозначения полной категории используется символ , а для неполной

Рис.5.37. Иерархия наследования, полная (а) и неполная (б) категория

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

 

 

Рис.5.38. Иерархия наследования. Комбинация полной и неполной категорий

 

Вопросы для самоконтроля

1. В чем заключаются основные принципы структурного подхода?

2. Понятие методологии IDEF0.

3. Синтаксис и семантика моделей IDEF0:

· семантика и обозначение функционального блока;

· семантика стрелок (типы стрелок);

· комбинированные стрелки;

· разбиение и соединение стрелок;

· туннели;

· типы связей между функциями.

4. Принципы построения моделей IDEF0.

5. Понятие методологии IDEF3.

6. Синтаксис и семантика моделей IDEF3:

· обозначение действия;

· типы связей;

· обозначения асинхронных соединений;

· обозначения синхронных соединений;

· примеры использования синхронных и асинхронных соединений.

7. Взаимосвязь моделей IDEF0 и IDEF3.

8. Понятие методологии DFD.

9. Синтаксис и семантика диаграмм DFD:

· обозначение функционального блока;

· семантика и обозначение внешней сущности;

· семантика и обозначение потоков данных;

· семантика и обозначение хранилища данных.

10. Подходы к построению диаграмм DFD.

11. Сравнительный анализ IDEF0 и DFD моделей.

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

13. Понятие диаграммы ERD.

14. Понятие сущности, атрибута, связи.

15. Понятие объектного отношения и ключа.

16. Понятие связного отношения и внешнего ключа.

17. Понятие методологии IDEF1X.

18. Синтаксис и семантика диаграмм ERD (нотация IDEF1X):

· семантика и обозначение независимой сущности;

· семантика и обозначение зависимой сущности;

· семантика и обозначение идентифицирующей связи;

· семантика и обозначение не идентифицирующей связи;

· обозначение внешних ключей;

· понятие правила ссылочной целостности, примеры таких правил;

· понятие и обозначение иерархии наследования (полная и неполная категории).