ого забезпечення.
.4 Архітектура програмного забезпечення та ее рефакторінг
3.4.1 Архітектура програмного забезпечення
У Данії годину не існує загальнопрійнятого визначення терміна «архітектура програмного забезпечення». У тієї ж годину, існує велика кількість різніх визначеня цього Поняття, что мают Багато в чому схожий сенс. Як приклад можна навести Наступний визначення: архітектура програмного забезпечення - це первинна організація системи, сформована ее компонентами, відносінамі между компонентами и зовнішнім СЕРЕДОВИЩА системи, а такоже принципами, что візначають дизайн и еволюцію системи
3.4.2 навіщо міняті архітектуру програмного забезпечення?
Потреба у зміні існуючого програмного забезпечення может вінікнуті в ході Вирішення широкого кола Завдання по его модернізації. У загально випадка Зміни існуючого програмного забезпечення здатні торкнути НЕ Тільки его код, альо й ВСІ Інші артефакти, пов'язані з трансформованості програмних системою. Однією з найбільш істотніх різновідів тут є зміна архітектури програмної системи. У якості прікладів можна навести Такі Сценарії, что вімагають Зміни архітектури існуючого ПЗ:
Перетворення, зумовлені функціональнімі змінамі ПЗ. Бажано, щоб Впровадження Нової функціональності НЕ торкнуло існуючу логіку системи. Такоже бажано, щоб складність Впровадження Нової функціональності в існуючу систему НЕ перевіщувало істотнім чином складність реалізації цієї функціональності в рамках нового проекту. Гарна архітектура дозволяє досягті поставлених цілей. Отже, зміна існуючої архітектури - хороший крок на шляху Впровадження Нової функціональності, до того ж полегшує и подалі еволюцію системи.
Зміна платформи ПЗ. Вкрай бажано, щоб зміна платформи ПЗ як можна менше торкнуло існуючій код, и щоб можна Було обмежитися змінамі Тільки у вузькій переносних залежних прошарку системи. Віділення такий прошарку - архітектурна Завдання. Ее решение всегда пов'язане з необхідністю Зміни архітектури.
Перетворення, пов'язані з реорганізацією Компанії, что веде розробка. Прикладом, Такої реорганізації может стать аутсорсинг. Рішення про Використання аутсорсингу - Типове крок по оптімізації виробництва. На жаль, цею крок часто ускладнюється проблемою.Більше віділення и передачі компонентів для зовнішньої розробки. Зміна архітектури програмної системи здатн полегшіті Вирішення цього Завдання.
Список сценаріїв прізводять до спожи у зміні архітектури існуючого ПЗ на цьом НЕ вічерпується: наведені Вище Приклади поклікані позбав продемонструваті широкий спектр Завдання, Які обумовлюють необхідність подібніх змін.
Висновок
У рамках діпломної роботи булу розроблено программа - графічний редактор «MISC_Paint».
Графічний редактор є спрощений аналогом Paint, має англомовній інтерфейс, тому может використовуват широким колом Користувачів. Однак, не Дивлячись на свою простоту, редактор володіє рядом й достатньо таки складних функцій, Які НЕ реалізовані в стандартному редакторі Paint, Наприклад, вертикальний и горизонтальний поворот малюнки, Перетворення кольорового зображення в чорно-біле або фарбування в бежеві тони и т. д.
