МЕТОДОЛОГІЇ ТА СТАНДАРТИ ФУНКЦІОНАЛЬНОГО МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ

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

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

■ SADT - цікава як основоположна методологія, що заклала принципи сучасного моделювання й лягла в основу для розробки стандарту IDEF0;

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

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

Методологія SADT, розроблена Дугласом Россом, є однією з найвідоміших і широко використовуваних систем моделювання. SADT (Structured Analysis and Design Technique - технологія структурного аналізу і проектування) -це графічні позначення і метод опису процесів. SADT може застосовуватися на всіх стадіях життєвого циклу системи. Визнання корисності SADT призвело до стандартизації та публікації її частини, призначеної для функціонального моделювання, як методології і стандарту функціонального моделювання IDEFO.

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

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

SADT-модель дає повний і точний опис системи, що має конкретне призначення. Це призначення, зване метою моделі , випливає з формального визначення моделі в SADT: М є модель системи S, якщо М може бути використана для отримання відповідей на питання щодо S з точністю А.

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

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

З визначенням моделі тісно пов'язана позиція, з якої спостерігається система і створюється її модель. Оскільки якість опису системи різко знижується, якщо воно не сфокусовано ні на чому, SADT вимагає, щоб модель розглядалася весь час з однієї і тієї ж позиції. Ця позиція називається точкою зору даної моделі. Точку зору найкраще уявляти собі як місце людини або об'єкта, в яке треба встати, щоб побачити систему в дії. З цієї фіксованої точки зору можна створити узгоджене опис системи так, щоб в ній не змішувалися незв'язані опису. Очевидно, що функціональні моделі одного і того ж підприємства з точок зору начальника виробництва і головного бухгалтера будуть істотно відрізнятися за спрямованістю їх деталізації. Це пов'язано з тим, що за родом службових обов'язків головного бухгалтера в меншій мірі цікавлять питання обслуговування верстатного парку підприємства, а начальника виробництва мало хвилюють тонкощі обчислення оподатковуваної бази. Точка зору визначає основний напрямок розвитку моделі та рівень необхідної деталізації. Чітке фіксування точки зору дозволяє спростити модель, відмовившись від деталізації і дослідження окремих компонентів, які не є для даної моделі важливими. Правильний вибір точки зору істотно скорочує тимчасові витрати на побудову кінцевої моделі.

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

Мета і точка зору моделі

Мал. 20.3. Мета і точка зору моделі

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

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

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

Малюнки 20.3 і 20.4 ілюструють функціональне моделювання в нотації IDEF0 і його підтримку програмними засобами BPWin. IDEFO-моделі складаються з трьох типів документів: графічних діаграм, тексту і глосарію. Ці документи мають перехресні посилання один на одного. Графічна діаграма - головний компонент IDEFO-моделі, що містить блоки, стрілки, з'єднання блоків і стрілок і асоційовані з ними відносини. Блоки представляють собою основні функції об'єкта, що моделюється. Основні об'єкти нотації IDEF0: роботи (Activity), відображають функції; стрілки (Arrows). Стрілка входу (Input) відображає вхідні документи, матеріальні та інформаційні ресурси, необхідні для виконання роботи. Робота може не мати жодної стрілки входу. Стрілка виходу (Output) відображає вихідні документи, матеріальні та інформаційні ресурси, які є результатом виконання роботи. Стрілка управління (Control) відображає правила, обмеження та інші дії, що управляють. В нотації кожна робота повинна мати не менше однієї стрілки управління. Стрілка механізму (Mechanism) відображає ті ресурси, які необхідні для виконання роботи, але що не піддаються зміні. стрілка

Декомпозиція та подання функцій

Мал. 20.4. Декомпозиція та подання функцій

виклику (Call) - спеціальна стрілка, що відображає звернення з роботи даної моделі до роботи поза модельованої системи, яка забезпечує зв'язок між моделями.

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

Для опису процесу в IDEF3 визначені дві стратегії і відповідно два типи діаграм:

  • 1) process-centered strategy - стратегія опису процесу як послідовності виконуваних дій. Діаграми цього типу отримали назву Process Flow Description Diagrams (PFDD) -діаграмми потокового опису процесу;
  • 2) object-centered strategy - стратегія опису процесу як послідовності змін станів об'єкта, над яким виконуються дії. Діаграми такого типу отримали назву Object State Transition Network (OSTN) - діаграми послідовності змін станів об'єкта.

Опис процесу в IDEF3 може містити діаграми PFDD і OSTN або діаграми будь-якого одного типу.

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

Предметна область діаграми потоків даних (Data Flow Diagramm - DFD) в нотації Йордона - Де Марко будується з елементів (табл. 20.2).

Таблиця 20.2. Типи позначень елементів DFD-діаграми

елемент

опис

функція

Дія, що виконується моделюється системою

потік даних

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

сховище

Структура для зберігання інформаційних об'єктів

зовнішня сутність

Зовнішній по відношенню до системи об'єкт, обмінюються з нею потоками даних

Крім нотації Йордона -де Марко для елементів DFD-діа-грам можуть використовуватися і інші умовні позначення (ОМТ, SSADM, нотація Гейне - Сарсона і т.д.). Всі вони мають практично однакову базову функціональність і розрізняються лише в деталях. Інструментальні засоби проектування (CASE-сис- теми), як правило, підтримують кілька нотацій уявлення DFD-діаграм.

У сучасному комп'ютерному світі намітилася тенденція моделювання складних систем візуальними (наочними) моделями. Найбільш відомими візуальними моделями є діаграми мови UML [3] і стандарту IDEF0, таблиці і діаграми стандарту IDEF1X. Ці візуальні моделі мають математичну основу у вигляді теорій графів, множин і матриць. Документування вихідних кодів програм UML діаграмами і специфікаціями створює єдину мову спілкування між програмістами, системними аналітиками і замовниками автоматизованих систем. Але найголовніше, що дає UML, - це можливість широкої стандартизації мов програмування. Відомо, що в різних мовах програмування використовуються однакові операції і методи, але вони мають різні назви і символьні позначення. Мова UML дозволяє стандартизувати як самі операції і методи мов програмування, так і їх термінологію.

Мова UML має ієрархічну структуру, перший рівень якої складають суті, відносини між сутностями і наочні діаграми. Суті на другому рівні поділяються на види: структурні, поведінкові, группирующие і анотаційні сутності. На третьому рівні до структурних сутностей відносяться класи, інтерфейси, кооперації, прецеденти, активні класи, компоненти, вузли. Поведінкові суті діляться на два види діаграм. Діаграми першого виду називаються взаємодіями , другого виду - автоматами. Групуються суті мають тільки один вид піктограм, які називаються пакетами . Анотаційні сутності також мають один вид піктограм, які називаються примітками. Відносини на другому рівні включають в себе відносини залежностей, асоціацій, узагальнень, реалізацій. Виділяють наступні діаграми другого рівня: класів, об'єктів, прецедентів, послідовностей, кооперацій, станів, дій, компонентів, розгортання. Наприклад, діаграма прецедентів (use case diagram) - графічне представлення всіх або частини діючих осіб (actors - хтось (або щось), зовнішній по відношенню до комп'ютерної системи, хто (або що) взаємодіє з нею). Графічно зображується у вигляді піктограми (рис. 20.5), що представляє людини, прецедентів і взаємодій між ними. Найбільш часто actor - це людина або група людей, що використовують дані, що надаються комп'ютерною системою. Діаграма класів застосовуються для моделювання об'єктно-орієнтованих систем. UML-діаграми класів включають в себе як окремий випадок діаграми "сутність - зв'язок" (Entity-relationship diagrams), які використовуються для логічного проектування реляційних, об'єктно-орієнтованих і гібридних об'єктно-реляційних БД.

Приклад UML-діаграми прецедентів

Мал. 20.5. Приклад UML-діаграми прецедентів

Серед інструментальних програм підтримки мови UML найбільш відомою є пакет Rational Rose.

З 2000 р розвивається методика ВРМ (Business Process Management) - одна з сучасних управлінських методик, що включає в себе сукупність ідеології і програмного забезпечення управління бізнес-процесами. З точки зору управління ВРМ передбачає перехід від функціонального осмислення діяльності організації до її баченню як сукупності бізнес-процесів, які перетинають функціональні межі. Тут на відміну від реінжинірингу орієнтація відбувається на безперервний процес удосконалення бізнес-процесів компанії. Крім того, концепція ВРМ передбачає фокус на взаємодії як між людьми, так і системами та апаратними засобами.

Для моделювання архітектури підприємства в цілому застосовується спеціальний уніфікована мова моделювання UEML (Unified Enterprise Modeling Language).

UEML включає в себе:

■ інструментальні засоби загального, візуального, базованого на шаблонах мови, моделювання підприємств і програмних систем класу workflow;

■ стандартизовані, незалежні від інструментів механізми передачі моделей між проектами;

■ репозитарій моделей підприємств.

Моделювання здійснюється відповідно до міжнародних стандартів: ISO 14258 Rules and Guidelines for Enterprise Models (Правила та керівні принципи для моделей підприємства); ISO 15704 Requirements for enterprise-reference architectures and methodologies (Вимоги та методології по опису архітектури підприємства).

Інструментальними засобами моделювання підприємств, що підтримують мову UEML, є: Metis (Compu- tas), e-MAGIM (GraiSoft), MOzGO (IPK) і ін.

 
< Попер   ЗМІСТ   Наст >