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

Основні поняття і термінологія


Читачам, яким доводилося працювати з Eclipse, IBM Rational Application Developer або продуктами IBM WebSphere (попередниками Rational Application Developer) вже знайомі деякі терміни, що використовуються в даній статті.


Робочі області, проекти і типи проектів


Можливо, ви вже знаєте, що в Eclipse файли розміщуються в проектах, ці проекти можуть бути різних типів (або, в термінології Eclipse, проекти мають характер (natures)), а також угрупування і управління проектами відбувається робочих областях. Завдання нашої статті не припускають докладного опису всіх типів проектів, доступних в Rational Application Developer, і всіх інструментів Rational для UML-моделювання на базі Eclipse. Нас, в основному, цікавлять дві категорії проектів:


  • UML-проекти, Що представляють собою базові проекти, що містять UML-моделі;


  • проекти реалізації, Які містять спеціалізовані типи проектів, а саме: проект корпоративного додатки (Enterprise Project), проект корпоративного bean-компонента Java (EJB) (Enterprise Java Beans Project), Web-проект (Web project), Java-проект (Java Project) і проект C + + (C + + Project)

Моделі


Уніфікований процес IBM Rational (IBM Rational Unified Process, RUP) визначає модель як “завершену специфікацію предметної області проблеми або рішення з конкретної точки зору”. Предметна область проблеми або система можуть бути описані кількома моделями, які представляють різні точки зору на цю предметну область або систему. Наприклад, традиційне керівництво по процесу RUP пропонує конкретний набір UML-моделей:



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

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


В контексті досліджуваних продуктів моделі бувають двох загальних типів: концептуальні та конкретні.



  • Концептуальні моделі є ідеї і маніпулюють ідеями. Відмінним прикладом можуть служити типові UML-моделі. Концептуальні моделі не мають автоматизованої прив’язки до виконуваної реалізації. Примітка: існують продукти, наприклад, IBM Rational Rose RealTime, які підтримують виконання, налагодження і тестування UML-моделей в середовищі виконання, призначеної для цієї мети. Такі UML-моделі слід вважати конкретними.
  • Конкретні моделі є спосіб графічного зображення і прямого маніпулювання артефактами реалізації, які можуть бути автоматично перетворені в виконуваний файл. Характерні приклади – Java-моделі і C + +-моделі. Конкретні моделі іноді називають просто моделями коду, якщо в їх основі лежить семантика мов 3GL. Ще один клас конкретних моделей будується на декларативних мовах. Характерний приклад – фізичні моделі даних, які безпосередньо оперують мовою визначення даних (Data Definition Language) SQL.

У розглянутих продуктах ми взаємодіємо з моделями, в основному, через діаграми і панель оглядача проектів Eclipse Project Explorer.


Примітка
Різниця між концептуальними і конкретними моделями та відмінність, яка керована моделями архітектура (Model Driven Architecture, MDA) Object Management Group (OMG) проводить між платформенно-залежними і переносних незалежними моделями – це не одне і те ж. Модель може бути платформенно-залежної і в той же час концептуальної.


Файли моделей (механізми зберігання для моделей)


Розглянуті продукти зберігають моделі у вигляді файлів. В Eclipse файл вважається видом ресурсу. Ресурси в середовищі Eclipse можуть володіти додатковими властивостями і поведінкою, отже, поняття ресурс ширше, ніж файл. Описувані тут файли моделювання реалізовані у вигляді ресурсів Eclipse. Отже, терміни ресурс моделювання та файл моделювання тут і в інших матеріалах позначають одне і те ж.


У більш широкому сенсі програмне забезпечення підтримує два види файлів моделювання:



  • файли концептуальної UML-моделі зберігаються в проектах Eclipse і мають розширення імені файлу. emx і. efx (про відмінності між цими типами файлів ми поговоримо пізніше). Перераховані файли містять два види контенту:

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


  • файли конкретного моделювання (наприклад, Java, C + +, DDL) також зберігаються в проектах Eclipse в робочій області Eclipse і містять комбінацію семантичної і нотаціонной інформації, але в цьому випадку семантичне і нотаціонное вміст більш чітко розділяються:

    • семантичні елементи конкретної моделі зберігаються в артефактах реалізації. Наприклад, для Java семантична модель серіалізуются і зберігається у вигляді колекції фото вихідного коду Java. (Коли ми запускаємо інструмент, семантична модель розміщується в пам’яті як абстрактне синтаксичне дерево Java);
    • кожна діаграма зберігається в окремому файлі. Файли діаграм можуть мати різні розширення, але найчастіше використовується розширення. Dnx. Діаграми конкретного моделювання можуть використовувати як нотацію UML, так і інші нотації (наприклад, IDEF1X, нотації інформаційної інженерії для візуалізації даних або фірмові нотації IBM, які використовуються для проектування Web-шарів).

Наші рекомендації щодо структурування моделей стосуються, в основному, структурування артефактів і контента концептуальних моделей. Рекомендації щодо організації контенту конкретних моделей (тобто, проектів реалізації) можна знайти в інших джерелах, наприклад в довідці (Help) в Rational Software Architect, Rational Application Developer, і Eclipse. До деякої міри організація конкретних моделей визначається угодою про типи проектів Eclipse. Тим не менш, загальні принципи, що відносяться до логічної організації рішень і розглядаються в розділі “Питання колективної розробки та управління моделями” цієї статті, застосовні і концептуальним моделям, і до артефактів реалізацій.


У розглянутих продуктах ми взаємодіємо з файлами моделювання, головним чином, через панель оглядача проектів Eclipse Project Explorer.


Файли UML-моделі: логічні одиниці і фрагменти


Іноді UML-моделі стають настільки великими, що виникає необхідність їх зберігання у вигляді менших за розміром частин. Крім того, коли колективи фахівців з моделювання спільно працюють над контентом моделі з високим ступенем взаємозв’язку, необхідно управляти проблемами суперечностей і володіння. Для цього розглядаються продукти надають два шляхи розбиття логічного контенту UML-моделі на фізичні контейнери зберігання:



  • логічні одиниці (Logical Units);
  • фрагменти (Fragments).

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


  • В інтерфейсі програми логічна одиниця (ЛЕ) називається UML Model (UML-модель). Отже, коли ми вибираємо в меню команди New > UML Model, Насправді ми створюємо ЛЕ.


  • UML-модель (а отже, ЛЕ) являє собою найменшу одиницю UML-контенту, яку можна “відкрити” і “закрити” за допомогою команд в меню File і в меню браузера проектів Project Explorer. (Існує можливість відкрити фрагмент (Fragment), вибравши його в поданні Navigator, але в результаті цієї дії все одно відкривається ЛЕ, що містить цей фрагмент.)


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

    • набір UML-функцій, які задіяні при роботі з ЛЕ;
    • UML-профілі, що застосовуються до ЛЕ.


  • ЛЕ існує у вигляді файлу з розширенням. Emx (див. малюнок 1).


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


  • UML-модель (ЛЕ) в поданні Project Explorer завжди відображається як конструкція верхнього рівня. Іншими словами, в поточному інтерфейсі Rational логічні одиниці не можна наочно впорядкувати в довільні логічні структурні ієрархії. Існує можливість створити довільні структурні ієрархії в чистому вигляді за допомогою відносин <<ElementImport>> і <<PackageImport>>. Однак це як і раніше не відбивається на зображенні ієрархій в Project Explorer, в яких UML-модель/ЛЕ завжди є елементом самого верхнього рівня.

Крім того, програма підтримує концепцію фрагментів моделі, що мають такі властивості:


  • фрагмент зберігається у файлі з розширенням. efx;


  • хоча фрагмент існує самостійно, в сенсі логічних структур зберігання і простору імен він повністю залежить від ЛЕ, якій належить;


  • іншими словами, як і ЛЄ, фрагмент може містити довільне підмножина логічної моделі;


  • на відміну від ЛЕ, фрагмент не обов’язково визначає логічну структуру зберігання або простір імен. По суті, фрагмент можна визначити на рівні UML-класифікатора або діаграми. Наприклад, фрагмент може включати тільки один клас, одну діяльність або один компонент, але він також може бути визначений на рівні пакета, і в цьому випадку він співвідноситься з простором імен і може містити інші елементи. Але і в цьому випадку вся структура, обумовлена ​​таким фрагментом, залишається дочірнім елементом містить її ЛЕ;


  • внаслідок залежності від структури зберігання і простору імен, фрагмент можна відкрити поза контекстом. Іншими словами, щоб відкрити фрагмент, необхідно відкрити ЛЕ, якій він належить.

У розглянутих продуктах можна створити кілька ЛЕ (як UML-моделі). В одному проекті можна створити одну або більше логічних одиниць, а кілька проектів в робочій області можуть містити кілька ЛЄ. Одночасно може бути відкрито і доступно для редагування будь-яку кількість логічних одиниць. Можна визначити відносини, які будуть існувати між елементами, що містяться в різних ЛЕ.






 



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

Rational XDE підтримує многомодельную парадигму, аналогічну використовуваної в програмах для управління архітектурою Rational. Крім того, програма підтримує також структури, аналогічні фрагментами (Fragments) в Rational, які називаються subunits.


У Rational Rose, на відміну від Rational XDE і ПО Rational для управління архітектурою, в будь-який момент часу може бути відкрита тільки одна модель. Отже існує тільки один спосіб спільного використання контенту в різних моделях – це ізолювати потрібний контент в файлах з розширенням. cat, а потім включити ці. cat-файли в декілька моделей. У Rational Rose. Cat-файли також використовуються як механізм розбиття сховища моделі. Отже, у термінах Rational,. Cat-файли Rose можна використовувати або як логічні одиниці, або як фрагменти.


Як уже говорилося раніше, ми взаємодіємо з логічним контентом UML-моделей через діаграми і через оглядач проектів Project Explorer. Якщо мова йде про UML-моделі, то елементи, що містяться в ЛЕ і фрагментах (логічний контент моделі) відображаються в поданні Project Explorer, а реальні файли. Emx і. Efx (фізичні механізми зберігання) не відображаються. Ці моменти важливі з наступних причин:



  • спосіб, що передбачає використання декількох ЛЕ для фізичного розбиття контенту моделі, є логічно непрозорим. Тобто, ми ясно бачимо, що ЛЕ відображаються в поданні Project Explorer, тому що вони завжди відображаються як елементи верхнього рівня;


  • спосіб, що передбачає використання фрагментів для фізичного розбиття контенту моделі, є логічно прозорим. Тобто, за умовчанням, єдиний спосіб побачити якесь позначення фрагментів полягає в тому, що UML-елементи, що відповідають фрагментам, позначаються графічними символами, видимими в Project Explorer (див. малюнок 1).

До сих пір ми розглядали логічні одиниці і фрагменти, які представляють собою механізм розбиття моделі. У розділі “Питання колективної розробки та управління моделями”, ми розповімо про те, як використовувати ці механізми в стратегії розбиття моделі.


Особливості використання наступних термінів: модель, файл моделювання, логічна одиниця і модель / ЛЕ


У попередньому розділі ми визначили модель як логічну конструкцію (відповідно до RUP). Потім ми дали визначення файлу моделювання. Далі ми точно визначили логічну одиницю як фізичний механізм зберігання для одиниць логічного контенту моделі. У поточній версії програми, коли ми створюємо, відкриваємо, закриваємо, перейменовуємо, видаляємо або об’єднуємо “UML-моделі,” ми насправді здійснюємо ці операції з логічними одиницями. В наступних версіях буде можна об’єднувати ЛЕ у віртуальні структурні ієрархії, в результаті поняття “UML – моделі” і ЛЄ будуть розділені. Оскільки в поточному проекті поняття UML-моделі і ЛЄ зливаються, ми скористаємося більш суворим терміном модель / ЛЕ для позначення ЛЕ в поточній реалізації. Це дозволить вам точно зрозуміти, коли в статті йдеться про модель або UML-моделі в чисто логічному сенсі, на відміну від моделі / ЛЕ.


Далі в рекомендаціях щодо структурування моделей використовуються такі терміни в наступних значеннях:


файл моделювання: якщо не вказано інше (наприклад, “файл конкретного моделювання”), термін використовується в загальному сенсі для позначення файлів з розширенням. emx або. efx;


логічна одиниця: використовується для позначення логічної одиниці як інструменту для фізичного розбиття логічного контенту моделей;


модель або UML-модель: використовується при розгляді моделей взагалі, і UML-моделей зокрема, в чисто логічному сенсі;


модель / ЛЄ: використовується для позначення логічної одиниці як фізичного артефакту, над якими виконуються операції при створенні, відкриття, закриття, перейменування, видалення або об’єднанні “UML-моделей” в рамках користувальницького інтерфейсу.


Включення моделей в проекти


Як уже говорилося раніше, платформа Eclipse підтримує кілька типів проектів, а аналізовані продукти підтримують два види моделей:



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


  • конкретні моделі (різних видів), які зберігаються як проекти Eclipse, що включають:

    • файли різних типів, які містять семантичну інформацію, засновану на декількох технологічно-специфічних метамоделі (наприклад, в Web-діаграмах) або абстрактних синтаксичних деревах (наприклад, в Java ™);


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

При включенні моделей в проекти слід пам’ятати наступні рекомендації:



  1. Конкретні моделі не вимагають особливої ​​уваги, тому що, по суті, [конкретна модель] = [проект Eclipse].


  1. При використанні UML-моделей для перетворень Java, C + + чи C #, що поставляються з розглянутими продуктами:

    • Якщо використовуються ітеративні повторні застосування перетворення UML – 3GL або прямі і зворотні перетворення разом з функцією Reconcile, помістіть модель / ЛЕ в проекти Eclipse, в які не включені відповідні конкретні моделі (згенерований код).


    • Якщо перетворення використовуються для заміни елементів, і при цьому ви зазвичай практикуєте комбіноване моделювання (при якому UML-елементи і 3GL-елементи зображуються на одних і тих же діаграмах), помістіть модель / ЛЕ в ті ж проекти Eclipse, що і згенерований код. У цих випадках в моделях / ЛЕ повинен зберігатися тільки контент проектування (моделювання на рівні класів), а решті контент (Прецеденти, аналітика, взаємодії на рівні проекту чи моделі станів і т. д.) повинні зберігатися в окремих моделях / ЛЕ в інших проектах Eclipse.
      У ряді випадків це може виявитися неможливим. Наприклад, існують конкретні угоди для використання декількох проектів Eclipse різних типів (наприклад, Java, Web і корпоративні bean-компоненти Java ™ (EJBs)) для зберігання контенту реалізації корпоративного Java-рішення.


  1. В інших випадках (коли перетворення не використовуються), можна помістити концептуальні (UML) моделі, які тісно пов’язані з певними конкретними моделями, в папку з ім’ям Conceptual Models в тому ж проекті Eclipse. Це відображення архітектурного принципу високої функціональної зчеплення, до якого ми постійно будемо повертатися в наступних рекомендаціях щодо структурування моделей.
  2. Як правило, проекти Eclipse використовуються, в тому числі, як грубо деталізованих одиниць управління конфігурацією. З цього випливає, що, якщо конкретна модель / ЛЕ була структурована для підтримки строгого володіння конкретним виконавцем, вона повинна являти собою окремий проект Eclipse. Варіантом цієї теми може бути ситуація, в якій один виконавець строго володіє колекцією моделей / ЛЕ, яка відноситься до певного функціональному аспекту, але цей виконавець моделює зазначені аспекти протягом усього життєвого циклу і бажає використовувати окремі моделі / ЛЕ для моделювання прецедентів, аналізу і на рівні проекту з урахуванням цього функціонального аспекту. У подібних випадках має сенс помістити ці кілька моделей / ЛЕ в один функціонально-орієнтований проект Eclipse і зберігати всі концептуальні моделі для всього життєвого циклу розробки в одному проекті. Однак попередня рекомендація про використання перетворень має пріоритет перед даною рекомендацією.
  3. Моделі / ЛЕ, які відображають загальні аспекти і на які повинні посилатися кілька інших високосцепленних і слабосвязанних моделей / ЛЕ, необхідно зберігати в UML-проектах, які інкапсулюють такі загальні аспекти. Наприклад, якщо на модель прецеденту посилається вміст кількох проектів, то ця модель не повинна бути розміщена в жодному з цих посилаються на неї проектів. Її необхідно розмістити в окремому проекті або в проекті, який об’єднує кілька інших спільних аспектів.





 



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

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


Розглянуті продукти не підтримують режим автоматичної синхронізації (Autosync mode) Rational Rose і Rational XDE. Замість цього на рівні абстракції коду ви просто компонуєте діаграми (за допомогою UML-сумісних нотацій), які безпосередньо зображують семантику коду (як і раніше, ми відносимо це до конкретного моделювання).


Типи UML-моделей


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


  • створити порожню модель / ЛЕ; в цьому випадку, щоб задати її тип, необхідно просто назвати модель відповідним чином і помістити в неї відповідний контент (включаючи і UML-профілі, які будуть до неї застосовуватися);


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

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


Основні поняття


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



  • кілька робочих груп працюють над основними або загальними функціями, на кшталт нижчеперелічених, які використовуються кількома рішеннями:

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

  • кілька робочих груп працюють над різними підсистемами рішення Інформаційної системи лабораторії (Laboratory Information System, LIS), яка виконує такі завдання:

    • обробка замовлень на послуги лабораторії;
    • управління та видача результатів лабораторних аналізів.

  • Одна робоча група працює над вирішенням Інформаційної системи радіологічної лабораторії (Radiology Information System, RIS), яка виконує такі завдання:

    • обробка замовлень на послуги радіологічної лабораторії;
    • обслуговування і видача результатів лабораторних аналізів;
    • складання розкладу послуг радіологічної лабораторії.

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

Рисунок 1. Приклади способів розбиття моделей різними робочими групами

Важливе зауваження:
для стислості на малюнку 1 показані всі проекти в одній робочій області. В реальній ситуації більш імовірно, що робочі області кожної робочої групи будуть виглядати по-різному. Для прикладу припустимо, що між системами радіологічної лабораторії та Лабораторії не існує прямих залежностей, робочі області колективів, що працюють над LIS і RIS, можуть містити лише загальні проекти Eclipse, від яких вони залежать, і їхні власні проекти Eclipse. Робоча область колективу, що має загальні кодові словники, може містити тільки модель / ЛЕ основних функцій у власному проекті Eclipse. Крім того, цілком імовірно, що робоча група LIS розмістить кожну зі своїх декількох моделей / ЛЕ в окремому проекті Eclipse, що дозволить працювати з ними, а також управляти конфігураціями, як з незалежними одиницями, а, значить, і з більшою ефективністю.


У цьому сценарії ми отримаємо наступні результати:


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


  • робоча група LIS вибрала розбиття на кілька моделей / ЛЕ. Можливо, це сигналізує про те, що архітектура LIS є досить суворою і складається з деякої кількості високосцепленних підсистем, які мають слабкі взаємозалежності, так що в окремих працівників рідко виникає необхідність переглянути контент, яким вони “володіють” в контексті всього контенту LIS;


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

Питання колективної розробки та управління моделями







 



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

Оглядач моделей Model Explorer в Rational Rose і в Rational XDE забезпечує тільки логічне уявлення UML-моделей, тоді як оглядач проектів Project Explorer в розглянутих продуктах дозволяє побачити логічні представлення різних видів моделей (UML, Java, Web і т. д.) в одному програмному поданні.


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


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


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


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


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

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


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


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


  • кількість і спрямованість зв’язків (взаємозалежностей) в моделях відрізняються більшою складністю, ніж базовий код;

    • якщо код реалізує залежність, просто посилаючись на ім’я постачальника, моделі реалізують відносини як реальні семантичні елементи відповідно до визначення метамоделі (наприклад, Асоціація, Узагальнення, Реалізація). Цими елементами необхідно ретельно управляти, щоб запобігти взаємне накладення складних моделей;


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


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

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


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

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



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

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


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


Моделювання в колективі: загальні принципи


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


Принцип 1: сувора архітектура


В даному контексті термін сувора архітектура відноситься, головним чином, до декомпозиції. Застосовувані тут принципи архітектурної декомпозиції – це ті ж принципи, які лежать в основі об’єктно-орієнтованої розробки, проектування на основі компонентів і сервіс-орієнтованої архітектури.



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


  • Прагніть до мінімальної пов’язаності бізнес-функцій.


  • Ті функції, які повинні залишатися жесткосвязаннимі, згрупуйте, а потім ізолюйте такі групи від решти функцій.

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


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


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


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



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


  • приготуйтеся до того, що доведеться виконувати безліч нетривіальних злиттів.

Хороший спосіб оцінити сувору архітектуру моделі – це перевірити, наскільки ця сувора архітектура проявляється в базовому коді. Тут ми чітко бачимо принципи стабілізації загальних фрагментів, а потім успішного поділу на рівні більш спеціалізованих фрагментів. Розглянемо гіпотетичну архітектуру для вирішення на базі технології Java ™ 2 Platform, Enterprise Edition (J2EE), зображену на малюнку 2.


Рисунок 2. Гіпотетична архітектура рішення на базі J2EE



Отже, ми бачимо, що API Java ™ Platform, Standard Edition (Java SE) досить стабільні. API Java 2 Platform, Enterprise Edition (J2EE) майже так само стабільні, як в Java SE. І ті, й інші використовуються всіма сервісами та додатками. Поверх базової інфраструктури J2EE ми бачимо такі елементи, як Access Layer for “Common” Data and Common Utilities (Рівень доступу для “загальних” даних і загальних утиліт “). Вони також використовуються всіма сервісами та додатками, тому ізольовані від них і стабілізуються на ранніх стадіях проекту. Поверх них є рівень спільно використовуються, або загальних, сервісів (або компонентів, якщо ви віддаєте перевагу цей термін). Ці рівні залежать від рівнів, розташованих під ними, і всі програми, які їх використовують, також залежать від них, тому, в ідеалі, вони досить стабільні до того моменту, коли поверх них надбудовуються програми.


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


Принцип 2: суворе володіння


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







 



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

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


Моделювання в колективі: розбиття моделей


З розділу “Основні поняття і терміни”, ми дізналися, що ПЗ Rational для управління архітектурою пропонує два способи розбиття фізичного втілення UML-моделі: моделі / ЛЕ і фрагменти. (Важливо: якщо ви пропустили цей розділ, поверніться і прочитайте його зараз.) У цьому розділі даються відповіді на наступні питання:


  • Коли слід виконувати розбиття моделі?
  • Який механізм краще використовувати для розбиття – моделі / ЛЕ або фрагменти?

Приймаючи рішення, слід врахувати наступні фактори:


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


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


  • вибір програмного забезпечення для управління конфігурацією (configuration management, CM). Деякі CM-інструменти відрізняються кращою підтримкою розбиття моделей в порівнянні з іншими інструментами.


  • застосування перетворень. Принцип роботи деяких перетворень накладає обмеження, які можуть впливати на прийняття рішення про розбиття моделі. Наприклад, стандартне перетворення Java – UML, що поставляється з деякими розглянутими продуктами, дозволяє використовувати в якості мети тільки моделі / ЛЕ. Отже, якщо існує потреба в перетворенні декількох Java-проектів окремо, можливо, краще створити окрему модель / ЛЕ для кожного з них.

Насправді не так вже й складно зрозуміти, коли необхідно виконати розбиття моделей з причин складності або розміру. Розбиття необхідно, в основному, в тих випадках, коли файли розростаються до занадто великих розмірів для машин, які використовуються в даному співтоваристві користувачів. Наприклад, з моделлю, яка займає 30 Мбайт дискового простору, стає дуже важко виконувати повсякденні операції на комп’ютері з 1 Гбайт оперативної пам’яті. Рекомендується розбити таку модель, щоб в будь-який даний момент часу в оперативній пам’яті розміщувалося від 5 до 10 Мбайт. В якості альтернативи можна збільшити розмір оперативної пам’яті, що дає переваги не тільки для моделювання. Комп’ютер з оперативною пам’яттю 2 Гбайт без файлу підкачки виконує майже всі операції Eclipse швидше. Він також змушує працювати дуже швидко дуже великі моделі.


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


Часто виникає наступне питання: чи можна уникнути нетривіальних злиттів шляхом розбиття моделей на кілька моделей / ЛЕ або фрагментів? Можна відповісти одним словом: ні.


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


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


І все ж у деяких випадках розбиття неможливо уникнути. Якщо вам доводиться використовувати розбиття, можливо, ви захочете дізнатися, за яким принципом слід робити вибір між використанням моделей / ЛЕ або фрагментів в якості фізичного механізму розбиття. Рекомендуємо враховувати наступні моменти, пов’язані з моделям / ЛЕ і фрагментами:



  • в фрагментах зберігається відображення ієрархічної структури організації моделі в Project Explorer;


  • моделі / ЛЕ відображаються в Project Explorer у вигляді окремих контейнерів верхнього рівня і не можуть (у поточній версії) бути вкладеними в інші логічні структури організації моделі;


  • фрагменти уповільнюють роботу CM-системи, тому що доводиться обробляти більше файлів;


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


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


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


  • механізм злиття моделей / ЛЕ оснащений дистанційним клієнтським інтерфейсом IBM ® Rational ® ClearCase ®. Він оберігає контекст від поширення конфліктуючих змін, але також уповільнює процес злиття;


  • моделі / ЛЕ в повній мірі підтримуються механізмом уніфікованого управління змін (Unified Change Management, UCM); тоді як для фрагментів існують обмеження;


  • з моделями / ЛЕ можна працювати через інтерфейс ClearCase і командний рядок; тоді як для фрагментів і тут є обмеження.

Враховуючи все вищесказане, рекомендуємо обирати наступні варіанти:


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


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

    • використовуйте IBM ® Rational ® ClearCase MultiSite ®, і здійснюйте роботу над основними моделями / ЛЕ в кожному локальному підрозділі, виконуючи централізовані злиття за допомогою UCM-системи (цей метод краще всього працює в тих ситуаціях, коли самі моделі / ЛЕ не розбиті на фрагменти);


    • використовуйте систему управління паралельними версіями (Concurrent Versions System, CVS) і розбиття на кілька моделей / ЛЕ;


    • використовуйте CVS-систему і розбиття моделей на фрагменти. Для цього необхідно використовувати суворе володіння, щоб, по можливості, уникнути злиття, тому що злиття не слід виконувати при відсутності адекватного контексту.






 



Посилання між елементами моделі в різних файлах моделювання

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


При будь-яких операціях (редагуванні) з групою пов’язаних файлів моделювання (тобто, колекцією файлів моделювання, які посилаються один на одного), можна спробувати розмістити всі ці файли моделювання в одній робочій області. Це необов’язково означає, що всі файли моделювання з такої групи повинні розміщуватися в одному проекті. Тим не менше, використання одного проекту, як правило, гарантує, що всі моделі будуть в наявності, тому що, в типових робочих потоках СМ-системи всі файли моделі передаються спільно в рамках одного проекту. Але якщо це не робиться через те, що у вас немає доступу до моделей, які створюють ваші “споживачі”, то при внесенні змін не слід думати, що можна виконати рефакторинг всього іншого контенту, який залежить від вашого. Отже, переміщення елемента з одного ресурсу (файлу. efx або. emx) в інший може дорого обійтися вашим споживачам. Програмне забезпечення Rational для управління архітектурою надає підтримку таких операцій, але це буде коштувати вашим споживачам втрати цінного часу, оскільки вони повинні будуть запустити функцію Validation, виділити кожну зіпсовану посилання і виправити її, і все це виконати не один раз.


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


Сценарії


Давайте подивимося, як розглянуті нами до цього моменту принципи колективного моделювання застосовуються в певних сценаріях. Ми впорядкуємо опис сценаріїв відповідно до першого принципом: Чи є моделі строго структурованими, чи використовується суворе володіння об’єктами? Другим питанням буде: Яке СМ-рішення вибрано?


Добре продумана архітектура моделі:

Характеристики моделі:



  • структура пакета відображає високу функціональну зчепленість, слабку зв’язаність і суворе володіння файлами окремими виконавцями;


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

Нижче перераховані методи, які зазвичай виявляються ефективними (у порядку убування ефективності).



  1. Використання однієї не розбитою на фрагменти моделі / ЛЕ. Злиття будуть виконуватися, але нетривіальні злиття не повинні бути частими і, якщо в них виникає необхідність, повинні виконуватися з урахуванням усього контексту моделі.
  2. Використання взаємозалежної групи моделей / ЛЕ з посиланнями між файлами. Злиття виконуються мене часто, при цьому доступний досить адекватний контекст.
  3. Використання однієї моделі / ЛЕ з тонкодеталізірованним розбивкою на фрагменти. Використання рішення для управління конфігурацією (наприклад, ClearCase), із загальними динамічними уявленнями в потоці інтеграції з резервуванням зняття з контролю), яке ефективно блокує файли із змінами (фрагменти).
  4. Використання системи управління конфігурацією, наприклад, ClearCase або CVS, яка може синхронізувати всю робочу область і допускає виконання злиттів окремих фрагментів при виникненні рідкісних конфліктів на цьому рівні.

Менш продумана архітектура моделі:


характеристики моделі:



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

можливі варіанти (у порядку від найбільш до найменш пріоритетним кращого):



  1. використання однієї моделі / ЛЕ з тонкодеталізірованним розбивкою на фрагменти в поєднанні з рішенням для управління конфігурацією типу ClearCase, яке блокує файли зі змінами за допомогою поділюваних динамічних уявлень в потоці інтеграції та примусового застосування зарезервованих знять з контролю;
  2. використання однієї моделі / ЛЕ без розбиття на фрагменти. Використання ClearCase з приватними уявленнями (статичними або динамічними). Використання перебазування і поставки в UCM для збереження цілісності приватної копії кожного виконавця до завершального моменту інтеграції. UCM також забезпечує можливість атомарної поставки, що дозволяє легко повернутися до попереднього стану після невдалого злиття. Злиття стають проблематичними і затяжними зі збільшенням розміру набору конфліктів. Цей набір збільшується в періоди між інтеграції, тому необхідно виконувати інтеграцію як можна частіше;
  3. використання групи взаємозалежних моделей / ЛЕ. У цьому разі злиття стануть більш складними, а контексту для них буде менше, але зате місце, займане моделлю / ЛЕ в пам’яті, теж скоротиться, а конфлікти будуть виникати набагато рідше. В цьому випадку також необхідно часто виконувати інтеграцію, щоб зменшити ймовірність виникнення конфліктів змін на цьому рівні.

Ще раз підведемо підсумок сказаному.


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



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


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

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


Рисунок 3. Міркування, які слід враховувати при управлінні моделями та їх розбитті



Методи розбиття моделей


Для управління моделями та їх розбиття існують наступні методи:



  1. створення нової моделі / ЛЕ в проекті;
  2. видалення пакета існуючої моделі / ЛЕ, в результаті чого пакет перетворюється в окрему модель / ЛЕ;
  3. об’єднання двох наявних моделей / ЛЕ в одну модель / ЛЕ (це називається сплавлення (fusing));
  4. розбиття моделі / ЛЕ на фрагменти;
  5. включення фрагментів в моделі / ЛЕ (операція, зворотна створенню фрагментів).

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


Інші корисні інструменти і методи


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


Діаграми за запитами
На відміну від звичайних діаграм, на яких елементи, які потрібно зобразити, розміщуються вручну, контент діаграм за запитами визначається в результаті виконання запиту до поточного стану контенту моделі, що дозволяє нанести елементи на діаграму з урахуванням семантичних змін, які були зроблені з моменту останнього перегляду діаграми. Використання діаграм за запитами замість діаграм, намальованих вручну, може зменшити кількість конфліктів злиття, пов’язаних з діаграмами, які в іншому випадку могли б мати місце. Розглянуті продукти підтримують два типи діаграм по запиту: Актуальні (Topic) діаграми і Оглядові (Browse) діаграми.



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


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

Модель огляду архітектури (Architecture Overview Model)
При виконанні робіт з моделювання, вам, можливо, здасться корисним визначити модель огляду архітектури Architecture Overview Model для фіксації високорівневого подання про архітектуру, яке допоможе зрозуміти, як організувати і виконати розбиття інших моделей (це тільки одна з можливих застосувань). Момент створення такої моделі і спосіб її переробки в міру розвитку проекту може залежати від ряду факторів, в тому числі, від загального процесу розробки і вибраного принципу моделювання (наприклад, стандартний підхід RUP або принцип розробки, керованої бізнесом). Фактично всі докладні опису їх застосування представлені в розділах цього посібника, присвяченого конкретним стилям.







 



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

У керівництві по структуруванню моделей в Rational XDE в якості пристрою, що представляє огляд реалізації на рівні підсистеми, рекомендувалося використовувати модель огляду реалізації (Implementation Overview model). Деталізація кожної підсистеми потім визначалася в моделі коду проекту, що реалізує цю підсистему.


Призначення моделі огляду архітектури (Architecture Overview Model) в програмному забезпеченні Rational для управління архітектурою дещо інше і більше орієнтоване на осмислення загальної архітектури ПО як засоби планування розбивки моделей та організаційної стратегії. (Зверніть увагу на те, що ні модель Implementation Overview model, ні модель Architecture Overview Model не описуються традиційним RUP.)


Щоб зрозуміти, який обхват і рівень абстракції може відображати така модель, розглянемо малюнок 4. На цьому малюнку показано, що базовий код ділиться на модулі для реалізації суворої архітектури і суворого володіння. Однак з малюнка також зрозуміло, якого типу огляд архітектури (модулів та їх залежностей) можна виразити в моделі огляду архітектури (Architecture Overview Model).


Модель Architecture Overview Model можна також використовувати для того, щоб створити ескіз передбачуваної структури робочої області, як показано на малюнку 4.


Рисунок 4. Приклад моделі огляду архітектури Architecture Overview Model



Ще одне можливе застосування Architecture Overview Model – це запис неформальних схем і діаграм різних аспектів рішення, наприклад, висококонцептуальной схеми системи аукціону на малюнку 5.


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


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

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

Ваш отзыв

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

*

*