 |
Представление результатов стадии 4
|
|
|
|
После определения атрибутов диаграммы функционального представления могут быть теперь обновлены так, чтобы отразить детали модели, и расширены с тем, чтобы показать неключевые атрибуты. Неключевые атрибуты перечисляются ниже линии внутри каждого блока сущности. Для того чтобы внутри блока сущности хватило места, размеры блока могут быть увеличены. На рис. 4-25 приведен пример функционального представления стадии 4.
Рис. 4-25. Пример диаграммы функционального представления на стадии 4
Соответствующие определения и информация для модели должны быть обновлены, чтобы отразить определение неключевых атрибутов и их принадлежности. Эта дополнительная информация может быть представлена сущностью вместе с ранее определенной информацией. Теперь каждый набор документов сущности будет содержать:
- определение каждой сущности;
- список первичных, альтернативных и внешних ключевых атрибутов;
- список принадлежащих сущности неключевых атрибутов;
- определение каждого принадлежащего сущности атрибута (как ключевого, так и неключевого);
- список отношений, в которых данная сущность является родительской:
- отношение категоризации;
- идентифицирующие отношения указанного выше типа;
- неидентифицирующие отношения указанного выше типа; - список отношений, в которых данная сущность является сущностью-потомком:
- отношение категоризации;
- идентифицирующие отношения указанного выше типа;
- неидентифицирующие отношения указанного выше типа; - утверждения всех двойных путей.
Необязательные диаграммы сущностей также могут быть расширены для указания неключевых атрибутов.
Определения отношений могут быть повторены в комплекте документов для каждой сущности или перечислены отдельно с перекрестными ссылками на эти сущности. Ключевые и неключевые атрибуты должны быть также перечислены и снабжены перекрестными ссылками на эти сущности.
|
|
|
Документирование и верификация
Введение
Целью IDEF1X-методологии является выработка непротиворечивого интегрированного определения семантических характеристик данных, которые могут использоваться для организации потоков данных и управления при создании распределенных баз данных и интеграции информационных систем. Это означает, что модели должны быть снабжены подробной документацией и тщательно проверены специалистами как по бизнесу, так и по теории систем. После построения и проверки исходной модели на первый план, по мере создания новых моделей и объединения их с существующими спецификациями, выходят соображения, связанные с управлением конфигурацией моделей данных.
С помощью средств программного обеспечения можно намного облегчить работу по созданию документации и конфигурации модели. В качестве простейшей системы поддержки для обслуживания определений сущностей, отношений и атрибутов может использоваться система обработки текстов. Для создания диаграмм могут использоваться стандартные интерактивные графические пакеты. Польза от этих средств, однако, ограничена, поскольку они не учитывают содержания модели. Большинство коммерческих систем словарей данных не поддерживают определений семантических моделей данных. Однако некоторые из этих словарей данных содержат разделы, определяемые пользователем. Они могут применяться для хранения определений и составления различных отчетов. Другой возможностью является построение простой базы данных для хранения описания модели и использование средств СУБД для генерирования различных отчетов. Активный трехсхемный словарь к проекту "Поддержка интегрированных информационных систем" (IISS) ВВС США снабжен системой управления реляционной базой данных. Кроме того, недавно стали коммерчески доступны специальные программные средства моделирования. Для программных средств моделирования важны следующие свойства:
|
|
|
- автоматические генерирование и размещение диаграмм модели;
- объединение моделей данных;
- проверка непротиворечивости и автоматическая детализация моделей в соответствии с правилами моделирования;
- возможность представления отчетов;
- поддержка управления конфигурацией.
Хотя некоторый уровень автоматической поддержки крайне желателен, он не обязателен для IDEF1X-моделирования. В следующих разделах будут рассматриваться процессы документирования модели и проверки ее правильности, предполагающие минимальный уровень автоматической поддержки.
IDEF1X-папка
Папка - это технический документ, который может содержать диаграммы, текст, глоссарии, сводки решений, основополагающую информацию и все остальное, что можно собрать для обзора и комментирования. Каждая стадия IDEF1X-проекта моделирования требует создания одной или нескольких папок для рецензирования экспертами, утверждающими модель. На рис. 5.1 показан цикл рецензирования папки. Если папка отсылается для письменного комментирования, автор всегда должен отвечать на комментарии рецензента. Как альтернатива рассылки папок для получения письменных комментариев может использоваться сквозной анализ с целью достижения консенсуса рецензентов. Сквозной анализ рассматривается в разделе 5.4.
Рис. 5-1. Цикл папки
Каждое лицо, принимающее участие в проекте, может поддерживать файл полученной информации. Однако для поддержки эталонного и справочного файлов каждой папки должно быть организовано ведение библиотеки. В функции библиотеки входит также распределение папок для рецензирования.
Ниже приводится обобщенное содержание папок, создаваемых на всех стадиях, хотя для каждой стадии моделирования может использоваться более одной папки.
- Папка стадии 0:
- Титульный лист папки.
- Формулировка цели и точки зрения.
- План разработки и рецензирования модели.
- Состав разработчиков и их обязанности.
- Исходные материалы (не обязательно).
- Авторские соглашения (не обязательно). - Папка стадии 1:
- Титульный лист папки.
- Пул сущностей.
- Определения сущностей. - Папка стадии 2:
- Титульный лист папки.
- Матрица отношений (не обязательно).
- Диаграммы стадии 2 (уровня сущностей).
- Отчеты о сущностях (определение и отношения).
- Определение отношений.
- Перекрестные ссылки отношения/сущности. - Папка стадии 3:
- Титульный лист папки.
- Диаграммы стадии 3 (уровня ключей).
- Отчеты о сущностях (определение, отношения, утверждения и ключи).
- Определения отношений.
- Список и определения ключевых атрибутов.
- Отношения (перекрестные ссылки сущностей).
- Перекрестные ссылки ключевой атрибут/сущность. - Папка стадии 4:
- Титульный лист папки.
- Диаграммы стадии 4 (уровня атрибутов).
- Отчеты о сущностях (определение, отношения, утверждения, ключи и атрибуты).
- Определения отношений.
- Список и определения (ключевых и неключевых) атрибутов.
- Перекрестные ссылки отношение/сущность.
- Перекрестные ссылки атрибут/сущность (ключевые и неключевые).
|
|
|
Стандартные бланки
Титульный лист служит для организации материала в папке. В нем есть поля для указания имени автора, даты, проекта, номера документа, названия, статуса и примечаний. Для каждой папки создайте титульный лист и заполните в нем следующие поля (см. рис. 5-2):
Рис. 5-2. Титульный лист
- Рабочая информация (рис. 5-2, пометка А):
- Автор или коллектив, создающие модель.
- Имя проекта и номер задания.
- Дата первого представления в библиотеку.
- Даты всех опубликованных версий папки.
- Статус модели (рабочая, эскиз, рекомендована к принятию, опубликована в качестве завершенной модели). - Информация о рецензировании (рис.5-2, пометка В):
- Информация о занесении в файлы и копировании.
- Список рецензентов папки.
- График работы с папкой. - Информация о содержании (рис.5-2, пометка С):
- Оглавление папки.
- Статус каждого раздела папки.
- Комментарии или специальные инструкции библиотекарю. - Информация об идентификации (рис. 5-2, пометка D):
- Имя модели ("Узел"), например MFG-1.
- Название модели.
- Количество страниц.
|
|
|
