litceysel.ru
добавить свой файл
1
Київський національний університет імені Тараса Шевченка.


Факультет кібернетики. Кафедра моделювання складних систем.


Реферат

на тему:



Удосконалення програмних систем. (Виявлення «вузьких місць».

Методи удосконалення програм.)


Студентки V курсу, кафедра МСС

Овсієнко Н. А.


Київ-2007

Зміст


1. Процеси життєвого циклу програмного забезпечення 3

2. Удосконалення програмних систем 4

2.1. Необхідність ухвалення рішень по модернізації комплексу технічних і програмних засобів 4

2.1.1. Дослідження інформаційної системи для виявлення «вузьких місць» 4

2.1.2. Технології і методи, вживані для виявлення критичних ділянок обробки інформації 5

2.1.2.1.Тестування 5

2.1.2.2. Інструментальні засоби, вживані для оптимізації програмних систем 6

2.2. Методи удосконалення програм 9

2.2.1. Рефакторінг архітектури програмного забезпечення 10

Література: 13

1. Процеси життєвого циклу програмного забезпечення



У 1997 році Міжнародна Організація по Стандартизації - ІСО (International Organization for Standadization - ISO) і Міжнародна Електротехнічна Комісія - МЕК (International Electrotechnical Comission - IEC) створили Сумісний Технічний Комітет з Інформаційних Технологій - Joint Technical Committee (JTC1) on Information Technology. Зміст робіт JTC1 визначений як “стандартизація в області систем і устаткування інформаційних технологій (включаючи мікропроцесорні системи)”. У 1989 році цей комітет ініціював розробку стандарту ISO/IEC 12207, створивши для цього підкомітет SC7 (SuСommittee 7) по програмній інженерії. Відповідний стандарт вперше був опублікований 1-го серпня 1995 року під заголовком “Software Life Cycle Processes” – “Процеси життєвого циклу програмного забезпечення.

Даний стандарт визначає життєвий цикл як структуру декомпозиції робіт. Деталізація, техніка і метрики проведення робіт – питання програмної інженерії. Організація послідовності робіт – модель життєвого циклу. Сукупність моделей, процесів, техніки і організації проектної групи задаються методологією. Зокрема, вибір і застосування метрик оцінки якості програмної системи і процесів знаходяться за рамками стандарту 12207, а концепція вдосконалення процесів розглядається в стандарті ISO/IEC 15504 “Information Technology - Software Process Assessment” (“Оцінка процесів <в області> програмного забезпечення).


Основні процеси життєвого циклу - Primary Processes


1.1. Замовлення - Acqusition

1.2. Постачання - Supply

1.3. Розробка - Development

1.4. Експлуатація - Operation

1.5. Супровід – Maintenance


1.3. Процес розробки (Development) включає етапи:


  • Аналіз системних вимог

  • Системне проектування.

  • Аналіз вимог до програмного забезпечення.

  • Проектування програмного забезпечення.

  • Детальне проектування програмного забезпечення.

  • Програмування та «отладка».

  • Інтеграція програмного забезпечення.

  • Кваліфікаційне тестування програмного забезпечення.

  • Системна інтеграція.

  • Кваліфікаційне тестування системи.

  • Інсталяція ПЗ.


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



Мал. 1. Модель ітеративного процесу розробки ПЗ.

2. Удосконалення програмних систем

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

Необхідність ухвалення даного рішення виникає в двох випадках:


  1. Система (на етапі тестування), що розробляється нами, не відповідає технічному завданню;

  2. Необхідно удосконалити існуючу працюючу систему.

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

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


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

  • поточний стан ринку технічних і програмних засобів;

  • інформацію про виробників ПЗ (програмного забезпечення) і засобів обчислювальної техніки і їх номенклатурі;

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

  • відомості про постачальників технічних засобів і ПЗ (номенклатура, рівень цін, надійність, рівень сервісу і тому подібне).



2.1.1. Дослідження інформаційної системи для виявлення «вузьких місць»


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

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

  • визначення напрямів потоків даних, що склалися;

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


  • визначення вимог до надійності роботи системи і надійності зберігання даних;

  • визначення вимог до захисту від несанкціонованого доступу до даних і інших вимог;

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

2.1.2. Технології і методи, вживані для виявлення критичних ділянок обробки інформації


Зазвичай для пошуку вузьких місць використовують - моделювання та тестування.
        1. Тестування


На практиці зазвичай використовуються такі види тестування:

  • Тестування продуктивності

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

  • Тестування навантаження

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

  • Тестування надійності

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

  • Функціональне тестування

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


  • Регресійне тестування

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

  • Конфігураційне тестування

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

Детальніше зупинимося на тестуванні продуктивності «производительности».

Схемний цикл тестування продуктивності виглядає так:

  • планування аналізу продуктивності

  • створення ефективних сценаріїв навантажень

  • виконання сценаріїв навантажень

  • аналіз зібраних даних для визначення і усунення "вузьких" місць

Планування аналізу продуктивності

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

Створення ефективних сценаріїв навантажень

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


Виконання сценаріїв навантажень

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

Аналіз результатів тестування продуктивності

Фаза аналізу починається після того, як виконані тести навантажень і зібрані їх результати. Основна мета аналізу - ефективне виявлення "вузьких" місць і пропозиція способів для досягнення максимальної продуктивності.

2.1.2.2. Інструментальні засоби, вживані для оптимізації програмних систем


1). Intel VTune 7.0 (або Intel VTune Enterprise);

Пакет VTune версії 7.0, сумісний з середовищем розробки Microsoft Visual Studio .NET, дає розробникам можливість оптимізувати програмні системи і драйвери пристроїв під ОС Windows Server 2003 і платформ під управлінням ОС Windows на базі процесорів Intel.
Пакет VTune Enterprise версії 2.0 для Web.(NET Edition) дозволяє знаходити "вузькі місця" в багаторівневих застосуваннях, що працюють на комплексах систем з процесорами Intel, і надає можливості аналізу роботи Web-інфрастуктури на рівні транзакцій і діагностики на рівні об'єктів .NET.

Аналізатор продуктивності VTune Performance Analyzer збирає, аналізує і відображає дані про продуктивність програмного забезпечення в найширшому діапазоні - від рівня всієї системи до рівня окремої функції, модуля або команди в початковому коді. Цей пакет допомагає розробникам спростити виявлення потенційних "вузьких місць" і істотно підвищити продуктивність і конкурентоспроможність їх застосувань. VTune Performance Analyzer дозволяє розробникам, Microsoft Visual Studio, ретельніше досліджувати початковий код програмних систем, щоб заздалегідь усунути "вузькі місця", а потім оптимізувати код так, щоб скомпільоване застосування працювало на платформах Intel з максимально можливою продуктивністю. Пакет має в своєму розпорядженні призначений для користувача інтерфейс і вдосконалену функціональну схему, в нього включена підтримка багатопотокового режиму, завдяки якій розробники можуть проводити відладку програмних систем для забезпечення повної сумісності з передовою технологією багато потокової обробки команд Hyper-Threading. Інтегрований компонент Intel Tuning Assistant надає розробникові докладну інформацію про систему і початковий код, засновану на показниках роботи операційної системи і процесора.


2). IBM Tivoli

Вирішення Tivoli для управління програмними системами допомагає:


  • Своєчасно виявляти і попереджати виникнення проблем з продуктивністю для кінцевих користувачів

  • Підтверджувати рівень сервісу транзакцій з погляду кінцевого користувача

  • Швидко ізолювати, виявляти і усувати проблеми в роботі програмних систем

  • Забезпечити комплексне управління роботою критичних для бізнесу багато-платформених систем (для z/OS і J2EE, CICS, IMS і тому подібне)

  • Підвищити готовність програмних систем

  • Усунути проблеми в ході розробки і тестування програмних систем

  • Підвищити продуктивність роботи співробітників завдяки швидшому виявленню і дозволу проблем

  • Скоротити витрати на експлуатацію і технічну підтримку

Вирішення Tivoli охоплює всі три напрями ефективного управління прогамними системами:

  • Транзакції – час відгуку і ізоляції проблеми відповідно до рівня сервісу IBM Tivoli Composite Application Manager for Response Time Tracking – швидко виявляє «вузькі» місця і ізолює джерела їх появи. (IBM Tivoli Composite Application Manager for SOA – управляє і контролює веб-сервер – сервіси)

  • Програмні системи – глибинна діагностика і можливість кореляції в рамках декількох підсистем. (IBM Tivoli Composite Application Manager for WebSphere – забезпечує діагностику для J2EE, CISC, IMS програмних систем).

  • Моніторинг ресурсів – моніторинг роботи серверів програмних систем і споживання ресурсів (IBM Tivoli OMEGAMON XE for WebSphere Business Integration)

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


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

3). KLOCwork Architect

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

Моделі програмних систем, використовувані в KLOCwork Architect (надалі моделі), нагадують моделі типу суть-зв'язок (Entity-Relation models). Кажучи строго, вони відносяться до класу контейнерних моделей. Основними елементами моделі є наступні елементи:

Архітектурний блок (Architecture Block). Модель KLOCwork Architect складається з так званих архітектурних блоків. Архітектурні блоки представляють в моделі структурні елементи програмної системи, незалежно від рівня абстракції, на якому йде моделювання. Архітектурні блоки мають, щонайменше два основними атрибутами: ім'я і тип. Імена архітектурних блоків зумовлюються іменами тих структурних елементів системи, які вони представляють в моделі. Типи архітектурних блоків істотно залежать від рівня абстракції, на якому відбувається моделювання, і конкретного завдання, в рамках якого проводяться дослідження архітектури. Наприклад, при моделюванні систем, побудованих в рамках компонентних технологій, основним використовуваним типом архітектурних блоків є “компоненти. При моделюванні системи збірки ПЗ основними використовуваними типами є “папки і “файли.

Відношення (Relation). У моделі KLOCwork Architect під відношенням розуміється односторонній зв'язок між парою архітектурних блоків. Так само, як і архітектурні блоки, стосунки можуть бути різних типів. Як приклад можна привести наступні типи стосунків:

  • Інстанциация: A «инстанциирует» B (блок A – функція, блок B – клас).


  • Доступ до даних: A читає дані з B (блок A – функція, блок B – клас або атрибут класу).

Між будь-якою парою блоків в моделі може існувати довільна кількість різноспрямованих стосунків, при цьому їх типи також можуть розрізнятися.

Приклад моделі. Як ілюстрація розглянемо мікроскопічну тестову систему на мові C і модель, автоматично отриману з неї системою Architect. Система має наступну структуру:

  • Тека test, що містить:

Файл a.h, що містить текст

void а();

Файл а.cpp, текст, що містить

#include "а.h"

void a() {

int а = 0; a++;



Для подібної системи модель, що витягує автоматично, матиме наступну структуру:


Таблиця 1.

Коренева діаграма




Містить:

  • Ім'я блоку: test, тип: DIRECTORY



Діаграма




Містить:

  • Ім'я блоку: а.cpp, тип: FILE

  • Ім'я блоку: b.cpp, тип: FILE

  • Відношення між а.cpp і a.h, тип INCLUDES

  • Відношення між а.cpp і a.h, тип DECLARED-BY



Діаграма а.cpp




Містить:
  • Ім'я блоку: а, тип: FUNCTION


  • Витікаюче відношення в блок а з діаграми a.h, тип DECLARED-BY



Діаграма a.h




Містить:

  • Ім'я блоку: а, тип: FUNCTION-DECLARATION

  • Вхідне відношення з блоку а з діаграми а.cpp, тип DECLARED-BY


2.2. Методи удосконалення програм


На даному етапі потрібно ухвалити рішення або переробити архітектуру системи, або переписати критичний модуль в рамках існуючої системи. Існує достатньо багато думок про те, що скільки не займайся оптимізацією системи в цілому, набагато простіше і ефективніше виправити програму. Чи правильно це твердження? І так, і ні. "Так" — оскільки зміни в SQL-запиті можуть підвищити його швидкість в декілька десятків разів, а досягти таких результатів при оптимізації ІС в цілому практично неможливо. "Ні", тому що змінити такий запит не завжди можливо, наприклад, у випадках, коли програма є закритою або такий запит диктується складними бізнес-правилами. Змінити бізнес-правила найчастіше не можна або цей процес може зажадати довгих узгоджень.

Якщо на етапі дослідження системи виявили, що проблема програмної системи полягає в поганому коді і можна виправити його без виправлення бізнес-логіки, необхідно зробіть це!

У необхідності зміну архітектури програмної системи можна привести наступні сценарії (вимагаючи зміни архітектури того, що існує ПЗ):
  • Перетворення, обумовлені функціональними змінами ПЗ. Бажано, щоб впровадження нової функціональності не торкнулося існуючої логіки системи. Також бажано, щоб складність впровадження нової функціональності в існуючу систему не перевищувало істотним чином складність реалізації цієї функціональності в рамках нового проекту. Хороша архітектура дозволяє досягти поставлених цілей. Отже, зміна існуючої архітектури – хороший крок на шляху впровадження нової функціональності, що до того ж полегшує і подальшу еволюцію системи.


  • Зміна платформи ПЗ. Украй бажано, щоб зміна платформи ПЗ якомога менше торкнулася існуючого коду, і щоб можна було обмежитися змінами тільки у вузькому платформено-залежному прошарку системи. Виділення такого прошарку – архітектурне завдання. Її рішення завжди зв'язане з необхідністю зміни архітектури.

  • Перетворення, пов'язані з реорганізацією компанії (яка веде розробку). Прикладом, такій реорганізації може стати аутсорсинг. Рішення про використання аутсорсинга - типовий крок по оптимізації виробництва.

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

2.2.1. Рефакторінг архітектури програмного забезпечення

Вступ


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

2.2.3. Рефакторінг архітектури, основні поняття


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

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


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

Рефакторінг об'єктно-орієнтованої коду зарекомендував себе як ефективний спосіб вирішення завдань еволюції і супроводу програм.

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

2.2.4. Відмінності архітектурного і класичного рефакторингів


При перенесенні методики рефакторинга на рівень архітектури існує ряд особливостей.

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

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


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

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

2.2.5. Фази архітектурного рефакторинга



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

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


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

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

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

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

Література:


1. Архітектура корпоративних програмних застосувань, Мартін Фаулер, Вільямс, М., 2004.


2. Алгоритми: побудова і аналіз, Т. Кормен, Ч. Лейзерсон, Р. Рівест, МЦНМО, М., 2001.


3. Рефакторінг архітектури програмного забезпечення, М.В.Ксензов, ІСП РАН, Препрінт 4, М., 200.