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

1. Введення


Останнім часом спостерігається тенденція до збільшення тривалості життєвого циклу успішних програмних проектів. Як наслідок, зростає обсяг успадкованого коду, підтримуваного спільнотою розробників [1]. Саме це пояснює виняткову важливість завдань, пов'язаних з полегшенням супроводу та розвитку існуючого програмного коду. У той же час, цим завданням приділяється недостатня увага з боку наукового співтовариства і розробників інструментальних засобів. Як наслідок, сучасні методики переоцінюють значення початкової фази життєвого циклу програмної системи і практично ігнорують її подальшу еволюцію. Таким чином, в даний час існує явний недолік методик та ефективних інструментів підтримки роботи з існуючим кодом.

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

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

2. Архітектура ПЗ та її рефакторинг


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

2.1. Навіщо міняти архітектуру?

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

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

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

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

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

2.2. Як уявити архітектуру і її зміни?

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

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

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

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

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

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


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

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


Читати частина 2

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*