Основи програмної інженерії Омельчук Л Л 1

Основи програмної інженерії Омельчук Л. Л. 1

Поняття програмної інженерії Термін програмна інженерія (Software Engineering) почав вживатись з 1968 року, що засвідчило перехід до розробки програмного забезпечення (ПЗ) чи програмних систем (ПС) на інженерній основі. Програмна інженерія § вивчає питання, пов'язані з розробкою та використанням ПЗ на інженерній основі (систематичність, дисциплінованість, можливість деталізації), охоплюючи всі етапи життєвого циклу; § узагальнює дослідження й досвід у вигляді комплексів знань та правил, що регламентують діяльність по створенню ПС. Омельчук Л. Л. 2

SWEBOK – простір знань програмної інженерії SWEBOK - Software Engineering Body of Knowledge – проект IEEE Computer Society www. swebok. org ЩО ТАКЕ ПРОГРАМНА ІНЖЕНЕРІЯ? The IEEE Computer Society інженерію наступним чином: визначено програмну (1) Застосування систематичного, дисциплінованого, вимірного підходу до розробки, експлуатації, та обслуговуванню ПО – це і є застосування програмної інженерії. (2) Вивчення підходів ПІ, відповідно до (1) В SWEBOK виділено 10 областей знань з програмної інженерії: Омельчук Л. Л. 3

Кожна область знань описується за допомогою підобластей (subarea), що в свою чергу, розбиваються на кілька тем (topic) та підтем (subtopic): · · · · · Виявлення вимог Проектування Реалізація Тестування Супровід Управління конфігурацією Технічне управління Процес розробки Інструментальні засоби та методи Якість ПЗ Омельчук Л. Л. 4

Моделювання у програмній інженерії Існує багато аспектів, пов'язаних з успішною розробкою програмних проектів, і одним з головних є моделювання. І не випадково, загалом, моделювання – загальноприйнята в інженерії методика. Модель – це спрощене представлення дійсності, але важливо, щоб модель M надавала певну уяву про об’єкт моделювання A: "M моделює A, якщо M дозволяє відповідати на запитання відносно A". Чим більша й складніша система, тим важче її "охопити" у цілому, а, отже, тим важливіше моделювання. Розвиток засобів CASE (Computer Aided Software Engineering (автоматизоване проектування та створення ПЗ)), що підтримують моделювання ПС. Моделі § програмних систем; § архітектури ПС; § життєвого циклу. Омельчук Л. Л. 5

§ § § Основні принципи моделювання програмних систем Принцип абстрагування. Система представляється моделлю, що відповідає певному рівню абстракції. Вибір моделі (вибір певного рівня абстракції) визначає те, як будуть осмислюватися проблеми реалізації і які рішення будуть прийматися; Принцип візуальності. Моделі повинні забезпечувати можливість одержувати візуалізоване представлення системи (“одна діаграма заміняє близько 100 сторінок тексту”); Принцип багатомодельності. Не слід обмежуватися єдиною моделлю, якщо система досить нетривіальна. Найкраще використовувати сукупність моделей, що незалежні одна від одної або, іншими словами, що задають різні представлення системи. Принцип ієрархічності (ієрархічної побудови моделей). Цей принцип обумовлює в рамках фіксованих представлень розробляти моделі стосовно до різних рівнів конкретизації (абстрагування). Принцип еволюційності. Як правило, якісна модель системи не є результатом одного акту створення, а отримується шляхом послідовних (еволюційних) уточнень. Омельчук Л. Л. 6

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

Життєвий цикл ПС Неоднорідність (та повторюваність із проекту в проект) робіт, виконуваних при розробці ПС, залежність цих робіт одна від одної, нарешті, колективний характер їх виконання — ось підстави для поетапної організації розвитку ПС, а отже, виділення окремих етапів у життєвому циклі (ЖЦ) ПС. Термін життєвий цикл ПС є фактично запозиченим із традиційних галузей промислового виробництва, де давно використовується поняття життєвого циклу матеріального продукту. Життєвий цикл — це проекція поняття користувача “час життя” на поняття розробника “технологічний цикл (цикл розробки)”. Саме комбінацією цих понять пояснюється походження самого терміну “життєвий цикл”. Розвиток концепцій життєвого циклу пов'язаний з пошуком адекватних моделей для нього. Розходження призначень застосування моделей визначає їх різноманітність. Омельчук Л. Л. 8

Моделі життєвого циклу ПС Найчастіше виділяють наступні п'ять основних етапів ЖЦ: · аналіз і формалізація вимог замовника; · проектування; · реалізація й тестування; · впровадження; · супровід. Іноді виділяють як етапи: · аналіз вимог, · проектування, · кодування (програмування), · тестування та налагодження, · експлуатація й супровід. Часто можна зустріти виділену окремим етапом інтеграцію. Головна особливість індустрії ПЗ складається в концентрації уваги на початкових етапах ЖЦ (аналіз, проектування): невирішені питання й помилки, допущені на етапах аналізу й проектування, породжують на наступних етапах важкі, часто нерозв'язні проблеми і, у кінцевому Омельчук Л. Л. 9 рахунку, призводять до невдачі всього проекту.

Модель послідовного типу (каскадна, водоспад) Омельчук Л. Л. 10

Застосування послідовної моделі. Вимоги до ПС Послідовна модель може застосовуватись, коли: · вимоги до продукту · (1) чітко визначені; · (2) надалі не змінюються; · є досить великий досвід реалізації подібного роду систем. Реалізація проекту за даним типом моделі ЖЦ легко планується й контролюється. ПРОТЕ, як правило: ВИМОГИ ДО ПС ЗМІНЮЮТЬСЯ!!! Таким чином, застосовна! Омельчук Л. Л. послідовна модель 11 в таких випадках не

Реалії розробки більшості ПС Омельчук Л. Л. 12

Реалії розробки більшості ПС (каскадна модель) Омельчук Л. Л. 13

Модифікована каскадна модель За рахунок жорсткості перевірок можна позбавитись прямих відкатів на кілька етапів. Омельчук Л. Л. 14

Календарний план (КП) як модель життєвого циклу ПС КП — це документ, за допомогою якого встановлюються юридичні відносини, що стосуються обсягу, термінів і (найчастіше) ресурсних потреб виконуваних робіт, та який відображає розбиття проектного завдання на етапи, які, як правило, відповідають етапам ЖЦ. (КП є корисним інструментом для менеджера як засіб керування діяльністю розроблювачів). У міру поглиблення декомпозиції й уточнення задач у КП можна уводити нові рядки таблиці. Омельчук Л. Л. 15

Діаграми Ганта - метод планування проектів Являють собою відрізки, розміщені на горизонтальній шкалі часу. Кожен відрізок відповідає окремій задачі чи підзадачі. Задачі і підзадачі, що складають план, розміщуються по вертикалі. Початок, кінець і довжина відрізку на шкалі часу відповідають початку, кінцю та часу виконання задачі. На деяких діаграмах Ганта також показується залежність між задачами. Діаграма може використовуватися для представлення поточного стану виконанння робіт: частина прямокутника, що відповідає задачі, заштриховується, відмічаючи процент виконання задачі; відображається вертикальна лінія, що відповідає моменту «сьогодні» . Одна з реалізацій MS Project. Омельчук Л. Л. 16

Модель Гантера “фази — функції” Надзвичайно важливим мотивом розвитку моделей життєвого циклу програмного забезпечення є потреба в придатному засобі для керування проектом (зокрема, для підтримки функцій менеджера). Для цього використовується накладення на модель не тільки контрольних точок (вони задають організаційно-часові рамки проекту), але і так званих виробничих функцій, виконуваних протягом розвитку проекту. Найбільше послідовно таке доповнення класичної схеми реалізовано в моделі Гантера (1981) у вигляді двох вимірів (ще кажуть матриці) “фази - функції”: фазовий вимір, що відображає етапи виконання проекту і супутні їм події; функціональний вимір, що показує, які виробничі функції виконуються в ході розвитку проекту та яка їх інтенсивність на кожному з етапів. Омельчук Л. Л. 17

Фазовий вимір моделі “фази – функції” Омельчук Л. Л. 18

Фази-функції (модель Гантера) 1) Етап дослідження - починається, коли необхідність розробки визнана керівництвом проекту (контрольна точка 0), полягає в тому, що для проекту обґрунтовуються необхідні ресурси (контрольна точка 1) і формулюються вимоги до розроблювального системи (контрольна точка 2). 2) Аналіз здійснюваності - починається на етапі дослідження, коли визначені виконавці проекту (контрольна точка 1), і завершується твердженням вимог (контрольна точка 3). Ціль етапу - визначити можливість конструювання системи з технічної точки зору (чи досить ресурсів, кваліфікації й т. п. ), чи буде система зручною для практичного використання; рішення питань економічної й комерційної ефективності. 3) Конструювання - починається звичайно на етапі аналізу здійснюваності, як тільки документально зафіксовані попередні цілі проекту (контрольна точка 2), і закінчується твердженням проектних рішень у вигляді офіційної специфікації на розробку (контрольна точка 5). Омельчук Л. Л. 19

Фази (модель Гантера) (продовження) 4) Програмування - починається на етапі конструювання, коли стають доступними основні специфікації на окремі компоненти системи (контрольна точка 4), але не раніше утвердження угоди про вимоги (контрольна точка 3). Сполучення даної фази із заключним етапом конструювання забезпечує оперативну перевірку проектних рішень і деяких ключових питань розробки. Ціль етапу - реалізація програм компонентів з наступною зборкою системи. Він завершується, коли розробники закінчують документування, налагодження й компонування й передають систему службі, що виконує незалежну оцінку результатів роботи (незалежні випробування почалися контрольна точка 7). 5) Оцінка - є буферною зоною між початком випробувань і практичним використанням виробу. Етап починається, як тільки проведені внутрішні (силами розробників) випробування виробу (контрольна точка 6) і закінчується, коли підтверджується готовність виробу до експлуатації (контрольна точка 9). Омельчук Л. Л. 20

Фази (модель Гантера) (продовження) 8) Використання - починається ближче до кінця етапу оцінки, коли готовність виробу до експлуатації перевірена й може організовуватися передача виробу на розповсюдження (контрольна точка 8). Етап триває, поки виріб перебуває в дії й інтенсивно експлуатується. Він пов'язаний із впровадженням, навчанням, настроюванням і супроводом, можливо, з модернізацією виробу. Етап закінчується, коли розробники припиняють систематичну діяльність по супроводу й підтримці даного програмного виробу (контрольна точка 10). Омельчук Л. Л. 21

Функціональний вимір моделі “фази – функції” Перелік (варіантний!) функцій: · Планування · Розробка · Обслуговування · Випуск документації · Випробування · Підтримка використання робочих продуктів · Супровід (для зовнішнього використання продуктів) Поняття інтенсивності функції є принципово невіддільним від стратегії, прийнятої для кожної функції й у кожному специфічному випадку ведення проекту. (Як варіанти можливого розрахунку інтенсивності можна вказати на трудовитрати на виконання функції, питомі трудовитрати, трудовитрати з урахуванням кваліфікаційних вимог, кадрових потреб тощо. Можна, нарешті, використовувати різні показники одночасно). Омельчук Л. Л. 22

Модель Гантера “фази — функції” Омельчук Л. Л. 23

Ітеративність § Врахування змінюваності вимог. (Зміни, “повзучість”, “дрейф” вимог є першоджерелами невдач проектів, оскільки призводять до порушень планів, запізнень і навіть повного “провалу” проектів. ) § Використання зворотного зв’язку з користувачами та замовниками з метою виявлення справжніх вимог. § Неперервна інтеграція, а не “вибух” проблем інтеграції як при “водоспаді”. Загалом, компоненти ПС насправді інтегруються поступово, отже, тут просто доцільно використовувати ітераційний підхід. § Пом’якшення наслідків від реалізації ризиків. Омельчук Л. Л. 24

Ітеративність (продовження) § Можливість навчатись. § Сприяння виробленню стійкої архітектури (слабкі місця виявляються вже на ранніх ітераціях). § Можливість тактичних маневрів (випуск версії з обмеженими функціональними можливостями, але значно раніше – захоплення ринку). § Сприяння більш ранньому виявленню суперечливості вимог, проекту та реалізації. § Неперервне ітеративне тестування дозволяє більш ефективно і точно оцінювати поточний стан розробки Омельчук Л. Л. розробникам накопичувати 25 досвід,

Перехід до ітеративних (ітеративноінкрементних) моделей ЖЦ § § Омельчук Л. Л. Як визначати, що саме має реалізовуватись у кожній з ітерацій? Як гарантувати цілеспрямованість та, зокрема, завершуваність процесу створення ПС? 26

Ітеративна модель ЖЦ Омельчук Л. Л. 27

Моделі еволюційного типу. Інкрементність та ітераційність моделей ЖЦ (“спіраль охоплення предметної області” ) Поступове нарощування можливостей системи по мірі розвитку проекту. Омельчук Л. Л. 28

Інструментальна спіраль Боема Омельчук Л. Л. 29

Спіраль Боема (продовження) Спіраль Боема розкручується на площині, розділеній на чотири квадранти, кожний з яких відповідає за певне коло проектних робіт. Витки спірали позначають розвиток проектної діяльності від центру (початок проекту) до периферії. У квадрантах розкручування спірали передбачаються наступні дії. 1. Визначення цілей, альтернативних варіантів та обмежень: На кожному витку спіралі розробники повинні явно визначити мету та варіанти її досягнення в умовах фіксованих обмежень. У цьому квадранті починається проект, тобто визначається мета проекту та всі аспекти умов його виконання. Наступні витки в даному квадранті повинні зробити явними ті аспекти проекту, які мають потребу в дослідженні та розробці. 3. Розробка й тестування продукту на черговій ітерації: принципово, що роботи в даному квадранті починаються з верифікації й атестації прототипных рішень (сектор "Імітація, моделювання, атестація"). Тільки після подолання цього бар'єру дозволяється подальший рух по спіралі. Омельчук Л. Л. 30

Спіраль Боема (продовження) 2. Оцінка альтернативних варіантів, ідентифікація та оцінка ризиків: у цьому квадранті розроблювачі оцінюють інформацію, отриману при визначенні цілей, варіантів та обмежень. Метод оцінки, запропонований Боемом, полягає в аналізі ризиків, на основі якого готується прототип для вивчення ситуації. Як прототипи можуть виступати програми, документи, схеми та інші матеріали. Прототип або розробляється спеціально (найчастіше), або запозичиться з оточення проекту (для добре пророблених завдань завжди можна знайти набір рішень, придатний для аналізу). Оцінка повинна зачіпати всі сторони проектного рішення, що відноситься як до користувальницьких потреб і ризиків (невиправдані очікування, втрати інвестицій тощо), так і до конкретних методів і прийомів, а також кадрові обставини проекту: рівень досвіду й кваліфікації команди, необхідність організації навчання й т. п. Підставою для оцінки служить вивчення прототипів. Передбачається, що розробка прототипу вимагає витрат менше, ніж пряма реалізація рішення, що перевіряє. Наступні витки і їх прототипи стосуються конкретизованих завдань, що виникають при втіленні вироблених концепцій. 4. Планування наступної ітерації: цей квадрант відповідає за планування робіт проекту, що залежить від накопиченої до цього часу інформації. Принципово, що для планування робіт на основі досягнутих результатів залучаються представники замовника. Омельчук Л. Л. 31

“Модифікована” модель фази-функції (з урахуванням ітеративності для ОО розвитку проекту) Омельчук Л. Л. 32

Технологічні аспекти у моделях ЖЦ (модифікація моделі “фази-функції” для об’єктно-орієнтованого розвитку проекту) У рамках об’єктно-орієнтованого підходу явно виділяється ще один вид технологічного паралелізму: одночасна розробка декількох ітерацій різними групами виконавців. Технологічний паралелізм означає принципову можливість одночасної розробки декількох ітерацій. Однак це не означає їх механічного злиття, оскільки ітерації залежать одна від іншої. Наприклад, неможливе нарощування ще не побудованої системи класів, не можна використати функцію з невідомими умовами її виконання, тощо. Проте, можливо суміщати ітерації коди залежність ослаблена, або гарно описані очікувані результати незавершеної попередньої ітерації. Омельчук Л. Л. 33

Технологічні аспекти у моделях ЖЦ (можливість одночасного виконання різних ітерацій) Омельчук Л. Л. 34

Технологічні аспекти у моделях ЖЦ (можливість одночасного виконання різних ітерацій). Спіраль розвитку Омельчук Л. Л. 35

Застосування еволюційних моделей Даний тип моделей ЖЦ може застосовуватись у випадках, коли: ·вимоги до системи не цілком визначені або будуть змінюватися (“повзучість” вимог); ·відсутній достатній досвід розробки подібних систем; ·використовуються нові технології та/або інструментарії; ·у ході розробки ПС необхідно отримувати й використовувати її проміжні версії. Процес розробки, що є одночасно ітераційним та інкрементним, часто пов'язують із поняттям процесу, керованим ризиками (risk-driven), коли в кожній новій версії серйозна увага приділяється, по-перше, виявленню факторів, що представляють найбільший ризик для успішного завершення проекту, і, по-друге, зведенню ризиків до мінімуму. Омельчук Л. Л. 36

Деякі приклади ризиків § § § § Зрушення графіка постачання – у день передбачуваного постачання ви повідомляєте замовника, що програмне забезпечення буде готовим не раніше ніж через 6 місяців. Проект закрито – після численних зрушень проект закривається, навіть не передаючи його у виробництво. Система “прокисла” - програмне забезпечення було успішно передане у виробництво, але через пару років вартість змін і кількість помилок настільки зросли, що система повинна бути заміщена. Інтенсивність дефектів – систему передано у виробництво, але кількість дефектів настільки велика, що систему не можливо використовувати. Нерозуміння вимог бізнесу – програмне забезпечення передане у виробництво, але воно не вирішує тих задач, що були поставлені спочатку. Зміни вимог бізнесу – програмне забезпечення було передане у виробництво, але вимоги, заради яких воно розроблялось, 6 місяців тому замінили іншими, більш актуальними. Наявність неактуальних можливостей – програмне забезпечення має цілий ряд цікавих можливостей, не потрібних замовнику (не приносять йому грошей). Плинність кадрів – через два роки роботи над проектом усі досвідчені програмісти починають ненавидіти розроблювану програму і йдуть із фірми. Омельчук Л. Л. 37

CASE-системи та UML Сьогодні універсальні CASE - системи будуються з розрахунку не загального призначення, а в рамках застосування розвинених, але всетаки спеціальних методологій. Безумовний прогрес у даній сфері досягнуто для проектування, орієнтованого на моделювання на етапах аналізу й конструювання. У рамках об’єктно-орієнтованого підходу розроблена спеціальна уніфікована мова моделювання UML (Unіfіed Modelіng Language ), що розглядається як основа проектування в методології ітеративного нарощування можливостей об’єктноорієнтованих програмних систем. На базі цієї мови побудовано низку CASE -систем загального призначення з досить розвиненими засобами. Найбільш помітної з них є Ratіonal Rose фірми Ratіonal Software, що запропонувала на ринок не тільки інструментарій для використання UML, але й комплексну методологію виробництва систем - Ratіonal Unіfіed Processіng (RUP). Дана методологія претендує на охоплення всіх аспектів технологій сучасного програмування. В якості CASE -системи Ratіonal Rose має безліч засобів, дуже корисних для підтримки зв'язку перших етапів проектування з етапом кодування, а також з етапом оцінки. Зокрема, перевіряється, що моделювання на різних етапах погоджено, що модельні угоди, визначення класів, інших елементів моделей й їхніх взаємозв'язків несуперечливі. Рівень автоматичного аналізу високий настільки, що дозволяє будувати по моделях «заготовки» програмного коду, що включають у себе описи класів та їх методів в тому вигляді, який можна витягти з моделей. Омельчук Л. Л. 38

Rational Unified Process IBM Rational Unified Process — процес, керуємий на основі прецедентів. Т. б. як метод опису функціональних вимог до системи, а для подальшого планування та оцінки виконання робіт використовуються сценарії використання. Сценарії використання дозволяють легко виявити реальні потреби майбутніх користувачів системи та відсліджувати повноту опису цих вимог. Вони гарантують виконання вимог замовника до ПС. Крім того, використання завершених сценарії в якості одиниці виміру прогресу допомагає уникнути неадекватної оцінки ступеню виконання проекту виконавцем. Омельчук Л. Л. 39

Два виміри процесу розробки ПС із позицій Rational Unified Process Перший вимір представляє статичний аспект процесу: він описується в термінах потоків робіт чи технологічних процесів (виконавці, дії тощо). Другий вимір представляє динамічний аспект процесу і виражається в часових термінах: циклів, ітерацій і фаз (стадій). Увесь життєвий цикл програми розбивається на еволюційні цикли, кожний з яких має справу з новим поколінням продукту. У Rational Unified Process визначаються чотири послідовних стадії (фази) ПС: · · Задум (початок) Уточнення (аналіз, дослідження) Конструювання (побудова) Впровадження Омельчук Л. Л. 40

Два виміри процесу розробки ПС із позицій Rational Unified Process Омельчук Л. Л. 41

Динамічний аспект RUP. Чотири стадії (фази), чотири віхи RUP Перша фаза – фаза задуму (або початку) – завершується віхою “Вимоги життєвого циклу”. (Віха LCO – lifecycle objective). Друга фаза – фаза уточнення завершується віхою “Архітектура життєвого циклу”. (Віха LCA – lifecycle architecture). Третя фаза – фаза конструювання (або реалізації) завершується віхою “Початкова працездатність”. (Віха IOC – initial operational capabiliny). Четверта фаза – фаза переходу (або передачі, розгортання) завершується віхою “Випуск продукту”. (Віха PR – product release). Омельчук Л. Л. 42

Програмна архітектура (ПА) Усі розуміють важливість ПА (архітектуру має будь-яка ПС, не залежно від того, чи розроблялась архітектура цілеспрямовано, чи ні!), та не завжди акцентують на неї увагу. Причини: § § мета ПА не завжди піддається чіткому формулюванню; § § не існує загального способу представлення ПА; концепція ПА не завжди чітка (це десь між керуванням вимогами та поняттям системи); не описано процес розробки ПА ("чорна магія"). Разом із тим, відсутність ПА чи неякісна ПА є основним технічним ризиком програмних проектів. Омельчук Л. Л. 43

Поняття програмної архітектури Припустимо, треба описати систему таким чином, щоб зацікавлені особи (розробники, програмісти, користувачі, замовники) змогли б: § § § зрозуміти, що робить система; § розширити систему. зрозуміти, як працює система; попрацювати з частиною системи, зокрема, використати повторно; Грубо – відповідний опис (ПА) робить систему зрозумілою (зрозуміло що і як вона робить). Іноді з опису вилучають частини. Архітектура – це коли вилучити більше нічого не можна, щоб система лишалася зрозумілою. Модель – не архітектура (моделі складних систем можуть бути дуже великими). Омельчук Л. Л. 44

Термінологія ПА Більшість означень ПА ґрунтуються на поняттях: § статична структура ПС (елементи ПС та відношення між ними); § динамічна структура ПС (відношення, що представляють динамічні аспекти); § § § композиція чи декомпозиція ПС (підсистеми, модулі); § § § стиль, що визначає розробку та розвиток ПС; компоненти та їх взаємодія; рівні та їх взаємодія; організація фізичного розгортання елементів ПС; деякі обмеження на ПС (оточення, мова програмування, тип СУБД тощо); функціональні можливості ПС; інші аспекти (повторне використання, продуктивність, масштабованість); Омельчук Л. Л. 45

Представлення архітектури. Що дає архітектура? Наведені різні означення ПА відображають складність та багатовимірність поняття ПА. Зрозуміло, що для різних зацікавлених сторін важливими є різні аспекти ПА. Як наслідок, використовуються різні представлення однієї й тієї ж ПА. Архітектура: § § спрощує розуміння ПС; § надає ефективну використання; § надає можливість управління проектом (наприклад, організувати планування, кадрове забезпечення – за рівнями, підсистемами). дозволяє отримати повний інтелектуальний контроль на всіх етапах ЖЦ ПС, забезпечуючи гнучкість та адаптивність ПС, спрощуючи розробку та супровід; Омельчук Л. Л. основу широкомасштабного 46 повторного

Модель архітектури “ 4+1” Статична складова Представлення системи з погляду проектування погляду реалізації (структурні відношення, (складання, відношення між функціональність, словник) компонентами) кінцевий користувач програміст Представлення системи з погляду прецедентів (поведінка) Представлення системи з з погляду процесів погляду розгортання (продуктив-ність, (топологія системи) масштабування, про-пускна системний адміністратор спроможність) системний інтегратор Динамічна складова Логічна складова Фізична складова Омельчук Л. Л. 47