Інструкції до виконання лабораторних робіт з дисципліни Моделі та методи проектування інформаційних систем, НУ ЛП

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА” 

Інститут комп’ютерних наук та інформаційних технологій 

Кафедра інформаційних систем та мереж

Інструкції до виконання лабораторних робіт

з дисципліни

«Моделі та методи проектування інформаційних систем»

для студентів спеціальності

8.180003 "Управління проектами"

кваліфікаційного рівня "магістр"

Затверджено на засіданні

кафедри інформаційних систем та мереж 

Протокол № 1 від “ 30 ” серпня 2010 р.

Львів-2010 

Моделювання ПО з використанням структурної та об’єктно-орієнтованої методик

Діяльність і моделі процесу 

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

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

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

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

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

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

Прямокутник діяльності, що зображений на малюнку 1-2, показує рамку системи. Якщо ми придивимося детальніше до цього прямокутника, – фактично заглянемо всередину –, ми побачимо й інші прямокутники. Ці прямокутники, в свою чергу, можуть місти і свої власні дочірні прямокутники. Малюнок 1-3 показує ієрархічну залежність діяльності у форматі графічної демонстрації.

Більш скорочений формат демонстрації ієрархії ілюструється в Таблиці 1-1. 

Таблиця 1.1. Часткова ієрархія діяльності у формі плану 

Методи моделювання діяльності 

Ця книга описує три методи моделювання діяльності – IDEF0 метод моделювання функції, IDEF3метод збору опису процесу та діаграму потоків даних (DFD).

IDEF0, спочатку названий як структурний аналіз і метод проектування (SADT^®), який був розроблений компанією SofTech, наприкінці 1960-х як технічна дисципліна для розробки (проектування) комплексних систем машин та людей. Американські Воєнно-Повітряні сили прийняли багато різновидів SADT (називаючи їх в процесі IDEF0) як частину свого інтегрованого автоматизованого керування виробництвом (Integrated Computer-Aided Manufacturing (ICAM)) протягом кінця 1970-х, і ця методика швидко стала стандартом технологіїї моделювання діяльності американського Міністерства оборони (Department of Defense’s (DoD)).

В 1993р. Група Користувачів IDEF (тепер Організація Прикладного Підприємництва (Society of Enterprise Engineering – SEE), у співробітництві з Національними Інститутами Стандартів і Технології (National Institutes of Standards and Technology – NIST), зробили зусилля, щоб створити документований стандарт IDEF0 для використання всіма цивільними і військовими галузями американського уряду та їхніми союзниками. Цей стандарт опублікований під назвою Федеральні Стандарти Опрацювання Інформації (Federal Information Processing Standards – FiPS) видання 183.

В деякі мірі незалежно, але використовуючи багато тих самих принципів, технології DFD стали популярними для структурного проектування (і пізніше, структурного аналізу) програмного забезпечення розробки проектів. Діаграми потоків даних у багатьох відношеннях схожі до моделей IDEF0 і можуть використовуватися для детального моделювання проекту як доповнюючі для розвитку IDEF0 аналізу моделей.

IDEF3 був розроблений спеціально для проекту, підтриманого американською Лабораторією Повітряних Сил Армстронга. Це технологія для збору описів процесу від експертних предметів і для проектування моделей процесу, де важливо зрозуміти послідовність діяльності і паралелізм. Хоча IDEF3 не досяг того ж самого статусу, що й FiPS, проте ця технологія одержала широке сприйняття в межах Dod (Міністерства оборони) для процесу моделювання як доповнення до IDEF0 моделювання діяльності.

Структурний аналіз і проектування 

Структурний аналіз і проектування – назва класу декількох формальних методів (процесів), що використовуюються для аналізу і проектування систем. Хоча можливо розробити моделі діяльності поза структурним аналізом проекту, проте важливо зрозуміти контекст, у якому моделі діяльності зазвичай формуються. На додаток до моделей діяльності, структурний аналіз включає інформаційні моделі, що моделюють дані, і діаграми переходів (state-transition diagrams – STD), що моделюють часову поведінку системи.

Основний принцип структурного аналізу і проектування – повний аналіз поточної системи є необхідним для проектування оптимального рішення. Значна кількість даних зібрана і проаналізована як частина процесу. Традиційно, інформація зібрана аналітиком, що формально бере інтерв'ю у фахівців (експертів) із певної області знань, – людей, які добре інформовані щодо системи, що нас цікавить. Через деякий час, деякі фахівці з проблемної області вчилися формувати моделі діяльності, і нові методи моделювання діяльності (наприклад, IDEF3) були розроблені, щоб полегшити збір інформації від фахівців з проблемної області. Проте, центральна роль аналітика в структурному аналізі і проектуванні проекту залишається в значній мірі незачепленою.

Часто, моделі спочатку розроблені, щоб документувати поточне місце розташування (відомі, як AS-IS моделі). Ці моделі пізніше використані як засіб розробки проектування моделей (відомі як TO-BE моделі). Вони також використовуються як еталонний тест, з якими TO-BE моделі співставляються, щоб гарантувати, що запропонований проект – дійсно покращений.

На додаток до управління проектом запропонованої системи, TO-BE моделі використовуються для планування завантаження, складання бюджету, і отримання ресурсів. Моделі також використовуються, щоб одержати проектний план реалізації, який визначає, як система перетворена від AS-IS ситуації в TO-BE ситуацію.

Потрібно звісити прибуток від розробки AS-IS моделей з вартістю та часом розробки. Ділова література переповнена прикладами існуючих систем, що розв'язують хибну проблему, яку може допомогти зрозуміти AS-IS моделювання. З іншого боку, якщо проблема, в загальному, добре зрозуміла (часто випадок формування комп'ютерних систем), то рентабельність AS-IS моделювання менше очевидна.

Системний аналіз об’єкту дослідження та предметної області

У попередньому розділі було розглянуто теоретичне підґрунтя реальних явищ предметної області. Мета цього розділу полягає в переведенні  властивостей та зв’язків реальних явищ  з оточенням  в абстрактні категорії теорії систем, а також виявити нові конкретні властивості та взаємні зв’язки даного об’єкта дослідження. За допомогою системного аналізу ми намагатимемося знайти шлях, яким можна перетворити складну проблему в простішу, а правильно поставити задачу — це означає на 50%  її розв’язати.

Проблеми розрізняються за ступенем їх структурованості:

• добре структуровані та сформульовані кількісно;

• слабо структуровані, в яких зустрічаються як кількісні, так і якісні оцінки;

• неструктуровані, якісні проблеми.

Системний аналіз застосовується для розв’язання складних проблем, що пов’язані з діяльністю людей.

Людську діяльність умовно можна поділити на дві області:

• рутинна діяльність, розв’язання регулярних, щоденних завдань;

• розв’язання нових задач, які виникають вперше.

Мова описів UML

Нам необхідно провести аналіз та реалізувати розв’язання проблеми видачі путівок для студентів на оздоровлення. Для опису системного аналізу ми використаємо мову UML.

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

Почавши уніфікацію, автори поставили перед собою три головні цілі:

• моделювати системи цілком, від концепції до артефакту, що виконується, за допомогою об‘єктно-орієнтованих методів;

• вирішити проблему масштабованості, що властива складним системам, призначеним для виконання відповідальних завдань;

• створити таку мова моделювання, що може використовуватися не тільки людьми, але й комп'ютерами.

Словник мови UML включає три види будівельних блоків:

• сутності;

• відносини;

• діаграми.

В UML є чотири типи сутностей:

• структурні;

• поведінкові;

• що групують;

• анотаційні.

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

Далі розглянемо основні поняття даної мови та компоненти, які ми будемо використовувати при побудові діаграм:

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

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

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

Прецедент (Use case) - це опис послідовності виконуваних системою дій, що робить спостережуваний результат, значимий для якогось певного актора (Actor).

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

Компонент (Component) - це фізична замінна частина системи, що відповідає деякому набору інтерфейсів і забезпечує його реалізацію.

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

Взаємодія (Interaction) - це поводження, суть якого полягає в обміні повідомленнями (Messages) між об'єктами в рамках конкретного контексту для досягнення певної мети.[14]

Системний опис спроектованої системи

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

Рис.1 Основні користувачі даної системи та основні події

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

Рис.2.  Зв'язки між об'єктами 

Рис.3. Організація сукупності компонентів і існуючі між ними залежності.

На діаграмі компонентів представлена організація сукупності компонентів і існуючі між ними залежності. Діаграми компонентів відносяться до статичного виду системи з погляду реалізації.

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

Рис.4.  Діаграмами класів

Далі розглянемо діаграму активності, що відображає загальний процес рішення: 

Рис. 2.5 Діаграма активності

На діаграмі розгортання представлена конфігурація вузлів системи й розміщених у них компонентів: 

Рис. 2.6  Діаграма розгортання

Висновки до роділу:

Отже проведений системний аналіз об’єкту дослідження та проблемної області, відповідає основним принципам:

Принцип остаточної мети;

Принцип єдності;

Принцип зв’язності;

Принцип модульності;

Принцип ієрархії:  в системі реалізована ієрархічна побудова;

Принцип функціональності: структура системи та її функції повинні розглядаються сумісно з пріоритетом функції над структурою;

Принцип розвитку: необхідно враховувати змінність системи, її здатність до розвитку, розширення, заміни складових, накопичення інформації;

Принцип децентралізації: в управлінні системою співвідношення між централізацією та децентралізацією визначається призначенням та метою системи;

Принцип невизначеності: невизначеності та випадковості повинні братися до уваги при визначенні стратегії та тактики розвитку системи.

З повагою ІЦ "KURSOVIKS"!