Визначення архітектури додатків за допомогою Rational Software Architect: Частина 2. ітеративна уточнення архітектури

  1. Серія контенту:
  2. Цей контент є частиною серії: Визначення архітектури додатків за допомогою Rational Software Architect
  3. Итеративное вдосконалення архітектури
  4. Уточнення архітектурних механізмів
  5. Малюнок 1. Аналітичні стереотипи
  6. Малюнок 2. Аналітичні елементи пакета обробки замовлень
  7. Малюнок 3. Шаблон реалізації сценаріїв використання для функцій замовлення по меню.
  8. Малюнок 4. Схема класів для функції замовлення по меню
  9. Уточнення структурної моделі
  10. Малюнок 6. Подання Architectural Layer Dependencies для системи Online Catering
  11. Малюнок 7. Пакети проектів для системи Online Catering
  12. Малюнок 8. Детальна схема класів для генерації коду
  13. Уточнення архітектури розгортання
  14. Малюнок 9. Приклад логічної топології для системи Online Catering
  15. Малюнок 10. Приклад докладної моделі розгортання системи Online Catering
  16. Поетапне побудова системи
  17. Малюнок 11. Інструмент рефакторінга в Rational Software Architect
  18. Малюнок 13. Перетворення в Rational Software Architect
  19. висновок
  20. Малюнок 14. Моделі для різних архітектурних уявлень
  21. Ресурси для скачування

Визначення архітектури додатків за допомогою Rational Software Architect

Серія контенту:

Цей контент є частиною # з серії # статей: Визначення архітектури додатків за допомогою Rational Software Architect

http://www.ibm.com/developerworks/rational/library/?sort_by=&show_abstract=true&show_all=&search_flag=&contentarea_by=Rational&search_by=Define+application+architectures+with+Rational+Software+Architect&product_by=-1&topic_by=-1&industry_by=- 1 & type_by = All + Types & ibm-search = Search

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Визначення архітектури додатків за допомогою Rational Software Architect

Слідкуйте за виходом нових статей цієї серії.

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

  1. Виявлення значущих вимог
  2. Визначення передбачуваної архітектури
  3. Визначення вихідної моделі розгортання
  4. Визначення моделі домену

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

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

  1. Уточнення архітектурних механізмів: технічні концепції задоволення архітектурно значущих вимог, визначених на першому кроці.
  2. Уточнення елементів проекту: архітектурно значущі елементи проекту.
  3. Уточнення архітектури розгортання: одиниці і топології розгортання.

Итеративное вдосконалення архітектури

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

Уточнення архітектурних механізмів

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

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

Для наочності можна зв'язати ці класи з аналітичним стереотипом. Для подання класу, яка виконує функції інтерфейсу до системи, використовується стереотип Boundary. Компонент, який здійснює контроль над іншими класами, описується класом Control. Клас, що містить дані, визначається стереотипом Entity.

Графічне представлення цих аналітичних стереотипів наведено на малюнку 1.

Малюнок 1. Аналітичні стереотипи
Визначення архітектури додатків за допомогою Rational Software Architect   Серія контенту:   Цей контент є частиною # з серії # статей: Визначення архітектури додатків за допомогою Rational Software Architect   http://www

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

Малюнок 2. Аналітичні елементи пакета обробки замовлень

Після визначення аналітичних класів (малюнок 2) також може знадобитися визначення статичних і динамічних аспектів деяких значущих вимог.

Потім для кожного значимого сценарію визначаються його статичні та динамічні аспекти. Rational Software Architect допомагає архітектору ПО вирішити цю задачу, надаючи шаблон реалізації сценаріїв використання.

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

Малюнок 3. Шаблон реалізації сценаріїв використання для функцій замовлення по меню.

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

Малюнок 4. Схема класів для функції замовлення по меню
Малюнок 5. Циклограма для функції замовлення по меню

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

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

Уточнення структурної моделі

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

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

У нашому прикладі система ресторанного інтернет-обслуговування Yummy Inc. розробляється на платформі Java EE. Для забезпечення персистентності даних використовується API Java Persistence (див. Розділ ресурси ), Логіка додатка реалізується за допомогою Session Beans, а доступ до служби доставки здійснюється за допомогою Web-сервісів.

При створенні архітектури та проектуванні рекомендується визначати різні рівні рішення і спосіб їх взаємодії. N -уровневая архітектура Java EE сприяє розділенню завдань між рівнями.

У перспективі Architectural Layers системи Rational Software Architect шаблон структури містить уявлення, на якому можна визначити залежності між рівнями (рисунок 6).

Малюнок 6. Подання Architectural Layer Dependencies для системи Online Catering

Коли архітектурні рівні визначено, архітектор виконує першу ітерацію проектування. Шаблон проекту Rational Software Architect містить готову структуру для цього. У специфікації компонента зазвичай є інтерфейси і дані, використовувані для взаємодії з цим компонентом (малюнок 7). Як правило, це перше, що визначає архітектор ПО. Для кожного компонента важливо вказати дані, якими він маніпулює, і його інтерфейс, включаючи доступні операції.

Малюнок 7. Пакети проектів для системи Online Catering

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

Для деяких компонентів складної програмної системи може знадобитися поглиблене проектування. Пам'ятайте, що структура деталізується тільки в тому випадку, якщо це допомагає групі в реалізації і випуску програми. На малюнку 8 представлена ​​докладна схема класів, складена з конкретною метою. Група хоче створити Java-код з структурної моделі з використанням деяких перетворень, які забезпечує Rational Software Architect (докладніше про перетвореннях см. В розділі ресурси ).

Малюнок 8. Детальна схема класів для генерації коду

Архітектор програмного забезпечення не завжди відповідає за створення детального проекту окремих компонентів. Залежно від розміру і досвіду групи роль проектувальника ПО можна доручити одному або кільком розробникам, наприклад, старшим програмістам (межі між архітектурним проектуванням, структурним проектуванням і розробкою бувають розпливчастими).

Уточнення архітектури розгортання

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

Інструменти планування процесу розгортання Rational Software Architect дозволяють створювати топології, що демонструють відносини між ІТ-ресурсами. Також можна планувати і перевіряти сценарії розгортання (докладніше про планування і автоматизації процесу розгортання за допомогою Rational Software Architect см. Розділі ресурси ).

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

Малюнок 9. Приклад логічної топології для системи Online Catering

Збільшений варіант малюнка 9.

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

Малюнок 10. Приклад докладної моделі розгортання системи Online Catering

Збільшений варіант малюнка 10.

Поетапне побудова системи

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

Постійне обдумування архітектури є частиною зусиль по розробці, і група не повинна писати новий код або змінювати існуючий, не подумавши про те, як ця зміна вплине на додаток в цілому. Популярний метод зміни існуючого коду називається рефакторингом (див. Розділ ресурси ). Rational Software Architect надає багатий набір інструментів для полегшення розробки та рефакторінга коду. За допомогою інструменту рефакторінга можна змінити структуру коду (рисунок 11). А функція архітектурного виявлення дозволяє виділити в коді програми шаблони і антішаблони (рисунок 12). Обидві функції допомагають поліпшити код і виявити проблеми на ранніх стадіях розробки програмного забезпечення.

Малюнок 11. Інструмент рефакторінга в Rational Software Architect
Малюнок 12. Пошук шаблонів

Якщо при обмірковуванні архітектури ви створили якісь моделі, то їх можна перетворити в код. Rational Software Architect містить набір перетворень для створення коду Java, елементів Java EE або артефактів SOA (рисунок 13). Можна також генерувати моделі з існуючого вихідного коду.

Малюнок 13. Перетворення в Rational Software Architect

Так у міру поступового побудови системи створюється робоче ПО, відповідне конструктивним рішенням, прийнятим в ході планування архітектури.

висновок

Гнучкі методи проектування сприяють застосуванню коротких ітерацій для побудови системи крок за кроком. Якщо підхід Big Design Up Front (див. BDUF в розділі ресурси ) Виявився неефективним і застосовується головним чином в водоспадних моделях, то це не означає, що з гнучких проектів потрібно викинути планування архітектури та структури. Проектування повинно бути продуманим і послідовним. Продуманим, тому що вже на початку проекту можна передбачити деякі технічні вимоги, грунтуючись на черзі невирішених завдань (планування архітектури). Послідовним, тому що в ході ітерацій розробки проект адаптується і збагачується при вирішенні нових технічних завдань, з якими стикається група.

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

Малюнок 14. Моделі для різних архітектурних уявлень

Обдумування архітектури - це безперервний процес, який групи досвідчених розробників впроваджують в свою роботу. Він не завжди приводить до створення формальної схеми. Майте на увазі, що якщо UML не підходить для вашого контексту, то ніщо не заважає використовувати замість нього ескізи Rational Software Architect, як якщо б ви малювали на дошці. Ескізи Rational Software Architect носять менш формальний характер, ніж UML-схеми, але можуть служити хорошою альтернативою для конкретного проекту.

Ресурси для скачування

Схожі теми

  • Оригінал статті: Define application architectures with Rational Software Architect: Part 2: Iteratively refine the architecture .
  • Визначення архітектури додатків за допомогою Rational Software Architect: Частина 1. Планування архітектури
  • Моделювання топології розгортання : Навчальний модуль про побудову топології розгортання за допомогою Rational Software Architect.
  • Безкоштовний самовчитель з моделювання із застосуванням Rational Software Architect.
  • Проект Design Management : Нове рішення, що допомагає групі співпрацювати в галузі планування архітектури та проектування.
  • Big Design Up Front (BDUF) Сторінка, присвячена підходу BDUF.
  • Java Persistence API : Спрощена модель програмування для забезпечення персистентності логічних об'єктів.
  • Вікі по Rational Software Architect : Безліч ресурсів, корисних при проектуванні, розробці, реалізації та розгортання додатків.
  • Підготовка архітекторів програмного забезпечення : Спосіб набути необхідних навичок і отримати сертифікацію.
  • IBM Practices : Вся необхідна інформація про IBM Practices
  • OpenUP : Процес розробки ПЗ з відкритим вихідним кодом із застосуванням ітеративного і поетапного підходів в рамках структурованого життєвого циклу.
  • IBM agility @ scale : Короткий відеоролик, присвячений IBM agility @ scale.
  • IEEE Recommended Practice for Architectural Description for Software-Intensive Systems : Інформація про стандарт IEEE тисячі чотиреста сімдесят одна.
  • Deployment topologies with Rational Software Architect: стаття про те, як створювати топології розгортання за допомогою Rational Software Architect.
  • What's new in IBM Rational Software Architect v8.0 : Введення в нові функції Rational Software Architect версії 8.
  • Сторінка продукту IBM Rational Software Architect : Технічна документація, статті, інструкції, навчальні курси, завантаження і інформація про продукти Rational Software Architect.
  • Architectural Blueprints - The "4 + 1" View Model of Software Architecture : Робота Філіпа Крухтена.
  • Сторінка ресурсів по UML : Офіційний сайт UML.
  • Завантажте будь-яку або обидві ознайомчі версії:

Підпишіть мене на повідомлення до коментарів

Com/developerworks/rational/library/?
Новости
Слова жизни
Фотогалерея