Програмна інженерія та case-технології 2003 Зміст


НазваПрограмна інженерія та case-технології 2003 Зміст
Дата конвертації27.03.2013
Розмір445 b.
ТипПрезентации


Програмна інженерія та CASE-технології

  • 2003


Зміст

  • 1. Основні етапи життєвого циклу програмних систем.

  • 2. Типи моделей життєвого циклу.

  • 3. Моделювання програмних систем.

  • 4. Моделювання та CASE-технології.

  • 5. Архітектура програмних систем.

  • 6. Модель архітектури “4+1” та методологія RUP.



Розробка програмних систем як промислове виробництво

  • Розробка програмних систем (ПС) і, зокрема, інформаційних систем (ІС) сьогодні розглядається не інакше, як промислове виробництво.

  • Метою такого виробництва є створення спеціального промислового продукту – програм або, як ще говорять, програмного продукту.

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



Життєвий цикл програмних систем

  • Одним з основних понять технології розробки програмного забезпечення є поняття життєвого циклу (ЖЦ) програмних систем.

  • Під життєвим циклом ПС розуміють сукупність процесів, пов’язаних з послідовною зміною стану ПС, починаючи від формування вимог і закінчуючи експлуатацією.

  • Життєвий цикл складається з етапів (процесів), які слід розглядати як логічно завершені частини ЖЦ.

  • Найчастіше виділяють наступні п'ять основних етапів ЖЦ:

    • аналіз і формалізація вимог замовника;
    • проектування;
    • реалізація і тестування;
    • впровадження;
    • супровід.


Життєвий цикл програмних систем

  • Виділення окремих етапів ЖЦ тем не менше не конкретизує в деталях, як реалізувати чи виконувати дії і задачі, властиві цим етапів. У зв'язку з цим були вироблені різні моделі ЖЦ.

  • Серед різноманітності моделей можна виділити два основних типи моделей:

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



Модель послідовного типу (каскадна, водоспад)



Застосування каскадної моделі

  • Така модель може застосовуватись, коли:

    • вимоги до продукту чітко визначені і надалі не змінюються;
    • є досить великий досвід реалізації подібного роду систем.
  • Реалізація проекту за даним типом моделі ЖЦ легко планується і контролюється. Однак при цьому необхідно заздалегідь мати усі вимоги до продукту, що буває далеко не завжди.

  • Теза-жарт: “Замовник щось хоче, але точно не знає, що саме він хоче”.

  • Даний тип моделей ЖЦ не пристосований до умов, коли вимоги змінюються у процесі розробки, крім того, розроблюваний продукт не може використовуватися аж до завершення роботи над ним.



Використання каскадної моделі. Реалії

  • Реально ж частіше спостерігається інша картина:



Моделі еволюційного типу

  • При використанні моделей еволюційного типу можливості системи, зокрема, функціональні, поступово нарощуються (інкрементність): кожна наступна версія є удосконаленою у порівнянні з попередньою.

  • У процесі розробки основні етапи ЖЦ (аналіз, проектування, реалізація) проходяться по кілька разів (ітераційність).

  • При цьому істотно, що не потрібно заздалегідь мати у своєму розпорядженні усі вимоги до системи, а це, у свою чергу, дозволяє замовнику активно брати участь у її еволюційній розробці.



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



Застосування еволюційної моделі

  • Даний тип моделей ЖЦ може застосовуватись у випадках, коли:

    • вимоги до системи не цілком визначені або будуть змінюватися;
    • відсутній достатній досвід розробки подібних систем;
    • використовуються нові технології і/або інструментарії;
    • у ході розробки системи необхідно отримувати і використовувати її проміжні версії.
  • Процес розробки, що є одночасно ітераційним та інкрементним, часто пов'язують з поняттям процесу, керованим ризиками (risk-driven), коли в кожній новій версії серйозна увага приділяється, по-перше, виявленню факторів, що представляють найбільший ризик для успішного завершення проекту, і, по-друге, зведенню ризиків до мінімуму.

  • Існує багато аспектів, пов'язаних з успішною розробкою програмних проектів, але одним з основних є моделювання.



Моделювання програмних систем

  • Моделювання – загальноприйнята в інженерії методика.

  • Модель, як відомо, – це спрощене представлення дійсності, але важливо, щоб модель M надавала певну уяву про об’єкт моделювання A:

  • "M моделює A, якщо M відповідає на питання відносно A".

  • Розроблювана модель повинна включати тільки ті елементи, що найбільш істотні стосовно обраного рівня абстракції.

  • Модель програмної системи - це семантично замкнена абстракція системи, тобто модель представляє повне і самодостатнє спрощене представлення реальної системи, створене для кращого розуміння цієї системи.

  • Система може розглядатися з різних позицій, при цьому вибираються різні моделі. Наприклад, модель може бути структурною, представляючи організацію системи у вигляді окремих частин, а може бути поведінковою, представляючи динаміку системи.



Окремі задачі моделювання програмних систем

  • У цілому, моделі розробляються для того, щоб краще розуміти систему, яку потрібно створити. Зокрема, моделювання дозволяє вирішувати наступні важливі задачі:

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

  • Побудова моделі системи перед програмною розробкою цієї системи настільки ж необхідна, наскільки необхідні проектні креслення перед будівництвом нетривіальної споруди.



Основні принципи моделювання програмних систем

  • Принцип абстрагування. Система представляється моделлю, що відповідає певному рівню абстракції. Вибір моделі (вибір певного рівня абстракції) визначає те, як будуть осмислюватися проблеми реалізації і які рішення будуть прийматися;

  • Принцип візуальності. Моделі повинні забезпечувати можливість одержувати візуалізоване представлення системи;

  • Принцип багатомодельности. Не слід обмежуватися єдиною моделлю, якщо система досить нетривіальна. Найкраще використовувати сукупність моделей, що незалежні одна від одної або, іншими словами, що задають різні представлення архітектури системи.

  • Принцип ієрархічності (ієрархічної побудови моделей). Цей принцип обумовлює в рамках фіксованих представлень розробляти моделі стосовно до різних рівнів абстрагування.

  • Принцип еволюційності. Як правило, архітектура системи не є результатом одиничного акта творення, а розробляється шляхом послідовних (еволюційних) уточнень.



Візуальне моделювання

  • Візуальні моделі широко використовуються в існуючих технологіях управління проектуванням систем, складність, масштаби і функціональність яких постійно зростають.

  • Візуальні моделі забезпечують ясність обраних архітектурних рішень і дозволяють зрозуміти систему у всій її повноті. Побудова візуальних моделей дозволяє вирішити одразу кілька типових проблем.

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



Візуальне моделювання

  • По-друге, візуальні моделі дозволяють налагодити змістовну і плідну взаємодію між замовниками, користувачами і командою розроблювачів.

  • По-третє, візуальне моделювання істотне полегшує досягнення таких цілей, як:

    • підвищення якості програмного продукту;
    • скорочення вартості проекту;
    • постачання системи в запланований термін.


Моделювання та CASE-технології

  • CASE-технологія (від Computer Aided Software Engineering) являє собою методологію проектування ПС, а також набір інструментальних засобів, що дозволяють:

    • у наочній формі моделювати предметну область;
    • аналізувати і використовувати отриману модель на всіх етапах розробки і супроводу ПС, створюючи продукт відповідно до потреб замовника;
    • окрім процесів створення і супроводу ПС, що включають аналіз і формулювання вимог, проектування програмних додатків і необхідних баз даних, генерацію коду, тестування, документування, конфігурування, підтримувати також інші процеси, наприклад, забезпечення якості, зведення ризиків до мінімуму тощо.


Моделювання та CASE-технології

  • Більшість існуючих CASE-технологій засновано на методологіях структурного і/або об'єктно-орієнтованого аналізу і проектування, що використовують специфікації у вигляді діаграм (графів) для опису архітектури системи, включаючи:

    • облік вимог;
    • представлення різних моделей, у тому числі таких, що описують поведінку системи та зв'язки між окремими частинами системи.
  • У підходах, що ґрунтуються на структурному аналізі використовуються в основному дві групи засобів: одні задають функції, виконувані системою, а другі – відношення між даними.

  • Кожній групі засобів відповідають певні види моделей (діаграм), найбільш розповсюдженими серед який є наступні:

    • функціональні діаграми (моделі) SADT (Structured Analysis and Design Technique);
    • діаграми потоків даних DFD (Data Flow Diagrams);
    • діаграми "сутність-зв'язок" ERD (Entity-Relationship Diagrams).


Архітектура програмних систем

  • Усі дії моделювання програмних систем, як правило, зосереджені навколо поняття архітектури системи.

  • Під архітектурою програмної системи розуміють сукупність рішень відносно:

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



Архітектура у розрізі проектування програмних систем

  • Архітектура – один з найважливіших аспектів проектування програмних систем:

    • наявність проекту архітектури дозволяє мати інтелектуальний контроль над проектом, керувати цим проектом, контролюючи його складність і підтримуючи цілісність системи.
    • архітектура закладає основу для розуміння всього проекту, встановлюючи загальний набір довідників, словників і т.д.
    • архітектура є основою для забезпечення повторних (багаторазових) використань.


Представлення архітектури

  • Архітектура описується множиною її представлень або виглядів (views).

  • Кожне представлення архітектури відбиває деякий аспект, що цікавить ту чи іншу групу людей, пов'язаних із проектом.

  • Будь-хто, хто має відношення до проекту – замовник, кінцевий користувач, системний аналітик, керівник проекту, розроблювач, менеджер і т.д. – переслідує власні цілі і тому дивиться на створювану систему по-своєму.

  • Представлення фіксують головні рішення проектування структури, показуючи, із яких компонентів складається система і як пов'язані ці компоненти. Такі рішення повинні випливати з вимог функціональності та інших факторів. З іншого боку, ці рішення встановлюють подальші обмеження на вимоги і на майбутні проектні рішення нижнього рівня.

  • Представлення архітектури, власне кажучи, є зрізами, проекціями, що ілюструють “архітектурно істотні” складові моделей.



Модель архітектури “4+1”

  • Зокрема, Rational Unified Process (RUP) відштовхується від набору з п'яти представлень, названого моделлю архітектури “4+1”.

  • Кожне з п'яти представлень є однією з можливих проекцій організації й структури системи і загострює увагу на певному аспекті її функціонування.

  • Відповідно моделювання системної архітектури пропонується провадити в такий спосіб:

    • оберіть представлення, які ви будете використовувати для моделювання архітектури. Найчастіше це п'ять наступних представлень: з погляду прецедентів, проектування, процесів, реалізації й розгортання.
    • специфікуйте контекст системи, зокрема акторів, що її оточують.
    • при необхідності розкладіть систему на елементарні підсистеми.


Модель архітектури “4+1”



Методологія RUP. Крок 1

  • При моделюванні системи в цілому та її підсистем RUP у відповідності з моделлю архітектури “4+1” пропонує виконувати наступні п'ять кроків специфікації програмної системи:

  • 1. Специфікуйте представлення системи з погляду варіантів використання або прецедентів (use case view), що описують поведінку системи так, як це представляється кінцевим користувачам, аналітикам і тестувальникам.

  • Це представлення специфікує не істинну організацію програмної системи, а лише ті позиції, від яких залежить формування системної архітектури. Більш конкретно, визначаються насамперед функціональні вимоги до системи, тобто ті послуги, які система повинна надавати кінцевим користувачам.

  • Загалом містить прецеденти й сценарії, що охоплюють архітектурно істотну поведінку системи. Для моделювання слід застосовувати діаграми прецедентів. Також можна використати діаграми діяльності (для моделювання поведінки за сценаріями).



Методологія RUP. Крок 2

  • 2. Специфікуйте представлення системи з погляду проектування (design view).

  • Представлення з погляду проектування охоплює класи, інтерфейси та їх кооперації. При цьому формується словник предметної області і пропонованого рішення.

  • Для моделювання статичних аспектів слід застосовувати діаграми класів і діаграми об'єктів, а для моделювання динамічних – діаграми послідовностей, діаграми станів та діаграми діяльності.



Методологія RUP. Крок 3

  • 3. Специфікуйте представлення системи з погляду процесів (process view), який охоплює потоки і процеси, що формують механізми паралелізму й синхронізації у системі.

  • Це представлення описує, головним чином, продуктивність, масштабування і пропускну спроможність системи.

  • Слід використовувати ті ж діаграми, що і для представлення з погляду проектування, але основну увагу треба приділити активним класам і об'єктам. (Активним класом є той клас, об'єкти якого залучені в процеси чи потоки, тобто діяльність таких об'єктів здійснюється одночасно з діяльністю інших елементів і може впливати на останні).

  • Потреба в цьому представленні виникає тільки тоді, коли система має істотний ступінь паралелізму.



Методологія RUP. Крок 4

  • 4. Специфікуйте представлення системи з погляду реалізації (implementation view), у який входять компоненти, що використовуються для складання й випуску готової (фізичної) системи – кінцевого програмного продукту.

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

  • Для моделювання статичних аспектів слід застосувати діаграми компонентів, а при потребі моделювання ще й динамічних - діаграми взаємодії, діаграми станів і діаграми діяльності.



Методологія RUP. Крок 5

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

  • У першу чергу таке представлення пов'язане з розподілом, постачанням і установкою частин, які відповідають типовим конфігураціям системи.

  • Для моделювання статичних аспектів слід застосовувати діаграми розгортання, а для моделювання динамічних - діаграми взаємодії, діаграми станів і діаграми діяльності.

  • Потреба у такому представленні виникає тільки у випадках, коли програмна система є розподіленою.



Два виміри процесу розробки ПС з позицій Rational Unified Process



Два виміри процесу розробки ПС з позицій Rational Unified Process

  • Перший вимір представляє статичний аспект процесу: він описується в термінах основних потоків робіт (виконавці, дії, їх послідовність і так далі).

  • Другий вимір представляє динамічний аспект процесу і виражається в часових термінах: циклів, ітерацій і фаз (стадій).

  • Увесь життєвий цикл програми розбивається на еволюційні цикли, кожний з яких працює над новим поколінням продукту.

  • Rational Unified Process поділяє один цикл розвитку (еволюційний цикл) на чотири послідовних стадії (фази):

    • Задум
    • Уточнення (аналіз, дослідження)
    • Конструювання (побудова)
    • Упровадження


Стадія задуму

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

  • На стадії задуму визначаються цілі системи і встановлюються рамки проекту. Аналіз цілей включає вироблення критерію успішності, оцінку ризиків, необхідних ресурсів і складання плану. Може створюватися виконуваний прототип, що демонструє реалістичність задуманої системи. Наприкінці фази повинно прийматися рішення про те, ли варто починати повномасштабну розробку системи.



Стадії дослідження, побудови та впровадження

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

  • На стадії побудови провадиться розробка системи (знов-таки ітеративно), а також її тестування. Наприкінці фази побудови приймається рішення про готовність системи до впровадження.

  • На стадії впровадження система передається користувачам, при цьому може виникнути необхідність у перенастроюванні системи, а також у виправленні помилок, що виявляються користувачами під час експлуатації системи. Наприкінці фази робиться висновок про те, чи досягнуті цілі проекту, чи ж варто починати новий цикл розробки.



Віхи стадій

  • Кожна стадія закінчується чітко визначеною віхою – часовою точкою, у якій повинні бути досягнуті ключові цілі відповідної стадії.

  • У початковій фазі головною задачею є вироблення вимог, у фазі дослідження - аналіз і проектування, у фазі побудови - реалізація, а у фазі впровадження - розгортання.

  • Наприкінці кожної фази оцінюється, якою мірою досягнуті намічені цілі і чи не варто внести в процес зміни, перш ніж рухатися далі.



Статичний зміст процесу проектування

  • Статичний зміст процесу проектування систем організовано в основних потоках робіт. Rational Unified Process включає дев'ять основних потоків робіт; з них шість потоків робіт процесу розробки. Потоки робіт описуються в термінах працівників, дій і артефактів.

  • Працівник визначає поведінку і відповідальності індивідуума чи декількох індивідуумів, що працюють разом як група. Працівник – це не конкретна людині, це – роль, що визначає в чому складається робота індивідууму чи декількох індивідуумів.

  • Дія – це найменша частина роботи (частину дії виконати неможливо!). Такий поділ роботи полегшує можливість контролювати розробку. Набагато краще (простіше) знати, що в проекті реалізовано три з п'яти дій, ніж те, що виконано 60 % проекту.

  • Артефакти – штучні об'єкти (моделі, документи), з якими мають справу окремі дії: дії їх (артефакти) виробляють як результуючу інформацію, переробляють ("підтримують") або ж використовують як вихідну інформацію.



Схожі:

Програмна інженерія та case-технології 2003 Зміст iconОснови програмної інженерії 2003-2009 Зміст
Програмна інженерія вивчає питання, пов'язані з розробкою та використанням пз на інженерній основі
Програмна інженерія та case-технології 2003 Зміст iconОснови програмної інженерії 2003-2012 Зміст
Програмна інженерія вивчає питання, пов'язані з розробкою та використанням пз на інженерній основі
Програмна інженерія та case-технології 2003 Зміст iconОснови програмної інженерії 2005 Програмна інженерія
Програмна інженерія вивчає питання, пов'язані з розробкою та використанням пз на інженерній основі
Програмна інженерія та case-технології 2003 Зміст iconОснови програмної інженерії 2007 Зміст
Програмна інженерія вивчає питання, пов'язані з розробкою та використанням пз на інженерній основі
Програмна інженерія та case-технології 2003 Зміст iconОснови com-технології 2003 Зміст
З назви можна зробити висновок, що ідеологію даної технології мають складати загалом класичні підходи
Програмна інженерія та case-технології 2003 Зміст iconОснови com-технології. Практичне використання com 2003-2009 Зміст
З назви можна зробити висновок, що ідеологію даної технології мають складати загалом класичні підходи
Програмна інженерія та case-технології 2003 Зміст iconМетодические рекомендации по использованию case. Проблемная ситуация Проблемная ситуация
Одним из методов, позволяющих реализовать потенциал учащегося, является метод обучения case-study
Програмна інженерія та case-технології 2003 Зміст iconЗміст вступ 2 розділ інформаційно-комунікаційні технології у навчальному процесі 4
«Інформаційні технології як фактор розвитку форм і методів викладання трудового навчання»
Програмна інженерія та case-технології 2003 Зміст iconОснови com-технології. Практичне використання com 2007 Зміст
З назви можна зробити висновок, що ідеологію даної технології мають складати загалом класичні підходи
Програмна інженерія та case-технології 2003 Зміст iconОснови com-технології. Практичне використання com 2005 Зміст
З назви можна зробити висновок, що ідеологію даної технології мають складати загалом класичні підходи

Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка