IDEF4 - IDEF4

Пример IDEF4: Диаграмма поведения для методов, реализующих Louder.

IDEF4, или же Интегрированный DEFinition для объектно-ориентированного дизайна, является объектно-ориентированный дизайн язык моделирования для проектирования компонентных систем клиент / сервер. Он был разработан для поддержки плавного перехода от моделей предметной области и анализа требований к дизайну и генерации фактического исходного кода. Он определяет объекты дизайна с достаточной детализацией, чтобы можно было генерировать исходный код.^[1]

Этот метод является частью IDEF семья языки моделирования в области системы и программная инженерия.

Обзор

Метод IDEF4 представляет собой графически ориентированную методологию проектирования объектно-ориентированных программных систем. Парадигма объектно-ориентированного программирования предоставляет разработчику абстрактное представление о его программе, состоящей из набора объектов, поддерживающих состояние, которые определяют поведение программы по протоколу их взаимодействия. Объект состоит из набора атрибутов, определяющих локальное состояние, и набора методов (процедур), которые определяют поведение этого конкретного объекта и его отношения с другими объектами, составляющими систему.^[2]

Многомерный подход метода IDEF4 к объектно-ориентированному проектированию программных систем состоит из следующих элементов:^[1]

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

История

Разработка IDEF4 исходила из признания того, что модульность, ремонтопригодность и возможность повторного использования кода, являющиеся результатом объектно-ориентированного программирования парадигма может быть реализована в традиционных обработка данных Приложения. Доказанная способность парадигмы объектно-ориентированного программирования поддерживать интеграцию на уровне данных в больших комплексах. распределенные системы также является важным фактором широкого интереса к этой технологии со стороны традиционного сообщества обработки данных.^[2]

IDEF4 был разработан как инструмент проектирования для разработчиков программного обеспечения, использующих объектно-ориентированные языки, такие как Общая объектная система Lisp, Ароматизаторы, Болтовня, Цель-C, C ++ и другие. Поскольку для эффективного использования объектно-ориентированной парадигмы требуется иной мыслительный процесс, чем при использовании обычных процедурных или языки базы данных, стандартные методологии, такие как структурные диаграммы, диаграммы потоков данных, и традиционные модели дизайна данных (иерархический, реляционный и сетевой) недостаточны. IDEF4 стремится предоставить необходимые средства для поддержки процесса принятия объектно-ориентированных проектных решений.^[2]

Концепции IDEF4

Размеры объектов дизайна IDEF4

Размеры объектов дизайна IDEF4.

IDEF4 использует метод или процедуру объектно-ориентированного проектирования, которые очень похожи на Рамбо Метод объектного метода^[3] и Schlaer /Меллор Методика объектно-ориентированного анализа и дизайна (OOA / OOD).^[4] Однако есть несколько важных отличий:

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

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

IDEF4 Проектная деятельность

В IDEF4 дизайн начинается с анализа требований и принимает в качестве входных данных объекты предметной области. Эти объекты домена закодированы в их эквивалентной форме IDEF4 и помечены как объекты домена. По мере разработки вычислительных объектов для этих объектов они помечаются как «переходные» и, наконец, как «завершенные». Уровень завершения дизайна IDEF4 определяется путем установки мер на основе статуса, уровня и размеров модели отдельных артефактов в проекте.^[1]

IDEF4 Проектная деятельность.

Проектирование на системном уровне начинается после того, как будут собраны «сырые» (доменные) объекты. Это развивает контекст проектирования, обеспечивает возможность подключения к унаследованным системам и определяет приложения, которые должны быть созданы для удовлетворения требований. Статические, динамические, поведенческие и логические модели строятся для объектов на системном уровне. Эти спецификации становятся требованиями на уровне приложения - следующего уровня дизайна. Проект уровня приложения идентифицирует и определяет все программные компоненты (разделы), необходимые в проекте. Статические модели, динамические модели, поведенческие модели и компонент обоснования создаются для объектов на уровне приложения. Эти спецификации становятся требованиями следующего уровня проектирования - низкоуровневого проектирования. Статические модели, динамические модели, поведенческие модели и обоснование дизайна Компонент построен для низкоуровневых объектов дизайна. Подуровни могут быть построены внутри каждого уровня для уменьшения сложности.^[1]

IDEF4 - это итеративная процедура, включающая операции разбиения, классификации / спецификации, сборки, моделирования и повторного разбиения, см. Рисунок. Сначала проект разбивается на объекты, каждый из которых либо классифицируется по существующим объектам, либо для которых разрабатывается внешняя спецификация. Внешняя спецификация позволяет делегировать внутреннюю спецификацию объекта и выполнять ее одновременно. После классификации / спецификации интерфейсы между объектами указываются в процессе сборки (т.е. разрабатываются статические, динамические и поведенческие модели, детализирующие различные аспекты взаимодействия между объектами). Пока модели разрабатываются, важно моделировать сценарии или случаи использования. ^[5] между объектами, чтобы выявить недостатки дизайна. Основываясь на этих недостатках, дизайнер может затем переставить существующие модели и моделировать их, пока дизайнер не будет удовлетворен.^[1]

IDEF4 Объектно-ориентированные концепции

IDEF4 определяет набор объектно-ориентированных концепций:^[1]

• Домены : IDEF4 проекты реализованы в домене. Домен можно рассматривать как объем разрабатываемой системы. Во время проектирования системы программное обеспечение перемещается между тремя доменами: доменом приложения, доменом проектирования и доменом реализации.
• Особенности, артефакты и объекты
• Экземпляр объекта : Объекты могут быть экземплярами объектов, классами объектов и разделами объектов. Экземпляры объектов - это отдельные вещи, встречающиеся в домене приложения.
• Классы : Классы являются обобщениями об объектах и ​​используются для управления сложностью, используя преимущества сходства в экземплярах объектов и группируя их по классам или категориям.
• Подкласс / Суперкласс : Термин подкласс охватывает концепцию группировки конкретных экземпляров класса в еще более специализированный класс.
• Перегородки : Объект раздела содержит объекты и отношения.
• Атрибуты : Атрибуты - это выбор реализации того, как представлять состояние объекта.
• Состояния объекта : Состояния объекта представляют собой ситуации или условия экземпляра объекта, которые имеют значение в дизайне.
• Метод : Метод - это реализация поведения (то есть набор инструкций, согласно которым объект выполняет некоторую операцию).
• Сообщение и полиморфизм : Объекты общаются, отправляя сообщения друг другу.
• Мероприятие : Событие - это сигнал, генерируемый методом в объекте, указывающий на некоторое состояние объекта.
• Жизненные циклы объекта : В любой системе объекты демонстрируют шаблоны поведения, поскольку они циклически проходят через различные состояния.
• Клиент / Сервер : Объект играет роль клиента по отношению к сообщению, если он является отправителем этого сообщения.
• Отношения и роли : Объекты, соединенные вместе дугами. Эти дуги называются отношениями, и они показывают связи между объектами.
• Наследование : Особый тип отношений, используемый в объектно-ориентированной технологии, - это наследование.
• Инкапсуляция и скрытие информации : Инкапсуляция и сокрытие информации - две объектно-ориентированные концепции, которые легче всего понять, если обсудить их с точки зрения взаимодействий между объектами.

Идентификация класса объекта

Пять типов классов объектов в IDEF4.

Метод IDEF4 предполагает, что объекты домена были идентифицированы посредством объектно-ориентированного анализа домена. Такие методы как IDEF1, IDEF5, IDEF3, SA / SD может использоваться для выполнения анализа предметной области.^[6] Тем не менее, практикующие IDEF4 должны знать, как идентифицируются объекты, поскольку в процессе проектирования могут быть обнаружены недостатки объектно-ориентированного анализа. IDEF4 определил пять типов классов:^[1]

• Физические объекты
• Объекты ролей : Роль может быть связана с другими видами деятельности, которыми занимается человек (например, пациент в больнице, акционер, клиент, доверенное лицо, подозреваемый в краже со взломом или налогоплательщик).
• Объекты событий : События или инциденты также могут считаться объектами. Идентификация событий как объектов очень субъективна и будет зависеть от области, в которой будет использоваться программное обеспечение.
• Объекты взаимодействия : Объекты взаимодействия являются результатом взаимодействий или транзакций между двумя или более объектами.
• Объекты спецификации и процедуры : Объекты спецификации описывают допустимые характеристики экземпляров объектов. Объекты процедуры относятся к способу взаимодействия других экземпляров объекта.

IDEF4 Строительные блоки

Организация строительных блоков IDEF4.

Слои IDEF4

Пользователи IDEF4 проектируют на трех разных уровнях:^[1]

1. Системный дизайн,
2. дизайн приложения, и
3. низкоуровневый дизайн.

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

Статус артефакта IDEF4

IDEF4 различает артефакты IDEF4, вновь созданные из домена приложения, артефакты при переходе к спецификации проекта и указанные артефакты, которые можно применять для создания спецификации проекта. Любой артефакт дизайна в IDEF4 можно пометить как домен, переход или завершенный. Это позволяет специалистам-практикам и рецензентам отслеживать продвижение дизайна к завершению.^[1]

Модели дизайна IDEF4

Организация модели IDEF4.

IDEF4 использует три модели проектирования и компонент обоснования дизайна:^[1]

• Статическая модель (SM) определяет неизменные во времени отношения между объектами (например, наследование).
• Динамическая модель (DM) определяет связь между объектами и переходы состояний объектов.
• Модель поведения (BM) определяет отношения между соответствующим поведением объектов.

Компонент «Обоснование дизайна» обеспечивает нисходящее представление системы, давая широкий обзор, охватывающий три модели дизайна и документирующий обоснование основных изменений дизайна.

Каждая модель представляет собой разное поперечное сечение конструкции. Три модели дизайна охватывают всю информацию, представленную в дизайн-проекте, а обоснование дизайна документирует обоснование дизайна. Каждая модель поддерживается графическим синтаксисом, который подчеркивает проектные решения, которые необходимо принять, и их влияние на другие аспекты дизайна. Для облегчения использования графический синтаксис всех трех моделей идентичен.^[1]

Особенности дизайна

IDEF4 предоставляет широкий спектр конструктивных особенностей - от общих до специальных. Этот диапазон позволяет отложить принятие решений, позволяя проектировщику сначала фиксировать особенности проекта в общих чертах, а затем уточнять их. Это значительно снижает нагрузку на дизайнеров, позволяя им сразу же захватывать новые концепции дизайна с помощью функций дизайна IDEF4, даже если эти концепции дизайна еще не были подробно изучены.^[1]

Рекомендации

дальнейшее чтение

• Томас М. Блинн (1989). Документы требований к системе автоматизации IDEF3 и IDEF4 и модели системной среды: промежуточный технический отчет.. Национальная служба технической информации.
• Патрисия Гриффит Фрил и Томас М. Блинн (1989). «Документ по проектированию автоматизированных систем IDEF3 и IDEF4». Технический отчет. Космический центр имени Джонсона НАСА.
• Ричард Дж. Майер, Дуглас Д. Эдвардс (1990). Технический отчет IDEF4, версия 1.0. НАСА * Ричард Дж. Майер, Дуглас Д. Эдвардс (1990). Отчет о формализации IDEF4, версия 1.0. НАСА
• Ричард Дж. Майер, и другие. (1992). Отчет о методе IDEF4. База ВВС Райт-Паттерсон, Огайо, 45433-7604. Май 2002 г.
• Ричард Дж. Майер и другие. (1995). Отчет о методе объектно-ориентированного проектирования IDEF4 Версия 2.0. Январь 1995 г.

внешняя ссылка

• Обзор IDEF4 на idef.com333