Презентація на тему:
Інженерія програмних систем

Інженерія програмних систем 2004 (Курс “Інформаційні технології”) Інженерія програмних систем - 2004

Головна практична мета Головна практична мета - отримати знання та практичні навички стосовно розробки програмних систем з використанням UML та Rational Rose. Триєдина задача: Технології проектування та розробки програмних систем (ПС) Уніфікована мова моделювання UML (Unified Modeling Language) як засіб проектування ПС Rational Rose як CASE-засіб, що підтримує UML Інженерія програмних систем - 2004

Інженерія програмних систем 1. Основні етапи життєвого циклу (ЖЦ) ПС. Варіанти (моделі) ЖЦ. 2. Використання моделювання. 3. Структурний та обєктно-орієнтований підходи до проектування ПС. 4. CASE-технології; 5. Архітектура ПС, представлення (вигляди) архітектури. Інженерія програмних систем - 2004

Розробка програмних систем як промислове виробництво Розробка програмного забезпечення на сьогодні розглядається не інакше, як промислове виробництво. Метою такого виробництва є створення спеціального промислового продукту – програм або, як ще говорять, програмного продукту. В основі будь-якої галузі промислового виробництва, у тому числі й у промисловому виробництві програмних продуктів лежить технологічний процес. Більшість характеристик програмного продукту – якість, вартість, терміни створення, об'єм – безпосередньо визначаються технологією розробки. Інженерія програмних систем - 2004

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

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

Аналіз вимог На цьому етапі вимоги замовника уточнюються, формалізуються і документуються. Фактично потрібно отримати відповідь на питання: "Що повинна робити майбутня ПС?". Саме тут лежить ключ до успіху всього проекту. Список вимог до розроблювальної ПС повинен включати: функціональність - опис виконуваних системою функцій; контекст - склад людей та інших систем, що мають безпосередні стосунки з розроблюваною системою; інтерфейси і розподіл функцій між людиною і системою; сукупність умов, при яких передбачається експлуатація ПС (апаратні і програмні ресурси, зовнішні умови функціонування). Метою аналізу є перетворення загальних, неясних знань про вимоги до майбутньої системи в точні (по можливості) визначення. На цьому етапі закладається архітектура системи. Інженерія програмних систем - 2004

Проектування Етап проектування має дати відповідь на питання: "Як (яким чином) система забезпечуватиме виконання поставлених до неї вимог?". Задачею цього етапу є дослідження структури системи і логічних взаємозв'язків між її елементів, одержання логічної моделі системи та специфікацій її компонент у відповідності до визначених вимог. Іноді цей етап поділяють на два підетапи: проектування архітектури ПС (включаючи розробку структури та узгодження функціональності і вимог до її окремих компонентів); детальне проектування ПС, що включає розробку специфікацій кожного компонента, уточнення інтерфейсів між компонентами, розробку вимог до тестів і плану інтеграції компонент. Інженерія програмних систем - 2004

Моделі (варіанти) життєвого циклу програмних систем Виділення окремих етапів ЖЦ тем не менше не конкретизує в деталях, як реалізувати чи виконувати дії і задачі, властиві цим етапам. У зв'язку з цим були вироблені різні моделі ЖЦ. Серед різноманітності моделей можна виділити два основних типи моделей: моделі послідовного типу (каскадні, “водоспаду”); моделі еволюційного типу (спіральні, ітераційно-інкрементні). Стосовно першого типу моделей ЖЦ припускається, що кожен наступний етап може бути розпочатий тільки після завершення робіт на попередньому етапі. Інженерія програмних систем - 2004

Модель послідовного типу (каскадна, водоспад) Інженерія програмних систем - 2004

Застосування каскадної моделі Така модель може застосовуватись, коли: вимоги до продукту чітко визначені і надалі не змінюються; є досить великий досвід реалізації подібного роду систем. Реалізація проекту за даним типом моделі ЖЦ легко планується і контролюється. Однак при цьому необхідно заздалегідь мати усі вимоги до продукту, що буває далеко не завжди. Теза-жарт: “Замовник щось хоче, але точно не знає, що саме він хоче”. Даний тип моделей ЖЦ не пристосований до умов, коли вимоги змінюються у процесі розробки, крім того, розроблюваний продукт не може використовуватися аж до завершення роботи над ним. Інженерія програмних систем - 2004

Використання каскадної моделі. Реалії Реально ж частіше спостерігається інша картина: Інженерія програмних систем - 2004

Використання каскадної моделі. Реалії Інженерія програмних систем - 2004

Моделі еволюційного типу При використанні моделей еволюційного типу можливості системи, зокрема, функціональні, поступово нарощуються (інкрементність): кожна наступна версія є удосконаленою у порівнянні з попередньою. У процесі розробки основні етапи ЖЦ (аналіз, проектування, реалізація) проходяться по кілька разів (ітераційність). При цьому істотно, що не потрібно заздалегідь мати у своєму розпорядженні усі вимоги до системи, а це, у свою чергу, дозволяє замовнику активно брати участь у її еволюційній розробці. Інженерія програмних систем - 2004

Моделі еволюційного типу. Інкрементність та ітераційність Інженерія програмних систем - 2004

Моделі еволюційного типу Інженерія програмних систем - 2004

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

Застосування еволюційної моделі Найчастіше ризики виявляються під час інтеграції. Елементи ПС насправді інтегруються все одно поступово, багатократно, а не однократно. Тут ітераційність просто доцільна. Інженерія програмних систем - 2004

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

Два виміри процесу розробки ПС з позицій Rational Unified Process (RUP) Інженерія програмних систем - 2004

Два виміри процесу розробки ПС з позицій Rational Unified Process Інженерія програмних систем - 2004

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

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

Еволюція станів артефактів по стадіях розробки Інженерія програмних систем - 2004

Віхи стадій Кожна стадія закінчується чітко визначеною віхою – часовою точкою, у якій повинні бути досягнуті ключові цілі відповідної стадії. У початковій фазі головною задачею є вироблення вимог, у фазі дослідження (уточнення) - аналіз і проектування архітектури системи, у фазі конструювання - реалізація, а у фазі впровадження (переходу) - розгортання. Наприкінці кожної фази оцінюється, якою мірою досягнуті намічені цілі і чи не варто внести в процес зміни, перш ніж рухатися далі. Інженерія програмних систем - 2004

RUP: Віхи стадій Інженерія програмних систем - 2004

RUP. Віха цілей життєвого циклу (віха стадії початку). Оціночні критерії Оціночні критерії для стадії початку: Узгодженість зі співвласниками при визначенні оцінок контексту і вартості/графіку Розуміння вимог, що підтверджуються точністю опису одного з основних прецедентів Ступінь точності оцінок вартості/графіку, пріоритетів, ризиків і процесу розвитку Глибина і широта архітектурного прототипу Фактичні витрати щодо запланованих витрат. При досягненні віхи цілей життєвого циклу розглядається опис ділових обставин, щоб гарантувати, що проект економічно життєздатний. План проекту (хоча і грубо) розглядається з погляду допустимості і несуперечності з діловими обставинами і з прийнятою практикою: Оцінки ресурсів у плані проекту повинні бути сумісні з бюджетом проекту (зверніть увагу на час, персонал і, особливо, витрати на розвиток середовища) План проекту не повинен спиратись на рівні продуктивності, що істотно відрізняються від середнього. Інженерія програмних систем - 2004

RUP. Віха архітектури життєвого циклу (віха стадії уточнення). Оціночні критерії Головні оціночні критерії для стадії уточнення включають відповіді на питання: Чи є стійке бачення програми? Чи дійсно є стійкою архітектура? Чи показує виконана демонстрація, які головні елементи ризику були виявлені і достовірно дозволені? Чи досить деталізований і точний план стадії конструювання, і чи заснований він на досить імовірних оцінках? Чи всі співвласники згодні, що запропоноване бачення може бути реалізовано, якщо буде виконаний поточний план розробки закінченої системи в контексті поточної архітектури? Чи відповідають фактичні витрати ресурсів запланованим прийнятним витратам? При досягненні віхи архітектури життєвого циклу програмна архітектура повинна стати стійкою (стабільною). Інженерія програмних систем - 2004

RUP. Віха архітектури життєвого циклу (віха стадії уточнення). Стабільність архітектури. (Продовження) Потреба стабільності диктується природою наступної стадії: при конструюванні збільшується число людей, що розробляють код програми. Необхідна при цьому ступінь незалежності і паралельності просто не може бути досягнута, якщо архітектура не стійка. Важливість стійкої архітектури не можна недооцінювати. Зміни архітектури в ході конструювання наносять відчутні удари: вони мають тенденцію бути дорогими, руйнівними і деморалізуючими. Реальні труднощі оцінки стабільності архітектури полягають у тому, що треба оцінити те, що практично не відоме (не всі ж зміни є очікуваними!). Сама архітектура розробляється при розгляді “архітектурно істотних” сценаріїв (для підмножини прецедентів, що представляють найбільш перспективну поведінку, яку повинна підтримати система). Оцінка стабільності архітектури включає гарантію того, що архітектура має деяку вільну зону, що в архітектурі не виникне ніяких “сюрпризів” при подальшому просуванні програмного проекту. Гарним індикатором стабільності може бути досвід роботи з архітектурою: якщо зміни в архітектурі малі і залишаються малими, коли вводяться нові сценарії, є всі підстави думати, що архітектура стабільна. Інженерія програмних систем - 2004

RUP. Віха початкової працездатності (віха стадії конструювання) Оціночні критерії для стадії конструювання включають відповіді на питання: Цей випуск програми досить стійкий і зрілий, щоб розгорнути його в користувача? Чи дійсно всі співвласники готові до передачі виробу користувачу? Чи ще є прийнятним співвідношення фактичних і запланованих витрат? Якщо є збої, початок стадії переходу, імовірно, прийдеться відкласти на один випуск, щоб досягти цієї віхи. При досягненні віхи початкової працездатності програма повинна бути готова до передачі групі розгортання. Усі функціональні можливості повинні бути вже реалізованими. На додаток до програмного забезпечення повинні бути розробленими керівництво користувача й опис поточного випуску. Після цієї віхи програмне забезпечення випускається для випробовувань “бета”-версії. Починається навчання користувачів і планується промислове розгортання. Інженерія програмних систем - 2004

RUP. Віха випуску виробу (віха стадії переходу ) Віха переходу (випуску) виробу Первинні оціночні критерії для стадії переходу включають відповіді на питання: Чи задоволений користувач? Чи є прийнятним співвідношення фактичних і запланованих витрат? При досягненні віхи випуску виробу програма є розробленою, і починається цикл експлуатації результуючого випуску. Інженерія програмних систем - 2004

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

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

Визначення кількості і довжини ітерацій у межах стадій Рекомендації з тривалості виконання ітерацій залежать, головним чином, від кількості людей, зайнятих у проекті. П'ять чоловік можуть скласти план у понеділок вранці, щодня за кавою контролювати просування і перерозподіляти задачі, почати компонування в четвер, і завершити ітерацію до вечора п'ятниці. Але цього буде дуже складно досягти, якщо працюють 20 чоловік. Буде потрібно більше часу для розподілу робіт, синхронізації робіт підгруп, інтеграції і т.д. Ітерація, швидше за все, займе 3 чи 4 тижня. Деякі емпіричні дані: Ітерації, тривалістю більш, ніж 12 місяців створюють свій власний ризик з погляду річного циклу фінансування. Інженерія програмних систем - 2004

Кількість ітерацій RUP рекомендує планувати, як правило, 6 ± 3 ітерації в проекті. У залежності від ризику, розміру і складності проекту можлива безліч варіантів. RUP пропонує наступні чотири стратегії побудови життєвого циклу проекту: покроковий життєвий цикл; еволюційний життєвий цикл; життєвий цикл покрокового постачання; життєвий цикл “головного проекту”. Інженерія програмних систем - 2004

Покроковий життєвий цикл Для покрокового життєвого циклу характерні наступні ітерації: коротка попередня ітерація, щоб установити контекст і бачення, і визначити ділові прецеденти; одна ітерація уточнення, протягом якої визначаються вимоги і встановлюється архітектура; кілька ітерацій конструювання, протягом яких реалізуються прецеденти й архітектура описується в деталях; кілька ітерацій переходу для передачі програми співтовариству користувачів. Ця стратегія придатна, якщо: прикладна область відома; ризики добре зрозумілі; проектна група надійна. Інженерія програмних систем - 2004

Еволюційний життєвий цикл Еволюційна стратегія відрізняється від покрокової тим, що потреби користувача не цілком зрозумілі, усі вимоги не можуть бути визначені одразу, вони уточнюються в кожній наступній версії. Характерні наступні ітерації: коротка попередня ітерація, щоб установити контекст і бачення, і визначити ділові прецеденти кілька ітерацій уточнення, протягом яких уточнюються вимоги одна ітерація конструювання, протягом якої реалізуються прецеденти й архітектура описується в деталях кілька ітерацій переходу для передачі програми Ця стратегія придатна, якщо: прикладна область нова чи незнайома група недосвідчена. Інженерія програмних систем - 2004

Життєвий цикл покрокового постачання Ця стратегія є корисною, коли є вигода від ранньої готовності хоч деяких головних можливостей (захоплення ринку). Стадія переходу починається раніше і має більше ітерацій. Ця стратегія вимагає дуже стійкої архітектури, чого важко досягти в початковому циклі розвитку для “безпрецедентної” системи. Характерні наступні ітерації: коротка попередня ітерація, щоб установити контекст і бачення, і визначити ділові прецеденти одна ітерація уточнення, протягом якої компонується стійка архітектура одна ітерація конструювання, протягом якої реалізуються прецеденти й архітектура описується в деталях кілька ітерацій переходу для передачі програми. Ця стратегія придатна, якщо: прикладна область відома, а тому архітектуру і вимоги можна рано стабілізувати проектна група надійна для замовника важливі поступові випуски з нарощуваними можливостями. Інженерія програмних систем - 2004

Життєвий цикл “головного проекту” Традиційний підхід водоспаду можна представити як вирождений випадок, коли є тільки одна довга ітерація стадії конструювання. На практиці важко уникнути додаткових ітерацій у стадії переходу. Характерні наступні ітерації: коротка попередня ітерація, щоб установити контекст і бачення, і визначити ділові прецеденти; одна дуже довга ітерація конструювання, протягом якої реалізуються прецеденти й архітектура описується в деталях; кілька ітерацій переходу. Ця стратегія придатна, якщо: маленькі збільшення добре визначеної функціональності додаються до дуже стійкої програми; нові функціональні можливості добре визначені і зрозумілі; група має досвід роботи в прикладній області і з існуючою програмою. Інженерія програмних систем - 2004

Гібридні стратегії На практиці небагато проектів строго слідують одній стратегії. Часто одержують гібрид: деяке уточнення спочатку, деяке покрокове конструювання і численні постачання. Серед переваг стадійно-ітеративної моделі - можливість пристосовувати гібридну технологію, просто збільшуючи довжину та кількість ітерацій у визначених стадіях: Для складних чи незнайомих прикладних областей, де потрібна велика дослідницька робота: збільште число ітерацій стадії уточнення та її довжину. Для проектів із проблемами розробки, де виникають труднощі транслювання проекту в код: збільште число ітерацій стадії конструювання і її довжину. Щоб поставляти ПС поступово зростаючими випусками: збільште число ітерацій стадії переходу і її довжину. Кожна ітерація робить випуск - виконувану програму, за якою оцінюється просування і якість розроблюваної ПС. Оскільки цілі ітерацій різні, функціональні можливості і закінченість випусків різноманітні. Цілі ітерацій повинні бути досить визначеними, щоб можна було оцінювати ступінь їхнього виконання. У ранніх ітераціях цілі звичайно виражаються в оцінках пом'якшення ризиків; у більш пізніх - в оцінках забезпечення функціональності та якості. Інженерія програмних систем - 2004

Статичний зміст процесу проектування Статичний зміст процесу проектування систем організовано в основних потоках робіт. Rational Unified Process включає дев'ять основних потоків робіт; з них шість потоків робіт процесу розробки. Потоки робіт описуються в термінах працівників, дій і артефактів. Працівник визначає поведінку і відповідальності індивідуума чи декількох індивідуумів, що працюють разом як група. Працівник – це не конкретна людині, це – роль, що визначає, в чому складається робота індивідууму (чи декількох індивідуумів). Дія – це найменша частина роботи (частину дії виконати неможливо!). Такий поділ роботи полегшує можливість контролювати розробку. Набагато краще (простіше) знати, що в проекті реалізовано три з п'яти дій, ніж те, що виконано 60 % проекту. Артефакти – штучні об'єкти (моделі, документи), з якими мають справу окремі дії: дії виробляють артефакти як результуючу інформацію, переробляють ("підтримують") або ж використовують як вхідну інформацію. Інженерія програмних систем - 2004

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

Діаграми основного потоку робіт. Діаграма короткого огляду дій Діаграма короткого огляду дій для потоку робіт ділового моделювання Для кожного основного потоку робіт можуть представлятися спеціальні діаграми. 1. Діаграма короткого огляду дій - містить всі дії і всіх працівників, включених у потік робіт. Приклад: Інженерія програмних систем - 2004

Діаграми основного потоку робіт. Діаграма короткого огляду артефактів 2. Діаграма короткого огляду артефактів - містить всі артефакти і всіх працівників, включених у потік робіт. Приклад: Типова діаграма короткого огляду артефактів для потоку робіт ділового моделювання Інженерія програмних систем - 2004

Діаграми основного потоку робіт. Діаграми деталей потоку робіт 3. Діаграми деталей потоку робіт. Вони використовуються для більшості з основних потоків робіт. Такі діаграми показують групування дій, що часто виконуються разом. Містять відповідних працівників, артефакти і виконувані дії. Діаграми деталей потоків робіт представляються з різних причин. Наприклад, іноді складно показати артефакти для всіх дій потоку робіт на одній діаграмі. Діаграма деталей дозволяє показати одночасно дії й артефакти для деякої частини потоку робіт. Основні потоки робіт не є цілком незалежними. Наприклад, інтеграція відбувається потоках робіт: і в потоці виконання, і в потоці випробувань. Діаграма деталей потоку робіт може показувати групу дій і артефактів у потоці робіт разом зі зв'язаними діями з іншого потоку робіт. Інженерія програмних систем - 2004

Діаграми основного потоку робіт. Діаграми деталей потоку робіт. Приклад Приклад: Типова діаграма деталей потоку робіт (потік робіт ділового моделювання) Інженерія програмних систем - 2004

Моделювання програмних систем Існує багато аспектів, пов'язаних з успішною розробкою програмних проектів, але одним з основних є моделювання. Моделювання – загальноприйнята в інженерії методика. Модель, як відомо, – це спрощене представлення дійсності, але важливо, щоб модель M надавала певну уяву про об’єкт моделювання A: "M моделює A, якщо M відповідає на питання відносно A". Розроблювана модель повинна включати тільки ті елементи, що є найбільш істотними стосовно обраного рівня абстракції. Модель програмної системи - це семантично замкнена абстракція системи, тобто модель представляє повне і самодостатнє спрощене представлення реальної системи, створене для кращого розуміння цієї системи. Система може розглядатися з різних позицій, при цьому вибираються різні моделі. Наприклад, модель може бути структурною, представляючи організацію системи у вигляді окремих частин, а може бути поведінковою, представляючи динаміку системи. Інженерія програмних систем - 2004

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

Використання моделей програмних систем Наприклад, при застосуванні для моделювання засобів UML (так званих UML-діаграм) отримані моделі можуть використовувати не тільки безпосередніми розробниками системи: користувачі можуть отримати досить повне уявлення про систему, зокрема, уявлення про її функціональні можливості та контекст (відповідну інформацію можна отримати з діаграм прецедентів); менеджери проекту - про сферу застосування системи та про можливий розподіл проекту на окремі задачі (відповідну інформацію в основному також можна отримати з діаграм прецедентів); аналітики можуть провести аналіз логіки системи, використовуючи діаграми взаємодії та документацію по прецедентам (так звані сценарії); тестувальники можуть отримати дані для розробки тестових сценаріїв (з діаграм діяльності, діаграм взаємодії тощо); експлуатаційний персонал з діаграм компонентів та діаграм розгортання може отримати уявлення про топологію системи, її розташування в мережі. Інженерія програмних систем - 2004

Важливість моделювання програмних систем Загалом, моделювання дозволяє вирішувати наступні важливі задачі: одержувати візуалізоване представлення архітектури системи; специфікувати структуру та поведінкові аспекти системи; одержувати деякий шаблон, що дозволяє в деякій мірі генерувати систему; проводити документування прийнятих рішень, виходячи безпосередньо з моделей. Чим більша і складніша система, тим важче її "охопити" в цілому, а, отже, тим важливіше моделювання. Інженерія програмних систем - 2004

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

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

Візуальне моделювання По-друге, візуальні моделі дозволяють налагодити змістовну і плідну взаємодію між замовниками, користувачами і командою розроблювачів. По-третє, візуальне моделювання істотне полегшує досягнення таких цілей, як: підвищення якості програмного продукту; зменшення вартості проекту; постачання системи в запланований термін. Інженерія програмних систем - 2004

Моделювання та CASE-технології CASE-технологія (від Computer Aided Software Engineering) являє собою методологію проектування ПС, а також набір інструментальних засобів, що дозволяють: у наочній формі моделювати предметну область; аналізувати і використовувати отриману модель на всіх етапах розробки і супроводу ПС, створюючи продукт відповідно до потреб замовника; окрім процесів створення і супроводу ПС, що включають аналіз і формулювання вимог, проектування програмних модулів і необхідних баз даних, генерацію коду, тестування, документування, конфігурування, підтримувати також інші процеси, наприклад, забезпечення якості, зведення ризиків до мінімуму тощо. Інженерія програмних систем - 2004

CASE-методології Більшість існуючих CASE-технологій засновано на методологіях структурного та/або об'єктно-орієнтованого аналізу і проектування, що використовують специфікації у вигляді діаграм (графів) для опису архітектури системи, включаючи: облік вимог; представлення різних моделей, у тому числі таких, що описують поведінку системи та зв'язки між окремими частинами системи. У підходах, що ґрунтуються на структурному аналізі використовуються в основному дві групи засобів: одні задають функції, виконувані системою, а другі – відношення між даними. Кожній групі засобів відповідають певні види моделей (діаграм), найбільш розповсюдженими серед який є наступні: функціональні діаграми (моделі) SADT (Structured Analysis and Design Technique); діаграми потоків даних DFD (Data Flow Diagrams); діаграми "сутність-зв'язок" ERD (Entity-Relationship Diagrams). Інженерія програмних систем - 2004

Окремі риси Rational Rose Підтримка UML Об'єктно-орієнтована основа Багатомодельність Узгодженість моделей Кодогенерація, зворотне проектування, round-trip Інженерія програмних систем - 2004

Підтримка потоків робіт засобами Rational Інженерія програмних систем - 2004

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

Архітектура у розрізі проектування програмних систем Архітектура – один з найважливіших аспектів проектування програмних систем: наявність проекту архітектури дозволяє мати інтелектуальний контроль над проектом, керувати цим проектом, контролюючи його складність і підтримуючи цілісність системи. архітектура закладає основу для розуміння всього проекту, встановлюючи загальний набір довідників, словників і т.д. архітектура є основою для забезпечення повторних (багаторазових) використань. Інженерія програмних систем - 2004

Представлення архітектури Архітектура описується множиною її представлень або виглядів (views). Кожне представлення архітектури відбиває деякий аспект, що цікавить ту чи іншу групу людей, пов'язаних із проектом. Будь-хто, хто має відношення до проекту – замовник, кінцевий користувач, системний аналітик, керівник проекту, розроблювач, менеджер і т.д. – переслідує власні цілі і тому дивиться на створювану систему по-своєму. Представлення фіксують головні рішення проектування структури, показуючи, із яких компонентів складається система і як пов'язані ці компоненти. Такі рішення повинні випливати з вимог функціональності та інших факторів. З іншого боку, ці рішення встановлюють подальші обмеження на вимоги і на майбутні проектні рішення нижнього рівня. Представлення архітектури, власне кажучи, є зрізами, проекціями, що ілюструють “архітектурно істотні” складові моделей. Інженерія програмних систем - 2004

Модель архітектури “4+1” Зокрема, Rational Unified Process (RUP) відштовхується від набору з п'яти представлень, названого моделлю архітектури “4+1”. Кожне з п'яти представлень є однією з можливих проекцій організації й структури системи і загострює увагу на певному аспекті її функціонування. Відповідно моделювання системної архітектури пропонується провадити в такий спосіб: оберіть представлення, які ви будете використовувати для моделювання архітектури. Найчастіше це п'ять наступних представлень: з погляду прецедентів, проектування, процесів, реалізації й розгортання. специфікуйте контекст системи, зокрема акторів, що її оточують. при необхідності розкладіть систему на елементарні підсистеми. Інженерія програмних систем - 2004

Модель архітектури “4+1” Інженерія програмних систем - 2004

Модель архітектури “4+1” Інженерія програмних систем - 2004

Методологія RUP. Крок 1 При моделюванні системи в цілому та її підсистем RUP у відповідності з моделлю архітектури “4+1” пропонує виконувати наступні п'ять кроків специфікації програмної системи: 1. Специфікуйте представлення системи з погляду варіантів використання або прецедентів (use case view), що описують поведінку системи так, як це представляється кінцевим користувачам, аналітикам і тестувальникам. Це представлення специфікує не істинну організацію програмної системи, а лише ті позиції, від яких залежить формування системної архітектури. Більш конкретно, визначаються насамперед функціональні вимоги до системи, тобто ті послуги, які система повинна надавати кінцевим користувачам. Загалом містить прецеденти й сценарії, що охоплюють архітектурно істотну поведінку системи. Для моделювання слід застосовувати діаграми прецедентів. Також можна використати діаграми діяльності (для моделювання поведінки за сценаріями). Інженерія програмних систем - 2004

Методологія RUP. Крок 2 2. Специфікуйте представлення системи з погляду проектування (design view). Представлення з погляду проектування охоплює класи, інтерфейси та їх кооперації. При цьому формується словник предметної області і пропонованого рішення. Для моделювання статичних аспектів слід застосовувати діаграми класів, а для моделювання динамічних – діаграми послідовностей, діаграми станів та діаграми діяльності. Інженерія програмних систем - 2004

Методологія RUP. Крок 3 3. Специфікуйте представлення системи з погляду процесів (process view), який охоплює потоки і процеси, що формують механізми паралелізму й синхронізації у системі. Це представлення описує, головним чином, продуктивність, масштабування і пропускну спроможність системи. Слід використовувати ті ж діаграми, що і для представлення з погляду проектування, але основну увагу треба приділити активним класам і об'єктам. (Активним класом є той клас, об'єкти якого залучені в процеси чи потоки, тобто діяльність таких об'єктів здійснюється одночасно з діяльністю інших елементів і може впливати на останні). Потреба в цьому представленні виникає тільки тоді, коли система має істотний ступінь паралелізму. Інженерія програмних систем - 2004

Методологія RUP. Крок 4 4. Специфікуйте представлення системи з погляду реалізації (implementation view), у який входять компоненти, що використовуються для складання й випуску готової (фізичної) системи – кінцевого програмного продукту. Це представлення призначене у першу чергу для управління конфігурацією версій системи, що складаються з незалежних (до деякої міри) компонентів і файлів, які, загалом, можуть по-різному поєднуватися між собою. Для моделювання статичних аспектів слід застосувати діаграми компонентів, а при потребі моделювання ще й динамічних - діаграми взаємодії, діаграми станів і діаграми діяльності. Інженерія програмних систем - 2004

Методологія RUP. Крок 5 5. Специфікуйте представлення системи з погляду розгортання (deployment view), що охоплює вузли, які формують топологію апаратних засобів, необхідних для функціонування системи. (Вузол - це елемент реальної системи, який існує під час функціонування програмного продукту і який являє собою деякий обчислювальний ресурс. Сукупність компонентів може розміщуватися на вузлі, а також може мігрувати з одного вузла на інший). У першу чергу таке представлення пов'язане з розподілом, постачанням і установкою частин, які відповідають типовим конфігураціям системи. Для моделювання статичних аспектів слід застосовувати діаграми розгортання, а для моделювання динамічних - діаграми взаємодії, діаграми станів і діаграми діяльності. Потреба у такому представленні виникає тільки у випадках, коли програмна система є розподіленою. Інженерія програмних систем - 2004

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