Тема 4. Базові принципи та поняття технології розробки

Тема 4. Базові принципи та поняття технології розробки інформаційних систем на основі UML 2

Відсутність моделей при розробці ПЗ Не дозволяє вирішити проблему зростаючої складності програмних систем Не дозволяє ефективно керувати розробкою в умовах змінних вимог Створює бар’єри непорозуміння: аналітик не розуміє керівника проекту, розробник – аналітика, тестувальник – розробника і т.і. Не дозволяє забезпечити контроль змін в процесі виконання робіт Не дозволяє уникнути суб'єктивності в оцінці якості продуктів Модель (model) — абстракція фізичної системи, що розглядається з певної точки зору та наводиться на певній мові або в графічній формі

Уніфікований підхід до створення ПЗ Повинен забезпечувати керівництво діяльністю команди Повинен керувати задачами окремого розробника і команди в цілому Повинен вказувати, які артефакти розробляти Повинен надавати критерії відслідковування та виміру продуктів та функціонування проекту УП – компоненто-орієнтований каркас процесу

Кращі практики розробки ПЗ використання візуальни моделей при розробці ПЗ ітеративна розробка ПЗ керування вимогами керування змінами конфигурації артефактів ПЗ використання компонентних архітектур безперервне тестування та верифікація якості ПЗ використання паттернів проектування використання CASE-засобів керування ризиками: Технологичними ризиками Пов’язаними з вимогами Пов’язаними з кваліфікацією персоналу проекту

Що таке візуальне моделювання? Візуальне моделювання - моделювання з використанням графічної нотації На вході – Неструктурована інформація На виході – Моделі ПЗ та бізнес-процесів Продукція Відходи виробництва Забезпечення якості Стандарти, технічні умови і т.і. Замовлення на складові

Основні поняття візуального моделювання Нотація – система умовних позначень для графічного представлення візуальних моделей Семантика – система правил та домовленостей, що визначає зміст та інтерпретацію конструкцій якоїсь мови Методологія – сукупність принципів моделювання та підходів до логічної організації методів та засобів розробки моделей CASE (Computer Aided Software Engineering) – методологія розробки програмного забезпечення, основана на комплексному використанні компютерів не тільки для запису програмного коду, а й для аналізу та моделювання відповідної предметної області CASE-засоби (CASE-tools) – програмне забезпечення, яке призначене для розробки візуальних моделей програмних систем та генерації коду або схеми бази даних на деякій мові

CASE-засоби 1-е покоління: генерація схем БД (Oracle Designer 2000, ERwin) 2-е покоління: генерація програмного коду (Borland Together Designer 2005) 3-е покоління: пряма та зворотня кодогенерація (IBM Rational Rose 2002/2003, Borland Together Developer 2005, Sparx Enterprise Architect) 4-е покоління: синхронізація програмного коду та моделей (IBM Rational Software Architect 6/7, Borland Together Architect 2006, Borland Development Studio 2006) розробка візуальних моделей складних систем спирється на спеціальні засоби програмної підтримки

Програмна система Інтерфейси

Візуальні моделі наводять архітектуру програмних систем Візуальна модель системи не повинна залежати від мови її реалізації! Інтерфейси користувача (Delphi, Visual Basic, Java) Бізнес-логіка (C++, Java) Бази даних (SQL)

Візуальні моделі є засобом комунікації Бізнес-аналітики, системні аналітики, архітектори, CIO, MIS, CPO Програмісти, тестувальники, менеджери проектів Візуальні моделі дають опис бизнес-процесів Візуальні моделі використовують для проектування та розробки програмних систем Графічна нотація (мова UML) Артефакти ПЗ Артефакти БП Користувачі

Візуальні моделі – основа багатократного використання коду Моделювання охоплює істотні (основні, релевантні) аспекти структури та поведінки системи ERP-Системи Багатократно використовувані компоненти (Reusable Components) Інтернет-портали Бази даних

Аспекти Уніфікованого процесу Керується Варіантами використання Архітектурно-орієнтований Ітеративний та інкрементний

Варіанти використання ПЗ створюється для користувачів Користувачі – люди та системи Варіант використання (ВВ – Use Case) – частина функцій, системи, необхідних для отримання потрібного користувачеві результату Сума ВВ = Модель ВВ = Всі функції ПЗ Процес розробки = Серія процесів реалізації ВВ Реалізація ВВ: аналіз, проектування, реалізація та тестування

Керуванння процесом розробки Модель ВВ=> Модель аналізу => Модель проектування => Модель розгортання => Модель реалізації => Модель тестування

Архітектура визначається: Варіантами використання Платформою програми Готовими програмними блоками Варіантами розгортання Надійністю Ефективністю роботи

Цілі архітектора: Зрозумілість Легкість внесення змін Можливість повторного використання Архітектор створює форму програмної системи

Кроки архітектора системи: Створюється ескіз архітектури, що не стосується ВВ На базі ключових ВВ створюються підсистеми, класи та компоненти Для всіх ВВ створюються підсистеми, класи та компоненти

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

Переваги ітеративності Уніфікованого процесу Зниження фінансових ризиків Зниження ризику невиведення продукту на ринок в строк Прискорюється процес розробки в цілому Полегшує адаптацію до зміни вимог

Класифікація проектів за складністю Висока технічна складність Вбудовані системи реального часу Розподілені високонадійні системи Високовиробничі системи Мала технічна складність - Використання макромов або 4GL - Реінжинирінг додатків баз даних - розробка обліково-розрахункових додатків Висока складність керування - Великий масштаб - Контрактні замовлення - Багато пользователей - «Проекти» Мала складність керування - Малий масштаб - Неформальні замовлення - Один користувач - “Продукти” використання мови UML не обов’язкове Використання мови UML обов’язкове!

Графічні нотації моделювання UML (Unified Modeling Language) – галузевий стандарт OMG, підтримує більше як 50 CASE-засобів, основний інструмент IBM Rational Rose/ IBM RSA (IBM Rational Software) IDEF – родина нотацій, стандарт МО США, основний інструмент AllFusion Pricess Modeller (Computer Associations) ARIS (ARchitecture of Integrated Information Systems) – методологія та нотація для професійного моделювання бізнес-процесів, інструмент ARIS Toolset (IDS Scheer AG)

Взаимозв’язок нотації UML, методології та інструментальних засобів + додаткова інтеграція з продуктами IBM Rational Нотація – UML методологія - RUP засіб – IBM Rational Rose

методологія ARIS House of Business Engineering (HOBE) засіб ARIS Toolset методологія MSF (Microsoft Solutions Framework) засіб MS Visual Studio/.NET Нотація – UML Нотація – UML варіанти Взаимозв’язок нотації UML, методології та інструментальних засобів

Нотація – UML 2.х методологія ALM (Application Lifecycle Management) засоби Borland Together Architect 2006 Нотація - UML 2.х методологія RUP засобів IBM Rational Software Architect варіанти Взаимозв’язок нотації UML, методології та інструментальних засобів

Популярні графічні нотації візуального моделювання (кінець 80-х рр.) ERD (Entity-Relationship Diagrams) – діаграми «сутність-зв’язок» DFD (Data Flow Diagrams) – діаграми потоків даних, що забезпечують аналіз вимог та функціональне проектування інформаційних систем STD (State Transition Diagram) – діаграми переходу станів для проектування систем реального часу SADT (Structured Analysis and Design Technique) – технологія структурного аналізу та проектування ICAM (Integrated Computer Aided Manufacturing) – інтегроване комп’ютерне виробництво FDD (Functional Decomposition Diagrams) – діаграми функціональної декомпозиції Структурні карти Джексона и Константайна – проектування міжмодульних взаємодій та внутрішньої структури об'єктів

Мова UML і сучасні технології

Основні розробники мови UML OMG (Object Management Group) — назва консорціуму, створеного в 1989 році для розробки індустріальних стандартів з їх наступним використанням в процесі створення масштабованих неоднорідних розподілених об'єктних середовищ. Grady Booch Гради Буч Dr. James Rumbaugh Джеймс Рамбо (Джим Румбах) Dr. Ivar Jacobson Айвар Джекобсон (Ивар Якобсон)

Визначення мови UML Unified Modeling Language — уніфікована мова моделювання для опису, візуалізації та документування об'єктно-орієнтованих систем в процесі їх аналізу и проектування мова UML надає стандартний метод написання проектної документації на системи, включаючи концептуальні аспекти, такі як бізнес-процеси та функції системи, а також конкретні аспекти, такі як вирази мов програмування, схеми баз даних та повторно використовувані компоненти ПЗ UML = нотація + семантика !

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

Призначення мови UML Опис мови UML повинен включати в себе семантичний базис для розуміння загальних особливостей об’єктно-орієнтованого аналізу та проектування (ООАП) Сприяти розповсюдженню об'єктних технологій та сприяти розвитку ринку програмних інструментальних засобів Інтегрувати в себе новітні та найкращі досягнення практики ООАП

ООАП – основні поняття Об'єктно-орієнтований аналіз та проектування (Object-Oriented Analysis/Design) — технологія розробки програмних систем, в основу яких покладена об'єктно-орієнтована методологія представлення предметної області у вигляді об'єктів, що є екземплярами відповідних класів Предметна область (domain) – частина реального світу, яка має істотне значення або безпосереднє відношенняя до процесу функціонування програми Діаграмма (diagram) — графичне представлення сукупності элементів моделі у формі зв’язаного графу, вершинам та ребрам (дугам) якого приписується визначена семантика Нотація каноничних діаграм є основним засобом розробки моделей на мові UML

Особливості графічного зображення елементів діаграм мови UML

Особливості зображення діаграм в нотації UML Графічні вузли на площині, які зображуються за допомогою геометричних фігур та можуть мати різну вишину та ширину з метою розміщення всередині цих фігур інших конструкцій мови UML Шляхи, які є послідовністю з відрізків ліній, що з’єднують окремі графічні вузли Значки або піктограми - є графічними фігурами фіксованого розміру та форми, які не можуть збільшити свої розміри, щоб розмістити всередині додаткові символи Рядки тексту служать для представлення різних видів інформації

Загальні рекомендації зображення діаграм в нотації мови UML Кожна діаграма повинна служити закінченим виглядом відповідного фрагменту предметної галузі, що моделюється Всі сутністі на діаграмі моделі повинні бути одного концептуального рівня Вся інформація про сутністі повинна бути явно наведена на діаграмах Діаграми не повинні містити протирічну інформацію Діаграми не слід перевантажувати текстовою інформацією Кожна діаграма повинна бути самодостатньою для правильної інтерпретації всіх її елементів та розуміння семантики всіх використовуваних графічних символів

Протиріччя та адекватність моделей в нотації UML Модель, що відповідає правилам нотації або семантики мови UML називається непротирічною (well-formed model) Модель, що порушує правила нотації або семантики мови UML називається протирічною (ill-formed model) Модель, що достатньо повно та правильно відображує предметну область або проблему називається адекватною Модель, що недостатньо повно или неправильно отражающая предметную область або проблему називається не адекватною

Класифікатори – основні елементи мови UML Прямокутник – основний символ для графічного зображення класифікатору

Класифікатори

Класифікатори

Класифікатори

Класифікатори

Діаграми

Поведінкові діаграми взаємодії

Класифікатори

Класифікація моделей в мові UML Структурні моделі (structured models) – моделі, призначені для опису статичної структури сутностей або елементів системи, включаючи їх класи, інтерфейси, атрибути та відношення. Моделі поведінки (behavioral models) – моделі, призначені для опису процесу функціонування елементів системи, включаючи їх методи та взаємодію між ними, а також процес зміни станів окремих елементів та системи вцілому.

Структурні діаграми (Structure diagrams)

Поведінкові діаграми (behavior diagrams)