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