Мет_ЛР_ТССА_2017_2. Методичні вказівки до лабораторних робіт з дисциплін теорія систем та системний аналіз
 Скачать 1.02 Mb.
|
|
3.2 Методичні вказівки з організації самостійної роботи студентів Під час підготовки до виконання лабораторної роботи необхідно: вивчити основні завдання системного аналізу; вивчити зміст основних етапів розробки програмних систем та їх життєвого циклу; вивчити призначення методології структурного аналізу і проектування систем SADT; вивчити призначення сімейства методологій IDEF; вивчити призначення стандарту IDEF0 та ознайомитися з його нотацією; вивчити призначення CASE-засобів та функції програмного пакета All Fusion Process Modeler (BpWin); вивчити основні етапи процесу створення функціональної моделі системи за стандартом IDEF0. Для підготовки до лабораторної роботи необхідно використовувати навчальний посібник [1], конспект лекцій [2], методичні вказівки до самостійної роботи [3] і рекомендовану літературу [4-11]. 3.3 Опис лабораторної установки У якості лабораторної установки використовується персональний комп'ютер типу IBM PC. Виконання завдань лабораторної роботи здійснюється за допомогою CASE-засобу All Fusion Process Modeler (BpWin). 3.4 Порядок виконання роботи і методичні вказівки з її виконання 3.4.1 Завдання на лабораторну роботу Кожному виконавцю лабораторної роботи згідно варіантом, представленим у табл. 3.1, потрібно розробити функціональну модель системи з точки зору її адміністратора, який її експлуатує. Таблиця 3.1 – Варіанти завдання для лабораторної роботи № 3
3.4.2 Порядок виконання роботи Методологія функціонального моделювання IDEF0 (Integrated Definition Function Modeling), є підмножиною методології структурного аналізу і проектування SADT (Structured Analysis And Design Technique). При SADT-моделюванні систем використовуються взаємодоповнюючі один одного моделі двох типів: функціональні моделі, що виділяють події (функції, бізнес-процеси) у системі; моделі даних, що виділяють об'єкти (дані) системи. При реалізації воєнної програми інтегрованої комп'ютеризації виробництва (ICAM – Integrated Computer-Aided Manufacturing) у США були розроблені принципи підвищення ефективності розробки і виробництва систем за рахунок застосування комп'ютерних технологій. Відповідно до проекту ICAM було розроблене сімейство методологій IDEF (IDEF – ICAM Definition), що складається з ряду самостійних методологій моделювання різних аспектів функціонування систем різного призначення. Для створення функціональних моделей систем використовуються CASE-засоби. У цей час використовується двояке тлумачення абревіатури CASE, що відповідає двом напрямкам використання даного виду систем. Перше з них – Computer Aided Software Engineering – переводиться як автоматизоване проектування програмного забезпечення, а відповідні CASE-системи часто називають інструментальними середовищами розробки програмного забезпечення RAD (Rapid Application Developmen – методологія швидкої розробки програмного забезпечення). Друге – Computer Aided System Engineering – сукупність методів і засобів проектування інформаційних систем – підкреслює спрямованість на підтримку концептуального проектування складних систем, переважно зі слабким структуруванням. Такі CASE-системи часто називають системами BPR. BPR (Business Process Reengineering) – методологія реінжинірингу бізнесу. Вона заснована на корінної (радикальної, стрибкоподібної, фундаментальної) зміні бізнесу, перехід до бізнесу, орієнтованого на процеси, що дозволяє збільшити виробничі потужності і прибуток у десятки разів. Сучасні CASE-засоби охоплюють велику область підтримки багаточисельних технологій проектування програмних систем: від простих засобів аналізу і документування до повномасштабних засобів автоматизації, що підтримують увесь життєвий цикл програмного забезпечення. Найбільш відомими засобами CASE-засобів розробки систем на етапі пред'явлення вимог і проектування бази даних є: пакет All Fusion Process modeler (BPWin), що дозволяє проводити моделювання з використанням стандартів IDEF0, IDEF3, DFD; пакет All Fusion Data modeler (ERWin), що дозволяє проводити логічне і фізичне моделювання структури даних систем з використанням ER‑діаграм (ER, «Entity-Relationship» – «сутність-зв'язок») у нотації стандарту IDEF1Х и нотації Мартіна; Методологія функціонального моделювання IDEF0, що прийнята в якості федерального стандарту США, включає: нотацію моделювання (умовні позначки), що складається з елементів, за допомогою яких будується функціональна модель; метод моделювання (спосіб аналізу), що включає опис порядку та правил використання елементів нотації IDEF0. Стандарт IDEF0 використовується для створення функціональних моделей, що відображають структуроване зображення функцій виробничої системи або середовища, а також інформації і об'єктів, що зв'язують ці функції. З погляду розроблювача IDEF0 – це методологія функціонального моделювання, що дозволяє описати бізнес-процеси системи у вигляді ієрархічної системи взаємозалежних функцій. Функціональна модель системи, що створюється за допомогою стандарту IDEF0, може бути використана: для визначення функціональних вимог до розроблювальної системи; для аналізу функцій існуючої системи та визначення вимог до її доробки. Порядок створення функціональної моделі по стандарту IDEF0 включає наступні етапи. На першому етапі побудови моделі IDEF0 системному аналітикові необхідно чітко сформулювати мету розробки моделі і точку зору особи, з погляду якої вона розробляється. «Точка зору» моделі відображає позицію особи, що приймає рішення на розробку моделі. Зміна точки зору моделі може зробити її неадекватною. Після визначення мети і точки зору моделі починається перша ітерація процесу побудови моделі за методологією IDEF0. Системний аналітик визначає, що включати в модель, а що ні. Точка зору диктує авторові моделі вибір потрібної інформації і спосіб її подачі. Мета стає критерієм закінчення моделювання. Кінцевим результатом цього процесу є набір ретельно взаємодіючих описів, починаючи з опису самого верхнього рівня всієї системи (контекстна діаграма) і кінчаючи детальним описом функцій або операцій системи (декомпозиція контекстної діаграми). Кожен з таких ретельно погоджених описів називається діаграмою. Для створення діаграм використовується нотація стандарту idef0. Нотація idef0 включає наступні елементи.  Рисунок 3.1 – Нотація функціонального блоку (Activity) для контекстної діаграми Елемент «Activity» – функціональний блок, що зображується на діаграмах прямокутником. Призначення функціонального блоку – дати визначення функції, що виконує система або її частина, тому найменуваннями блоків (функцій) служать дієслова або дієслівні звороти (рис. 3.1). Елемент Arrow (рис. 3.2) – дуга (зв'язок), що описує взаємодію функцій (блоків) із зовнішнім миром і між собою. Елементи Arrow представляються на діаграмах у вигляді ліній зі стрілками. Оскільки дуги позначають об'єкти даних, то вони описуються (позначаються) іменниками або іменниками з визначеннями.  Рисунок 3.2 – Нотація дуг (Arrow), що входять до функціонального блоку (Activity) контекстної діаграми В нотації IDEF0 (рис. 3.2) розрізняють наступні типи дуг; дуга, що визначає «Вхід» (Input) – матеріал або інформація, які використовуються або перетворяться блоком для одержання результату (виходу). Блок може не мати вхідної дуги. Даний вид дуги надходить на ліву сторону блоку. дуга, що визначає «Управління» (Сontrol) – умови, правила, стратегії, стандарти, які впливають на виконання функції. Кожний блок повинен мати хоча б одну дугу управління. Даний вид дуг надходить на верхню сторону блоку. дуга, що визначає «Вихід» (Output) – результат виконання функції (матеріал або інформація). Кожна функція повинна мати хоча б одну вихідну дугу. Даний вид дуг виходить із правої сторони блоку. дуга, що визначає «Механізм» (Mechanism) – ресурси, за допомогою яких виконується робота (персонал підприємства, програмне забезпечення, обладнання). Даний вид дуг з'єднується з нижньою стороною блоку. На другому етапі створюється перша (контекстна) діаграма системи (рис. 3.2). Вона містить один функціональний блок (Activity), в якому вказується найменування глобальної функції, що виконує система. На цій діаграмі вказуються глобальні вхідні та вихідні дані, а також дані, що використовуються системою в якості «Управління» та «Механізму». На третьому етапі здійснюється послідовна декомпозиція, спочатку контекстної діаграми, а потім кожної функції (Activity), що входять до діаграм декомпозиції. Таким чином, створюється функціональна модель IDEF0, що об'єднує і організовує діаграми в ієрархічні структури, в яких діаграми верхнього рівня менш деталізовані, чим діаграми нижнього рівня. На рис. 3.3 представлена ієрархічна структура декомпозиції концептуальної діаграми IDEF0 системи. Діаграми декомпозиції IDEF0 дозволяють розширити представлення щодо глобальної функції системи шляхом розділення її над підфункції (декомпозиції). На діаграмах декомпозиції IDEF0 (рис. 3.4), крім вже описаних вище, використовуються наступні види зв’язків (Arrow) для опису відношень між функціональними блоками (Activity): зворотний зв'язок по управлінню (Output-Control Feedback); зв'язок по управлінню (Output-Control); зв'язок по входу (Output-Input); зворотний зв'язок по входу (Output-Input Feedback); зв'язок вихід-механізм (Output-Mechanism). Оскільки дуги представляють набори об'єктів, вони можуть мати кілька початкових точок (джерел) і кінцевих точок (призначень). Тому дуги можуть розгалужуватися і з'єднуватися різними способами. Розгалуження дуг, що відображається у вигляді ліній, які розходяться до різних Activity, означає, що весь вміст дуг (даних, що прив’язані к ним) або їх частина може з'явитися в кожному відгалуженні дуги. Дуга завжди позначається до розгалуження, щоб дати назву всьому набору. Кожна гілка дуги може бути помічена або не помічена відповідно до наступних правил: помічені гілки містять всі об'єкти, вказані в мітці дуги перед розгалуженням (тобто всі об'єкти належать цим гілкам); гілки, помічені після крапки розгалуження, містять всі об'єкти або їх частину, вказані в мітці дуги перед розгалуженням (тобто кожна мітка гілки уточнює, що саме містить гілку). З'єднання дуг, що відображається як лінії, що сходяться разом, вказують, що вміст кожної гілки йде на формування мітки для дуги, що є результатом злиття вихідних дуг.  Рисунок 3.3 – Ієрархічна структура створення функціональної моделі IDEF0 за результатами декомпозиції  Рисунок 3.4 – Види внутрішніх зв’язків (Arrow) на діаграмі декомпозиції Після з’єднання результуюча дуга завжди позначається для вказівки нового набору об'єктів, що виникають після об'єднання. Крім того, кожна гілка перед з'єднанням може позначатися або не позначатися відповідно до наступних правил: непомічені гілки містять всі об'єкти, вказані в загальній мітці дуги після з'єднання (тобто всі об'єкти виходять зі всіх гілок); помічені перед з'єднанням гілки містять всі або деякі об'єкти з перерахованих в загальній мітці після з'єднання (тобто мітка гілки ясно вказує, що містить гілку). На четвертому етапі завершується процес розробки функціональної моделі IDEF0. Створюється «Діаграми древа вузлів», що відображає ієрархію декомпозиції від глобальної функцій системи до усіх її підфункцій нижнього рівня. Також на цьому етапі готуються звіти (Reports) за об’єктами та зв’язками, що використовуються на діаграмах декомпозиції IDEF0. 3.5 Зміст звіту Звіт повинен містити: мету роботи; опис вибору мети і точки зору для досліджуваного об'єкту; діаграма верхнього рівня (контекстна діаграма) А0; декомпозиція контекстної діаграми верхнього і подальших рівнів для повного опису досліджуваної системи; звіт у вигляді списку об'єктів Activity; звіт у вигляді списку об'єктів Arrow; діаграма дерева вузлів, що містить ієрархічний список функцій, які повинна виконувати система; аналіз отриманих результатів і висновки по роботі. 3.6 Контрольні запитання та завдання Для рішення яких завдань застосовується системний аналіз? Яке призначення має методології структурного аналізу і проектування SADT? Яке призначення має сімейство методологій IDEF? Яке призначення стандарту IDEF0? Які складові входять до стандарту IDEF0? Перелічить елементи, що входять до нотації стандарту IDEF0. Пояснить призначення елементу нотації «Activity». Визначите поняття «бізнес-процес» і поясните, яким-образом відбувається його ідентифікація при структурному аналізі? Пояснить призначення елементу нотації «Arrow» та їх можливі типи. Опишіть п'ять типів взаємозв'язку між елементами «Activity»? Сформулюйте поняття «функціональна модель системи». Для вирішення яких завдань створюється функціональна модель системи? Для чого застосовується візуальне проектування? Для вирішення яких завдань використовуються CASE-засоби? Яке призначення і функції пакета All Fusion Process Modeler (BpWin)? Вкажіть основні етапи процесу створення функціональної моделі системи за стандартом IDEF0 і допомогою CASE-засобу BpWin. 4 РОЗРОБКА МОДЕЛІ ПОТОКІВ ДАНИХ СИСТЕМИ 4.1 Мета роботи Ознайомитися з особливостями створення функціональної моделі потоків даних програмної системи за стандартом DFD. Отримати практичні навички створення контекстної діаграми та діаграм декомпозицій з використанням CASE-засобу All Fusion Process Modeler (BpWin). 4.2 Методичні вказівки з організації самостійної роботи студентів Під час підготовки до виконання лабораторної роботи необхідно: вивчити основні завдання системного аналізу; вивчити зміст основних етапів розробки систем та їх життєвого циклу; вивчити призначення методології структурного аналізу і проектування систем SADT; вивчити призначення сімейства методологій IDEF; вивчити призначення стандарту DFD та ознайомитися з його нотацією; вивчити призначення CASE-засобів та функції пакета All Fusion Process Modeler (BpWin); вивчити основні етапи процесу створення моделі потоків даних системи за стандартом DFD. Для підготовки до лабораторної роботи необхідно використовувати навчальний посібник [1], конспект лекцій [2], методичні вказівки до самостійної роботи [3] і рекомендовану літературу [4-11]. |