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 глибоке розуміння метамоделей не є обов'язковим. Вимога вільного оперування метамоделями висувається лише для спеціалістів, що мають високу кваліфікацію в області моделювання.


 

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

41324. Исследование состава и возможностей ИС РПО для семейства МК АVR 3.63 MB
  Основные теоретические положения Программная среда АVR Studio Фирма Аtmel разработчик микроконтроллеров АVR очень хорошо позаботилась о сопровождении своей продукции. Для написания программ их отладки трансляции и прошивки в память микроконтроллера фирма разработала специализированную среду разработчика под названием АVR Studio Программная среда АVR Studio это мощный современный про граммный продукт позволяющий производить все этапы разработки программ для любых микрокон троллеров серии АVR ....
41325. Работа с ИС РПО для семейства МК АVR 5.99 MB
  Если уже есть файл с текстом программы на Ассемблере и просто необходимо создать проект а затем подключить туда готовый программный файл снимите соответствующую галочку. Оно должно содержать имя файла куда будет записываться текст программы. При выборе этого элемента диалог создания проекта будет автоматически запускаться каждый раз при запуске программы VR Studio.ps; файл куда будет помещен текст программы на Ассемблере Prog1.
41326. Лабораторная работа Определение скорости полета пули методом баллистического маятника 461 KB
  Приборы: пули свинцовые 5 штук; пневматическое ружье; баллистический маятник; аналитические весы 0001 г; технические весы 1 г; линейка 1 см; секундомер 01 с. где d – расстояние от зеркальца до шкалы; n –отклонение “зайчика†по шкале; – расстояние от оси вращения до точки удара пули; l – расстояние от оси вращения до центра тяжести; h – высота поднятия цента тяжести;  угол отклонения; масса пули m.
41327. Основные закономерности движения простых колебательных систем. Изучение вынужденных колебаний 123 KB
  Найдем коэффициент возвращающей силы К и модуль Юнга Е. Теперь найдем добротность Q логарифмический декремент затухания  коэффициент затухания  коэффициент трения r частота резонанса Wрез: Итак подытожим результат: Е = 54 109  05 109 с1; К = 58  01 кгс1; W0 = Wрез= 622 с1; Q = 2074;  = 002;  = 02; r = 06.
41328. Измерение ускорения силы тяжести при помощи оборотного маятника Катера и механического секундомера 33.5 KB
  Положение ножа Х см Время с Период с1 67 71 142 84 168 82 915 183 91 183 Примерное значение А  81 см. Проведем измерения при нескольких значениях Х лежащих вблизи А: Положение ножа Х см Период Т1 с1 Период Т2 с1 825 184 183 820 184 181 815 183 181 810 183 180 805 182 179 800 182 179 795 182 179 Установим и измерим расстояние а между подшипниками: а = 8546 – 42 = 8504 мм. Определим центр инерции: а1 = 225 – 88 = 137 см Измерение периода колебаний Т I положение маятника: N1 = 100; t1 = 181 c.; N3...
41329. Измерение токов и напряжений 188.76 KB
  Цель работы: сравнение две возможные схемы включения амперметра и вольтметра; определение сопротивления амперметра и вольтметра. Приборы: три реостата (30 Ом, 5А; 30 Ом, 5А; 100 Ом, 2А), амперметр (класс точности 0.2; цена деления 0,05 А), вольтметр (точность 0.2; цена деления 1.5 В), выключатель и два переключателя
41330. Измерение токов и напряжений. Дополнение к лабораторной работе 40.5 KB
  Гадуировка шкалы – до 100 В; установка – до 150 В, относительно всей шкалы. Тогда одно деление равно 150/100 = 1,5 В. Vотсч = 0,5 * 1,5 = 0,75 В
41331. Определение отношения e/m при помощи фокусировки электронного пучка в продольном магнитном поле 219 KB
  Приборы: потенциометр 100 Ом 2А вольтметр градуировка 600 В вся шкала 1200 В класс точности 10 амперметр градуировка 150 А вся шкала 3 А класс точности 05. а Ищем Vград Класс точности = 10; Vград Vномин = 001; Vград = 1200 001 = 12 В Vград = 12 В б Ищем Vотсч Градуировка шкалы – до 600 В; установка – до 1200 В относительно всей шкалы. Общая формула: а Ищем Iград Класс точности = 05; Iград Iномин = 0005; Iград = 3 0005 = 0015 А Iград = 0015 А б Ищем Iотсч Градуировка шкалы – до 150 А; установка – до 3...
41332. Определение моментов инерции тела 329.5 KB
  Отчет по работе № 90 “Определение моментов инерции тела” студента 12 группы I курса Василькова Сергея Дмитриевича. Приборы: штангенциркуль (0,05 мм); весы (гиревые) (1 г); секундомер (0,1 с). Изучаемый прибор...