 |
Процедура сквозного анализа IDEF-модели
|
|
|
|
В дополнение к циклу папки разработана процедура сквозного анализа. Эта процедура может использоваться, когда участники создания модели могут быть собраны вместе для обсуждения.
- Представьте модель для анализа, используя ее пул сущностей. Пул является оглавлением модели и дает рецензентам краткий обзор того, что будет дальше.
- Представьте глоссарий терминов. Это позволит каждому рецензенту заменить свою терминологию той, которая употребляется представляющим модель коллективом. Значения слов в этот момент не должны ставиться под сомнение. Изменения значений потребуют больших изменений в диаграммах.
- Представьте на рецензирование диаграммы функционального представления.
Процесс сквозного анализа функционального представления является организованным поэтапным процессом, в процессе которого могут задаваться вопросы, выявляющие потенциальные слабости модели. Сквозной анализ состоит из шести этапов.
Исправления модели могут предлагаться на любом этапе. Эти исправления могут отмечаться для последующего внесения, а могут производиться немедленно.
Этап 1. ПРОСМОТР ПУЛА СУЩНОСТЕЙ
Данный этап позволяет читателю получить общее впечатление о содержании модели. Поскольку в пуле сущностей перечисляются и сущности, впоследствии удаленные, читатель получает более полное представление об эволюции модели. На этом этапе читатель должен проверить определения сущностей.
Критерии принятия:
- Выбранные сущности представляют типы информации, необходимые для описания моделируемой среды.
- По мнению рецензента, выбранные сущности отвечают цели и области действия модели.
Критика, за исключением совершенно очевидных случаев, должна быть отложена до второго этапа. Первые впечатления не должны, однако, быть потеряны. До окончательного решения они могут быть записаны на доске или каком-нибудь другом временном носителе информации.
|
|
|
Этап 2. ЧТЕНИЕ ДИАГРАММЫ ФУНКЦИОНАЛЬНОГО ПРЕДСТАВЛЕНИЯ
После того, как читатель понял сущности, читается диаграмма для определения точности представления отношений.
Критерии принятия:
- Мощность отношений соответствует правилам детализации, определенным в руководстве по методологии IDEF1X.
- Все требующиеся отношения показаны либо прямо, либо косвенно.
- Диаграмма обладает легкой для чтения структурой (минимальное число пересечений линий, связанные сущности располагаются недалеко друг от друга).
Этап 3. ПРОВЕРКА КЛЮЧЕВЫХ АТРИБУТОВ
Этот этап служит для проверки того, что указанный ключ действительно будет идентифицировать отдельный экземпляр сущности. Читатель проверяет, что все элементы/атрибуты первичного ключа являются необходимыми.
Критерии принятия:
- Значения атрибутов первичного ключа в совокупности однозначно идентифицируют каждый экземпляр сущности.
- Атрибуты первичного ключа не противоречат правилам необращения в ноль и неповторяемости.
Этап 4. ПРОВЕРКА МИГРАЦИИ КЛЮЧЕВЫХ АТРИБУТОВ
На данном этапе проверяется миграция первичных ключей из родительской сущности в сущность-потомок.
Критерии принятия:
- Миграция первичных ключей согласуется с правилами моделирования.
- Сущность-владелец любого внешнего ключа представлена в модели.
- Миграция первичного ключа не противоречит отношению.
Этап 5. ПРОВЕРКА НЕКЛЮЧЕВЫХ АТРИБУТОВ
Для каждой сущности анализируются атрибуты, не являющиеся элементами первичного ключа.
Критерии принятия:
- Атрибуты не противоречат правилам необращения в ноль и неповторяемости.
- Атрибуты служат для отображения информации, принадлежащей области действия модели.
- Каждый атрибут является уникальным в модели.
Этап 6. УСТАНОВЛЕНИЕ СТАТУСА ДИАГРАММЫ
|
|
|
Возможные решения:
- Рекомендуется в существующем виде.
- Рекомендуется с модификациями.
- Проект: сделано слишком много изменений, требуются переделка и новое повторное рецензирование.
- Не принята: необходим повторный полный анализ.
Приложение А
Глоссарий IDEF1X
Авторские соглашения (author conventions)
Специальные приемы и стандарты, вырабатываемые разработчиком для улучшения представления и использования модели. Авторские соглашения должны не противоречить никаким методологическим правилам.
Альтернативный ключ (alternate key)
Ключ, не являющийся первичным ключом сущности.
Атрибут (attribute)
Характеристика или элемент данных, описывающие что-либо в сущности. Атрибуту присваивается специфическое имя, обозначающее его смысл (например, цвет волос) и значение (например, коричневый)
Булево ограничение (boolean constraint)
Условие ограничения на экземпляры сущностей-потомков в кратных отношениях с одной и той же родительской сущностью. Оператор "AND" означает, что родительская сущность должна обладать экземплярами сущности-потомка во всех отношениях. Оператор "OR" означает, что родительская сущность должна обладать экземплярами сущности-потомка хотя бы в одном из отношений. Оператор "XOR" означает, что родительская сущность может обладать экземплярами сущности-потомка не более чем в одном из отношений.
Внешний ключ (foreign key)
Атрибуты, появляющиеся в зависимой сущности и являющиеся также первичным ключом другой сущности (сущности-родителя или общей сущности).
Диаграмма сущности (entity diagramm)
Диаграмма, изображающая "основную" сущность и все сущности, прямо связанные с основной сущностью.
Зависимость от идентификатора (identifier dependency)
Ограничение между двумя сущностями, требующее, чтобы внешний ключ в зависимой сущности был ее первичным ключом (или его частью). Зависимость от идентификатора является более сильной формой зависимости существования.
Зависимость существования (existence dependency)
Ограничение между двумя сущностями, указывающее на то, что экземпляры зависимой сущности могут существовать только, если они связаны с экземплярами второй сущности. Зависимость существования - это согласованность на уровне ссылок вместе с ограничением, что внешний ключ не может принимать нулевое значение.
|
|
|
Значение атрибута (attribute value)
Конкретное значение, даваемое атрибуту (например, атрибут: цвет волос; значение атрибута: коричневый).
Имя роли (role name)
Имя, присваиваемое внешнему ключу, появляющемуся более одного раза в сущности.
Имя отношения (relationship name)
Определение в виде предложения, которое отражает значение отношения между двумя сущностями, показанными на той диаграмме, где приводится это имя.
Источник (source)
Члены коллектива разработчиков, ответственные за обеспечение информацией (документами, бланками, процедурами, знанием и т.п.), на основе которых будет начинаться и продолжаться разработка модели.
|
|
|
