Рекомендації щодо структурування моделей за допомогою ПЗ IBM Rational. Частина 2., Комерція, Різне, статті

У статті розповідається про те, як зобразити артефакти моделей IBM Rational Unified Process (RUP) в пакетах IBM Rational Software Modeler , IBM Rational Systems Developer або IBM Rational Software Architect(Далі перераховані продукти узагальнено іменуються “розглянутими продуктами” або просто “програмним забезпеченням, ПО”). Крім того, в статті пропонуються рекомендації по внутрішнім організаційним структурам підмножини цих артефактів. Щоб вам було легше зрозуміти, яким артефактів слід приділити увагу, ми спробуємо пояснити бізнес-цінність кожного конкретного продукту, але в наші завдання НЕ входить:



Розділи цієї статті охоплюють такі теми:



Цільова аудиторія:


Дана стаття (частина 2 серії статей) призначена для фахівців, які цікавляться застосуванням рекомендацій з моделювання класичного процесу Rational Unified Process при роботі в розглянутих продуктах.


Примітка
описуваний RUP-орієнтований, керований прецедентами підхід до організації моделі – не єдиний можливий підхід. В процесі розробки також знаходяться рекомендації щодо структурування моделей для стилю організації моделей керованої бізнесом розробки для SOA (сервіс-орієнтованої архітектури) (іноді званої BDD4SOA) і для керованої моделями розробки систем (Model Driven Systems Development) (RUP for MDSD).


Рекомендації щодо структурування моделей для класичного RUP


Після того, як кілька років тому корпорація IBM придбала компанію Rational Software, Був початий процес адаптації RUP до інших інфраструктур процесів IBM, а також розширення RUP за рахунок рекомендацій для таких технологій, що розвиваються, як SOA і моделювання бізнес-процесів. До цього рекомендації з моделювання, запропоновані уніфікованим процесом Rational (Rational Unified Process) (і отримали розвиток в книгах Террі Кватрані (Terry Quatrani), Джима Коналлена (Jim Conallen), Еріка Нейбурга (Eric Naiburg), Роберта Максимчука (Robert Maksimchuck) та інших), деякий час залишалися досить статичними. У цих рекомендаціях описується набір моделей – моделі прецедентів, моделі аналізу і моделі проектування – представляє собою ретельно продуманий погляд на предметні області проблеми і рішення систем. Даний підхід більшою мірою орієнтований на процес, в якому прецеденти є першими створюваними артефактами моделювання, і допускається використання практично будь-якого типу технічної архітектури. Корисність цього набору моделей була підтверджена багатьма реальними проектами. Тепер ми називаємо такий підхід і стиль моделювання стилем рекомендацій з моделювання “загального” або “класичного” RUP.


Реалізація типів моделей RUP в інструментах UML-моделювання Rational на базі Eclipse


У RUP кожна модель відноситься до певного типу, наприклад, модель UML-прецедентів, модель аналізу або модель даних. У розглянутих продуктах типи UML-моделям насправді не призначаються. Отже, відображення типів моделей RUP на ці продукти є, переважно, питанням низки домовленостей, у тому числі з приводу наступних моментів:



Розглянуті продукти включають кілька шаблонів моделей, які можна використовувати при створенні моделей / ЛЕ. Деякі з таких шаблонів увазі певний тип моделі і принцип організації моделі, які відповідають RUP. Ви зустрічаєтеся з шаблонами при створенні нових моделей / ЛЕ і можете будувати нові моделі за цими шаблонами.


На малюнку 1 показані сторінки майстра створення моделей new model wizard. На знімку екрану зліва можна побачити деякі зі стандартних шаблонів. На правому знімку екрану ми бачимо, що в якості шаблону або відправної точки можна також використовувати власну модель.


Рисунок 1. Майстер New UML Model
 




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


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


Таблиця 1. Часто використовувані типи моделей RUP
































Модель RUP Способи використання в розглянутих продуктах
Модель бізнес-прецеденту Модель / ЛЕ, створена на основі стандартного шаблону Blank Model (Порожня модель) із застосуванням профілю Business Modeling (Бізнес-моделювання). Рекомендується обмежити допустимий контент відповідно з керівництвом RUP для моделі бізнес-прецедентів

Модель / ЛЕ, створена на основі визначається користувачем моделі із застосуванням профілю Business Modeling. Рекомендується обмежити допустимий контент відповідно до керівництва RUP для моделі бізнес-прецедентів

Об’єктна модель бізнесу Модель / ЛЕ, створена на основі стандартного шаблону Blank Model (Порожня модель) із застосуванням профілю Business Modeling (Бізнес-моделювання). Рекомендується обмежити допустимий контент відповідно з керівництвом RUP для Об’єктній моделі бізнесу

Модель / ЛЕ, створена на основі визначається користувачем моделі із застосуванням профілю Business Modeling. Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Об’єктній моделі бізнесу

(Рішення) Модель прецедентів Модель / ЛЕ, створена на основі стандартного шаблону Use-Case Model (Модель прецедентів). Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі прецедентів

Модель / ЛЕ, створена на основі визначається користувачем моделі. Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі прецедентів

Модель / ЛЕ, створена на основі стандартного шаблону Blank Model (Порожня модель). Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі прецедентів

(Рішення) Модель аналізу Модель / ЛЕ, створена на основі стандартного шаблону Analysis Model (Модель аналізу). Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі аналізу.

Модель / ЛЕ, створена на основі визначається користувачем моделі. Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі аналізу.

Модель / ЛЕ, створена на основі стандартного шаблону Blank Model (Порожня модель). Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі аналізу.

Модель / ЛЕ, створена на основі стандартного шаблону моделі Проектування корпоративних інформаційних систем (Enterprise IT Design Model). Рекомендується використовувати пакети <<analysis>>; Містять контент рівня аналізу, обмежений у відповідності з керівництвом RUP для Моделі аналізу

Модель взаємодії з користувачем (User Experience Model) Модель / ЛЕ, створена на основі стандартного шаблону Blank Model (Порожня модель). Рекомендується обмежити допустимий контент моделі відповідно рекомендаціями, що додаються до RUP-конфігурації User Experience Modeling (в складі конфігурації IBM ® Rational ® Method Composer).

Рекомендується використовувати графічні редактори Web Diagram Editor або Java ™ Visual Editor в IBM ® Rational ® Software Architect або IBM ® Rational ® Application Developer.

Модель проектування Для ІТ: модель / ЛЕ, створена на основі стандартного шаблону моделі Проектування корпоративних інформаційних систем (Enterprise IT Design Model). Рекомендується обмежити допустимий контент відповідно до керівництвом RUP для Моделі проектування.

Для ІТ або систем: Модель / ЛЕ, створена на основі стандартного шаблону Blank Model (Порожня модель). Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі проектування.

Для ІТ або систем : Модель / ЛЕ, створена на основі визначається користувачем моделі. Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Моделі проектування.

Модель реалізації В UML не підтримується. Рекомендується використовувати спеціальну функцію моделювання коду для 3GL.

Рекомендується використовувати UML-модель проектування, але при генерації коду застосувати перетворення з опцією заміни UML-елементів “Replace UML elements”, що дозволить зробити модель проектування комбінованої, включає контент рівня реалізації.

Модель розгортання Модель / ЛЕ, створена на основі визначається користувачем моделі. Обмежує допустимий контент відповідно до керівництва RUP для Моделі розгортання.

Модель / ЛЕ, створена на основі стандартного шаблону Blank Model (Порожня модель). Рекомендується обмежити допустимий контент відповідно до керівництва RUP для Об’єктній моделі бізнесу

Модель даних Рекомендується використовувати логічні і фізичні моделі даних в залежності від їхньої підтримки інструментом IBM ® Rational ® Data Architect.


Організація моделей в RUP


У частині 1 ми розповідали про аспекти колективного моделювання та принципах суворої архітектури і монопольного володіння. Ці принципи зберігають своє першорядне значення при використанні стилю моделювання RUP, а й сам стиль додає деякі незалежні аспекти, які теж необхідно враховувати.


Щоб проілюструвати цей момент, давайте знову звернемося до використання базового коду і розглянемо трирівневу архітектуру програми. Ми можемо розбити такий базовий код на модулі за принципом монопольного володіння, виходячи виключно з міркувань, пов’язаних з функціональністю програми. В принципі, саме такий підхід зображений на малюнку 1:рішення розбивається на загальні утиліти і сервіси програми та модулі додатків.


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


RUP пропонує аналогічний набір аспектів, які стосуються організації моделей, але різні артефакти моделей RUP не відповідають рівням архітектури рішення. Вони відповідають різним рівням абстракції, які, можливо, зажадають вираження в процесі розробки. Виявляється, що ініціатива OMG Model-Driven Architectures, MDA (керованої моделями архітектури) має на увазі аналогічну стратифікацію моделей на інших рівнях абстракції. У таблиці 2 наведені приблизні порівняльні характеристики принципів RUP і MDA.


Таблиця 2. Порівняльна характеристика типів моделей RUP і MDA






















Типи моделей RUP Типи моделей MDA Призначення та примітки
Модель бізнес-прецедентів

Модель бізнес-аналізу

CIM (Обчислювально незалежна модель) Для відображення керованих бізнесом вимог і обчислювально-незалежних уявлень рішень.
Модель прецеденту рішення

Модель аналізу рішення

Модель взаємодії з користувачем (User Experience Model)

Логічна модель даних

PIM (платформні-незалежна модель) Для відображення обчислювально-залежних, але незалежних від платформи вимог до вирішення і уявлень рішень.
Модель проектування рішення
PIM або PSM Для відображення або переносних незалежних уявлень проекту рішення, або уявлень, що характеризуються певними аспектами, залежними від конкретної платформи. Модель проектування рішення може еволюціонувати з PIM в PSM природним чином.
Модель реалізації

Фізична модель даних

Модель розгортання

PSM Для відображення платформенно-залежних аспектів проектування рішення.

Так само, як фахівці, які розробляють код реалізації, можуть спеціалізуватися в розробці на стороні клієнта або сервера, Web-розробники можуть мати спеціалізацію в галузі аналізу бізнес-вимог, розробки вимог рішень, аналізу рішень, проектування рішень, проектування інформації і т. д. Проте, при роботі на деталізованому рівні абстракції проекту, вони можуть гостро потребувати в узгодженні структури моделі проектування зі структурою базового коду (особливо в тих випадках, якщо використовується автоматизована генерація коду). У таблиці 3 наводяться рекомендації з приводу того, як можна розставити пріоритети між різними аспектами при плануванні стратегії для практичного моделювання по процесу RUP.


Таблиця 3. Стратегії визначення власників контенту моделі

















Для наступних типів моделей RUP Будуйте стратегію визначення власників, виходячи з наступних міркувань
Модель бізнес-прецеденту

Модель бізнес-аналізу

Виділення спільно використовуваного і загального контенту

Спеціалізовані навички

Бізнес-орієнтоване структурний розбиття проблемної області (наприклад, на підрозділи, робочі потоки, стратегічні ініціативи)

Модель прецеденту рішення

Модель аналізу рішення

Модель взаємодії з користувачем

Модель предметної області (іноді називається також еталонної інформаційної моделлю (Reference Information Model) або логічною моделлю даних (Logical Data Model)

Виділення спільно використовуваного і загального контенту

Спеціалізовані навички

Функціонально-орієнтоване розбиття проблемної області (на додатки, робочі потоки, модулі і т. п.)

Модель проектування рішення

Фізична модель даних

Модель реалізації

Виділення спільно використовуваного і загального контенту

Додаткові принципи побудови стратегії:


  • Якщо колективи розробників характеризуються комплексним набором кваліфікованих кадрів, зосередьтеся на розбитті по функціональності і принципах сильної зчеплення і слабкою пов’язаності.


  • Для колективів розробників з вузькоспеціалізованим набором кваліфікованих кадрів може виявитися необхідним спочатку зосередитися на архітектурних рівнях, обраних технологіях реалізації і т. д., тим самим виконавши ефективну функціональну декомпозицію другорядного аспекту володіння контентом (який, тим не менш, залишається першорядним архітектурним аспектом). У розглянутих продуктах, на відміну від раніше випускалися продуктів Rational для моделювання, модель реалізації складається з базового коду і діаграм коду.
Модель розгортання Узгодження з Моделлю проектування

Узгодження з правами володіння ресурсами інфраструктури (машинами, мережами і т. п.)


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


У RUP-орієнтованих процесах моделювання існує тенденція до сильної взаємозв’язку між структурою Моделей прецедентів і Моделей аналізу (щонайменше, на ранніх стадіях процесу), оскільки RUP передбачає цілком автоматизований процес завантаження контента в Модель аналізу на основі контенту Моделі прецеденту. Таким чином, щоб завантажити контент в Модель аналізу, використовуйте наступні артефакти:



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



Способи узгодження: в цьому випадку не забезпечується підтримка монопольного володіння прецедентом бізнес-аналітиком і монопольного володіння контентом аналізу системним аналітиком або розробником архітектури програмного забезпечення. Значить, вам, можливо, доведеться прийняти рішення про об’єднання контента прецеденту та аналізу за допомогою ряду ітерацій до отримання стабільної структури, а потім реорганізувати контент аналізу в окрему модель / ЛЕ (зі структурою, яка відображає структуру Моделі прецеденту), щоб зробити можливим монопольне володіння з боку розробника архітектури програмного забезпечення. Надалі можна перемістити контент аналізу в окрему модель / ЛЕ, структур пакета якій буде відображати структуру контенту прецеденту.


Переваги та способи узгодження моделей RUP


У частині 1 ми радили: “Ось найкраща рекомендація з моделювання – моделюйте тільки те, що має очевидну цінність для бізнесу”. У цій статті ми побачили, що RUP пропонує досить багато різних типів моделей, що представляють різні аспекти і рівні абстракції предметних областей проблеми і передбачуваного рішення. Ці типи запропоновані тому, що вони забезпечили додавання економічної цінності, по меншій мірі, в деяких ситуаціях. Перед ними постають наступні питання: “Чи забезпечить кожен з них додавання економічної цінності у всіх ситуаціях?” Відповідь “немає.”


З першого питання випливає другий :: “Як визначити, що виявиться корисним в конкретній ситуації?” На це питання можна відповісти з усією визначеністю. Хоча в цій статті не передбачається обговорення цінності моделювання взагалі і цінності кожної моделі RUP зокрема, ми спробуємо пролити світло на те, коли слід використовувати певні типи моделей RUP. У таблиці 4 вказані: потенційні цінні сторони кожного типу моделі RUP, витрати на створення і обслуговування, а також вказівки з приводу того, які варіанти можна використовувати в якості альтернативи. Як правило, описи додається бізнес- цінності досить зрозумілі, але важливо враховувати, що трассируемого являє собою бізнес-цінність, щонайменше, для двох різних напрямків:


Таблиця 4. Переваги, способи узгодження і альтернативи для різних моделей RUP






































Тип моделі RUP Переваги, способи узгодження і альтернативи
Модель бізнес-прецедентів Переваги:

  • забезпечує краще розуміння бізнес-проблем, вимог і потенційних можливостей вдосконалення;
  • сприяє більш ефективному обговорення бізнес-проблем і потенційних рішень з зацікавленими особами в даному напрямку бізнесу і в інших напрямках;
  • може забезпечувати спадну трассируемого (наприклад, до вимог у репозиторії, Моделі бізнес-аналізу або до вимог і моделі).

Способи узгодження:



  • розробка та обслуговування моделі;
  • можливо, синхронізація контенту моделі бізнес-прецеденту з спадними вимогами або моделями;
  • можливе створення і обслуговування взаємозв’язків низхідній трассируемого.

Альтернативи:



  • бізнес-документи (звіти, презентації);
  • моделі бізнес-процесів.
Модель бізнес-аналізу Переваги:

  • забезпечує краще розуміння вимог, характеристик і вартості бізнес-рішень;
  • можливо, спадна трассируемого (до вимог у репозиторії і моделі прецедентів рішення).

Способи узгодження:



  • розробка та обслуговування моделі;
  • можливо, синхронізація моделі бізнес-аналізу з висхідними і спадними вимогами і моделями;
  • можливе створення і обслуговування взаємозв’язків трассируемого.

Альтернативи:



  • бізнес-документи (звіти, презентації);
  • моделі бізнес-процесів.
Модель прецеденту рішення Переваги:

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

Способи узгодження:



  • розробка та обслуговування моделі;
  • можливо, синхронізація контенту моделі прецедентів рішення з висхідними (наприклад, моделлю бізнес-аналізу) і спадними моделями (наприклад, Моделлю аналізу рішення);
  • можливо, створення і обслуговування узгоджувальних елементів висхідній і низхідній або латеральної трассируемого;
  • можливо, розробка користувацького інструментарію.

Альтернативи:



  • документи специфікації;
  • прототипи.
Модель аналізу рішення Переваги:

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

Способи узгодження:



  • розробка та обслуговування моделі;
  • можливо, синхронізація з висхідними (наприклад, Моделлю прецедентів) і спадними моделями (наприклад, Моделлю реалізації або Моделлю проектування);
  • можливо, створення і обслуговування узгоджувальних елементів низхідній трассируемого;
  • можливо, розробка користувацького інструментарію.

Альтернативи:



  • документи специфікації;
  • прототипи.
Модель взаємодії з користувачем Переваги:

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

Способи узгодження:



  • проектування, розробка та обслуговування стилю моделювання взаємодії з користувачем і (ймовірно) UML-профілю;
  • розробка та обслуговування Моделі взаємодії з користувачем;
  • можливо, синхронізація контенту моделі прецедентів рішення з висхідними (наприклад, Моделлю бізнес-аналізу) і спадними (наприклад, Моделлю аналізу рішення) моделями;
  • можливо, створення і обслуговування узгоджувальних елементів висхідній і низхідній або латеральної трассируемого;
  • можливо, розробка користувацького інструментарію.

Альтернативи:



  • документи специфікації;
  • схеми взаємодії з користувачем (інструментарій бізнес-партнерів Rational);
  • прототипи.
Модель предметної області (іноді називається також еталонної інформаційної моделлю (Reference Information Model) або логічною моделлю даних (Logical Data Model) Переваги:

  • забезпечує краще розуміння предметної області реального бізнесу;
  • надає навчальні посібники для інформування про предметну область бізнесу;
  • підвищує ефективність проектів баз даних;
  • можливо, спадна трассируемого (наприклад, до Моделі аналізу або Моделі проектування рішення);
  • можливо, завантаження контента в спадні моделі, такі, як Моделі аналізу чи проектування рішення (тягне за собою розробку користувальницького інструментарію);
  • можливо, завантаження контента в Логічні моделі даних (за допомогою інструментів Rational Data Architect) з моделей предметної області (або навпаки);
  • сприяє більш ефективному доведенню бізнес-проблем і потенційних рішень до відома зацікавлених осіб в даному напрямку бізнесу і в інших напрямках;
  • ефективне обговорення проблем узгодження та інтеграції інформації, підтримка робіт з розробки даних.

Способи узгодження:



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

Альтернативи:


Документи специфікації

Модель проектування рішення Переваги:

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

Способи узгодження:



  • розробка та обслуговування моделі;
  • можливо, синхронізація з висхідними моделями або вимогами;
  • можливо, синхронізація з моделями коду;
  • можливо, створення і обслуговування узгоджувальних елементів низхідній трассируемого;
  • можливо, розробка користувацького інструментарію.

Альтернативи:



  • документи специфікації;
  • прототипи;
  • моделі коду та код.
Фізична модель даних Переваги:

надає графічні (діаграмні) режими дослідження та перевірки реалізації рішення і допомогу в розумінні даної реалізації (що особливо цінно в фазі супроводу і при зміні співробітників).


Способи узгодження:


обслуговування діаграм.

Модель реалізації рішення Переваги:

надає графічні (діаграмні) режими дослідження та перевірки реалізації рішення і допомогу в розумінні даної реалізації (що особливо цінно в фазі супроводу і при зміні співробітників).


Способи узгодження:


обслуговування діаграм (хоча оглядові (Browse) діаграми можуть надати більше користі і не вимагають обслуговування).

Модель розгортання рішення Переваги:

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


Способи узгодження:


обслуговування моделей

Всі типи моделей Переваги:

забезпечує більш ефективну взаємодію з різними зацікавленими в проекті особами;


служить основою для інфраструктур управління рішенням;


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


Рекомендації по внутрішній організації моделі прецедентів RUP


У розглянутих продуктах надається можливість створення нової моделі / ЛЕ на основі шаблону моделі прецедентів. (Ви можете також створити для користувача модель / ЛЕ і використовувати її як шаблон).


Стандартний шаблон Моделі прецедентів (Use-Case Model)


Ці шаблони можуть визначати специфічне підмножина засобів UML, які зазвичай використовуються при моделюванні прецедентів (іншими словами, при роботі з моделями на основі шаблонів палітри для малювання і розкриваються меню будуть містити лише ті UML-елементи, які зазвичай використовуються фахівцями з моделювання прецедентів). Шаблони також надають набір контенту за замовчуванням, як показано на малюнку 2. У даній статті ми не будемо пояснювати, як використовувати контент компонувальних блоків прецедентів та пошукові рядки, але ви можете знайти докладні інструкції в примітках до шаблонів.


Рисунок 2. Контент за замовчуванням шаблону моделі прецедентів в розглянутих продуктах

Цей шаблон в якості основи організації моделі використовує метод логічного розбиття функціональності. (Це проявляється у використанні шаблону пакета ${functional.area} в якості основного компоновочного блоку моделі прецеденту.) На малюнку 3 зображено типовий приклад такого типу організації моделі прецеденту.


Рисунок 3. Приклад моделі прецеденту, організованої відповідно до методу розбиття функціональності

Як уже говорилося в розділі про організації моделей в RUP, Це не єдиний можливий підхід до логічного розбиття. Він був обраний для використання з даними шаблоном з наступних причин:




Даний шаблон також передбачає використання одного з нижчеперелічених організаційних методів:









 



Міграція між Rational XDE і Rational Rose

Рекомендації щодо структурування моделі прецеденту в чомусь є переглядом ранніх рекомендацій для RUP, які полягали в створенні двох пакетів верхнього рівня – одного для Діячів (Акторів) і ще одного – для прецедентів. Потім, коли цього зажадає зростаюча складність і збільшується розмір моделі, ми будемо використовувати пакети нижчого рівня для створення орієнтованих на функції угруповань, як показано в прикладі з використанням XDE, який представлений на малюнку 4.


Рисунок 4. Приклад з використанням XDE (згідно урізанні)

Контент Моделі прецеденту


У даній статті ми не пропонуємо докладний навчальний посібник про те, як створювати хороші прецеденти, або про те, що слід і що не слід робити, щоб ефективно використовувати прецеденти. Тим не менш, ми коротко розповімо, що слід включати в модель прецедентів крім Діячів і Прецедентів.


Рекомендуємо: створіть в корені моделі Main-діаграму, яка зображує інші пакети моделі і підтримуючу аналіз таких пакетів і відповідних їм Main-діаграм.


Рекомендуємо: в кожен пакет прецеденту дозволите діаграму, яка зображує прецеденти пакета, будь-які стосунки між ними і Діячів (Actor), які в них беруть участь. Якщо кількість прецедентів достатньо велика, може знадобитися більше однієї діаграми.


Рекомендуємо: опишіть основний і альтернативний потік кожного прецеденту в поле Documentation, як показано на малюнку 5. (Форматування в прикладі було виконано шляхом створення текстового шаблону для опису прецеденту з використанням редактора RTF (rich text format, розширений текстовий формат) з наступним копіюванням і вставкою цього шаблону в поле Description для прецеденту).


Рисунок 5. Документування описів потоку прецеденту у властивості прецеденту Documentation

Бажано: якщо це виправдовується складністю прецеденту, додайте діаграму діяльності та скомпонуйте її таким чином, щоб вона відображала загальні потоки діяльності даного прецеденту (див. малюнок 6). Обгрунтування: Це допоможе відобразити умови, що відповідають кожному потоку (основному (Main), альтернативного (Alternative) або особливому (Exceptional) і гарантувати, що всі ці потоки в кінці кінців зіллються. (В семантичному сенсі результатом додавання діаграми діяльності буде додавання елемента Діяльність, що належить елементу Прецедент, з діаграмою в складі цієї діяльності).


Бажано: створити модель реалізації по типу “чорної скриньки” для кожного з іменованих потоків (Main, Alternative і Exceptional) даного прецеденту.








 



Міграція між Rational XDE і Rational Rose

В UML 1 для цієї мети ми використовували б примірник Кооперації, а не Нечітке Поведінка.


Екземпляри нечіткого поведінки не слід плутати з реалізацією прецедентів на рівні проекту або аналізу, про які піде мова в наступних розділах. Останні є реалізації прецедентів по типу “білого ящика” і описують взаємодії між внутрішніми елементами рішення. Пропоновані тут елементи Нечітке поведінка (див. рисунок 6) є виключно взаємодіями по типу “чорного ящика “між діячами та системою. Вони надають для далеких від техніки зацікавлених осіб високорівневу картину взаємодії користувачів із системою. Нечітке поведінка може допомогти визначити, які уявлення (вікна або сторінки) знадобляться в даній реалізації. Вони також формально встановлюють правила присвоювання імен різним потокам (сценаріями) прецеденту шляхом призначення відповідних імен семантичним елементам моделі (елементам Нечітке Поведінка).



Бажано: якщо ви використовуєте рекомендації RUP для ідентифікації архітектурно значущих уявлень архітектури і, особливо, якщо ви плануєте вести документ Software Architecture Document, додайте пакет верхнього рівня <<perspective>> , Який буде містити діаграми прецеденту, що зображують архітектурно значимі прецеденти. Можливо, ви захочете дати цьому пакету ім’я Use-Case View of Architecture (Уявлення архітектури для прецеденту). В якості альтернативи ви можете включити цей пакет в Модель огляду архітектури.

Рекомендації по внутрішній організації Моделі аналізу RUP


Модель аналізу являє собою перше наближення до вирішення. Це допоміжний засіб, який використовується, головним чином, для документування інформації про предметну область бізнесу, демонструє передбачувані елементи рішення на високому (близькому до бізнесу) рівні абстракції і, тим самим, допомагає перейти від вимог до остаточного проекту. Саме тут ми використовуємо класи аналізу і реалізації прецедентів на аналітичному рівні. Саме через процес моделювання реалізацій прецедентів (головним чином, за допомогою Діаграми послідовності) приходить розуміння того, які класи реального проекту необхідні для вирішення. Якщо говорити конкретно, це будуть класи, відповідні життєво важливим лініях, які, відповідно до нашого розуміння, необхідні на діаграмах послідовності. Існує також кілька практичних правил (загальних рекомендацій), які можна застосувати, щоб створити контент Моделі аналізу на основі контенту Моделі прецеденту. (Далі ми коротко розповімо про це.)


У RUP рішення з приводу того, чи повинна Модель аналізу вестися незалежно від Моделі проектування, є специфічним для конкретного проекту. Це рішення приймається з урахуванням ваших припущень щодо того, чи виправдає ведення окремої Моделі аналізу витрачений на неї час. Можна мати на увазі кілька варіантів:



  1. Як уже говорилося в розділі про організації моделей в RUP, На ранніх фазах проекту, коли контент ще відрізняється високою нестабільністю (або на будь-якому етапі, якщо створення моделі аналізу і моделі прецеденту виконується одними і тими ж фахівцями), зберігайте контент аналізу в тій же моделі / ЛЕ, що й Модель прецеденту. Застосовуйте до моделей профіль RUPAnalysis і використовуйте пакети з ключовим словом <<analysis>> для поділу контента Моделі аналізу та контенту Моделі прецеденту Надалі ви зможете отримати контент аналітичного рівня в окрему модель / ЛЕ, якою можна буде управляти будь-яким з описаних тут способів.
  2. Створіть Модель аналізу незалежно від Моделі прецеденту (вона повинна розміщуватися в окремій логічної моделі, побудованої на основі шаблону Моделі аналізу). Потім вручну або за допомогою перетворень типу модель-модель створіть уточнені версії елементів аналізу в окремій Моделі проектування. Завдяки цьому у вас буде можливість продовжити ведення окремої Моделі аналізу або відмовитися від неї.
  3. Виконайте ті ж дії, але потім просто дозвольте Моделі аналізу еволюціонувати в Модель проектування природним чином. (Треба сказати, що в RUP згадується можливість створення класів аналізу і реалізацій прецеденту на аналітичному рівні в Моделі проектування, а потім розвитку їх безпосередньо в їх проектних формах, починаючи з цього моменту). В цьому випадку ви починаєте моделювання з реалізації прецедентів з використанням класів аналізу, а потім, через деякий час, уточнюєте їх, щоб справжні інтерфейси проекту придбали форму ролей в модельованих поведениях.
  4. Поєднання першого і другого варіанту можна використовувати для обслуговування свого роду Моделі аналізу в тій же моделі, що й Модель проектування. Якщо використовується цей підхід, то, в процесі створення Моделі проектування створюються пакети, в яких зберігаються деякі чисто аналітичні перспективи. З цією метою аналітичний контент виділяється в пакети, до яких застосовується ключове слово <<analysis>>.

Стандартний шаблон Моделі аналізу


У розглянутих продуктах надається можливість створення нової моделі / ЛЕ на основі шаблону Моделі аналізу. (Ви можете також створити для користувача модель / ЛЕ і використовувати її як шаблон). Шаблони можуть визначати специфічне підмножина засобів UML, які зазвичай використовуються при виконанні моделювання аналізу. Тобто, при роботі з моделями на основі шаблонів палітри для малювання і розкриваються меню будуть містити лише ті UML-“елементи, які використовуються фахівцями зі створення моделей аналізу.


Крім того, до моделей / ЛЕ, створеним на основі таких шаблонів, застосовується профіль RUPAnalysis, а шаблони надають набір контенту за замовчуванням, як показано на малюнку 7. (В даній статті ми не будемо пояснювати, як використовувати контент компонувальних блоків аналізу та пошукові рядки, але в примітки, які є в самих шаблонах, такі інструкції присутні.)


Малюнок 7. Контент за замовчуванням шаблону Моделі аналізу в розглянутих продуктах

Як і шаблон Моделі прецеденту, шаблон Моделі аналізу віддає перевагу використанню логічного розбиття функціональності як метод побудови структури моделі. (Це проявляється у використанні шаблона пакета ${functional.area} в якості основного компоновочного блоку моделі прецеденту.) На малюнку 8 зображений звичайний приклад такого типу структури Моделі аналізу, обумовлений зазначеним перевагою.


Рисунок 8. Приклад високорівневої організації Моделі аналізу

Як уже говорилося в розділі про організації моделей в RUP, Це не єдиний можливий підхід до логічного розбиття. Він був обраний для використання з даними шаблоном з наступних причин:



Даний шаблон також передбачає використання нижчеперелічених організаційних методів:



На малюнку 8 проілюстровані деякі методи структурування Моделі аналізу на основі загального підходу, обумовленого використанням шаблону Моделі аналізу. Варіант цього підходу зображений далі по тексту на малюнку 9. (Малюнок був зроблений за 6 версії розглянутих продуктів, у яких в браузері проектів Project Explorer використовуються інші значки. Різниця між описаними варіантами полягає в тому, що в останньому з них пакет верхнього рівня використовувався для відділення реалізацій прецедентів від класів аналізу. У цьому пакеті верхнього рівня ми бачимо набір подпакетах, відповідних орієнтованим на функції пакетам верхнього рівня. Потенційне перевага такої ізоляції реалізацій прецедентів полягає в тому, що вона допускає реорганізацію структури пакетів верхнього рівня, не впливаючи на структуру реалізацій прецедентів. Це може мати сенс (Особливо якщо Модель аналізу еволюціонує в Модель проектування природним чином) з тієї причини, що структура пакетів для класів, ймовірно, буде мати потребу в розвитку, щоб не збiгатися з структурою, яка спочатку була обрана для прецедентів.)


Малюнок 9. Варіанти високорівневої організації Моделі аналізу

В залежності від конкретної ситуації можуть знайтися причини для використання будь-якої угоди про призначення імен, яке полегшить злиття і повторне використання контенту моделей, створених кількома робочими групами, навіть групами з інших (партнерських) компаній. Якщо це має значення, подумайте про використання зворотного угоди про простір доменних імен, як на малюнку 10 (цей малюнок також створений по 6 версії розглянутих продуктів). Зверніть увагу, що це не має великого значення власне для моделювання аналізу, але якщо ви використовуєте підхід, що дозволяє Моделі аналізу природним чином еволюціонувати в Модель проектування, і заохочуєте багаторазове використання або бізнес-інтеграцію на рівні проекту, можливо, ви захочете заздалегідь спланувати це подібним чином. У цього підходу є ще одна перевага: оскільки він може добре відображатися на структуру коду, згенерованого з моделей аналізу і проектування, він може спростити подальшу настройку конфігурації перетворення типу “модель-текст (код)”.


Малюнок 10. Приклад використання угоди про інвертованому просторі доменних імен Інтернет

Контент Моделі аналізу


З’ясувати, які класи аналізу необхідні, можна кількома способами. Один із способів – почати зі створення Діаграми послідовності, яка будується на реалізаціях прецедентів. В процесі створення діаграми ви зрозумієте, які опорні лінії вам знадобляться. Як правило, кожен напрям є передбачуваний клас аналізу. Визначивши таким чином, які класи необхідні, ви можете створити їх в пакетах реалізації прецедентів Моделі аналізу, але не залишити в них (наприклад, ви можете перенести їх у пакети, орієнтовані на функції, як показано на попередніх малюнках).


Ще один спосіб визначення необхідних класів аналізу: Створіть в Моделі аналізу класи у відповідності з наступними рекомендаціями:






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


Рекомендуємо: модель аналізу повинна містити реалізації прецедентів рівня аналізу, які описують, як виконуються прецеденти в сенсі кооперацій класів аналізу. Кожна реалізація прецеденту (представлена ​​UML-кооперацією) відповідає UML-прецеденту в Моделі прецеденту. Ймовірно, вона повинна мати те ж ім’я, що й даний Прецедент, а також бути похідною або перебувати у відношенні реалізації до прецеденту (див. малюнок8 ).


Рекомендуємо: для будь-якого іменованого потоку прецедентів (заданого раніше в Моделі прецедентів), який, на вашу думку, необхідно моделювати як реалізацію на рівні аналізу, додайте в Кооперацію Діаграму послідовності, яка буде відображати реалізацію цього потоку. Це викличе автоматичне додавання UML-Взаємодії як сутності, що володіє даної діаграми послідовності. Див. малюнок 11. (На малюнку 11 зверніть увагу на те, що деякі параметри Preferences налаштовані таким чином, щоб більша частина семантичного UML-контенту типу властивостей піддавалася фільтрації. За умовчанням цей контент відображається в браузері проектів Project Explorer. Можливо, ви захочете налаштувати параметри Preference, щоб подання виглядало так само.).


Малюнок 11. Кооперації (реалізації прецедентів), які володіють діаграмами послідовності.

Пропонуємо: після того, як ви створили Діаграму послідовності для потоку прецедентів, ви можете виділити Взаємодія, якому вона належить в браузері проектів Project Explorer, і додати до нього Діаграму комунікації. У нову Діаграму комунікації будуть автоматично завантажені екземпляри класів аналізу, які є на Діаграмі послідовності.


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



  1. додайте в Кооперацію діаграму довільної форми;
  2. перетягніть на цю діаграму за допомогою миші елемент Кооперація;
  3. перетягніть на неї також прецедент (можливо, з іншої моделі);
  4. створіть відношення залежності;
  5. і, нарешті, в браузері проектів Project Explorer, видаліть діаграму з Кооперації.

Пропонуємо: включіть в кожну реалізацію прецеденту Діаграму учасників, яка буде показувати, які класи аналізу беруть участь у даній реалізації (тобто, екземпляри класів аналізу, які відображаються на діаграмах взаємодії, що описують реалізацію прецеденту) і відносини між цими класами, що підтримують кооперацію, описувану діаграмами взаємодії. Ця діаграма може містити класи сутностей і класи об’єктів передачі даних. Див. малюнок 12.


Малюнок 12. Приклад Діаграми учасників реалізації прецеденту

Рекомендації по внутрішній організації моделей проектування RUP


У розглянутих продуктах надається можливість створення нової моделі / ЛЕ на основі шаблонів Моделі проектування. Це ті шаблони, які можна використовувати для проектування (а, можливо, і для аналізу) при виборі бізнес-додатків. (Можна також створити для користувача модель / ЛЕ і використовувати її як шаблон).


Стандартний шаблон Проектування корпоративних інформаційних систем (Enterprise IT Design Model)


Ці шаблони можуть визначати специфічне підмножина засобів UML, які зазвичай використовуються при моделюванні проектування (іншими словами, при роботі з моделями на основі цього шаблону палітри для малювання та розкривних меню будуть містити лише ті UML-елементи, які зазвичай використовуються фахівцями з проектування). Крім того, ™ до моделей / ЛЕ, створюваним з цих шаблонів, застосовується профіль перетворення Enterprise Java Beans (EJB) і завантажується контент за замовчуванням з даних шаблонів (див. малюнок 13). У даній статті ми не будемо пояснювати, як використовувати контент компонувальних блоків прецедентів та пошукові рядки, але ви знайдете докладні інструкції в примітках, які є в шаблонах. .


Малюнок 13. Контент за замовчуванням шаблону Моделі проектування корпоративних інформаційних систем в розглянутих продуктах

Як уже говорилося раніше в розділі “Організація моделей в RUP”, Описані тут підходи – не єдині, які варто розглянути. Наприклад, характер спеціалізації трудових ресурсів в ваших колективах розробників може говорити про те, що при виборі принципу організації моделі слід більшою мірою спиратися на архітектурні рівні (і в меншій мірі – на функціональну декомпозицію).


На малюнку 14 показані методи структурування моделей проектування, засновані на загальному принципі, який диктується шаблоном Моделі проектування корпоративних інформаційних систем (Enterprise IT Design Model).


Малюнок 14. Організація Моделі проектування на високому рівні

Це такі методи і варіанти:



  1. Відокремте специфікації від проектів реалізації (типу інтерфейсів і підтримуваних патернів взаємодій). На ілюстрації показано використання пакетів верхнього рівня Угоди проекту та Проекти реалізації в якості одного із способів реалізації. Альтернативою описаному методу буде розміщення специфікацій і проектів реалізацій в окремих моделях / ЛЕ.
  2. Використовуйте пакети низлежащих рівнів для створення орієнтованих на функції угруповань.
  3. В пакетах, які об’єднують семантичні елементи моделі, додайте діаграми, які описують специфічні для даної угруповання уявлення, але не відображають елементи за її межами. Ця рекомендація підходить незалежно від того, на чому будується угруповання – на функціонально орієнтованих подмножествах предметної області бізнесу, архітектурних рівнях або на чому-небудь ще. Дайте діаграмі за замовчуванням ім’я, відповідне імені пакета або компонента і скомпонуйте її таким чином, щоб вона представляла огляд контенту даного пакета. Завдяки цьому деякі діаграми будуть ближче до тих моментів, які вони відображають, що спростить навігацію по моделі і її розуміння.
  4. Подумайте про використання інвертованого простору доменних імен Інтернету в Моделі проектування. Підстави:

    1. (В принципі, це ті ж підстави, за якими застосування описаних методів важливо для залежних від мови реалізацій):

      • сценарії, пов’язані з роботою з інтеграції, при яких використовується кілька керованих моделями додатків (особливо з партнерськими компаніями);
      • сценарії з багаторазовим використанням.

    2. Ймовірно, це спростить подальшу конфігурацію перетворень для реалізації (відображення імен та розміщень вихідної моделі на цільову).


  1. Щоб уникнути ускладнень і можливої ​​плутанини у відображенні просторів імен

    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *