80512

Автоматизація процесів оцінювання вартості підприємства

Лекция

Информатика, кибернетика и программирование

Для побудови зазначених типів моделей використовуються як власні методи моделювання RIS так і різні відомі методи та мови моделювання зокрема UML. Автори методу EricssonPenker створили свій профіль UML для моделювання бізнеспроцесів EricssonPenker Business Extensions ввівши набір стереотипів які описують основні категорії бізнесмоделі: процеси ресурси правила і цілі діяльності підприємства. Мова UML використовується також в методі який є частиною технології Rtionl Unified Process фірми IBM.

Украинкский

2015-02-17

157.79 KB

2 чел.

Лекція 16. Автоматизація процесів оцінювання вартості підприємства

План

1. Методи моделювання бізнес-процесів

2. Етапи розвитку UML

3. Поняття діаграми, нотації та мета моделі

1. Методи моделювання бізнес-процесів

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

  1.  метод функціонального моделювання SADT (IDEF0);
  2.  метод моделювання процесів IDEF3;
  3.  моделювання потоків даних DFD;
  4.  метод ARIS;
  5.  метод Ericsson-Penker;
  6.  метод технології Rational Unified Process.

Метод SADT (Structured Analysis and Design Technique) вважається класичним методом підходу до управління на основі процесів, базовим принципом якого є структуризація діяльності організації у відповідності з її бізнес-процесами. Бізнес-модель відповідає таким вимогам:

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

Метод використовується для моделювання штучних систем середньої складності.

Метод моделювання IDEF3 - частина сімейства стандартів IDEF; використовується для моделювання послідовності виконання дій і їх взаємозалежностей в рамках процесу. Метод отримав визнання серед системних аналітиків як доповнення до методу функціонального моделювання IDEF0.

Основою моделі IDEF3 служить сценарій процесу, який відокремлює послідовність дій і підпроцесів системи. Як і в методі IDEF0, основною одиницею моделі є діаграма. Іншим важливим компонентом є дія або "одиниця роботи" (Unit of Work), взаємодія яких зображається за допомогою зв' язків.

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

 Відповідно до методу, модель системи визначається як ієрархія діаграм потоків даних, основними компонентами яких є:

  1.  зовнішні об' єкти;
  2.  системи та підсистеми;
  3.  процеси;
  4.  накопичувачі даних;
  5.  потоки даних.

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

 Метод ARIS (Architecture of Integrated Information System), представляє собою комплекс засобів аналізу і моделювання діяльності підприємства. Його методичну основу складає сукупність різноманітних методів моделювання, що відображають різні погляди на системи. ARIS підтримує чотири типи моделей, які віддзеркалюють різні аспекти системи, що досліджується:

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

Для побудови зазначених типів моделей використовуються як власні методи моделювання ARIS, так і різні відомі методи та мови моделювання, зокрема UML.

Автори методу Ericsson-Penker створили свій профіль UML для моделювання бізнес-процесів - Ericsson-Penker Business Extensions, ввівши набір стереотипів, які описують основні категорії бізнес-моделі: процеси, ресурси, правила і цілі діяльності підприємства.

 Мова UML використовується також в методі, який є частиною технології Rational Unified Process (фірми IBM). Цей метод спрямовано насамперед на створення основи для формування вимог до ПЗ. Передбачає побудову двох базових моделей:

  1.  моделі бізнес-процесів (Business Use Case Model);
  2.  моделі бізнес-аналізу (Business Analysis Model).

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

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

2. Етапи розвитку UML

Уніфікована мова моделювання (UML - Unified Modeling Language) з'явилась внаслідок розвитку методів об'єктно-орієнтованого аналізу і проектування (OOA&D), що виникли наприкінці 80-х років. Мова UML поєднує в собі методи Граді Буча (Booch чи Booch'91), Джима Рамбо (Object Modeling Technique - OMT) і Айвара Джекобсона (Object-Oriented Software Engineering - OOSE), проте володіє розширеними можливостями. Мова моделювання пройшла процес стандартизації в рамках консорціуму OMG (Object Management Group) і на сьогоднішній день представляє собою фактичний стандарт OMG.

UML - це назва мови моделювання, але не методу, оскільки більшість методів містять щонайменше мову моделювання та процес. Мова моделювання - це нотація (як правило, графічна), яка використовується методами для опису проектів; процес - це рекомендація щодо етапів, які необхідно виконати при розробці проекту. Таким чином, мова моделювання є найважливішою частиною методу. Якщо проект обговорюється розробниками, всі вони повинні розуміти саме мову моделювання, а не процес, що використовується при розробці проекту. Розробниками мови UML було також створено і RUP (Rational Unified Process) - раціональний уніфікований процес. Причому, при застосуванні мови UML не висувається вимога одночасного використання RUP, оскільки вони є абсолютно незалежними. Процес RUP може використовуватись для розробки проекту в залежності від типу останнього та вимог замовника.

Розглянемо етапи розвитку галузі розробок програмного забезпечення для ілюстрації процесу становлення мови UML. Поняття об'єкту набуло практичного значення у проектуванні в 70-х - 80-х роках і стало основою методів об'єктно-орієнтованих розробок. В період з 1988 по 1992 роки з'явились наступні праці, присвячені методам об'єктно-орієнтованого аналізу і проектування:

o роботи Саллі Шлеєр (Sally Shlaer) та Стіва Меллора (Steve Mellor), що пізніше були втілені у рекурсивному проектуванні (Recursive Design);

o Пітер Коуд (Peter Coad) та Ед Йордон (Ed Yourdon) розробили неформальний та орієнтований на прототипи метод Коуда;

o Граді Буч (Grady Booch) з компанії Rational Software написав фундаментальну роботу по розробці систем на мові Ada;

o Джим Рамбо (James Rumbaugh) очолив групу у дослідній лабораторії General Electric і розробив популярний метод Object Modeling Technique - OMT;

o Айвар Джекобсон (Ivar Jacobson) виклав свій досвід роботи з телефонними системами фірми Ericsson і вперше ввів поняття варіанту використання (Use Case).

До 1995 року серед методів аналізу і проектування спостерігалось різноманіття підходів та жорстка конкуренція. На той час кожний з авторів методів (про яких згадувалось вище), був лідером групи розробників-практиків, що підтримували їх ідеї. У період 1989-1994 р. загальне число найбільш відомих мов моделювання зросло з десяти до більш ніж п'ятдесят. Багато користувачів відчували істотні труднощі при виборі мови моделювання, оскільки жодна з них не задовольняла всім вимогам, що висуваються до побудови моделей складних систем. Прийняття окремих методик і графічних нотацій як стандартів (IDEF0, IDEF1X) не змогло змінити сформовану ситуацію непримиренної конкуренції між ними на початку 90-х років, що одержала назву "війни методів".

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

Проте, у відповідь на пропозицію звести всі методи до єдиного стандарту, компанія OMG отримала відкритий лист із протестом від всіх авторів основних методологій. Тоді Джим Рамбо залишив General Electric і приєднався до Буча в Rational Software з наміром об'єднати їх методи та досягти стандартизації за прикладом компанії Microsoft. Всі, хто не погодився з таким рішенням, сформували анти-Бучівську коаліцію. На конференції OOPSLA'95 Буч та Рамбо представили перший опис об'єднаного методу у формі документації під робочою назвою "Unified Method 0.8". В цей самий час фірма Rational Software здійснила придбання компанії Objectory і до розробників уніфікованого методу приєднався Джекобсон. Розробка нового методу - вже під назвою UML - тривала до 1997 року, причому з відкритим несхваленням зі сторони голови OMG.

Тоді ж деякі компанії та організації побачили в мові UML стратегічний інтерес для свого бізнесу. Компанія Rational Software разом з декількома організаціями, що виявили бажання виділити ресурси для розробки строгого визначення версії 1.0 мови UML, заснувала консорціум партнерів UML, у який спочатку ввійшли такі фірми, як Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI і Unisys. Ці компанії забезпечили підтримку подальшої роботи з більш точного визначення нотації.

В січні 1997 року ряд організацій представив свої пропозиції по стандартизації методів обміну інформацією між різними моделями. Серед тих пропозицій була і документація на мову UML 1.0. Після внесення декількох істотних доповнень версія 1.1. мови UML була обрана в якості офіційного стандарту OMG.

На даний час усі питання подальшої розробки мови UML сконцентровані в рамках консорціуму OMG. При цьому статус мови UML визначений як відкритий для всіх пропозицій по його доробці та удосконаленню. Сама мова UML не є власністю і не запатентована, хоча зазначений вище документ є захищений законом про авторське право. У той же час абревіатура UML, як і деякі інші (OMG, CORBA, ORB), є торговою маркою їх законних власників.

Наринку CASE-засобів представлені десятки програмних інструментів, що підтримують нотацію мови UML і забезпечують інтеграцію, включаючи пряму і зворотну генерацію коду програм, з найбільш розповсюдженими мовами і середовищами програмування, такими як MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk.

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

3. Поняття діаграми, нотації та мета моделі

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

Діаграма (diagram) - графічне представлення сукупності елементів моделі у формі зв'язного графа, вершинам і ребрам (дугам) якого приписується визначена семантика

Нотація канонічних діаграм є основним засобом розробки моделей мовою UML.

S Нотація - множина символів і правила їх застосування, що використовуються для представлення понять і зв'язків між ними

У нотації мови UML визначені наступні види канонічних діаграм:

o варіантів використання (use case diagram);

o класів (class diagram);

o кооперації (collaboration diagram);

o послідовності (sequence diagram);

o станів (statechart diagram);

o діяльності (activity diagram);

o компонентів (component diagram);

o розгортки (deployment diagram);

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

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

мал. 3.1. Діаграми UML як складові бізнес-моделі

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

Нотація насамперед є синтаксисом мови моделювання. Наприклад, нотація діаграми класів показує, як саме визначаються такі елементи і поняття, як клас, асоціація та кратність (мал. 3.2-3.5).

Мал. 3.2. Асоціація у визначенні нотації діаграми класів

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

 

мал.3.3. Кратність у визначенні нотації діаграми класів.

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

Мал 3.4. Навігація у визначенні нотації UML

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

Мал. 3,5. Поняття залежності у визначенні нотації діаграми класів

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

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


 

А также другие работы, которые могут Вас заинтересовать

51726. Компьютерная грамотность как исходная цель введения курса ОИВТ в школу 33 KB
  План Организационный момент Постановка цели занятия и проверка домашнего задания Создание схемы к теории Подведение итогов занятия и задание на дом Тип занятия: комбинированный. Продолжительность занятия: 1 часа. 2004 Организационный момент приветствие учащихся проверка посещаемости Постановка цели занятия. Проверка домашнего задания желающие выходят к доске и рассказывают конспект несколько человек отвечают письменно Создание схемы Подведение итогов занятия и задание на дом повторить пройденные темы и быть...
51728. Хімія – природнича наука. Хімія в навколишньому світі. Короткі відомості з історії хімії 35 KB
  Хімія – природнича наука. Хімія в навколишньому світі. Чи чули ви слово хімія Що ж таке хімія Для чого вона нам потрібна ІІІ. До них належить і хімія.
51729. Правила техніки безпеки під час роботи в кабінеті хімії. Прийоми роботи з лабораторним посудом і нагрівальними приладами 211 KB
  Правила техніки безпеки під час роботи в кабінеті хімії. Прийоми роботи з лабораторним посудом і нагрівальними приладами. Мета: сформувати початкові навички практичної роботи з хімічними речовинами й лабораторним устаткуванням; перевірити знання техніки безпеки під час виконання практичної роботи в кабінеті хімії; сформувати вміння використовувати лабораторний посуд лабораторний штатив нагрівальний прилад; формувати навички й уміння проведення хімічного експерименту й аналізу явищ що спостерігаються робити висновки в ході практичної...
51730. Поняття про періодичну систему хімічних елементів Д. І. Менделєєва 89.5 KB
  Поняття про періодичну систему хімічних елементів Д. Мета уроку: ознайомити учнів з будовою періодичної системи хімічних елементів Д. Менделєєва; сформувати початкові навички визначення положення хімічного елемента в періодичній системі; продовжити знайомство із символами й назвами елементів за сучасною українською номенклатурою. Обладнання: періодична система хімічних елементів Д.
51731. Сім нот магічного кохання 72 KB
  Дербенева Шановні учні вчителі і гості свята Ми раді Вас вітати Любов це саме велике почуття. Слово любов на всіх мовах світу зрозуміле без перекладу. Почуття любові саме поетичне піднесене чисте прекрасне.
51732. СИЛА КАНОНА 45.5 KB
  придворный скульптор фараона Ментухотепа высек на надгробной плите следующие слова: Я знал тайну божественных слов ведение обряда богослужения Но я был и художником опытным в своём искусстве превосходящим всех своими знаниями Я умел передать движение фигуры мужчины походку женщины положение размахивающего мечом и свернувшуюся позу поражённого Я умел делать инструкции которые не горели от огня и не смывались водой. Рассмотрим знаменитую стелу фараона Нармера созданную на заре египетской художественной культуры на рубеже IVIII тыс....