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