Визначення й етапи реінжинірингу

Вступ

 

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

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

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

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

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

 

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

 

 

Визначення й етапи реінжинірингу

 

Реінжиніринг програмного забезпечення — процес створення нової функціональності або усунення помилок, шляхом революційної зміни, але використовуючи вже наявне в експлуатації програмне забезпечення. Процес реінжинірингу описаний Chikofsky і Кросом у їхній праці 1990 року «The examination and alteration of a system to reconstitute it in a new form». Виражаючись менш формально, реінжиніринг є зміною системи програмного забезпечення після проведення зворотного інжинірингу.

 

Реінжиніринг програмного забезпечення, можна розділити на кілька етапів:

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

Визначення системних архітектур. Роботи з опису архітектур починаються фактично на початковому етапі, коли визначається склад устаткування й стандартне програмне забезпечення (ПЗ), необхідні для інсталяції й запуску існуючої зафіксованої системи. Тим самим фактично визначаються архітектури БД, устаткування й стандартного ПЗ, телекомунікацій. Усі архітектури представляються в нотації UML і при необхідності доповнюються текстовими описами. Побудовані архітектурні моделі в процесі реінжинірингу будуть уточнюватися й доповнюватися.

Автоматичний реінжиніринг. Автоматичний реінжиніринг здійснюється за допомогою інструментальних засобів візуального моделювання. Його виконання дозволяє побудувати моделі, які можуть бути прийняті як початкові. Автоматичного реінжинірингу зазнає як бізнес логіка (якщо є початкові (ісходні) коди на об'єктно-орієнтованому або об'єктно-базованій мові), так і БД.

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

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

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

Якщо діаграма містить занадто багато елементів, то аналізувати її складно. Спробуйте проаналізувати діаграму, що містить більш 100 класів! Тому доцільно розбити таку діаграму на кілька окремих діаграм, залишаючи в кожної приблизно по 7 – 10 елементів.

Метод підвищення наочності діаграм добре відомий. Це ієрархічна реструктуризація. Засобом її здійснення в UML є пакети. Складні ПС звичайно включають кілька підсистем, що мають різне цільове призначення й функціональність. Тому на верхньому рівні ієрархії можна показати пакети – підсистеми. Кожний з таких пакетів повинен одержати ім'я, що відображає суть відповідної підсистеми. На цьому рівні можна також показати пакети класів, що є загальними для всієї системи й використовуються підсистемами. На початковій стадії реструктуризації логічної моделі можна ввести пакет верхнього рівня, куди містяться класи, які важко віднести до якого-небудь іншого пакета. У будь-який ПС є користувацький інтерфейс, зв'язок із БД, керування, обробка, класи даних. Такого типу пакети можна ввести в кожній підсистемі на наступному рівні ієрархії.

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

Визначення акторів. Для знаходження акторів слід шукати відповіді на наступні питання:

· Хто є безпосередніми користувачами системи? Необхідно при відповіді на дане питання вказувати ролі, а не конкретних людей, що виконують ці ролі.

· З яким зовнішнім устаткуванням або програмами здійснює взаємодія система?

· Чи виконує система роботи, які активуються настанням конкретного часу або закінченням певних інтервалів часу (при позитивній відповіді одним з акторів є таймер)?

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

Акторам слід привласнити імена, що відображають їхні ролі в роботі із системою.

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

Далі виконується деталізація побудованих пакетів ВВ на основі аналізу екранних форм. Рекомендовані правила:

· якщо екран містить меню, то це пакет ВВ. При цьому кожний рядок меню – це або підпакет, або окремий ВВ;

· якщо основний екран – форма, то це окремий ВВ.

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

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

· якщо вони взаємодіють із одним актором;

· мають один з одним відносини включення або розширення

· Можуть бути й інші способи забезпечення наочності моделі, важливо лише мати чітку стратегію розбивки на пакети.

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

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

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

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

 

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