МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
МІНІСТЕРСТВО ОСВІТИ
Державна освітня установа вищої НАУКИ
Звіт
по курсовій роботі
за курсом: МОДЕЛЮВАННЯ СИСТЕМ
на тему: «Розробка моделі Станції переливання крові,
використовуючи методології проектування IDEF 0, DFD та IDEF 3 »
2007
Мета роботи
Цілями даної курсової роботи були:
· Застосування методів передпроектного обстеження підприємства;
· Аналіз отриманих матеріалів для подальшого моделювання;
· Розробка моделі процесу у стандарті IDEF0;
· Опис документообігу та обробки інформації в стандарті DFD;
· Опису процесів у стандарті IDEF3;
· Розробка змішаної моделі опису процесу на основі стандартів IDEFO, DFD та IDEF3.
Введення
Для правильного координування процесів протікають в модельованої системі управління необхідно створити структуру, тобто упорядкувати процеси. Моделювання роботи інформаційної системи особливо важливо на перших етапах її створення. Так як виправлення допущених на цьому етапі помилок обходиться найдорожче, то і користь на етапі аналізу завдання і розробки логічної моделі її вирішення значна.
Модель - це образ чи прообраз якого-небудь об'єкта або системи об'єктів, використовуваний при певних умовах в якості їх «заступника» або «представника».
Моделювання - це процес, в результаті якого можна виконувати стратегічне планування проекту, аналіз і формалізацію вимог до інформаційної системи, створення системного проекту.
Діяльність, спрямована на те, щоб розібратися у функціонуванні систем, побудувати відповідні моделі і на їх основі висунути деякі припущення з приводу поліпшення роботи деяких ланок, вважається моделюванням.
Існує кілька видів моделювання:
Процесорний моделювання - опис діяльності підприємства у вигляді бізнес-процесів безперервних взаємопов'язаних функцій (наприклад, побудова моделі у вигляді організаційно-функціональної схеми або за методологією IDEF0).
Організаційно-функціональне моделювання - графічне опис бізнесу - процесів безперервних у вигляді послідовності робіт, яка реалізується окремими елементами організаційної структури, з інформаційними, речовими та / або фінансовими потоками між ними.
Інформаційне моделювання - опис інфармаціонной структури об'єктів (сутностей, атрибутів, ключів) з ідентифікацією відносин між ними.
Імітаційне моделювання - моделювання проведення системи в різних аспектах і в різних зовнішніх і внутрішніх умовах з аналізом динамічних характеристик бізнес-процесів і з аналізом розподілів ресурсів (наприклад, з використанням ділових ігор).
У цій роботі для розробки моделі організації навчального процесу використовується два види моделювання:
1. Процесорний моделювання (IDEF0).
2. Організаційно-функціональне моделювання.
Модель «як є» є «знімок» положення справ на підприємстві (оргштатної структура, взаємодії підрозділів, прийняті технології, автоматизовані і неавтоматизовані бізнес-процеси і т.д.) на момент обстеження і дозволяє зрозуміти, що робить і як функціонує дане підприємство з позицій системного аналізу, а також на основі автоматичної верифікації виявити ряд помилок і «вузьких» місць і сформулювати ряд пропозицій щодо поліпшення ситуації.
Модель «як повинно бути» інтегрує перспективні пропозиції керівництва і співробітників підприємства, експертів і системних аналітиків, і дозволяє сформувати бачення нових раціональних технологій роботи підприємства.
Побудовані моделі є не просто реалізацією початкових етапів розробки системи і технічним завданням на наступні етапи. Вони являють собою самостійний відокремлюваний результат, що має велике практичне значення, зокрема:
· Модель «як є» включає в себе існуючі неавтоматизовані технології, що працюють на підприємстві. Формальний аналіз цієї моделі дозволить виявити «вузькі» місця в технологіях і запропонувати рекомендації щодо її поліпшення (незалежно від того, передбачається на даному етапі автоматизація підприємства чи ні).
· Вона дозволяє здійснювати автоматизований та швидке навчання нових працівників конкретному напрямку діяльності підприємства (так як її технологія міститься в моделі) з використанням діаграм.
· З її допомогою можна здійснювати попереднє моделювання нового напрямку діяльності з метою виявлення нових потоків даних, взаємодіючих підсистем і бізнес-процесів.
Основними цілями моделювання при розробці проектів є:
· Представлення діяльності підприємства та прийнятих в ньому технологій у вигляді ієрархії діаграм, забезпечують наочність і повноту їх відображення;
· Формування на підставі аналізу пропозицій з реорганізації організаційно-управлінської структури;
· Упорядкування інформаційних потоків (у тому числі документообігу) усередині підприємства;
· Вироблення рекомендацій з побудови раціональних технологій роботи підрозділів підприємства і його взаємодії із зовнішнім світом;
· Аналіз вимог і проектування специфікацій корпоративних інформаційних систем;
· Рекомендації та пропозиції щодо застосовності і впровадження існуючих систем управління підприємством.
1. Інструментальне середовище ВР win
BPwin має досить простий і інтуїтивно зрозумілий інтерфейс користувача, що дає можливість аналітику створювати складні моделі при мінімальних зусиллях. BPwin підтримує три методології - IDEF0, IDEF3 і DFD, кожна з яких вирішує свої специфічні завдання. У BPwin можлива побудова змішаних моделей, тобто модель може містити одночасно як діаграми IDEF0, так і IDEF3 і DFD. Модель в BPwin розглядається як сукупність робіт, кожна з яких оперує з деяким набором даних. Робота зображується у вигляді прямокутників, дані - у вигляді стрілок.
1.1 Принцип побудови моделі IDEFO
Основу методології IDEFO складає графічний мова опису бізнес-процесів. Модель в нотації IDEFO являє собою сукупність ієрархічно впорядкованих і взаємозалежних діаграм. Кожна діаграма є одиницею опису системи і розташовується на окремому аркуші.
Модель може містити чотири типи діаграм:
· Контекстну діаграму (у кожній моделі може бути тільки одна контекстна діаграма);
· Діаграми декомпозиції;
· Діаграми дерева вузлів;
· Діаграми тільки для експозиції (FEO).
Контекстна діаграма є вершиною деревоподібної структури діаграм і являє собою саме загальний опис системи та її взаємодії з зовнішнім середовищем.
1. Загальні положення
Цей порядок медичного обстеження донора крові та її компонентів визначено під виконанні 14 Закону РФ «Одонорстве крові та її компонентів».
Відповідно до зазначеного закону донором може бути кожен дієздатний громадянин у віці від 18 до 60 років, що пройшов медичне обстеження. Медичне обстеження перед здачею крові і видача довідок про стан його здоров'я здійснюється безкоштовно.
Донорство підрозділяється на наступні види: донорство крові, донорство плазми, у тому числі імунної, донорство клітин крові.
Залежно від періодичності здачі крові та еекомпонентов донори поділяються на такі категорії: активні, мають 3 і більше кроводач на рік, і донори резерву, які мають менше 3 кроводач на рік.
2. організація медичного обстеження донора
Медичне обстеження донора здійснюється у відділенні обліку та комплектування донорських кадрів станції переливання крові лікувально-профілактичних установ.
Медичне обстеження містить у собі загальний для всіх видів донорства і категорій донорів порядок і додаткові до нього вимоги.
2.1 Порядок реєстрації донора
2.1.3 При реєстрації кожному донору видається «Анкета донора», що заповнюється ним самостійно або за допомогою мед реєстратора
2.1.4 Крім реєстрації донорів реєстратура виконує наступні функції:
- Ведення облікової картки донора на підставі відмітки про кількість зданої крові та її компонентів.
- Оформлення довідок підтверджують факт медичного обстеження або медичного обстеження з наступною здачею крові або її компонентів.
- Заповнення «журналу реєстрації заходів проведених при захворюванні донором сифілісом, гепатитом та ін»
2.2 Загальний порядок медичного обстеження
2.2.1 реєстратурою донор направляється в лабораторію для проведення первинного до здачі крові та її компонентів, клініко-лабораторного дослідження крові.
Дане дослідження містить у собі визначення рівня гемоглобіну і круппи крові, резудьтати якого вносяться в медичну документацію, і донор направдяется на прийом до лікарів-трансфузіологів.
2.2.2 лікарів-трансфузіологів здійснюється:
- Обстеження донора, що включає в себе вимірювання ваги, температури тіла, артеріального тиску, визначення ритмічності і частоти пульсу, огляд шкірних покривів идр.
- Визначення показань до донорства, його виду та об'єму взяття крові або її компонентів.
2.3. Дані про стан здоров'я, вид донорства й обсяг узяття крові або її компонентів заносяться у відповідну документацію і донор направляється у відділення забору крові та її компонентів
3. У відділенні забору крові та її компонентів взята додатково кров направляється для проведення дослідження (скринінгу) її складу та біохімічних показників, дослідження крові на наявність сифілісу, антигену гепатиту - В, антитіл до гепатиту С, ВІЛ -1 і ВІЛ - 2 антитіл, визначення резуспрінадлежності .
3.1 Заготівля крові від донорів здійснюється з урахуванням необхідності задоволення потреби лікувально-профілактичних закладів охорони здоров'я в крові, її компонентах про препарати.
Кров від донорів заготовляють в стаціонарних чи виїзних умовах тільки станції переливання крові.
Розстановка персоналу під час роботи повинна сприяти найбільш раціональної організації реєстрації, обстеження і взяття крові у донорів з мінімальними витратами часу. Тривалість перебування донора в пункті заготівлі крові дожна бути максимально скорочена.
Результати каждоголабораторного дослідження записує особа, яка проводила дослідження, в погрупповие листи або в облікову картку донора та журнал лабораторії. Ці документи надходять до співробітника, відповідального за паспортизацію крові.
Паспортизація крові здійснюється після повного її апробування. спеціально виділений працівник, відповідальний за паспортизацію, який звіряє правильність результатів усіх досліджень і вирішує питання про придатність крові длоя переливання.
Остаточно марковані контейнери з кров'ю передають в експедицію для видачі в лікувально-профілактичні установи.
2. Розробка моделі
2.1 Принцип побудови моделі IDEFO
Основу методології IDEFO складає графічний мова опису бізнес-процесів. Модель в нотації IDEFO являє собою сукупність ієрархічно впорядкованих і взаємозалежних діаграм. Кожна діаграма є одиницею опису системи і розташовується на окремому аркуші.
IDEFO-модель припускає наявність чітко сформульованої мети єдиного суб'єкта моделювання та однієї точки зору.
Модель може містити чотири типи діаграм:
· Контекстну діаграму (у кожній моделі може бути тільки одна контекстна діаграма);
· Діаграми декомпозиції;
· Діаграми дерева вузлів;
· Діаграми тільки для експозиції (FEO).
Контекстна діаграма є вершиною деревоподібної структури діаграм і являє собою саме загальний опис системи та її взаємодії з зовнішнім середовищем.
Цей процес називається функціональної декомпозицією, а діаграми, які описують кожен фрагмент і взаємодія фрагментів, називаються діаграмами декомпозиції.
В основі нотації і методології IDEF0 лежить поняття «блоку», тобто прямокутника, який виражає деяку функцію бізнесу. Як відомо, прямокутник має чотири сторони. В IDEF0 ролі (функціональні значення) всіх сторін різні:
· Верхня сторона має значення «управління»;
· Ліва - "входу";
· Права - «виходу»;
· Нижня - «механізму».
Другим елементом методології і нотації є «потік» (у стандарті званий - «інтерфейсна дуга») - елемент, що описує дані, неформальне управління, або що-небудь інше «надає вплив» на функцію, зображену блоком. У залежності від того, до якої сторони блоку спрямований потік, він, відповідно, носить назву «вхідний», «вихідний», «керівник».
Образотворчим елементом, що представляють «потік», є стрілка.
Управління - це що управляє діяльністю бюро, в даній розробляється моделі - це медичні інструкції.
Стрілки «входу» вносять функції вхідних даних, в контекстній діаграмі - це донор.
Стрілки «виходу» - вихідні дані. У контекстній діаграмі - це готові компоненти крові.
Стрілка «механізму» - це впливають на процеси дані. У діаграмі - це персонал та обладнання.
Після декомпозиції контекстної діаграми проводиться декомпозиція кожного великого фрагмента системи на більш дрібні, при цьому кожному фрагменту задається ім'я і так далі, до досягнення потрібного рівня подробиці опису.
Після кожного сеансу декомпозиції проводяться сеанси експертизи - експерти предметної області вказують на відповідність реальних бізнес-процесів створеним діаграм.
Знайдені невідповідності виправляються, і тільки після проходження експертизи без зауважень можна приступати до наступного сеансу декомпозиції. Так досягається відповідність.
Всі перехрестя на діаграмі нумеруються, кожен номер має префікс J. Можна редагувати властивості перехрестя за допомогою діалогу Definition Editor.
2.2 Принцип побудови моделі DFD
Діаграми потоків даних (DFD) є основним засобом моделювання функціональних вимог проектованої системи. З їх допомогою ці вимоги розбиваються на функціональні компоненти (процеси) і представляються у вигляді мережі, пов'язаної потоками даних. Головна мета таких засобів - продемонструвати, як кожен процес перетворює вхідні дані у вихідні, а також виявити відносини між цими процесами.
Для зображення DFD традиційно використовуються дві різні нотації: йоду (Yourdon) і Гейна-Сарсона (Gane-Sarson). Далі при побудові прикладів буде використовуватися нотація йоду, всі винятки будуть попередньо обговорюватися.
В основі даної методології (методології Gane / Sarson) лежить побудова моделі аналізованої ІС - проектованої чи реальною. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних (ДПД або DFD), що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС з зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція триває, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий такий рівень декомпозиції, на якому процес стають елементарними і деталізувати їх далі неможливо.
МІНІСТЕРСТВО ОСВІТИ
Державна освітня установа вищої НАУКИ
Звіт
по курсовій роботі
за курсом: МОДЕЛЮВАННЯ СИСТЕМ
на тему: «Розробка моделі Станції переливання крові,
використовуючи методології проектування IDEF 0, DFD та IDEF 3 »
2007
Мета роботи
Цілями даної курсової роботи були:
· Застосування методів передпроектного обстеження підприємства;
· Аналіз отриманих матеріалів для подальшого моделювання;
· Розробка моделі процесу у стандарті IDEF0;
· Опис документообігу та обробки інформації в стандарті DFD;
· Опису процесів у стандарті IDEF3;
· Розробка змішаної моделі опису процесу на основі стандартів IDEFO, DFD та IDEF3.
Введення
Для правильного координування процесів протікають в модельованої системі управління необхідно створити структуру, тобто упорядкувати процеси. Моделювання роботи інформаційної системи особливо важливо на перших етапах її створення. Так як виправлення допущених на цьому етапі помилок обходиться найдорожче, то і користь на етапі аналізу завдання і розробки логічної моделі її вирішення значна.
Модель - це образ чи прообраз якого-небудь об'єкта або системи об'єктів, використовуваний при певних умовах в якості їх «заступника» або «представника».
Моделювання - це процес, в результаті якого можна виконувати стратегічне планування проекту, аналіз і формалізацію вимог до інформаційної системи, створення системного проекту.
Діяльність, спрямована на те, щоб розібратися у функціонуванні систем, побудувати відповідні моделі і на їх основі висунути деякі припущення з приводу поліпшення роботи деяких ланок, вважається моделюванням.
Існує кілька видів моделювання:
Процесорний моделювання - опис діяльності підприємства у вигляді бізнес-процесів безперервних взаємопов'язаних функцій (наприклад, побудова моделі у вигляді організаційно-функціональної схеми або за методологією IDEF0).
Організаційно-функціональне моделювання - графічне опис бізнесу - процесів безперервних у вигляді послідовності робіт, яка реалізується окремими елементами організаційної структури, з інформаційними, речовими та / або фінансовими потоками між ними.
Інформаційне моделювання - опис інфармаціонной структури об'єктів (сутностей, атрибутів, ключів) з ідентифікацією відносин між ними.
Імітаційне моделювання - моделювання проведення системи в різних аспектах і в різних зовнішніх і внутрішніх умовах з аналізом динамічних характеристик бізнес-процесів і з аналізом розподілів ресурсів (наприклад, з використанням ділових ігор).
У цій роботі для розробки моделі організації навчального процесу використовується два види моделювання:
1. Процесорний моделювання (IDEF0).
2. Організаційно-функціональне моделювання.
Модель «як є» є «знімок» положення справ на підприємстві (оргштатної структура, взаємодії підрозділів, прийняті технології, автоматизовані і неавтоматизовані бізнес-процеси і т.д.) на момент обстеження і дозволяє зрозуміти, що робить і як функціонує дане підприємство з позицій системного аналізу, а також на основі автоматичної верифікації виявити ряд помилок і «вузьких» місць і сформулювати ряд пропозицій щодо поліпшення ситуації.
Модель «як повинно бути» інтегрує перспективні пропозиції керівництва і співробітників підприємства, експертів і системних аналітиків, і дозволяє сформувати бачення нових раціональних технологій роботи підприємства.
Побудовані моделі є не просто реалізацією початкових етапів розробки системи і технічним завданням на наступні етапи. Вони являють собою самостійний відокремлюваний результат, що має велике практичне значення, зокрема:
· Модель «як є» включає в себе існуючі неавтоматизовані технології, що працюють на підприємстві. Формальний аналіз цієї моделі дозволить виявити «вузькі» місця в технологіях і запропонувати рекомендації щодо її поліпшення (незалежно від того, передбачається на даному етапі автоматизація підприємства чи ні).
· Вона дозволяє здійснювати автоматизований та швидке навчання нових працівників конкретному напрямку діяльності підприємства (так як її технологія міститься в моделі) з використанням діаграм.
· З її допомогою можна здійснювати попереднє моделювання нового напрямку діяльності з метою виявлення нових потоків даних, взаємодіючих підсистем і бізнес-процесів.
Основними цілями моделювання при розробці проектів є:
· Представлення діяльності підприємства та прийнятих в ньому технологій у вигляді ієрархії діаграм, забезпечують наочність і повноту їх відображення;
· Формування на підставі аналізу пропозицій з реорганізації організаційно-управлінської структури;
· Упорядкування інформаційних потоків (у тому числі документообігу) усередині підприємства;
· Вироблення рекомендацій з побудови раціональних технологій роботи підрозділів підприємства і його взаємодії із зовнішнім світом;
· Аналіз вимог і проектування специфікацій корпоративних інформаційних систем;
· Рекомендації та пропозиції щодо застосовності і впровадження існуючих систем управління підприємством.
1. Інструментальне середовище ВР win
BPwin має досить простий і інтуїтивно зрозумілий інтерфейс користувача, що дає можливість аналітику створювати складні моделі при мінімальних зусиллях. BPwin підтримує три методології - IDEF0, IDEF3 і DFD, кожна з яких вирішує свої специфічні завдання. У BPwin можлива побудова змішаних моделей, тобто модель може містити одночасно як діаграми IDEF0, так і IDEF3 і DFD. Модель в BPwin розглядається як сукупність робіт, кожна з яких оперує з деяким набором даних. Робота зображується у вигляді прямокутників, дані - у вигляді стрілок.
1.1 Принцип побудови моделі IDEFO
Основу методології IDEFO складає графічний мова опису бізнес-процесів. Модель в нотації IDEFO являє собою сукупність ієрархічно впорядкованих і взаємозалежних діаграм. Кожна діаграма є одиницею опису системи і розташовується на окремому аркуші.
Модель може містити чотири типи діаграм:
· Контекстну діаграму (у кожній моделі може бути тільки одна контекстна діаграма);
· Діаграми декомпозиції;
· Діаграми дерева вузлів;
· Діаграми тільки для експозиції (FEO).
Контекстна діаграма є вершиною деревоподібної структури діаграм і являє собою саме загальний опис системи та її взаємодії з зовнішнім середовищем.
2. Аналіз предметної області
Порядок медичного обстеження донора крові та її компонентів1. Загальні положення
Цей порядок медичного обстеження донора крові та її компонентів визначено під виконанні 14 Закону РФ «Одонорстве крові та її компонентів».
Відповідно до зазначеного закону донором може бути кожен дієздатний громадянин у віці від 18 до 60 років, що пройшов медичне обстеження. Медичне обстеження перед здачею крові і видача довідок про стан його здоров'я здійснюється безкоштовно.
Донорство підрозділяється на наступні види: донорство крові, донорство плазми, у тому числі імунної, донорство клітин крові.
Залежно від періодичності здачі крові та еекомпонентов донори поділяються на такі категорії: активні, мають 3 і більше кроводач на рік, і донори резерву, які мають менше 3 кроводач на рік.
2. організація медичного обстеження донора
Медичне обстеження донора здійснюється у відділенні обліку та комплектування донорських кадрів станції переливання крові лікувально-профілактичних установ.
Медичне обстеження містить у собі загальний для всіх видів донорства і категорій донорів порядок і додаткові до нього вимоги.
2.1 Порядок реєстрації донора
2.1.1 Реєстрація донора як при первинному, так і при повторному зверненні, здійснюється реєстратурою відділення обліку та комплектування донорських кадрів лише за пред'явленням документа, що посвідчує його особу.
2.1.2 Ппрі зверненні донора резерву оформляється «Карта донора резерву» і «Облікова картка донора» з внесенням до них паспортних даних відповідно з пред'явленими документами.2.1.3 При реєстрації кожному донору видається «Анкета донора», що заповнюється ним самостійно або за допомогою мед реєстратора
2.1.4 Крім реєстрації донорів реєстратура виконує наступні функції:
- Ведення облікової картки донора на підставі відмітки про кількість зданої крові та її компонентів.
- Оформлення довідок підтверджують факт медичного обстеження або медичного обстеження з наступною здачею крові або її компонентів.
- Заповнення «журналу реєстрації заходів проведених при захворюванні донором сифілісом, гепатитом та ін»
2.2 Загальний порядок медичного обстеження
2.2.1 реєстратурою донор направляється в лабораторію для проведення первинного до здачі крові та її компонентів, клініко-лабораторного дослідження крові.
Дане дослідження містить у собі визначення рівня гемоглобіну і круппи крові, резудьтати якого вносяться в медичну документацію, і донор направдяется на прийом до лікарів-трансфузіологів.
2.2.2 лікарів-трансфузіологів здійснюється:
- Обстеження донора, що включає в себе вимірювання ваги, температури тіла, артеріального тиску, визначення ритмічності і частоти пульсу, огляд шкірних покривів идр.
- Визначення показань до донорства, його виду та об'єму взяття крові або її компонентів.
2.3. Дані про стан здоров'я, вид донорства й обсяг узяття крові або її компонентів заносяться у відповідну документацію і донор направляється у відділення забору крові та її компонентів
3. У відділенні забору крові та її компонентів взята додатково кров направляється для проведення дослідження (скринінгу) її складу та біохімічних показників, дослідження крові на наявність сифілісу, антигену гепатиту - В, антитіл до гепатиту С, ВІЛ -1 і ВІЛ - 2 антитіл, визначення резуспрінадлежності .
3.1 Заготівля крові від донорів здійснюється з урахуванням необхідності задоволення потреби лікувально-профілактичних закладів охорони здоров'я в крові, її компонентах про препарати.
Кров від донорів заготовляють в стаціонарних чи виїзних умовах тільки станції переливання крові.
Розстановка персоналу під час роботи повинна сприяти найбільш раціональної організації реєстрації, обстеження і взяття крові у донорів з мінімальними витратами часу. Тривалість перебування донора в пункті заготівлі крові дожна бути максимально скорочена.
З метою забезпечення рівномірного потоку донорів в операційну необхідна організація їх надходження на пункт заготівлі крові з урахуванням пропускної здатності операційної, умов роботи підприємств і т.д.
4. відділ контролю якості кровіРезультати каждоголабораторного дослідження записує особа, яка проводила дослідження, в погрупповие листи або в облікову картку донора та журнал лабораторії. Ці документи надходять до співробітника, відповідального за паспортизацію крові.
Паспортизація крові здійснюється після повного її апробування. спеціально виділений працівник, відповідальний за паспортизацію, який звіряє правильність результатів усіх досліджень і вирішує питання про придатність крові длоя переливання.
Остаточно марковані контейнери з кров'ю передають в експедицію для видачі в лікувально-профілактичні установи.
2. Розробка моделі
2.1 Принцип побудови моделі IDEFO
Основу методології IDEFO складає графічний мова опису бізнес-процесів. Модель в нотації IDEFO являє собою сукупність ієрархічно впорядкованих і взаємозалежних діаграм. Кожна діаграма є одиницею опису системи і розташовується на окремому аркуші.
IDEFO-модель припускає наявність чітко сформульованої мети єдиного суб'єкта моделювання та однієї точки зору.
Модель може містити чотири типи діаграм:
· Контекстну діаграму (у кожній моделі може бути тільки одна контекстна діаграма);
· Діаграми декомпозиції;
· Діаграми дерева вузлів;
· Діаграми тільки для експозиції (FEO).
Контекстна діаграма є вершиною деревоподібної структури діаграм і являє собою саме загальний опис системи та її взаємодії з зовнішнім середовищем.
Цей процес називається функціональної декомпозицією, а діаграми, які описують кожен фрагмент і взаємодія фрагментів, називаються діаграмами декомпозиції.
В основі нотації і методології IDEF0 лежить поняття «блоку», тобто прямокутника, який виражає деяку функцію бізнесу. Як відомо, прямокутник має чотири сторони. В IDEF0 ролі (функціональні значення) всіх сторін різні:
· Верхня сторона має значення «управління»;
· Ліва - "входу";
· Права - «виходу»;
· Нижня - «механізму».
Другим елементом методології і нотації є «потік» (у стандарті званий - «інтерфейсна дуга») - елемент, що описує дані, неформальне управління, або що-небудь інше «надає вплив» на функцію, зображену блоком. У залежності від того, до якої сторони блоку спрямований потік, він, відповідно, носить назву «вхідний», «вихідний», «керівник».
Образотворчим елементом, що представляють «потік», є стрілка.
Управління - це що управляє діяльністю бюро, в даній розробляється моделі - це медичні інструкції.
Стрілки «входу» вносять функції вхідних даних, в контекстній діаграмі - це донор.
Стрілки «виходу» - вихідні дані. У контекстній діаграмі - це готові компоненти крові.
Стрілка «механізму» - це впливають на процеси дані. У діаграмі - це персонал та обладнання.
Після декомпозиції контекстної діаграми проводиться декомпозиція кожного великого фрагмента системи на більш дрібні, при цьому кожному фрагменту задається ім'я і так далі, до досягнення потрібного рівня подробиці опису.
Після кожного сеансу декомпозиції проводяться сеанси експертизи - експерти предметної області вказують на відповідність реальних бізнес-процесів створеним діаграм.
Знайдені невідповідності виправляються, і тільки після проходження експертизи без зауважень можна приступати до наступного сеансу декомпозиції. Так досягається відповідність.
Всі перехрестя на діаграмі нумеруються, кожен номер має префікс J. Можна редагувати властивості перехрестя за допомогою діалогу Definition Editor.
2.2 Принцип побудови моделі DFD
Діаграми потоків даних (DFD) є основним засобом моделювання функціональних вимог проектованої системи. З їх допомогою ці вимоги розбиваються на функціональні компоненти (процеси) і представляються у вигляді мережі, пов'язаної потоками даних. Головна мета таких засобів - продемонструвати, як кожен процес перетворює вхідні дані у вихідні, а також виявити відносини між цими процесами.
Для зображення DFD традиційно використовуються дві різні нотації: йоду (Yourdon) і Гейна-Сарсона (Gane-Sarson). Далі при побудові прикладів буде використовуватися нотація йоду, всі винятки будуть попередньо обговорюватися.
В основі даної методології (методології Gane / Sarson) лежить побудова моделі аналізованої ІС - проектованої чи реальною. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних (ДПД або DFD), що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС з зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція триває, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий такий рівень декомпозиції, на якому процес стають елементарними і деталізувати їх далі неможливо.
Джерела інформації (зовнішні сутності) породжують інформаційні потоки (потоки даних), які переносять інформацію до підсистем або процесів. Ті в свою чергу перетворюють інформацію і породжують нові потоки, які переносять інформацію до інших процесів або підсистем, накопичувачів даних або зовнішнім сутностей - споживачам інформації. Таким чином, основними компонентами діаграм потоків даних є:
Ø зовнішні сутності;
Ø системи / підсистеми;
Ø процеси;
Ø накопичувачі даних;
Ø потоки даних.
2.3 Принцип побудови моделі IDEF 3
IDEF3 може бути також використаний як метод створення процесів. IDEF3 доповнює IDEFO і містить все необхідне для побудови моделей, які в подальшому можуть бути використані для імітаційного аналізу.
Кожна робота в IDEF3 описує будь-який сценарій бізнес-процесу і може бути складовою іншої роботи. Оскільки сценарій описує мету і рамки моделі, важливо, щоб роботи іменувалися віддієслівним іменником, що позначає процес дії, або фразою, що містить таке іменник.
Точка зору на модель повинна бути задокументована. Зазвичай це точка зору людини, відповідального за роботу в цілому. Також необхідно задокументувати мета моделі - ті питання, на які покликана відповісти модель.
Перехрестя (Junction). Закінчення однієї роботи може служити сигналом до початку декількох робіт або ж одна робота для свого запуску може очікувати закінчення декількох робіт. Перехрестя використовуються для відображення логіки взаємодії стрілок при злитті і розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи. Типи перехресть представлені в табл.:
Типи перехресть
Всі перехрестя на діаграмі нумеруються, кожен номер має префікс J. Можна редагувати властивості перехрестя за допомогою діалогу Definition Editor. На відміну від IDEFO і DFD в IDEF3 стрілки можуть зливатися і розгалужуватиметься тільки через перехрестя.
Об'єкт посилання. Об'єкт посилання в IDEF3 висловлює якусь ідею, концепцію чи дані, які не можна пов'язати зі стрілкою, перехрестям або роботою. Для внесення об'єкту посилання служить кнопка | R | - (додати в діаграму об'єкт посилання - Referent) у палітрі інструментів. Об'єкт посилання зображується у вигляді прямокутника, схожого на прямокутник роботи. Назва об'єкту посилання задається в діалозі Referent (пункт спливаючого меню Name Editor), в якості імені можна використовувати ім'я якої-небудь стрілки з інших діаграм або ім'я суті з моделі даних. Об'єкти посилання повинні бути пов'язані з одиницями робіт або перехрестями пунктирними лініями. Офіційна специфікація IDEF3 розрізняє три стилі об'єктів посилань - безумовні (unconditional), синхронні (synchronous) і асинхронні (asynchronous). BPwin підтримує тільки безумовні об'єкти посилань. Синхронні та асинхронні об'єкти посилань, використовувані в діаграмах переходів станів об'єктів, не підтримуються.
Висновок
Наступним етапом розробки є етап проектування. Перед початком проектування та реалізації потрібно мати точне і детальне розуміння вимог на високому рівні. Крім того, дуже корисно мати структуру вимог, яка може бути використана як вихідні дані для формування системи. Все це досягається за допомогою аналізу і моделювання. Виконуючи аналіз і моделювання, ми домоглися поділу завдань, які в попередній проект стані ми готували і спрощували для подальшої діяльності з проектування та реалізації. Розмежовуємо проблеми, які повинні бути вирішені, і рішення, які повинні бути прийняті для того, щоб впоратися з ними.
У результаті роботи на етапах моделювання та проектування ми отримали проект системи, що містить достатньо інформації для реалізації системи.
Після аналізу роботи СПК ми можемо судити про ступінь завантаженості кожної її складової, про те, що необхідно автоматизувати в першу чергу і якими засобами.
З'ясувалося, що на СПК вся інформація передається на паперовому носії. Через нього проходить велика кількість документів, які необхідно опрацювати. Саме тому необхідно впровадження засобів, які дозволять прискорити цей процес. Це прискорить документообіг, що поліпшить роботу даного відділу.
2. Рогозів Ю.І., Стукотій Л.М., Свиридов А.С. Лабораторний практикум з курсу «Моделювання систем», ТРТУ, 2004.
3. Маклаков С.В. CASE-засоби розробки інформаційних систем. BPwin і Erwin - М.: ДіалогМіфі, 2001.
4. Постанова Уряду РФ «Про заходи щодо організаії індивідуального (персоніфікованого) обліку для цілей державного пенсійного страхування».
5. Федеральний закон «Про індивідуальному (персоніфікованому) обліку в системі державного пенсійного страхування».
6. Інструкція про порядок ведення індивідуального (персоніфікованого) обліку відомостей про застрахованих осіб для цілей державного пенсійного страхування.
7. «Про форми документів індивідуального (персоніфікованого) обліку в системі державного пенсійного страхування та інструкції щодо їх заповнення»
8. Положення про порядок ведення індивідуального (персоніфікованого) обліку відомостей про застрахованих осіб для цілей обов'язкового пенсійного страхування.
9. Посадова інструкція на інспектора (з персоніфікованого обліку) відділу кадрів.
10. Посадова інструкція на старшого інспектора (бюро персоніфікованого обліку) відділу кадрів
Ø зовнішні сутності;
Ø системи / підсистеми;
Ø процеси;
Ø накопичувачі даних;
Ø потоки даних.
2.3 Принцип побудови моделі IDEF 3
IDEF3 може бути також використаний як метод створення процесів. IDEF3 доповнює IDEFO і містить все необхідне для побудови моделей, які в подальшому можуть бути використані для імітаційного аналізу.
Кожна робота в IDEF3 описує будь-який сценарій бізнес-процесу і може бути складовою іншої роботи. Оскільки сценарій описує мету і рамки моделі, важливо, щоб роботи іменувалися віддієслівним іменником, що позначає процес дії, або фразою, що містить таке іменник.
Точка зору на модель повинна бути задокументована. Зазвичай це точка зору людини, відповідального за роботу в цілому. Також необхідно задокументувати мета моделі - ті питання, на які покликана відповісти модель.
Перехрестя (Junction). Закінчення однієї роботи може служити сигналом до початку декількох робіт або ж одна робота для свого запуску може очікувати закінчення декількох робіт. Перехрестя використовуються для відображення логіки взаємодії стрілок при злитті і розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи. Типи перехресть представлені в табл.:
Типи перехресть
| Позначення | Найменування | Сенс у разі злиття стрілок (Fan-in Junction) | Сенс у разі розгалуження стрілок (Fan-out Junction) |
| | | & | Asynchronous AND | Всі попередні процеси повинні бути завершені | Всі наступні процеси повинні бути запущені |
| ||&|| | Synchronous AND | Всі попередні процеси завершені одночасно | Всі наступні процеси запускаються одночасно |
| | | O | Asynchronous OR | Один або кілька попередніх процесів повинні бути завершені | Один або кілька таких процесів повинні бути запущені |
| | | O | | | Synchronous OR | Один або кілька попередніх процесів завершені одночасно | Один або кілька таких процесів запускаються одночасно |
| | | X | XOR (Exclusive OR) | Тільки один попередній процес завершено | Тільки один наступний процес запускається |
Об'єкт посилання. Об'єкт посилання в IDEF3 висловлює якусь ідею, концепцію чи дані, які не можна пов'язати зі стрілкою, перехрестям або роботою. Для внесення об'єкту посилання служить кнопка | R | - (додати в діаграму об'єкт посилання - Referent) у палітрі інструментів. Об'єкт посилання зображується у вигляді прямокутника, схожого на прямокутник роботи. Назва об'єкту посилання задається в діалозі Referent (пункт спливаючого меню Name Editor), в якості імені можна використовувати ім'я якої-небудь стрілки з інших діаграм або ім'я суті з моделі даних. Об'єкти посилання повинні бути пов'язані з одиницями робіт або перехрестями пунктирними лініями. Офіційна специфікація IDEF3 розрізняє три стилі об'єктів посилань - безумовні (unconditional), синхронні (synchronous) і асинхронні (asynchronous). BPwin підтримує тільки безумовні об'єкти посилань. Синхронні та асинхронні об'єкти посилань, використовувані в діаграмах переходів станів об'єктів, не підтримуються.
Висновок
Наступним етапом розробки є етап проектування. Перед початком проектування та реалізації потрібно мати точне і детальне розуміння вимог на високому рівні. Крім того, дуже корисно мати структуру вимог, яка може бути використана як вихідні дані для формування системи. Все це досягається за допомогою аналізу і моделювання. Виконуючи аналіз і моделювання, ми домоглися поділу завдань, які в попередній проект стані ми готували і спрощували для подальшої діяльності з проектування та реалізації. Розмежовуємо проблеми, які повинні бути вирішені, і рішення, які повинні бути прийняті для того, щоб впоратися з ними.
У результаті роботи на етапах моделювання та проектування ми отримали проект системи, що містить достатньо інформації для реалізації системи.
Після аналізу роботи СПК ми можемо судити про ступінь завантаженості кожної її складової, про те, що необхідно автоматизувати в першу чергу і якими засобами.
З'ясувалося, що на СПК вся інформація передається на паперовому носії. Через нього проходить велика кількість документів, які необхідно опрацювати. Саме тому необхідно впровадження засобів, які дозволять прискорити цей процес. Це прискорить документообіг, що поліпшить роботу даного відділу.
Література
1. Рогозів Ю.І., Стукотій Л.М., Свиридов А.С. Моделювання систем, ТРТУ, 2004.2. Рогозів Ю.І., Стукотій Л.М., Свиридов А.С. Лабораторний практикум з курсу «Моделювання систем», ТРТУ, 2004.
3. Маклаков С.В. CASE-засоби розробки інформаційних систем. BPwin і Erwin - М.: ДіалогМіфі, 2001.
4. Постанова Уряду РФ «Про заходи щодо організаії індивідуального (персоніфікованого) обліку для цілей державного пенсійного страхування».
5. Федеральний закон «Про індивідуальному (персоніфікованому) обліку в системі державного пенсійного страхування».
6. Інструкція про порядок ведення індивідуального (персоніфікованого) обліку відомостей про застрахованих осіб для цілей державного пенсійного страхування.
7. «Про форми документів індивідуального (персоніфікованого) обліку в системі державного пенсійного страхування та інструкції щодо їх заповнення»
8. Положення про порядок ведення індивідуального (персоніфікованого) обліку відомостей про застрахованих осіб для цілей обов'язкового пенсійного страхування.
9. Посадова інструкція на інспектора (з персоніфікованого обліку) відділу кадрів.
10. Посадова інструкція на старшого інспектора (бюро персоніфікованого обліку) відділу кадрів