Картографування між 4 + 1 моделлю архітектурного виду та UML

Я трохи заплутаний у тому, як модель архітектурного виду 4 + 1 відображає UML.

Вікіпедія дає таке відображення:

• Логічний вигляд: Діаграма класів, Діаграма зв'язку, Послідовність діаграм.
• Вид розробки: Діаграма компонентів, Пакетна схема
• Перегляд процесу: Діаграма діяльності
• Фізичний вигляд: схема розгортання
• Сценарії: Діаграма використання

У статті Роль UML Sequence Diagram конструктів в життєвому циклі об'єктів Концепції дає відображення наступного:

• Логічний вигляд (діаграма класів (CD), діаграма об'єктів (OD), діаграма послідовностей (SD), діаграма співпраці (COD), діаграма стану стану (SCD), діаграма активності (AD))
• Перегляд розробки (схема пакета, діаграма компонентів),
• Перегляд процесу (використовуйте діаграму випадку, CD, OD, SD, COD, SCD, AD),
• Фізичний вигляд (схема розгортання) та
• Використовуйте вигляд випадку (використовуйте діаграму випадку, OD, SD, COD, SCD, AD), яка поєднує чотири згадані вище.

Веб-сторінка UML 4 + 1 Перегляд матеріалів представляє таке відображення:

Нарешті, білий документ із застосуванням архітектури 4 + 1 перегляду з UML 2 дає ще одне відображення:

• Діаграми класів логічного перегляду, діаграми об'єктів, діаграми стану та складені структури
• Діаграми послідовності перегляду процесів, діаграми зв'язку, діаграми активності, діаграми хронометражу, діаграми огляду взаємодії
• Діаграми компонентів подання перегляду
• Діаграма розгортання фізичного виду
• Використовуйте вигляд випадку використання діаграми випадку, діаграм діяльності

Я впевнений, що подальший пошук виявить і інші відображення.

Хоча різні люди зазвичай мають різні точки зору, я не бачу, чому це так. Спеціально, кожна діаграма UML описує систему з певного аспекту. Так, наприклад, чому "діаграма послідовностей" розглядається як опис "логічного виду" системи одним автором, тоді як інший автор розглядає це як опис "перегляду процесу"?

Не могли б ви допомогти мені з'ясувати плутанину?

Хоча я загалом погоджуюся з відповіддю Барта ван Інген Шенау , я думаю, що кілька питань потребують додаткового опрацювання.

Перевага моделі перегляду 4 + 1 полягає в тому, що вона відображає зацікавлені сторони до потрібної інформації, не вимагаючи використання конкретних позначень моделювання. Акцент робиться на тому, щоб усі групи мали інформацію, щоб зрозуміти систему та продовжувати виконувати свою роботу.

Модель перегляду 4 + 1 архітектури програмного забезпечення була описана в статті Філіппа Крухтена. Архітектурні креслення - Модель перегляду «4 + 1» архітектури програмного забезпечення, яка була опублікована в програмі IEEE (листопад 1995 р.). У цій публікації немає конкретних посилань на UML. Насправді, у статті використовується позначення Booch для логічного перегляду, розширення до позначення Booch для перегляду процесів та подання розвитку, закликає використовувати "кілька форм" розвитку фізичного перегляду та нове позначення для сценаріїв.

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

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

Перегляд процесу призначений для людей, які проектують всю систему, а потім інтегрують підсистеми або систему в систему систем. Цей огляд показує завдання та процеси, які має система, інтерфейси із зовнішнім світом та / або між компонентами в системі, повідомлення, що надсилаються та отримуються, та спосіб вирішення ефективності, доступності, стійкості до відмов та цілісності.

Погляд на розробку в першу чергу для розробників, які будуватимуть модулі та підсистеми. Він повинен показувати залежності та взаємозв'язки між модулями, організацію, повторне використання та переносимість модулів.

Фізичний вигляд - це насамперед для системних дизайнерів та адміністраторів, які повинні розуміти фізичні місця програмного забезпечення, фізичні зв’язки між вузлами, розгортання та встановлення та масштабованість.

Нарешті, сценарії допомагають охопити вимоги, щоб усі зацікавлені сторони зрозуміли, як передбачається використовувати систему.

Після того, як ви зрозумієте, що має забезпечувати кожен погляд, ви можете вибрати, які нотації моделювання використовувати та на якому рівні деталізації потрібно. Останній абзац Барта особливо вірний - ви можете показувати різні рівні деталей у своїх моделях UML, орієнтуючись на конкретні елементи дизайну або комбінуючи різні типи діаграм у набір. Крім того, ви можете розглянути можливість виходу за межі UML на інші нотації моделювання, щоб краще описати архітектуру системи - моделювання SysML , Entity-Relation або IDEF .

Причина того, що ви не можете знайти відображення «один на один» між видами архітектурної моделі 4 + 1 та різними діаграмами UML, полягає в тому, що такого відображення не існує.

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

Крім того, деякі діаграми UML можна використовувати по-різному, підкреслюючи різні елементи на діаграмі, що робить їх корисними для безлічі представлень. Але навіть якщо один тип діаграми UML може бути використаний у кількох представленнях, ви намалювали іншу діаграму (або набір діаграм) для кожного представлення даних.

Хоча я згоден із підходом відповідей Томаса Оуенса до задоволення потреб ваших кінцевих користувачів, одна річ, яку не можна не згадати, полягає в тому, що причина, чому оригінальне визначення "4 + 1 модельної архітектури" від Крухтена не робить жодної конкретні посилання на UML полягають у тому, що стаття була написана в 1995 році (як йдеться у відповіді), але UML насправді не була прийнята як стандарт до 1997 року .

Постійне використання нотації Booch у статті свідчить про те, що відношення кожної з моделей поглядів до конкретної UML-діаграми може бути доречним, оскільки Grady Booch був одним із людей, що займаються розробкою UML.

Саме через це так багато різних авторів вважають різні діаграми UML застосовними до кожного виду, оскільки кілька діаграм UML можна вважати деякою кількістю "абстракцій" Нотації Буха, що оригінальне визначення моделі 4 + 1 покладається на представляти кожен вид.

Сподіваюсь, що це прояснить дещо більше для всіх, хто в цьому займається.

Ви все ще використовуєте відеомагнітофон, який ви купили ще в 1995 році? 4 + 1 було застосовано ще тоді, коли програмне забезпечення було в дитинстві. Але навіть тоді ніхто ніколи не використовував більше 2 або 3 "поглядів". За останні 20 років інженерія програмного забезпечення змінилася. Нині сфера / контекст та концептуальні та логічні та фізичні та ... всі диференційовані. Багато COTS-рішень мають бути інтегровані тощо. Сьогодні ми говоримо про карти ландшафту, реалізацію послуг та десятки інших поглядів та точок зору. Найкращий спосіб подивитися на це через просту систему таксономії, як Захман: 6 переглядів і 6 точок зору. Нехай це стане вашою відправною точкою. 6 переглядів: контекстна концептуальна чи ділова логічна або системна фізична або технологічна доставка або артефакти, що функціонують на підприємстві

6 точок зору: дані або яка функція або як мережа або де люди або хто час або коли мотивація або чому

Давайте подивимось приклад. Якщо нас цікавлять лише дані, ми почнемо з перегляду сфери та скажемо: "Наша сфера дії є CRM". У концептуальному погляді на точку зору даних ми створимо деяку семантичну модель для CRM. Модель буде концептуальною, концепцією ділової інформації, а не об'єктами даних. Далі в логічному представленні ми створимо логічну модель даних з нашої концептуальної моделі CRM. Ми можемо використовувати методологію ER для створення логічної моделі даних. Тоді на фізичному огляді ми створимо фізичну модель даних. Тут ми визначимо конкретні типи даних для платформи db на наш вибір, індекси тощо. Нарешті, у поданні подачі будемо мати свій скрипт DDL, тоді як у функціонуючому представленні підприємства у нас буде розгорнуто бінарний файл на деякому сервері баз даних і відображено у внутрішніх структурах даних постачальника СУБД. Повторюємо це для кожної точки огляду або стовпця. Крім того, якщо є більше одного учасника, ми створимо більше однієї моделі для кожної точки зору / перегляду. Тепер, коли у вас є така систематика, ви можете визначити власні точки зору та точки зору та вирівняти їх у цю систематику. Наприклад, для ініціатив на рівні підприємства важливі наступні точки зору: поведінка акторів співпраця поведінка додаток співпраця структура застосування програми використання бізнес-функції бізнес-процес реалізація взаємодії бізнес-процесів та розгортання інформаційна структура інфраструктура використання інфраструктури використання ландшафтна карта огляд шаруватого здійснення організаційної послуги тощо Тепер, коли у вас є така систематика, ви можете визначити власні точки зору та точки зору та вирівняти їх у цю систематику. Наприклад, для ініціатив на рівні підприємства важливі наступні точки зору: поведінка акторів співпраця поведінка додаток співпраця структура застосування програми використання бізнес-функції бізнес-процес реалізація взаємодії бізнес-процесів та розгортання інформаційна структура інфраструктура використання інфраструктури використання ландшафтна карта огляд шаруватого здійснення організаційної послуги тощо Тепер, коли у вас є така систематика, ви можете визначити власні точки зору та точки зору та вирівняти їх у цю систематику. Наприклад, для ініціатив на рівні підприємства важливі наступні точки зору: поведінка акторів співпраця поведінка додаток співпраця структура застосування програми використання бізнес-функції бізнес-процес реалізація взаємодії бізнес-процесів та розгортання інформаційна структура інфраструктура використання інфраструктури використання ландшафтна карта огляд шаруватого здійснення організаційної послуги тощо

Крутчен 4 + 1 не міг задовольнити всі ці потреби