Змістовий модуль 9. Введення до рефакторінгу

Лекція 16. Введення до рефакторінгу

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

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

Основні положення

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

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

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

Причини проведення рефакторінга Існує кілька цілей рефакторінгу.

• Рефакторінг поліпшує композицію ПЗ.

• Рефакторінг полегшує розуміння ПЗ.

• Рефакторінг допомагає знайти помилки в ПЗ.

• Процес рефакторінга передбачає глибокий аналіз коду.

• Рефакторінг допомагає швидше писати програми. Планування рефакторінга

Рекомендується не планувати рефакторінг як самостійний етап в процесі розробки ПЗ, а застосовувати його щораз, коли виникає наступна ситуація:

• необхідно додати в ПЗ нову функцію;

• необхідно виправити помилку в ПЗ;

• у процесі операції розбору коду, який регулярно проводиться в деяких проектних організаціях.

Місце рефакторінга в технологіях створення ПЗ

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

Ознаки ситуацій, що визначають застосування рефакторінга

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

Дублювання коду.

Довгий метод.

Великий клас.

Довгий список параметрів.

Розбіжні модифікації.

Множинні модифікації.

Методи, орієнтовані на дані інших класів.

Групи даних.

Клас, що має занадто мало функцій.

Рідко використовуваний атрибут об'єкта.

Висока зв’язність класів.

Класи, які тільки встановлюють і одержують свої дані.

Відмова від спадкування.

Коментарі.

Принципи реалізації рефакторінгу на рівні програмних модулів

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

· зміна методів і даних;

· переміщення функцій між об'єктами;

· зміна організації даних;

· спрощення умовних виражень;

· спрощення виклику методів; · рішення завдань узагальнення.

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

Рефакторінг і шаблони проектування

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

Контрольні питання

1. Що собою представляє рефакторінг?

2. Коли потрібно виконувати рефакторінг?

3. Які цілі переслідує рефакторінг?

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

5. Що собою представляють процедури виконання рефакторінга?

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

Розглянемо процедуру за назвою «Вбудовування класу» (див. рис. 16.1). Треба перемістити всі функції з вхідного класу в іншій.

Рис. 16.1 Вбудовування класу

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

Послідовність кроків:

· оголошення відкритого протоколу вхідного класу в класі, який його поглине;

· перенос усіх посилань із вхідного класу в поглинаючий клас;

· виконання компіляції й тестування;

· за допомогою процедур «Переміщення методу» і «Переміщення поля» переміщення всіх методів одного за іншим з вхідного класу, поки в ньому нічого не залишиться.

Змістовий модуль 10. Класичні методи конструювання програмного забезпечення

Лекція 17. Методологія функціонального моделювання SADT

Література:1 [16-17]; 3[69-84]; 5

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

Структурний підхід, основні положення

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

· Принцип ієрархічного впорядкування (деревоподібні структури).

· Принцип абстрагування - виділення істотних аспектів системи.

· Принцип несуперечності - обґрунтованість і погодженість елементів системи.

· Принцип структурування даних -дані повинні бути структуровані й ієрархічно організовані.

Метод функціонального моделювання SADT

Метод SADT розроблений Дугласом Россом в 1973р. Використався й використається у військових, промислових і комерційних організаціях.

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

Основні елементи цього методу ґрунтуються на наступних концепціях.

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

Строгість і точність. В SADT є правила, які повинні точно виконуватися. Правила обмежують кількість блоків на кожному рівні декомпозиції (3-6 блоків), вимагають зв’язности діаграм, унікальності міток і найменувань, поділ входів і керувань.

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

Состав функціональної моделі

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

Рис. 17.1 Функціональний блок

Декомпозиція й ієрархія діаграм

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

Рис. 17.2. Загальне подання системи

У більше деталізованому поданні системи можна вказати її основні блоки (рис.

17.3).

Рис. 17.3. Деталізоване подання системи

Кожна з функцій із загального подання системи або більше низького рівня при необхідності може бути розгорнута в окрему діаграму (рис. 17.4).

Рис. 17.4. Ієрархія функцій.

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

Рис. 17.5. Відображення зворотного зв'язку

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

Рис. 17.6. Приклад механізму

Типи зв'язків між функціями

Методика SADT передбачає точну погодженість типів зв'язків між функціями.

Звичайно розрізняють зв'язки семи типів.

Випадковий зв'язок – показує, що конкретний зв'язок між функціями повністю відсутній або незначний.

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

Тимчасовий зв'язок – функції включаються й працюють одночасно, а не послідовно.

На діаграмі цей зв'язок також не позначається.

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

Комунікаційний зв'язок – функції групуються разом, оскільки вони використовують ті самі вхідні дані й/або роблять спільно використовувані вихідні дані.

Послідовний зв'язок – вихід однієї функції служить вхідними даними для наступної функції.

Функціональний зв'язок – функції поєднуються для виконання одного завдання (функції).

Контрольні питання

1. Які принципи лежать в основі структурного підходу конструювання?

2. У чому суть методу SADT?

3. Які концепції лежать в основі методу SADT?

4. У чому полягає декомпозиція і ієрархія діаграм SADT?

5. Які існують зв’язки між функціями у метода SADT?

Лекція 18. Моделювання потоків даних

Література:1 [16-17]; 3[69-84];5

Моделювання потоків даних. Зовнішні сутності. Системи і підсистеми. Процеси. Накопичувачі даних. Потоки даних. Ієрархії діаграм потоків даних. Моделювання даних, метод Баркера. Методологія швидкої розробки ПЗ (RAD).

Основні положення

Діаграми потоків даних DFD (Data Flow Diagrams) є засобом моделювання функціональних вимог до системи, що проектується, а також засобом конструювання системи.

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

Основні компоненти діаграм

Основними компонентами діаграм потоків даних є:

· зовнішні сутності;

· системи/підсистеми; · процеси;

· накопичувачі даних;

· потоки даних;

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

Рис. 18.1 Зовнішня сутність

При побудові моделі складної ІС її можна представити в самому загальному вигляді на так називаній контекстній діаграмі у виді одного елемента (рис. 18.2). Складна ІС може бути декомпозирована на ряд підсистем.

Рис. 18.2 Позначення підсистеми

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

Рис. 18.3 Процес

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

Рис. 18.4 Накопичувач даних

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

Рис. 18.5 Потік даних

Рекомендації щодо побудови діаграм

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

• Розміщати на кожній діаграмі від 3 до 7 процесів. Верхня межа визначена особливостями сприйняття інформації людиною. Нижня — здоровим глуздом.

• Не захаращувати діаграми несуттєвими на даному етапі деталями.

• Декомпозицію потоків даних здійснювати паралельно з декомпозицією процесів.

• Вибирати назви процесів і потоків, що відображають суть перетворень даних.

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

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

Деталізація діаграм

При деталізації діаграм повинні виконуватися наступні правила.

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

• Правило нумерації — при деталізації процесів повинна підтримуватися їхня ієрархічна нумерація. Наприклад, процеси, що деталізують процес із номером 13, повинні мати номера 13.1, 13.2 і т.д.

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

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

• наявності в процесу невеликої кількості вхідних і вихідних потоків(2, 3 потоки);

• можливості опису перетворення даних процесом у виді послідовного алгоритму;

• виконання процесом єдиної логічної функції перетворення вхідної інформації у вихідну;

• можливість опису логіки процесу за допомогою специфікації невеликого об'єму

(не більш 20-30 рядків);

Специфікації повинні задовольняти наступним вимогам:

• для кожного процесу нижнього рівня повинна існувати одна і тільки одна специфікація;

• специфікація повинна визначати спосіб перетворення вхідних потоків у вихідні;

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

• специфікація повинна прагнути до обмеження надмірності — не варто

перевизначати те, що вже було визначено на діаграмі;

• набір конструкцій для побудови специфікації повинний бути простим і зрозумілим.

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

Співвідношення застосування розглянутих двох моделей структурного аналізу складає 90% для DFD і 10% для SADT.

Використання функціональних моделей на стадії конструювання

На стадії проектування функціональні моделі уточнюються. Розширюються і доповнюються новими конструкціями.

Наприклад, для DFD перехід від моделі бізнес-процесів до моделі системних процесів може відбуватися в такий спосіб:

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

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

• процеси на діаграмі нульового рівня заміняються відповідними процесорами — обробними пристроями (процесорами можуть бути як технічні пристрої — персональні комп’ютери (ПК) кінцевих користувачів, робочі станції, сервери баз даних, так і службовці-виконавці);

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

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

• визначаються типи зв'язків між задачами;

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

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

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

• на DFD вибираються інтерактивні процеси нижнього рівня. Для кожного з них потрібно визначити екранну форму;

• форма діаграми зображується у виді прямокутника для кожного інтерактивного процесу на нижньому рівні діаграми;

• визначається структура меню. Для цього інтерактивні процеси групуються в меню (або так само, як у моделі процесів, або іншим способом — по функціональних ознаках або в залежності від належності до визначених об'єктів);

• форми з меню зображується над формами, що відповідають інтерактивним процесам, і з'єднуються з ними переходами у виді стрілець, спрямованих від меню до форм;

• визначається верхня форма (головна форма програми користувача), що зв'язує усі форми з меню.

Контрольні зпитання

1. Для чого використовуються діаграми потоків даних?

2. У чому полягає основна ідея побудови діаграм потоків даних?

3. Що собою представляють зовнішні сутності на діаграмі?

4. Що собою представляють системи/підсистеми на діаграмі?

5. Що собою представляють процеси на діаграмі?

6. Що собою представляють накопичувачі даних на діаграмі?

7. Що собою представляють потоки даних на діаграмі?

8. Для чого потрібна деталізація діаграм?

9. Про що говорить правило балансування?

10. Про що говорить правило нумерації?

11. До якого ступеня варто робити деталізацію діаграм?

12. Яким вимогам повинні задовольняти специфікації, побудовані на основі діаграм потоків даних?

13. Як використовуються діаграми потоків даних на стадії конструювання?

Приклади побудови діаграм

Як приклад розглянемо побудову діаграм потоків даних для видеобібліотеки (ВБ).

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

• якщо клієнт не є членом бібліотеки, він не має права на оренду;

• якщо необхідний фільм є в наявності, адміністрація інформує клієнта про орендну оплату;

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

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

Рис. 18.6 Початкова діаграма потоків даних

Рис. 18.7 Розгорнута діаграма потоків даних