IDEF4

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Приклад IDEF4: Діаграма поведінки для методів, що належать до «Гучніше».

IDEF4 — (Integrated DEFinition for Object-Oriented Design) — мова моделювання об'єктно-орієнтованого проектування клієнт-серверних систем, що базуються на компонентах. Вона була розроблена для підтримки плавного переходу від моделей аналізу предметної області застосування та вимог до дизайну, і до фактичної генерації вихідного коду. Вона описує об'єкти проекту з достатньою деталізацією щоб згенерувати вихідний код.

Цей метод є частиною IDEF класифікації мов моделювання в галузі системотехніки і програмної інженерії.

Опис[ред.ред. код]

IDEF4 — графічно орієнтована методологія для проектування об'єктно-орієнтованих програмних систем. Об'єктно-орієнтована парадигма програмування надає розробникам абстрактне бачення їх програми, у вигляді утвореної з певної кількості станів основних об'єктів, що визначають поведінку програми протоколом їх взаємодії. Об'єкт містить набір внутрішніх станів, що визначаються атрибутами та набором методів (процедур), які, в свою чергу, визначають поведінку конкретних об'єктів і їх взаємозв'язків з іншими об'єктами, що утворюють систему.

Метод IDEF4 багатовимірного підходу до об'єктно-орієнтованого проектування програмного забезпечення системи складається з наступних пунктів:

  • Проектування шарів (системного рівня, рівня додатків, і дизайн низького рівня),
  • Стан проектування артефактів (додатки, перехідний рівень, програмне забезпечення),
  • Проектування моделей (статичні, динаміка і поведінка) і компонент обґрунтування дизайну,
  • Проектування особливостей, починаючи від загальних до конкретних, включаючи відкладення прийняття рішень.

IDEF4 концепти[ред.ред. код]

Розміри об'єктів проектування IDEF4[ред.ред. код]

Розміри об'єктів проектування IDEF4

IDEF4 використовує об'єктно-орієнтований метод проектування або процедуру, яка дуже схожа на метод об'єктивного моделювання Рамбо і техніку об'єктно-орієнтованого аналізу та методику проектування (ООА/ООД) Шлаєр-Мелора. Проте, між ними існують суттєві відмінності:

  • IDEF4 була спеціально розроблена, для того аби бути сумісною з іншими методами IDEF,
  • IDEF4 дозволяє відстежувати стан проектних артефактів від об'єкту домена шляхом переходу до проектної специфікації,
  • IDEF 4 вміщує в собі елемент з документації обґрунтування прийнятих проектних рішень

Ці додаткові розміри показані на малюнку. Краї куба показують хід проектування від початку до кінця розробки кожного з цих вимірів.

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

У IDEF4 дизайн починається з аналізу вимог і приймає як вхідні дані об'єкти предметної області. Ці об'єкти предметної області закодовані в їх еквівалентній формі в IDEF4 та відмічені, як об'єкти предметної області. Оскільки для цих об'єктів розробляються обчислювальні об'єкти, вони мають позначки «перехідних» і врешті-решт «завершених». Рівень завершеності проектування IDEF4 визначається встановленням заходів, що залежать від стану, рівня та розмірів індивідуальних артефактів моделі у проектуванні.

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

Проектування системного рівня починається після того, як «сировину» (об'єкти предметної області) буде зібрано. Це розвиває контекст розробки, забезпечує підключення до унаслідуваним системам, і ідентифікує додатки, які повинні бути розроблені для задоволення вимог. Статичні, динамічні, поведінкові, і обґрунтувальні моделі побудовані для об'єктів на системному рівні. Ці характеристики стають вимогами до рівня додатків — наступний рівень проектування. Прикладний рівень проектування ідентифікує і визначає всі компоненти програмного забезпечення (розділів), необхідних при проектуванні. Статичні моделі, динамічні моделі, моделі поведінки, а також компонент обґрунтування побудовані для об'єктів на прикладному рівні. Ці характеристики стають вимогами до наступного рівня — низькорівневого проектування. Статичні моделі, динамічні моделі, моделі поведінки, а також компонент обґрунтування дизайну побудовані для об'єктів проекту нижнього рівня. В межах кожного шару можуть бути побудовані підшари, щоб зменшити складність.

IDEF4 — це ітераційна процедура за участю розділу, класифікація/специфікація, збірка, моделювання і перерозподіл діяльності, дивись малюнок. Перш за все, проектування розбивається на об'єкти, кожен з яких або було віднесено до існуючих об'єктів, або для яких розроблена зовнішня специфікація. Зовнішня специфікація включає внутрішню специфікацію об'єкта, одночасно делегуючись і виконуючись. Після класифікації/специфікації, інтерфейси між об'єктами вказані в сукупній діяльності (тобто, статичні, динамічні і поведінкові моделі, які деталізують різні аспекти взаємодії між об'єктами, що розробляються). У той час як моделі розроблені, важливо змоделювати сценарії або випадки між об'єктами, щоб виявити недоліки проектування. На підставі цих недоліків дизайнер може потім змінити існуючі моделі і моделювати їх, поки дизайнер не буде задоволений.

IDEF4 об'єктно-орієнтовані концепти[ред.ред. код]

IDEF4's визначає набір об'єктно-орієнтованих концептів:

  • Предметна область: проекти IDEF4 визначаються предметною областю. Предметну область можна спостерігати в межах системи, що розробляється. Проектуючи систему, програмне забезпечення переходить між трьома предметними областями: прикладний рівень, рівень проектування та рівень реалізації.
  • Особливості, артефакти та об'єкти
  • Екземпляр об'єкту: Об'єкти можуть бути екземплярами об'єктів, класами об'єктів та розділами об'єктів. Екземпляри об'єктів є індивідуальними особливостями, що зустрічаються в предметній області.
  • Клас: Класи є узагальненням об'єктів і використовуються для управління складністю, скориставшись їх схожістю в примірників об'єктів і групування в клас або категорію.
  • Підклас/суперклас: Термін «підклас» відображає концепцію групування конкретних екземплярів класу до більш спеціалізованого класу.
  • Розділи: Об'єкт розділів містить об'єкти та зв'язки.
  • Атрибути: Атрибути реалізовують вибір, як представляти стан об'єкту.
  • Стани об'єкту: Стани об'єкту представляють ситуації або умови примірника об'єкту, у сенсі проектування.
  • Методи: Методи є реалізацією поведінки (тобто, набір інструкцій, відповідно до якого об'єкт виконує деяку операцію).
  • Повідомлення та поліморфізм: Об'єкти спілкуються, надсилаючи повідомлення один одному.
  • Подія: Подія — це сигнал, що генерує метод у об'єкті, аби повідомити про певний стан об'єкту.
  • Життєві цикли об'єкту: У будь-якій системі об'єкти представляють паттерни поведінки, як їх цикл між різними станами.
  • Клієнт-сервер: Об'єкти грають роль відношення клієнту до повідомлення, якщо вони є відправниками повідомлення.
  • Взаємозв'язки та ролі: Об'єкти з'єднуються дугою докупи. Ці дуги називаються зв'язками і показують асоціації між об'єктами.
  • Наслідування: Специфічний тип відношення, що використовується у об'єктно-орієнтованій технології, називається наслідування.
  • Інкапсуляція та приховання інформації: Інкапсуляція та приховання інформації є двома об'єктно-орієнтованими концепціями, що допомагають легше зрозуміти, коли та якими даними об'єкти можуть обмінюватись.

Примітки[ред.ред. код]