IDEF4

IDEF4 , или Integrated DEFinition for Object-Oriented Design , — это объектно-ориентированный язык моделирования дизайна для проектирования клиент-серверных систем на основе компонентов. Он был разработан для поддержки плавного перехода от прикладной области и моделей анализа требований к проектированию и фактической генерации исходного кода. Он определяет объекты дизайна с достаточной степенью детализации для обеспечения генерации исходного кода. ^[1]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На Викискладе есть медиафайлы по теме IDEF4 .

• Обзор IDEF4 Архивировано 27.02.2016 на Wayback Machine