у, об'єднання існуючих елементів проекту, опис архітектури реального часу (якщо проектована ПС відноситься до цього класу). В результаті виконання цих робіт досягаються наступні цілі:
В· Забезпечується перехід від аналізу до проектування шляхом визначення з елементів і механізмів аналізу елементів і механізмів проектування;
В· Підтримується цілісність і несуперечність архітектури шляхом інтеграції нових елементів проекту, що визначаються в поточній ітерації, з уже існуючими та повторного використання доступних елементів проекту.
В· Здійснюється плавний перехід від проектування до реалізації;
Аналіз поведінки. Ця діяльність включає аналіз ВІ, визначення елементів проекту та огляд проекту. Ця діяльність має на меті перетворення описів поведінки у вигляді ВІ в набір елементів проекту (класи, відносини, операції та ін.)
Проектування компонентів. Цілі даної діяльності полягають у:
В· Визначенні та уточненні елементів проекту шляхом докладного опису того, як ці елементи реалізують необхідну поведінку.
В· Визначенні та уточненні реалізації ВІ на основі нових елементів проекту.
В· Контролі і рецензуванні проекту по мірі його розвитку.
Проектуються ВІ, підсистеми, класи та компоненти ПС. Точно описуються інтерфейси компонентів і їх реалізація.
Проектування БД. Дана діяльність виконується для проектів, використовують бази даних. Вона включає:
В· Визначення персистентних (постійно збережених) класів;
В· Проектування структури БД для зберігання таких класів;
В· Визначення механізмів і стратегій збереження і доступу до збережених даних, що задовольняють вимогам до продуктивності і надійності ПС.
Аналіз та проектування пов'язує управління вимогами і реалізацію. У цьому технологічному процесі створюється модель проектування. Одне з її уявлень - логічна модель - відображає декомпозицію ПС в набір логічних елементів (класи, підсистеми, взаємодії). Процедурне уявлення відображає ці елементи в процеси і підпроцеси системи. Представлення розгортання відображає ці процеси в набір вузлів обчислювального комплексу, на яких вони виконуються.
В
Реалізація
В
Цілі процесу реалізації
Основні цілі процесу можна сформулювати наступним чином:
В· Визначити структуру коду у вигляді рівнів;
В· Реалізувати компоненти, класи та об'єкти;
В· Провести блочне тестування компонент;
В· Інтегрувати розробки, виконані окремими розробниками, в єдину виконувану систему.
У процес реалізації не включено тестування всієї ПС, для якого в RUP передбачено окремий процес (див. наступну статтю).
Особливості процесу реалізації
RUP передбачає поелементну інтеграцію протягом усього життєвого циклу. Це означає, що коди пишуться невеликими блоками, після чого вони об'єднуються в єдине ціле шляхом поступового додавання блоків. Це спрощує процес локалізації помилок. Передбачено два рівні інтеграції - інтеграція результатів роботи групи розробників у підсистему та інтеграція підсистем у ПС. Інтеграція відбувається в кожній ітерації відповідно до плану ітерації, де визначені ВІ, які проектуються і реалізуються в цій ітерації. Таким чином, план ітерації визначає класи, які будуть реалізовані в цій ітерації.
У фазі конструювання створюється еволюційний прототип системи, який з часом розвивається в кінцеву ПС. Це прототип використовується для демонстрації фрагментів ПС замовнику і керівництву. За результатами подання прототипу можна отримати зауваження, які дозволяють уточнити, змінити або доповнити вимоги до ПС. RUP декларує можливість створення, крім еволюційних, поведінкових одноразових прототипів для проведення певних досліджень, стосуються функціональних можливостей системи.
У RUP декларується необхідність відповідності моделі та програмного коду. При цьому допускається можливість зміни коду з наступною переробкою моделі, яка забезпечувала б необхідну відповідність. Для цієї мети використовують інструментальні засоби, що включають можливості автоматичного реінжинірингу Методика реінжинірингу представлена ​​в статті В«Реінжиніринг програмних системВ». p> Ролі
Конструктор (кодіровщік) розробляє компоненти й класи, виконує блочне тестування.
Системний інтегратор виконує інтеграцію елементів в програмні конструкції (Систему і підсистеми). p> Архітектор визначає структуру реалізації (підприємство рівнів і підсистем).
Рецензент коду перевіряє якість програмного коду і його відповідність стандартам проекту.
Артефакти
Підсистема реалізації - це набір компонентів та інших підсистем реалізації, використовуваних для утворення моделі реалізації. Це поняття дозволяє ієрархічно представити модель реалізації.
Компонент частина програмного коду (див. статтю В«компонентно-базов...
