- •Питання
- •Проектування пз – проектування, цілі проектування, вимоги до пз
- •Життєвий цикл пз
- •Моделі життєвого циклу (1)
- •3. Моделі життєвого циклу(2)
- •Цілісність даних та надійність
- •Шаблони проектування
- •Класифікація архітектур пз
- •Обробка помилок, виключень та небажаних умов
- •Діаграми подій
- •Зв’язність та зв’язаність (coupling and cohesion)
- •Повторне використання коду
- •11. Ітеративне й інкрементне проектування
- •12.Функціональна методика потоків даних
- •13. Структурна схема розроблюваного пз
- •14. Проектування програмного забезпечення при структурному підході
- •15. Типи компонентних структур та основі означення
- •16. Методологія компонентної розробки пз
- •17. Приклади компонентних середовищ (1)
- •17. Приклади компонентних середовищ (2)
- •18. Планування архітектури (1)
- •1. Архітектура впливає на структуру компанії-розроблювача.
- •2. Архітектура здатна впливати на завдання розроблювача.
- •3. Архітектура може впливати на вимоги, висунуті замовником щодо наступної системи (якщо вона заснована на тій же архітектурі, що й попередня).
- •18. Планування архітектури(2)
- •4. Процес конструювання систем поповнює досвід архітектора.
- •5. Окремі «віхові» системи.
- •19. Програмний процес та архітектурно-економічний цикл (1)
- •19. Програмний процес та архітектурно-економічний цикл(2)
- •20. Архітектурні зразки, еталонні моделі та еталонні варіанти архітектури (1)
- •20. Архітектурні зразки, еталонні моделі та еталонні варіанти архітектури(2)
- •Архітектурні структури і подання
Повторне використання коду
Повторне використання коду - методологія проектування комп'ютерних систем, що полягає в тому, що комп'ютерна система частково або повністю повинна складатися із частин, написаних раніше компонентів та/або частин іншої системи. Повторне використання - основна методологія, що застосовується для скорочення працезатрат при розробці складних систем.
Найпоширеніший випадок повторного використання коду - бібліотеки програм. Бібліотеки надають загальну досить універсальну функціональність, що покриває обрану предметну область.
Модульність систем
Полягає в проектуванні якнайбільш модульних систем. В якості абстракцій, на основі яких можна побудувати модульність системи можуть виступати функції, співпрограма, клас, протокол. Бібліотека функцій гарний приклад абстракції, зручної для реалізації модульності програм і проходження методології повторного використання.
Повторне використання в малому
Іноді повторне використання коду являє собою просте копіювання деякої частини коду з існуючої програми в іншу. Це один із найбільш низькорівневих підходів до повторного використання. Але й він має місце, особливо коли мова йде про повторне використання коду "у малому".
Подібний підхід звичайно не рекомендується до використання, замість цього повторюваний фрагмент програми оформляється у вигляді підпрограми з набором параметрів. Крім того, при копіюванні коду звичайно виникає необхідність у зміні імен змінних, що також часто приводить до механічних помилок. У випадку використання підпрограм подібних перейменувань можна уникнути шляхом використання локальних змінних.
Переваги та недоліки методу повторного використання
Метод повторного використання коду дозволяє швидко будувати нові складні системи із уже налагоджених компонентів.
Підключення до проекту сторонніх бібліотек, у той же час, є і недоліком. Оскільки автоматично приводить до необхідності контролю сумісності версій компонент створюваної системи та версій використовуваних бібліотек. Крім того, часто бібліотеки недостатньо універсальні та не реалізують тієї функціональності, що потрібно створюваній системі, або, навпаки, занадто універсальні й у результаті неефективні, незручні або містять багато надлишкової функціональності.
11. Ітеративне й інкрементне проектування
На кожній ітерації розглядаються нові функції й кожна поточна ітерація ґрунтується на попередній. І якщо буде потрібно, кожну ітерацію можна залишити недоробленою.
Наприклад, якщо багато нових і корисних функцій було відкрито під час розробки, але вони не можуть бути реалізовані, то можна почати проект заново складанням нових вимог на стадії дослідження економічної доцільності. Або, навпаки, деякі функції можуть бути пропущені через обмеженість бюджету або часу. Проект може перейти в постпроектну стадію лише, коли виконані всі поставлені вимоги.
Завдяки ітеративній природі є в наявності належне керування вимогами й конфігурацією протягом усього проекту. Це забезпечує реалізацію всіх вимог, поставлених на ранніх стадіях проекту.
Приклад ітеративного й инкрементного методу
Метод розробки динамічних систем (Dynamіc Systems Development Method, DSDM) - методика розробки програмного забезпечення, заснована на концепції швидкої розробки додатків (Rapіd Applіcatіon Development, RAD) - ітеративний й инкрементный підхід, що надає особливого значення тривалій участі в процесі користувача.
Ціль методу - здати готовий проект вчасно й укластися в бюджет, але в той же час регулюючи зміни вимог до проекту під час його розробки. DSDM входить у сімейство гнучкої методології розробки програмного забезпечення, а також розробок не вхідних у сферу інформаційних технологій.