Класифікація підходів, методів і технологій.

 

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

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

поняття «реінжиніринг ІС» різними дослідниками дотепер трактується по різному, існує безліч близьких понять, наявність яких приводить до появи зовні одмінних, але по суті схожих підходів, методів і технологій;

пропоновані рішення не позиціонуються в контексті інших існуючих рішень;

рішення не інтегровані на рівні методологій і технологій, велика кількість методів і інструментальних засобів спрямоване на розв'язок окремих локальних завдань, пов'язаних з реінжинірингом ІС;

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

 

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

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

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

 

 

Рис 4. Рівні розгляду й дослідження аспектів, що співвідносяться з реінжинірингом ІС.

 

Перший рівень включає дослідження, спрямовані на досягнення концептуального розуміння діяльності по реінжинірингові ІС. Саме на цьому рівні досліджуються питання адекватного визначення поняття «реінжиніринг ІС», визначення місця реінжинірингу в життєвому циклі (ЖЦ) ІС, у тому числі виявлення зв'язків процесу реінжинірингу ІС у цілому з іншими процесами ЖЦ ІС. Слід уважати, що більша частина розглянутих раніше аспектів, стосується цього рівня.

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

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

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

На відміну від попередніх робіт в [33] авторами основний акцент зроблений на рішенні завдань оцінки успадкованих систем і підтримки прийняття рішень при реінжинірингу ІС. Авторами визначається процес оцінки, що полягає з наступних вхідних до його складу процесів (підпроцесів):

технічної оцінки (Reengineering Technical Assessment),

економічної оцінки (Reengineering Economic Assessment),

прийняття управлінських рішень (Reengineering Management Decision).

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

Ще одним прикладом процесу, спрямованого на розв'язок локального завдання, є ітеративний процес, що визначає наступну послідовність кроків, які повинні бути виконані при плануванні проектів реінжинірингу ІС [37]:

Визначення цілей, напрямків діяльності організації й інформаційної системи.

Формування об'єднаної команди, яка буде здійснювати реінжиніринг успадкованої системи.

Визначення середовища розробки й супроводу, що базується на застосуванні CMM (Capability Maturity Model).

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

Аналіз успадкованої системи.

Визначення процесу реалізації діяльності по реінжинірингові.

Розробка/Відновлення стандартних засобів тестування й валідації.

Аналіз засобів реінжинірингу.

Навчання.

 

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

З деякою умовністю всі методи реінжинірингу ІС можна розділити на два класи.

Методи, що відносяться до першого класу, визначені на концептуальному рівні й у цілому не залежать від якоїсь однієї програмної технології. Серед усієї безлічі розглянутих методів [2] до першого класу відносяться метод реплікації баз даних і заснований на об'єктно-орієнтованому підході метод побудови оболонок для компонентів успадкованої системи (object – oriented wrapping), методи «білого» і «чорного» ящика модернізації системи. Іншими представниками даного класу є: методи оцінки варіантів реінжинірингу ІС [9, 11, 33], метод планування міграції програмних засобів [8], методи добування знань про існуючу систему [3, 4, 17], методи трансформації (реконструкції) архітектури ІС [3, 7, 19, 21], методи автоматизації реінжинірингу програм [6, 23] і т.д. У цілому слід уважати, що область застосування таких методів, як правило, характеризується деяким класом програмних технологій. А для застосування в реальних проектах кожний з них адаптується з урахуванням використовуваних у проекті технологій і інструментальних засобів.

Окремим напрямком досліджень, що відносяться до даного класу і що одержали розвиток в останні роки, є дослідження й розробка зразків реінжинірингу ІС [26-30, 36]. Кожний зі зразків реінжинірингу ІС націлений на розв'язок деякого типового завдання (проблеми), яке супроводжує діяльність по реінжинірингові ІС. Не дивлячись на деякі відмінності, в цілому дотримуються єдиного підходу до опису таких зразків. Так, в [26] визначається наступний шаблон опису.

Ім'я зразка.

Мети застосування.

Область додатка.

Мотивація до застосування.

Структура системи до й послу застосування зразка.

Процес застосування зразка.

Обговорення зразка.

Особливості, що залежать від мови програмування.

 

Варто помітити, що хоча останній з розділів шаблону «прив'язує» шаблон до певного середовища реалізації, мовам програмування, все-таки кожний зі зразків представляє деякий концептуальний розв'язок проблеми. Докладну інформацію про зразки реінжинірингу можна знайти в книзі «Object-Oriented Reengineering Patterns» [27].

На відміну від першого класу, методи другого споконвічно орієнтовані на використання певних програмних технологій. До другого класу відносяться так само адаптації методів з першого класу. Тут методи найбільшою мірою пристосовані до їхнього безпосереднього (прямого) застосування в конкретних проектах. Прикладами методів даного класу слід уважати [2]: методи інтеграції з використанням CGI, методи інтеграції на основі технології XML, метод побудови оболонок для компонентів успадкованої системи з використанням технології CORBA.

І нарешті, четвертий рівень включає дослідження й розробку інструментальних програмних засобів, що автоматизують застосування підходів, методів і технологій, розглянутих на попередніх рівнях. Слід визнати, що в даний момент таких засобів існує велика кількість, серед якого виділяються засоби [3, 4, 6, 23, 31, 32, 35]:

переносу додатків написаних на застарілих мовах на сучасні мови й платформи (наприклад, з мов PL/1, Кобол на мови C++, Java, Visual Basic);

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

засоби автоматизованого добування даних з успадкованих систем;

засоби автоматизованого добування знань про успадковані системи;

засоби оптимізації (реструктуризації) успадкованих систем при їхньому переносі на сучасні мови й платформи (як на рівні програмного коду, так і на рівні архітектури ІС);

різні засоби аналізу програмного коду.

 

Корисна класифікація інструментальних засобів дається в [31]. У рамках цієї класифікації виділяються такі типи засобів, як

реінжинірингу бізнес процесів;

перетворення імен даних;

реінжинірингу даних (БД);

прямого інжинірингу;

перетворення форматів;

реструктуризації;

зворотного проектування;

трансляції вихідного коду;

і ін.

У цій же роботі авторами приводяться характеристики інструментальних засобів реінжинірингу ІС. Для кожного з них специфікується ім'я програмного продукту; вимоги до апаратної й програмній платформі; координати компаній – постачальників; підтримувані мови програмування, СУБД, платформи; приналежність до того або іншому типу засобів.

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

На теперішній час у процесі досліджень не було виявлено цілісних методологій і технологій реінжинірингу ІС, відповідних до рівня пророблення й області охвату RUP [24, 25]. Найбільшою мірою ця проблема досліджується в [1, 8, 15, 33]. У той же час, в [1] пропонується лише каркас, що визначає основний хід робіт, в [8] даються рекомендації з виконання основних видів діяльності по реінжинірингу. В [33] визначаються лише процеси оцінки успадкованих систем, а в [15] основну увагу приділяється питанням технічного характеру, при цьому основний акцент зроблений на вирішення проблем інтеграції систем, у той час як методи аналізу успадкованої системи практично не розглядаються.

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

оцінку стану в області методологічного й технологічного забезпечення реінжинірингу ІС;

адаптацію й розробку методологій і технологій реінжинірингу ІС.

 

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

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

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

 

Висновки

 

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

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

поняття «реінжиніринг ІС» різними дослідниками дотепер трактується по різному, існує безліч близьких понять, наявність яких приводить до появи зовні одмінних, але по суті схожих підходів, методів і технологій;

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

спостерігається розрив між рішеннями концептуального характеру й рішеннями, спрямованими на розв'язок конкретних прикладних завдань;

відсутня чіткий взаємозв'язок між методами/технологіями реінжинірингу й методологіями розробки ІС «з нуля».

 

У ситуації, що склалася, актуальними завданнями стають:

уніфікація, а можливо, і стандартизація поняття «реінжиніринг ІС», інших пов'язаних з ним понять;

розробка цілісних методологій реінжинірингу ІС;

розробка засобів адаптації методологій реінжинірингу ІС у реальних проектах;

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

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

 

Література.

1. John Bergey, William Hefley, Walter Lamia, Dennis Smith A Reengineering Process Framework, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1995.

2. Santiago Comella-Dorda, Kurt Wallnau, Robert C. Seacord, John Robert A Survey of Legacy System Modernization Approaches, Software Engineering Institute (Technical Note CMU/SEI-200-TN-003, 00tn003.pdf), Pittsburgh, 2000.

3. Rick Kazman, S. Jeromy Carriere Playing Detective: Reconstructing Software Architecture from Available Evidence. Technical Report CMU/SEI-97-TR-010. Pittsburgh, 1997.

4. Rick Kazman, S. Jeromy Carriere View Extraction and View Fusion in Architectural Understanding, Proceedings of the Fifth International Conference on Software Reuse (ICSR), June, 1998, Victoria, BC.

5. Кротов А.А. и Лупян Е.А. Обзор методов реструктуризации и интеграции информационных систем, http://d902.iki.rssi.ru/students/alekro/Dissertation/Papers/Reengineering/my_review.html

6. "Автоматизированный реинжиниринг программ" Сборник статей под ред. А.Н.Терехова и А.А.Терехова Издательство С.-Петербургского университета, 2000.

7. Guo G. Y., Atlee J. M., Kazman R. A Software Architecture Reconstruction Method, Department of Computer Science, University of Waterloo, Software Engineering Institute, Carnegie Mellon University.

8. John Bergey, Dennis Smith, Nelson Weiderman DoD Legacy System Migration Guidelines, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, September 1999.

9. John Bergey, Dennis Smith, Nelson Weiderman, Steven Woods Options Analysis for Reengineering (OAR): Issues and Conceptual Approach, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, September 1999.

10. Weiderman N., Nelson H., Bergey John K., Smith Denis B., & Tilley Scott R. Approaches to Legacy System Evolution, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213, 1997 (CMU/SEI-97-TR-014)

11. Ransom J., Sommerville I., & Warren I. A Method for Assessing Legacy Systems for Evolution, Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering (CSMR98), 1998

12. Bisdal Jesus, Lawless Deirdre, Wu Bing, Grimson Jane, Wade Vincent, Richardson Ray, & O'Sullivan D. An Overview of Legacy Information System Migration, APSEC 97, ICSC 97, 1997

13. John K. Bergey, Linda M. Northrop, Dennis B. Smith Enterprise Framework for the Disciplined Evolution of Legacy Systems, SEI CMU October 1997.

14. Энн Мак-Крори Что такое унаследованные системы?, Computerworld, США, 1998.

15. Michael L. Brodie, Michael Stonebraker Migrating Legacy Systems. Gateways, Interfaces & The Incremental Approach, Morgan Kaufmann Publishers, Inc., 1995

16. Weiderman N., Northrop L., Smith D., Tilley S., Wallnau K. Implications of Distributed Object Technology for Reengineering, CMU/SEI-97-TR-005, SEI CMU June 1997.

17. Tilley S. A Reverse-Engineering Environment Framework, SEI CMU April 1998

18. Bergey J., Smith D., Tilley S., Weiderman N., Woods S. Why Reengineering Projects Fail, SEI CMU April 1999.

19. Kazman R., O'Brein L., Verhoef Ch. Architecture Reconstruction Cuidelines, SEI CMU August 2001.

20. Kazman R., Woods S., Carriere S. Requirements for Integrating Software Architecture and Reengineering Models: CORUM II, SEI CMU, October 1998.

21. Carriere S.J., Woods S. Kazman R. Software Architectural Transformation, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, October 1999.

22. John Bergey, Dennis Smith, Nelson Weiderman DoD Software Migration Planning, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, August 2001.

23. www.ispras.ru

24. Kruchten P. The Rational Unified Process: an introduction. Reading: Addison Wesley, 1999.

25. Rational Unified Process, version 2002.05.00.25, Rational Software Corporation.

26. Ducasse S., Richner Т, Nebbe R. Type-Check Elimination: Two Object-Oriented Reengineering Patterns, Proceedings WCRE, 1999.

27. Demeyer S., Ducasse S., Nierstrasz O. Object-Oriented Reengineering Patterns, Morgan Kaufmann Publishers, Inc., 2002.

28. Ducasse S., Demeyer S., Nierstrasz O. A Pattern Language for Reverse Engineering, Proceedings of EuroPLoP, 2000.

29. Pooley R., Stivens P. Software Reengineering Patterns, University of Edinburg, Department of computer science, http://www.reengineering.ed.ac.uk/.

30. Dewar R. Characteristics of Legacy System Reengineering, The University of Edinburgh, Division of Informatics, http://www.reengineering.ed.ac.uk/.

31. Olsem M. R., Sittenauer Ch. Reengineering, Software Technology Support Center, Technology Report, Volume 2, April 1995, http://www.stsc.hill.af.mil/reng/.

32. Ducasse S., Lanza M, Tichelaar S. The Moose Reengineering Environment, University of Berne, Software Composition Group, 2001.

33. Software Reengineering Assessment Handbook, Technical Report, Version 3.0, 1997, http://www.stsc.hill.af.mil/

34. Sander T. Modeling Object-Oriented Software for Reverse Engineering and Refactoring, Thesis, University of Bern, 2001.

35. Ducasse S. Rґetro-Conception d'Application `a Objets Reengineering Object-Oriented Applications, Universitґe Pierre et Marie Curie, 2001.

36. The FAMOOS Object-Oriented Reengineering Handbook, http://www.iam.unibe.ch/_famoos/handbook/.

37. Olsem M. R., Sittenauer Ch. Reengineering, Software Technology Support Center, Technology Report, Volume 1, April 1995, http://www.stsc.hill.af.mil/reng/.

38. IEEE Computer Society TCSE, 1990, http://tcse.org/.

39. Стандарт ANSI/IEEE Std. 729-1983.

40. Joint Logistic Commanders Computer Resources Management group (JLC/CRM), 1992, http://www.stsc.hill.af.mil/reng/.