2012_Посібник_з_дисципліни_ТКП. Кафедра автоматизованих систем обробки інформації І управління посібник з дисципліни
 Скачать 3.1 Mb.
|
|
Рисунок 3.11 –Графічне представлення одиниці роботи Зв’язки та перехрестя. Зв'язки - показують взаємини робіт. Старша (Precedence) суцільна лінія, що зв'язує одиниці робіт (UOW). Рисунок 3.12 - Приклад використання Precedence 61 Відносини (Relational Link) пунктирна лінія, що використовується для зображення зв'язків між одиницями робіт (UOW), а також між одиницями робіт і об'єктами посилань. Робота-мета може закінчитися раніше, ніж закінчиться робота-джерело. Рисунок 3.13 - Приклад використання Relation Link Потоки об'єктів (Object Flow) стрілка з двома наконечниками, застосовується для опису того факту, що об'єкт використовується у двох або більше одиницях роботи, наприклад, коли об'єкт породжується в одній роботі і використовується в інший; Рисунок 3.144- Приклад використання Object Flow 62 Перехрестя Перехрестя використовуються для відображення логіки взаємодії стрілок при злитті та розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи; Перехрестя для злиття стрілок (Fan-in Junction) Перехрестя для розгалуження стрілок (Fan-out Junction) Таблиця 3.1 - Типи перехресть Позначення Найменування Сенс у разі злиття стрілок (Fan-in Junction) Сенс у випадку розгалуження стрілок (Fan-out Junction) Asynchronous AND Всі попередні процеси мають бути завершені Всі наступні процеси мають бути запущені Synchronous AND Всі попередні процеси завершені одночасно Всі наступні процеси запускаються одночасно Asynchronous OR Один або декілька попередніх процесів мають бути завершені Один або декілька наступних процесів мають бути запущені Synchronous OR Один або декілька попередніх процесів завершені одночасно Один або декілька наступних процесів запускаються одночасно XOR (Exclusive OR) Тільки один попередній процес завершено Тільки один наступний процес запускається На відміну від IDEF0 і DFD в IDEF3 стрілки можуть зливатися і розгалужуватися тільки через перехрестя. Рисунок 3.15 - Приклад використання перехресть типу AND 63 Рисунок 3.16 - Приклад використання перехресть типу ХОР Об'єкти вказівники Вказівники - це спеціальні символи, які посилаються на інші розділи опису процесу. Вони використовуються при побудові діаграми для залучення уваги користувача до будь-яких важливих аспектів моделі. Рисунок 3.17 - Приклад об’єктів вказівників Таблиця 3.2- Типи вказівників Тип вказівника Призначення ОБ'ЄКТ (OBJECT) Для опису того, що в дії бере участь об'єкт, який заслуговує окремої уваги ПОСИЛАННЯ (GOTO) Для реалізації циклічності виконання дій. Покажчик ПОСИЛАННЯ може відноситися і до з'єднання ОДИНИЦЯ ДІЇ (Unit of Behavior - UOB) Для розташування на діаграмі додаткового примірника вже існуючої дії без зациклення. Наприклад, якщо дія "Підрахунок готівки" виконується кілька разів, в перший раз вона створюється як дія, а наступні її появи на діаграмі оформляються покажчиками UOB ПРИМІТКА (NOTE) Для документування будь-якої важливої інформації загального характеру, що відноситься до зображеного на діаграмах. У цьому сенсі ПОСИЛАННЯ служить альтернативою методу 64 розташування текстових нотаток безпосередньо на діаграмах УТОЧНЕННЯ (Elaboration-ELAB) Для уточнення або більш докладного опису зображеного на діаграмі. Вказівники УТОЧНЕННЯ зазвичай використовуються для опису логіки розгалуження в з'єднаннях Декомпозиція робіт. Декомпозиція використовується для деталізації робіт. Методологія IDEF3 дозволяє декомпозувати роботу багаторазово, тобто робота може мати безліч дочірніх робіт. Функціонально-вартісний аналіз. ФВА включає такі основні поняття: об'єкт витрат - мета існування функції процесу, тобто основний вихід. Вартістю цільового технологічного процесу буде сумарна вартість всіх об'єктів витрат; рушій витрат - входи і управління функції, що визначають її існування і впливають на термін її дії; центри витрат - різні статті витрат. Приклад У процесі укладання договору на поставку ТМЦ (товарно-матеріальних цінностей) в компанії замовника договір спочатку надсилається постачальнику на підписання, а тільки після цього візується у посадових осіб усередині компанії і підписується генеральним керуючим (або його заступником). На перший погляд все вірно: спочатку договір підписує зацікавлена сторона, в даному випадку клієнт, а вже потім договір потрапляє на підпис керівнику. Рисунок 3.18 - Приклад ФВА Однак з інтерв'ю із співробітниками відділу закупівель з'ясувалося, що з боку клієнта ніколи не було розбіжностей з приводу підписання договору (або таких випадків мало). Але з боку керівництва компанії до клієнтів висуваються певні вимоги. В результаті договір може бути не підписаний. Проаналізувавши вартість цих робіт за критеріями «Кур'єрська доставка», 65 «Роздруківка», «Упаковка», консультанти виявили факт того, що вартість роботи з підписання договору у клієнта значно вища за вартість робіт по підписанню його керівництвом компанії - за рахунок збільшених витрат на упаковку і кур'єрську доставку. Таким чином, у разі непідписання договору керівництвом сума, яку втрачає компанія, вище, ніж якщо б договір підписувався у клієнта в останню чергу. В результаті проведених досліджень був зроблений висновок - про необхідність змінити порядок проходження процесів з метою зменшення витрат. Питання для самоперевірки 1. Які основні компоненти діаграми IDEF3 ? 2. Що таке одиниця роботи ? 3. Як виконується декомпозиція в діаграмі IDEF3? 4. Яке основне призначення діаграми IDEF3? 5. З якою метою виконується функціонально-вартісний аналіз ? Література: [15, с.27-42]; Завдання на СРС: [VI]. 66 3.4 Діаграми потоків даних DFD Структура теми : – Нотації DFD. – Основні символи. – Контекстна діаграма. – Декомпозиція даних. – Побудова діаграми. Діаграми потоків даних (DFD - Data Flow Diagram) є основним засобом моделювання функціональних вимог проектованої системи. 1. створюються для моделювання існуючого процесу руху інформації; 2. використовуються для опису документообігу, обробки інформації. Нотації DFD. Здійснюючий реорганізацію консультант позначив гуртком кожного клерка, а стрілкою - кожен документ, що передається між ними. Використовуючи таку діаграму, він запропонував схему реорганізації, відповідно до якої двоє клерків, що обмінюються безліччю документів, були посаджені поруч, а клерки з малою взаємодією були посаджені на великій відстані. 1. застосовуються як доповнення до моделі IDEF0 для більш наочного відображення поточних операцій документообігу (обміну інформацією); 2. забезпечують проведення аналізу та визначення основних напрямків реінжинірингу ІВ. Для зображення DFD традиційно використовуються дві різні нотації: Йодана (Yourdon) і Гейна-Сарсона (Gane-Sarson). Їх метою є перетворення загальних, неясних знань про вимоги до системи в точні (наскільки це можливо) визначення. Діаграми DFD можуть доповнити те, що вже відображено в моделі IDEF0, оскільки вони описують потоки даних, дозволяючи простежити, яким чином відбувається обмін інформацією як усередині системи між бізнес-функціями, так і системи в цілому із зовнішнім інформаційним середовищем. За допомогою DFD-діаграм вимоги до проектованої ІС розбиваються на функціональні компоненти (процеси) і представляються у вигляді мережі, пов'язаної потоками даних. Головна мета декомпозиції DFD-функцій - продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити відносини між цими процесами. На схемах бізнес-процесу відображаються: – функції процесу; – вхідна та вихідна інформація, при описі документів; – зовнішні бізнес-процеси, описані на інших діаграмах; – точки розриву при переході процесу на інші сторінки Основні символи. На діаграмах функціональні вимоги представляються за допомогою процесів і сховищ, зв'язаних потоками даних. 67 Рисунок 3.19 – Основні компоненти DFD діаграми Потоки даних є механізмами, що використовуються для моделювання передачі інформації (або навіть фізичних компонент) з однієї частини системи в іншу. Стрілки описують, як об'єкти (включаючи дані) рухаються з однієї частини системи в іншу. Стрілки можуть зливатися і розгалужуватись. Призначення процесу полягає в продукуванні вихідних потоків із вхідних у відповідності з дією, що задається іменем процесу. Кожен вузол-процес в DFD може розгортатися в діаграму нижнього рівня, що дозволяє на будь-якому рівні абстрагуватися від деталей. Ім'я процесу має містити дієслово в невизначеній формі з подальшим доповненням (наприклад, «вирахувати максимальну висоту»). Сховище (накопичувач) даних дозволяє на певних ділянках визначати дані, які будуть зберігатися в пам'яті між процесами. На відміну від стрілок, що описують об'єкти в русі, сховища даних зображують об'єкти в спокої. Зовнішня сутність (термінатор) - об'єкт діаграми потоків даних, що є джерелом або приймачем інформації ззовні моделі. Зовнішні посилання/сутності зображують входи і/або виходи, тобто забезпечують інтерфейс із зовнішніми об'єктами, що знаходяться поза модельованої системи. Контекстна діаграма. Контекстна діаграма моделює систему найбільш загальним чином, відображає інтерфейс системи із зовнішнім світом, а саме, інформаційні потоки між системою і зовнішніми сутностями, з якими вона повинна бути пов'язана. Кожен проект повинен мати рівно одну контекстну діаграму. DFD першого рівня будується як декомпозиція процесу, який присутній на контекстній діаграмі. 68 Рисунок 3.20 - DFD діагарма першого рівня Розробка контекстної діаграми включає визначення: – суб'єкта моделювання - визначення, що входить до складу моделі, а що з неї виключено; – мети, як критерію закінчення моделювання; – точки зору моделі, як визначення обсягу, складу інформації та форми подачі інформації; – обмежень, що накладаються на об'єкт; – побудова діаграми верхнього рівня та її узагальнення. Декомпозиція даних. Для забезпечення декомпозиції даних до DFD додаються типи об'єктів, представлені на рис.3.21. Рисунок 3.21 - Типи об’єків, що використовуються при декомпозиції даних Груповий вузол. Призначений для розщеплення і об'єднання потоків. Вузол-предок. Дозволяє пов'язувати вхідні та вихідні потоки між процесом та DFD, що деталізуються. 69 Невикористаний вузол. Застосовується в ситуації, коли декомпозиція даних проводиться в груповому вузлі, при цьому потрібні не всі елементи потоку, який входить до вузла. Вузол зміни імені. Дозволяє неоднозначно іменувати потоки, при цьому їх вміст еквівалентний. Текст у вільному форматі в будь-якому місці діаграми. Побудова діаграми Рекомендації при побудові моделі Розміщувати на кожній діаграмі від 3 до 6-7 процесів. Верхня межа відповідає людським можливостям одночасного сприйняття і розуміння структури складної системи з безліччю внутрішніх зв'язків, нижня межа вибрана з міркувань здорового глузду: немає необхідності деталізувати процес діаграмою, яка містить всього один або два процеси. Рекомендації при побудові моделі Не загромаджувати діаграми несуттєвими на даному рівні деталями. Декомпозицію потоків даних здійснювати паралельно з декомпозицією процесів; ці дві роботи повинні виконуватися одночасно, а не одна після завершення іншої. Вибирати ясні, що відображають суть справи, імена процесів і потоків для поліпшення розуміння діаграм, при цьому намагатися не використовувати абревіатури. Лише один раз визначати функціонально ідентичні процеси на самому верхньому рівні, де такий процес необхідний, і посилатися до нього на нижніх рівнях. Користуватися найпростішими діаграмними техніками: якщо що-небудь можливо описати за допомогою DFD, то це і необхідно робити, а не використовувати для опису більш складні об'єкти. Відокремлювати керуючі структури від структур, що обробляють(тобто процесів), локалізувати керуючі структури. Етапи побудови моделі 1. Розчленування безлічі вимог і організація їх в основні функціональні групи. 2. Ідентифікація зовнішніх об'єктів, з якими система повинна бути пов'язана. 3. Ідентифікація основних видів інформації, що циркулює між системою і зовнішніми об'єктами. 4. Попередня розробка контекстної діаграми, на якій основні функціональні групи представляються процесами, зовнішні об'єкти - зовнішніми сутностями, основні види інформації - потоками даних між процесами і зовнішніми сутностями. 5. Вивчення попередньої контекстної діаграми і внесення до неї змін за результатами відповідей на виникаючі при цьому вивченні питання по всіх її частинах. 6. Побудова контекстної діаграми шляхом об'єднання всіх процесів попередньої діаграми в один процес, а також групування потоків. 7. Формування DFD першого рівня на базі процесів попередньої контекстної діаграми 8. Перевірка основних вимог по DFD першого рівня 9. Декомпозиція кожного процесу поточної DFD за допомогою деталізуючої діаграми або специфікації процесу 10. Перевірка основних вимог по DFD відповідного рівня 11. Додавання визначень нових потоків в словник даних при кожній їх появі на діаграмах 70 12. Паралельне (з процесом декомпозиції) вивчення вимог (в тому числі і тих, що знову надходять), розбиття їх на елементарні та ідентифікація процесів або специфікацій процесів, які відповідають цим вимогам. 13. Проведення ревізії після побудови двох-трьох рівнів з метою перевірки коректності та поліпшення розуміння моделі Приклад побудови DFD діаграми Рисунок 3.22 - Контекстна діаграма системи «Обробка замовлень клієнтів» Рисунок 3.23 - Діаграма деталізації першого рівня системи «Обробка замовлень клієнтів» Приклад 2 побудови DFD діаграми 71 Рисунок 3.24 - Декомпозиції роботи «Зберігання моделі торгового підприємства» Приклад 3 побудови DFD діаграми Рисунок 3.25 - Декомпозиції роботи «Списання товару моделі торгового підприємства» 72 Питання для самоперевірки 1. Які дві нотації використовуються для зображення діаграми DFD? 2. Які основні компоненти діаграми DFD ? 3. Що таке контекстна діаграма ? 4. Як виконується декомпозиція в діаграмі DFD ? 5. Призначення елементів «сховище» та «зовнішня сутність». 6. Яке основне призначення діаграми DFD ? Література: [15, с.66-72]; Завдання на СРС: [11]. 73 4 Використання CASE-технологій в КП 4.1 CASE-засоби для проектування інформаційних систем Структура теми: – CASE-засоби для моделювання UML. – CASE-засоби структурного аналізу. – Порівняння CASE-засобів. CASE-засоби для моделювання UML. Властивості: – Пряме та / або зворотне проектування (forward or / and reverse engineering) Round-trip engineering (RTE) підтримка в синхронному стані різних артефактів (наприклад моделі та вихідного коду) – Підтримка нових версій UML – Можливості моделювання; – Підтримка багатокористувацького режиму; – Інтеграція з IDE – Інтеграція із засобами управління проектами (PM) / підтримка завдань PM; – Генерація документації. CASE-засоби структурного аналізу. Порівняння CASE-засобів. Enterprise Architect 9: 1. Підтримка FE, RE, RTE 2. UML 2.4.1 3. Модель може зберігатися в репозиторії бази даних (SQL Server, MySQL, Oracle, ...). Для цього спочатку в СУБД виконується певний скрипт створення репозиторію. 4. Багатокористувацький режим: - Можливість одночасного доступу і зміна різних частин моделі; - Може виникнути непередбачена ситуація при редагуванні однієї і тієї ж діаграми різними користувачами 5. Управління безпекою на рівні користувачів і ролей. Імпорт з Windows Active Directory. 6. Контроль версій. Порівняння версій. Subversion, CVS, SOA і XML. 7. Тестування. 8. Використання моделі валідації використовуючи Object Constraint Language (OCL). 9. Створення і управління тестовими скриптами. 10. Підтримка видів тестування: - група тестування - тестування інтеграції системне тестування - приймальне тестування - сценарне тестування 11. Звітність. 74 12. Автоматизація: - Виконання скриптів JavaScript, Microsoft JScript - Microsoft VBScript для відкритої моделі. - Add-Ins 13. . Розширення функціональності: - Можна визначати меню і підменю. - Отримувати нотифікації від користувальницьких подій. - Шукати інформацію в моделі. Power Designer Рисунок 4.1 – Модель взаємодії БД з Power Designer 1. Підтримка FE, RE, RTE 2. UML 2,3 3. Модель може зберігатися в репозиторії бази даних. 75 Рисунок 4.2 - Порівняння можливостей Enterprise Architect та Power Designer 76 Рисунок 4.3 – Позиції компаній з розробок CASE систем Питання для самоперевірки 1. Які основні властивості CASE-засобів для моделювання UML? 2. Які основні переваги та недоліки Enterprise Architect 9? 3. Які основні переваги та недоліки Power Designer? Література: [11, с.20-30]; [2, c.551-558] Завдання на СРС: [I],[II]. |