Основні принципи системного підходу

u Принцип системної погодженості: методи, підходи, методики, алгоритми, ППП мають бути функціонально та структурно взаємопов’язаними й взаємозалежними, тобто становити єдину системну методологію;

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

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

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

u Принцип цілеспрямованої відповідності: Процедури та прийоми методології мають бути взаємно погодженими та спрямованими на досягнення єдиної мети – забезпечення необхідної вірогідності й обґрунтованості результатів розв’язання проблеми.   

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

u Принцип багатоцільової загальності: системна методологія повинна мати достатній рівень загальності й забезпечувати розв’язання різнотипних класів системних проблем;

u Принцип багатофакторної адаптивності: процедури та прийоми системної методології повинні адаптуватися до як до різнотипних класів системних проблем, так і до вимог ОПР;

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

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

6. Основні види моделей, що застосовуються у системному аналізі. Модель системи типу «чорна скринька»: місце застосування, стандартні вимоги до представлення, приклади.

 

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

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

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

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

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

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

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

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

u Модель складу обмежується знизу тим, що вважається елементом, а зверху — межами системи. Як ці межі, так і границі розділення на підсистеми визначаються цілями побудови моделі і, отже, не мають абсолютного характеру. Це не означає, що сама система або її склад нереальні. В цьому випадку ми маємо справу не з різними системами, а з різними моделями системи.

Модель структури системи

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

u Необхідно правильно з'єднати всі деталі між собою, або встановити між елементами суттєві зв'язки — відношення.

u Сукупність необхідних і достатніх для досягнення цілей відношень між елементами створює структуру системи.

u Перелік зв'язків між елементами (тобто структура системи) є абстрактною моделлю: встановлені тільки відношення між елементами, але не розглянуті самі елементи.

u На практиці говорити про зв'язки можна лише після розгляду самих елементів (тобто розглянута модель складу). Теоретично модель структури можна вивчати окремо.

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

u Розглянемо зв'язок між поняттями " відношення" і " властивість" . У відношенні беруть участь не менш ніж два об'єкти, а властивістю ми називаємо деякий атрибут одного об'єкта. Ця відміна відображається і при їх математичному описі.

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

u Якщо модель складу системи дозволяє ідентифікувати сукупність частин та/або елементів системи, то моделі структури системи описують в тому чи іншому вигляді існування організаційної АГС в просторі та/або в часі в зовнішньому середовищі.

u В системному аналізі організаційних АГС та в проектуванні ІУСТ підприємств доводиться постійно мати справу з різними видами структурних моделей.

Структурна схема системи

u Очевидно, що визначення системи охоплює моделі " чорної скриньки”, складу і структури. Всі разом вони утворюють ще одну модель, яку називатимемо структурною схемою системи.

u У працях зустрічаються також терміни " біла скринька", " прозора скринька", що підкреслюють її відміну від моделі " чорної скриньки"; а також термін " конструкція системи", який ми застосовуватимемо для позначення матеріальної реалізації структурної схеми системи. У структурній схемі вказуються всі елементи системи, всі зв'язки між елементами в середині системи і зв'язки визначених елементів із зовнішнім середовищем (входи і виходи системи).

u Всі структурні схеми мають дещо загальне. Це спонукало розглядати їх як особливий об'єкт математичних досліджень. Абстрагування від змістовної сторони структурних схем дозволяє зосередитись в такий моделі тільки на загальному для кожної схеми. В результаті отримана схема, в якої позначається тільки наявність елементів і зв'язків між ними, а також (у випадку необхідності) різниця між елементами і між зв'язками. Така схема називається графом. Отже, граф складається з позначень елементів довільної природи, що називаються вершинами, і позначень зв'язків між ними, що називаються ребрами (іноді дугами). Наприклад, вершини можуть позначатися у вигляді кільця, а ребра – у вигляді ліній чи стрілок, позначають напрям дії зв'язку. До різних видів структурних схем відносяться лінійні, деревоподібні, матричні, сітьові.В організаційних АГС часто зустрічаються лінійні, деревоподібні (ієрархічні), матричні і сітьові структури; в технічних системах найчастіше зустрічаються сітьові структури; особливе місце в теорії систем займають структури із зворотними зв'язками, які відповідають кільцевим шляхам в орієнтованих графах.

Динамічні моделі систем

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

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

u Системи, в яких відбуваються якісь зміни в часі, називатимемо динамічними, а моделі, що відображають ці зміни, — динамічними моделями систем. Вже на етапі " чорної скриньки" розрізняють два типи динаміки систем: їх функціонування і розвиток. Під функціонуванням розуміють процеси, що відбуваються в системі (і в зовнішньому середовищі), яка стабільно реалізує фіксовану мету (функціонують, наприклад, годинник, місцевий транспорт, кінотеатр, канцелярія, радіоприймач, університет). Розвитком називають те, що відбувається з системою при зміні її цілей. Характерною рисою розвитку є той факт, що існуюча структура перестає відповідати новій цілі. Для забезпечення нової функції доводиться змінювати структуру, а іноді й склад системи, перебудовувати всю систему.

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

2. Типи динамічних моделей такі, як і статичних, тільки елементи цих моделей мають часовий характер. Наприклад, динамічний варіант " чорної скриньки" – підсистема планування в економіці з визначенням початкового (" вхід" ) і кінцевого (" вихід" ) стану системи на деякий момент часу. Моделі складу відповідає перелік етапів, робіт у деякій впорядкованій послідовності дій. Наприклад, доведено, що будь-який алгоритм можна побудувати, використовуючи всього три оператори: " виконувати послідовно", " якщо..., то..." і " виконувати, поки не задовольниться деяка умова". Ці оператори можна розглядати як моделі мінімального складу алгоритму, хоча і не обов'язково складати алгоритм тільки з цих операторів. Динамічний варіант " білої скриньки" - це докладний опис процесу, що робиться або планується.

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

Стратифіковані моделі систем

Стратифікація пов'язана з трьома основними властивостями

ієрархічних систем:

u вертикальною декомпозицією;

u пріоритетом дій;

u взаємозв'язком характеристик якості функціонування системи.

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

u Приклад стратифікації фрагменту системи управління

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

u нижня – поточне планування, де система (об'єкт управління) описується у вигляді якісно більш детальних моделей, наприклад сітьових, із застосуванням відповідних методів);

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

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

u Страти можуть виділятися з урахуванням різних принципів. Наприклад, при зображенні системи управління підприємством страти можуть відповідати рівням управління: управління технологічними процесами (виробничим процесом) і організаційне управління підприємством.   Якщо підприємство входить до об'єднання, то до цих двох страт може бути доданий рівень управління об'єднанням в цілому. Цей же принцип може бути покладений в основу виділення страт у структурі функціональної частини відповідної управляючої інформаційної системи. Стратифіковане зображення може використовуватися і як засіб послідовного поглибленого представлення про систему, її деталізацію. Чим нижче ми спускаємося по ієрархії страт, тим більш детальним стає розкриття системи. Чим вище піднімаємося, тим яснішим стає смисл і значення всієї системи. З'ясувати призначення системи за допомогою елементів нижньої страти в складних системах практично неможливо.

 

 

7. Моделі потоків даних(DFD-моделі): призначення, місце застосування в системному аналізі, правила побудови, приклади.

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

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

DFD використовує чотири основних елементи:
- роботи – в DFD позначають функції або процеси, які обробляють і змінюють інформацію. Роботи представлені на діаграмах у вигляді прямокутників з округленими кутами;
- стрілки – вказують від об'єкта-джерела до об'єкта-приймача, позначаючи інформаційні потоки в системі документообігу;
- зовнішні посилання – вказують на місце, організацію або людину за рамками цієї діаграми;
- сховища даних – являють собою дані, до яких здійснюється доступ, ці дані можуть бути створені або змінені роботами. На одній діаграмі може бути представлено кілька копій того самого сховища даних.
Побудовані моделі потоків даних організації можуть бути використані при рішенні наступних завдань:
- визначення існуючих сховищ даних (текстові документи, файли, система керування базою даних – СУБД);
- визначення й аналіз даних, необхідних для виконання кожної функції процесу;
- підготовка до створення моделі структури дані організації, так називаної ERD-моделі (IDEF1X);
- виділення основних і допоміжних бізнесів-процесів організації.
Слід також зазначити, що нотацію DFD можна ефективно застосовувати для опису як потоків документів, так і потоків матеріальних ресурсів (у тому числі на одній і тій же діаграмі).

DFD виконує такі задачі:

ü показує зовнішні за відношенням до системи джерела і адресати даних;

ü ідентифікує логічні функції (процеси), а також інформаційні об'єкти (групи елементів даних);

ü зв'язує одну функцію (процес) з іншою, тобто формує потоки даних;

ü ідентифікує сховища, що накопичують дані, до яких здійснюється доступ.    

 Структури потоків даних і визначення їх компонент зберігаються та аналізуються в словнику даних. Кожна логічна функція (процес) може бути деталізована за допомогою DFD нижнього рівня. Коли подальша деталізація стає не корисною, переходять до відображення логіки функції за допомогою специфікації процесу (мініспецифікації). Приклад фрагменту діаграми DFD (потоків даних) для функції F 11 в деякій типовій ситуації (активізовані: Замовник, ІУСТ (БД клієнтів, класифікатор продукції, блок бухгалтерії), менеджер з роботи з клієнтами):

8. Кроки процесу побудування моделей типу DFD

u Модель потоков даних (DFD):

u  містить зовнішні за відношенням до системи джерела і стоки

(адресати) даних;

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

u ідентифікує накопичувачі даних, до яких здійснюється доступ.

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

Для відображення потоків даних в різних методологіях проектування ІТ використовуються різні нотації. Традиційно використовуються два види нотацій: Йордана і Гейна-Сарсона.

u Основні символи цих нотацій наведені в таблиці:

Приклади представлення нотацій DFD

1. Фрагмент моделі “дерево функції”: “Оформлення замовлень”

F11 – оформлення замовлень

F111 – перевірка і внесення даних про клієнта;

F112 – внесення замовлення до “портфелю замовлень” (ПЗ)

2. Нотація моделі IDEF0 – “чорна скринька” або робота (F11), що в подальшому належить декомпозиції:

Приклад фрагменту діаграми DFD (потоків даних) для функції F11 в деякій типовій ситуації (активізовані: Замовник, ІУСТ (БД клієнтів, класифікатор продукції, блок бухгалтерії), менеджер з роботи з клієнтами):

9. Зміст стадій канонічного проектування КІС

До стадій канонічного проектування відносять:

1. Визначення вимог – дослідження діючою системи, визначення недоліків

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

3. Реалізація

4. Експертне тестування

5. Ввод в експлуатацію та супроводження

10. Заг. характеристика етапів проектування КІС. Технічне завдання на розробку КІС. Його зміст.

Сутність змісту процесу створення інформаційних управляючих систем і технологій (ІУСТ) організаційних АГС зводиться до виконання наступних стандартизованих етапів (стадій):

· Планування і аналіз вимог предметної області (передпроектна стадія) . На цій стадії здійснюються дії з використанням методів і засобів системного аналізу. Розробляються попередній бізнес-план (техніко-економічне обґрунтування) та технічне завдання на розробку.

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

· Реалізація (робоче проектування, фізичне проектування, програмування). На цій стадії здійснюються розробка і настроювання (тестування програмних модулів і програм в цілому) програм, наповнення баз даних, створення робочих інструкцій для персоналу, оформлення робочого проекту ІУСТ в цілому.

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

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

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

· із системного аналізу;

· системного синтезу (проектування та створення);

· впровадження розробленого проекту ІУСТ;

· експлуатації та супроводження ІУСТ.

Узагальнена технологічна схема створення ІУСТ наведена на наступному слайді

У системному аналізі:

· формулюються потреби  в новій ІУСТ (ідентифікуються всі недоліки існуючих системи управління та ІУСТ);

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

У системному синтезі:

· здійснюється конструювання архітектури ІУСТ (функціональної та системної);

· розробка технічного та робочого проекту ІУСТ.

· Конструювання моделей архітектури ІУСТ є важливим етапом тому, що тут закладаються основні рішення, зміна яких в подальшому призводить до великих втрат.

· Впровадження розробленого проекту ІУСТ не завжди здійснюється для системи в цілому. Іноді це здійснюється поетапно. Тому тут теж виникають ситуації, коли необхідно коригувати проект після кількох етапів впровадження. Перевірка відповідності вимогам та прийнятим у проекті рішенням на етапі впровадження стає основною задачею розробників і користувачів. Без засобів системного аналізу це зробити практично неможливо.

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

  МОЖЛИВІ ІТЕРАТИВНІ ЦИКЛИ В ПРОЦЕСІ РОЗРОБКИ ІТ

Можна виділити кілька таких ітеративних циклів. Наприклад:

§ перший ітеративний цикл включає " виявлення потреб замовника – встановлення вимог до створення попередніх цільових та функціональних моделей ІУСТ";

§ другий ітеративний цикл включає " виявлення типових ситуацій та необхідних варіантів економіко-математичних моделей – їх вирішення – уточнення цільових та функціональних моделей ІУСТ з узгодженням цих моделей";

§ третій ітеративний цикл може виникнути після первинного проектування і конструювання функціональної архітектури та системної архітектури ІУСТ, де здійснюються уточнення суттєвих вимог;

§ четвертий ітеративний цикл може виникнути після розробки робочого проекту ІУСТ в цілому (або її окремих підсистем) та експериментального впровадження, коли встановлюються часткові помилки та відхилення від прийнятих вимог;

u п'ятий ітеративний цикл може виникнути після здачі ІУСТ в промислову експлуатацію, коли виявляють системні помилки та відхилення від проекту (помилкові відношення між елементами системи, недостатньо враховані вимоги до інформаційного опису об'єктів та ін.);

u шостий ітеративний цикл може виникнути у тому випадку, коли необхідно адаптувати ІУСТ до нових умов функціонування організаційної АГС;

u сьомий ітеративний цикл виникає, коли і діюча ІУСТ, і існуюча організаційна АГС не відповідають новим обмеженням зовнішнього середовища.

На протязі розвитку комп'ютерних технологій існували три типи методологій проектування ІУСТ:

u каскадна модель проектування (до середини 70-х років минулого століття) – це послідовний перехід до наступного етапу проектування після повного завершення попереднього;

u ітераційна модель проектування (70-80 роки) – це ітераційне повернення на попередні етапи для їх уточнення після виконання чергового етапу;

u спіральна модель проектування (80-90 роки) – прототипна модель, що передбачає поступове розширення прототипу ІУСТ.

В основі спіральної моделі використовується підхід до проектування ІУСТ по принципу " зверху-вниз" (від цілей до функціональних підсистем і далі до постановки задач в окремих ситуаціях).

 

11.Інструментальні засоби IDEF для функціонально-організаційного моделювання.

Інструментальні засоби – Case-технології, IDEF –потоки даних

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

· функції, які система повинна виконувати;

· відношення між інформаційними об'єктами та даними;

· ситуаційну поведінку систем у часі.

До таких засобів структурного моделювання відносяться такі основні схемні моделі:

· моделі “чорної скриньки”;

· діаграми потоків даних – DFD (Data Flow Diagrams) – сумісно із словниками даних і специфікаціями процесів;

· діаграми " сутність-зв'язок" – ERD (Entity–Relationship Diagrams);

· діаграми переходів станів – STD (State Transition Diagrams).

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

12. Діаграми стану: STD-моделі: призначення, місце застосування в системному аналізі, правила побудови, приклади.

Діаграми переходів станів (State Transition Diagrams, STD), які відображають поведінку системи, залежну від часу; діаграми життєвих циклів сутності відносяться саме до цього класу діаграм.

Життєвий цикл сутності відноситься до класу STD-діаграм (рис. 4).

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

STD складається з таких об'єктів:

СТАН, який може розглядатись як умова стійкості для системи. Знаходячись у визначеному стані, ми маємо достатньо інформації про історію поведінки системи для того, щоб визначити черговий стан в залежності від поточних вхідних подій. Ім'я стану повинно відображати реальну ситуацію, в якої знаходиться система, наприклад, ПРИЙНЯТТЯ РІШЕННЯ, ЗВІТНІСТЬ тощо.

ПОЧАТКОВИЙ СТАН – вузол STD, що є стартовою точкою для початкового системного переходу. STD має тільки один початковий стан.

Рекомендовані правила побудови STD:

будувати STD на як можна більш високому рівні деталізації DFD;

будувати як можна більш простіші STD;

за можливістю деталізувати STD;

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: