Методичні вказівки з організації самостійної роботи студентів. Побудова моделі об’єкта автоматизації “AS-IS” із застосуванням методології IDEF0

ЛАБОРАТОРНА РОБОТА 1.

Побудова моделі об’єкта автоматизації “AS-IS” із застосуванням методології IDEF0

Мета роботи

Отримати навики з проектування інформаційних систем за допомогою інструментальних засобів. Побудувати модель об’єкта автоматизації типу "AS-IS" використовуючи методологію IDEF0. Засвоїти основні принципи функціонального моделювання бізнес-процесів на прикладі методології функціонального моделювання IDEF0.

Методичні вказівки з організації самостійної роботи студентів

При підготовці до лабораторної роботи необхідно вивчити літературу і лекційний матеріал з дисципліни «Проектування інформаційних систем». Для виконання роботи необхідно мати уявлення про характер роботи вибраного об'єкта автоматизації, клас і призначення проектованої системи. Лабораторну роботу рекомендовано виконувати за допомогою засобу функціонального моделювання BPwin.

1.2.1 Базові поняття функціонального моделювання.

За допомогою простої графічної мови IDEF0 система, яку необхідно змоделювати, може бути відображена у вигляді набору функціональних блоків, пов’язаних між собою.

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

Кожний з чотирьох боків функціонального блоку має своє певне призначення:

− Верхній бік – "Управління" (Control);

− Лівий бік – "Вхід" (Input);

− Правий бік – "Вихід" (Outpu);

− Нижній бік – "Механізми" (Mechanism).

Кожний функціональний блок у рамках розглянутої системи повинен мати свій унікальний ідентифікаційний номер (рис. 1.1).

Рис. 1.1 Функціональний блок.

Нумерація блоків і діаграм. Усі функціональні блоки IDEF0-діаграм нумеруються. У більшості випадків використовується префікс А, номер блоку проставляється за префіксом. Контекстний блок завжди має номер А0. Префікс залишається незмінними для кожного блоку моделі. Номер вказує на рівень декомпозиції блоку, для кожного рівня у кінці номера додається одна цифра (наприклад: А0 декомпозований у А1, А2, А3 і т. д.; А1 декомпозований у А11, А12, А13 і т. д.).

Стрілки. Існує чотири основні типи стрілок, кожний з яких приєднується до свого боку функціонального блоку. Для назви стрілок використовують іменники, які відображають людей, місця, речі, ідеї, події тощо. У різних джерелах стрілки можуть мати різні назви: інтерфейсні стрілки, дуги, потоки та ін. Основне призначення стрілок полягає у відображенні елементів системи, які обробляються функціональним блоком або здійснюють новий вплив на бізнес-процес, відображений даним функціональним блоком.

1. Вхідні стрілки характеризують сировину, матеріали або інформацію, яка перетворюється функціональним блоком для створення виходу (продукту, дії, інформації). Наявність вхідних стрілок необов’язкова, так як деякі блоки нічого не перетворюють і не змінюють.

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

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

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

Тунелювання. Часто виникають випадки, коли окремі стрілки не має сенсу розглядати у дочірніх діаграмах нижче певного рівня у ієрархії, або, навпаки, окремі стрілки не мають практичного сенсу вище певного рівня. Для розв’язання подібних задач у методології IDEF0 передбачене тунелювання. Позначення "тунелю" (Arrow Tunnel) у вигляді двох круглих дужок навколо початку стрілки означає, що ця стрілка не була успадкована від функціонального батьківського блоку і з'явилася тільки на цій діаграмі. У свою чергу, те саме позначення навколо кінця стрілки означає, що у дочірній відносно до цього блоку діаграмі ця стрілка відображатися і розглядатися не буде. Найчастіше, окремі об’єкти і відповідні їм стрілки не розглядаються на деяких рівнях ієрархії – у такому випадку вони спочатку "занурюються у тунель", а потім, при необхідності, "повертаються з тунелю".

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

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

Рис. 1.2 Декомпозиція функціональних блоків.

Мета. Жодна модель не може бути побудована без конкретного об’єкту або мети. Формулювання мети повинно відповідати на наступні питання:

− для чого був змодельований процес;

− що відображає модель;

− що можна зробити за допомогою моделі.

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

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

При побудові моделі важливо дотримуватися однієї точки зору. Точка зору повинна складатися з посади, структурного підрозділу або опису посадових обов’язків.

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

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

Побудова моделі "AS IS". Обстеження підприємства є обов’язковою частиною будь-якого проекту створення або розвитку корпоративної інформаційної системи. Побудова функціональної моделі "AS IS" дозволяє чітко зафіксувати, які процеси відбуваються на підприємстві, які інформаційні об’єкти використовуються при виконанні цих процесів та окремих операцій. Функціональна модель "AS IS" є підґрунтям для аналізу потреб підприємства, виявлення проблем і розробки проекту удосконалення ділових процесів.

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

Після побудови та верифікації моделі "AS IS" аналітику необхідно провести її якісне дослідження, оптимізацію, необхідну для побудови моделі "TO BE".

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

1.2.2 Види IDEF0-діаграм.

У якості доповнення до контекстних діаграм і діаграм декомпозиції при необхідності можуть застосовуватися інші види діаграм.

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

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

Презентаційні діаграми (For Exposition Only diagrams – FEO-diagrams). Здебільшого будуються для відображення моделі з інших точок зору, більш детального розгляду важливої частини складної діаграми, або для розгляду варіантів моделі чи проблемної області та їх аналізу без змін основної моделі. Презентаційні діаграми припускають порушення правил побудови IDEF0-діаграм з метою відзначення важливих з точки зору аналітика частин моделі.

Рис. Діаграма дерева вузлів.

Існують наступні види презентаційних діаграм:

− копія IDEF0-діаграми, яка містить усі функціональні блоки і стрілки, які стосуються тільки одного з функціональних блоків (відображення взаємодії між цим блоком та іншими об’єктами діаграми);

− копія IDEF0-діаграми, яка містить усі функціональні блоки і стрілки, які стосуються тільки входу та/або виходу батьківського блоку;

− різні точки зору, як правило, на глибину одного рівня декомпозиції та ін.

1.3 Порядок виконання роботи

В процесі виконання роботи необхідно:

- обрати об'єкт автоматизації і предметну область;

- визначити інформаційні і матеріальні потоки, які перетворюються при виконанні бізнес-процесу;

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

- визначити механізми;

- визначити інформаційні і матеріальні потоки, які утворюються при виконанні бізнес-процесу;

- побудувати контекстну діаграму та діаграму першого рівня декомпозиції;

- побудувати діаграму дерева вузлів;

- продемонструвати викладачеві результати виконання роботи.

- виправити виявлені викладачем зауваження;

- скласти звіт про виконання лабораторної роботи.

Зміст звіту

Звіт про виконання лабораторної роботи повинен містити:

- назву лабораторної роботи;

- мету лабораторної роботи;

- контекстну діаграму та діаграму першого рівня декомпозиції;

- діаграму дерева вузлів;

- висновки щодо виконаної роботи.

Контрольні запитання

1. Сформулюйте визначення методології IDEF0.

2. Назвіть основні задачі, які можна розв’язати за домом гою методології IDEF0.

3. Назвіть базові принципи моделювання процесів, що були реалізовані у IDEF0.

4. Назвіть чотири типи обертів, які застосовуються для опису входів і виходів у стандарті IDEF0.

5. Назвіть, що саме дозволяє моделювати нотація IDEF0.

6. Що саме представляє собою функціональний блок?

7. Що представляє собою принцип функціональної декомпозиції?

8. Що представляє собою принцип контексту?

9. Що представляє собою принцип обмеження складності?

ЛАБОРАТОРНА РОБОТА 2.

Розробка моделей інформаційних потоків системи (діаграм потоків даних)

Мета роботи

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

Методичні вказівки з організації самостійної роботи студентів

2.2.1 Базові принципи моделювання

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

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

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

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

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

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

Процесові надається номер для його ідентифікації. Найменування процесу позначається реченням з дієсловом у невизначеній формі (обчислити, розрахувати, отримати, визначити, створити та ін.) та іменником, наприклад: "Надрукувати адресу отримувача". На відміну від IDEF0-діаграм у DFD-діаграмах не використовують стрілки управління та механізмів.

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

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

У DFD-діаграмах використовують наступні типи об’єктів:

1. Функціональний блок або робота (activity) синонім функціонального блоку IDEF0-моделі.

2. Зовнішня сутність (external entity) – об'єкти-джерела/отримувачі інформації/даних, які змінюються/використовуються у даному бізнес-процесі.

3. Стрілки (data flow) – позначення потоків інформації/даних.

4. Накопичувачі даних (data store) – будь-які механізми або абстракції, у яких зберігаються дані.

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

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

2.2.2 Побудова ієрархії DFD-діаграм

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

Рис. 2.1 Контекстна діаграма потоків даних задачі "Облік відвідувачів спорткомплексу".

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

- наявність великої кількості зовнішніх сутностей (десять або більше);

- розподілена природа системи;

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

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

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

Рис. 2.2 Діаграма потоків даних задачі "Облік відвідувачів спорткомплексу".

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

Після побудови контекстних діаграм отриману модель потрібно перевірити на повноту вихідних даних про об’єкти системи та ізольованість об’єктів (відсутність інформаційних зв’язків з іншими об'єктами).

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

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

- правило нумерації – означає, що при деталізації процесів повинна підтримуватися їх ієрархічна нумерація. Наприклад, процеси, які деталізують процес з номером 12, отримають номери 12.1, 12.2,12.3 т. ін.;

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

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

- наявність у процесу відносно невеликої кількості вхідних і вихідних потоків даних (2-3 потоки);

- процес можливо описати у вигляді алгоритму;

- процес виконує єдину логічну функцію перетворення вхідної інформації у вихідну;

- логіку процесу можливо описати у вигляді мініспецифікації невеликого об’єму (не 20-30 рядків).

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

Після побудови DFD-моделі її потрібно перевірити на повноту та узгодженість:

1. Модель можна вважати повною, якщо всі об’єкти (підсистеми, процеси, потоки даних) описані і деталізовані.

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

2.3 Порядок виконання роботи

В процесі виконання роботи необхідно:

- обрати об'єкт автоматизації і предметну область;

- визначити зовнішні сутності, сховища даних, процеси або роботи, потоки даних;

- побудувати модель інформаційних потоків системи (два або три рівні декомпозиції – залежно від предметної області);

- продемонструвати викладачеві результати виконання роботи.

- виправити виявлені викладачем зауваження;

- скласти звіт про виконання лабораторної роботи.

Зміст звіту

Звіт про виконання лабораторної роботи повинен містити:

- назву лабораторної роботи;

- мету лабораторної роботи;

- контекстну діаграму та діаграми декомпозиції;

- перелік сховищ даних та опис їх структури;

- висновки щодо виконаної роботи.

Контрольні запитання

1. Сформулюйте визначення моделі інформаційних потоків системи (діаграми потоків даних).

2. Що є основним компонентом діаграми потоків даних?

3. Що являють собою процес або робота на діаграмі потоків даних?

4. Вкажіть основні компоненти діаграми потоків даних.

5. Опишіть зміст контекстної діаграми верхнього рівня.

6. Назвіть відмінності між діаграмами потоків даних та IDEF0.

ЛАБОРАТОРНА РОБОТА 3.

Побудова моделі вимог із застосуванням діаграми видів діяльності

Мета роботи

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

Дата добавления: 2018-02-15; просмотров: 300; Мы поможем в написании вашей работы!

Поделиться с друзьями:

12 Следующая ⇒

Мы поможем в написании ваших работ!