2012_Посібник_з_дисципліни_ТКП. Кафедра автоматизованих систем обробки інформації І управління посібник з дисципліни
 Скачать 3.1 Mb.
|
|
Обов'язки: Клас Продаж: знання загальної суми продажу Клас ТоварПродажа: знання проміжної суми для даного товару Клас ТоварСпеціфікація: Знання ціни товару Шаблон Creator Проблема: хто має відповідати за створення нового екземпляра деякого класу? Рішення: Призначити класу В обов'язок створювати об'єкти іншого класу А Рекомендації: Логічно використовувати шаблон якщо клас В містить, агрегує, активно використовує і т.п. об'єкти класу А. Необхідно визначити, який об'єкт повинен відповідати за створення екземпляра «ТоварПродаж». Логічно, щоб це був об'єкт «Продаж», оскільки він містить (агрегує) кілька об’єктів «ТоварПродаж» 47 Рисунок 2.14- Результат застосування патерну Creator Шаблон High Cohesion Проблема: Забезпечити низьку зв'язаність при створенні екземпляра класу і зв'язуванні його з іншим класом. Рішення: Розподілити обов'язки між об'єктами так, щоб ступінь пов'язаності залишалася низькою. Ступінь зв'язності: міра, визначальна наскільки жорстко один елемент пов'язаний з іншими. Низька зв'язність, коли залежить не від великої кількості інших об'єктів. Необхідно створити екземпляр класу «Платіж». У предметної області реєстрація об'єкта «Платіж» виконується об'єктом «Реєстрація» (ведеться реєстр). Способи створення екземпляра класу «Платіж». Верхній малюнок - з використанням патерну «Creator», нижній - з використанням «Low Coupling». Останній спосіб забезпечує більш низьку ступінь зв'язування. 48 Рисунок 2.15 – Результат застосування патернів «Creator» та «Low Coupling». Шаблон Low Coupling Проблема: Необхідно забезпечити виконання об'єктами різнорідних функцій. Рішення: Забезпечити розподіл обов'язків з високим зачепленням. Рішення: елемент з високим ступенем зачеплення - якщо його обов'язки тісно пов'язані між собою і він не виконує непомірних обсягів робіт. На клас «Реєстрація» покладати все нові і нові системні функції, пов'язані з системними операціями. Даний клас буде занадто перевантажений і буде володіти низьким ступенем зачеплення. Нижній малюнок має більш високим рівнем зачеплення і низьким рівнем зв'язування (він є кращим) (див. рис.2.5). Питання для самоперевірки 1. Що таке шаблон проектування? 2. Для чого потрібні шаблони проектування? 3. Яке призначення шаблонів розподілу обов’язків ? 4. Призначення шаблонів InformationExpert, Creator? 5. Назвіть основні відмінності між шаблонами Creator та «Low Coupling». Література: [2, с.223-252]; Завдання на СРС: [14, с. 25-44]. 49 3 Структурний підхід в ТП 3.1 Огляд методологій та технологій структурного аналізу Структура теми : – Технологія структурного аналізу та проектування SADT. – Огляд методологій та технологій IDEF. Технологія структурного аналізу та проектування SADT. SADT( Structured Analysis and Design Technique) методологія структурного аналізу і проектування, у майбутньому використовується сімейство методологій IDEF. Огляд методологій та технологій IDEF. IDEF - Скорочення від Integration Definition Methodology (Об'єднання Методологічних Понять), методології сімейства ICAM (Integrated Computer-Aided Manufacturing) для вирішення завдань моделювання складних систем, дозволяють відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними. Історія виникнення методології IDEF Для опису процесів у світі розроблено велику кількість різних підходів і методів. На початку 70-х років Д. Росс в США запропонував метод структурного проектування та аналізу систем SADT (Structured Analysis and Design Techniques). В основі цього підходу лежить графічна мова опису (моделювання) систем. Перше її маштабне застосування було в 1973 р. при розробці великого аерокосмічного проекту. До 1981 р. SADT вже використали більш ніж в 50 компаніях при роботі більш ніж над 200 проектами, що включали понад 2000 людей і охоплювали дюжину проблемних областей, в тому числі телефонні мережі, аерокосмічне виробництво, управління і контроль, облік матеріально- технічних ресурсів та обробку даних. У середині 70-х ВПС США реалізували програму інтегрованої комп'ютеризації виробництва ICAM (Integrated Computer Aided Manufacturing). В рамках цієї програми були розроблені методи проектування та аналізу складних виробничих систем, а також способи обміну інформацією між фахівцями, що займаються такими проблемами. Для задоволення цих потреб в рамках програми ICAM була розроблена методологія IDEF (ICAM Definitions), що дозволяє представити і дослідити структуру, параметри та характеристики виробничо-технічних і організаційно-економічних систем. Процеси, що описують діяльність організації, відносяться саме до цього класу систем. IDEF-технологія використовується, починаючи з кінця 1980-х років. Міністерство оборони США є основним користувачем даної технології. Їй, також, користуються деякі крупні корпорації в США. IDEF0 DEF0 - методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 представляє досліджувану систему у вигляді набору взаємопов'язаних функцій («функціональних блоків»). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. IDEF1, IDEF1X IDEF1 - методологія моделювання інформаційних потоків усередині системи. Дозволяє відображати та аналізувати їх структуру і взаємозв'язок; IDEF1X (IDEF1 Extended) - методологія побудови реляційних структур. 50 IDEF1X відноситься до типу методологій «Сутність-взаємозв'язок» (ER - Entity- Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до даної системи. IDEF2 IDEF2 - методологія динамічного моделювання розвитку систем. Через серйозні труднощі, пов'язані з аналізом динамічних систем, від цього стандарту зараз практично відмовилися, і його розвиток призупинився на самому початковому етапі. Існуючі алгоритми та їх комп'ютерні реалізації дозволяють перетворювати набір статичних діаграм IDEF0 у динамічні моделі, побудовані на базі «розфарбованих мереж Петрі» (CPN - Color Petri Nets). IDEF3 IDEF3 - методологія документування процесів, що відбуваються в системі. За допомогою IDEF3 описуються сценарій та послідовність операцій для кожного процесу. IDEF3 безпосередньо пов'язана з методологією IDEF0: кожна функція (функціональний блок) може бути представлена засобами IDEF3 у вигляді окремого процесу. IDEF4 IDEF4 - методологія побудови об'єктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів та принципи їх взаємодії, дозволяючи аналізувати й оптимізувати складні об'єктно-орієнтовані системи. Рисунок 3.1 - Представлення IDEF4 IDEF5 IDEF5 - методологія онтологічного дослідження складних систем. За допомогою словника термінів і правил дозволяє описати онтологію системи. У результаті можуть бути сформовані достовірні твердження про стан системи в певний момент часу, на основі яких робляться висновки про подальший розвиток системи і провадиться її оптимізація. IDEF6 IDEF6 (Design Rational Capture Method) - даний метод дозволяє використовувати раціональний досвід проектування, що сприяє запобіганню структурних помилок. Призначення IDEF6 полягає в полегшенні отримання «знань про спосіб» моделювання, їх представлення і використання при розробці систем управління підприємствами. Метод IDEF6 акцентує увагу саме на процесі створення моделі; 51 IDEF7 IDEF7 (Information System Auditing) - даний метод описує проведення методології аудиту інформаційної системи. Не був повністю розроблений. IDEF8 IDEF8 (User Interface Modeling) - даний метод дозволяє розробляти необхідні моделі Графічного Інтерфейсу Користувача (Human-System Interaction Design). Метод призначений для проектування взаємодії людини і технічної системи. IDFE8 фокусує увагу розробників інтерфейсу на програмуванні бажаної взаємної поведінки інтерфейсу та користувача на трьох рівнях: 1. Виконуваної операції (що це за операція) 2. Сценарії взаємодії 3. Деталі інтерфейсу (які елементи управління, пропонує інтерфейс для виконання операції) IDEF9 IDEF9 (Business Constraint Discovery) - дана модель призначена для аналізу наявних умов і обмежень (у тому числі фізичних, юридичних або будь-яких інших) та їх впливу на рішення, що приймаються в процесі реінжинірингу. Не розроблені стандарти: IDEF10, IDEF11, IDEF12, IDEF13 IDEF10 - Implementation Architecture Modeling. Моделювання архітектури впровадження IDEF11 - Information Artifact Modeling. Моделювання інформації про артефакти IDEF12 - Organization Modeling. Організаційне моделювання. IDEF13 - Three Schema Mapping Design. Трисхемне проектування перетворення даних. IDEF14 (Network Design) - даний метод дозволяє моделювати обчислювальні мережі. Модель призначена для представлення і аналізу даних при проектуванні обчислювальних мереж на графічний мові з описом конфігурацій, черг, мережевих компонентів, вимог до надійності. Питання для самоперевірки 1. Опишіть історію виникнення стандартів IDEF. 2. Які основні стандарти методології IDEF ? 3. Опишіть, які стандарти IDEF мають відображення в UML? Література: [5, с.28-74]; Завдання на СРС: [VI]. 52 3.2 Методологія функціонального моделювання IDEF0 Структура теми : – Основні елементи та поняття IDEF0. – Декомпозиція діаграми. – Побудова діаграми. Основні елементи та поняття IDEF0. Історія виникнення стандарту IDEF0: 1969: Дуглас Росс - SADT (Structured Analysis and Design Technique). 1970-е: ВПС США (ICAM - Integrated Computer-Aided Manufacturing). Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках великої програми автоматизації промислових підприємств, яка носила позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово- Повітряних Сил США. Однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках «аналітик-спеціаліст». В основі методології лежать чотири основних поняття: 1. Функціональний блок (Activity Box) 2. Інтерфейсна дуга (Arrow) 3. Декомпозиція (Decomposition) 4. Глосарій (Glossary) Функціональний блок Процес (дія) представляється у вигляді функціонального блоку, який перетворює входи на виходи при наявності необхідних ресурсів (механізмів) в керованих умовах. Графічно зображується у вигляді прямокутника. Рисунок 3.2 - Графічне зображення функціонального блоку 53 Інтерфейсна дуга Інтерфейсна дуга відображає елемент системи, який обробляється функціональним блоком або іншим способом впливає на функцію, відображену даними функціональним блоком. Графічно зображується у вигляді односпрямованої стрілки. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). Глосарій Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт передбачає створення та підтримку набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений даними елементом. Цей набір називається глосарієм і є описом сутності даного елемента. Декомпозиція діаграми. Функціональні блоки можна розбити на складові блоки. Більш вірно декомпозиція «зовні всередину» (як у цибулини), ніж «зверху вниз». Рисунок 3.3 – Варіанти декомпозиціїї Побудова діаграми. Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт передбачає створення та підтримку набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений даними елементом. Цей набір називається глосарієм і є описом сутності даного елемента. Принципи обмеження складності IDEF0-діаграм 54 Модель IDEF0 завжди починається з представлення системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстної діаграмою, і позначається ідентифікатором «А-0». Побудова IDEF0-моделі Модель IDEF0 завжди починається з представлення системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстної діаграмою, і позначається ідентифікатором «А-0». Імена функцій зазвичай підбираються з використанням дієслів або віддієслівних іменників (наприклад: звірка документів). Типізація категорій інформації (ICOM): I (Input) - вхід, то що споживається в ході виконання. C (Control) - управління - обмеження та вказівки. O (Output) - вихід, результат виконання. M (Mechanism) - виконуючий механізм. Стрілкам присвоюються імена. Вхідних стрілок може і не бути (наприклад: прийняття рішення, коли не споживаються і не перетворюються фактори). Повинна бути як мінімум одна стрілка управління. Якщо не зрозуміло до чого віднести стрілку (вхід/керування) то більш переважно «керування». Рисунок 3.4 - Інтерфейсні дуги функціонального блоку Мінімум один вихід. Механізм виконання може бути відсутнім, якщо вони не важливі для досягнення мети. Комбіновані стрілки: вихід-вхід, вихід-механізм виконання, ... 55 Рисунок 3.5 - Комбінована стрілка типу «вихід»-«вхід» Вихід - зворотний зв'язок (наприклад бракована продукція використовується заново). Рисунок 3.6 – Комбінована стрілка типу «вихід» - «зворотний зв'язок» Рисунок 3.7 - Комбінована стрілка типу «роз'єднання» і «з'єднання» Рисунок 3.8 - Приклад діаграми IDEF Визначення механізмів виконання і ресурсів: – Після визначення входів і виходів; – Наприклад, «зібрати деталь» може потребувати обладнання. – Керування можна розглядати як окрему форму вводу. Нумерація: Наприклад, А0 декомпозуеться в А1, А2, ...; А1 декомпозуеться в А11, А111, ... Збір інформації про об'єкт, визначення його кордонів; Визначення мети моделі; Побудова, узагальнення та декомпозиція діаграм; Критична оцінка, рецензування і коментування. На контекстній діаграмі поміщається єдина дія (процес). Деталізація діаграм відповідає уточненню опису дії, розбиваючи його на більш докладні дії. На кожному рівні деталізації не повинно бути більше 5-6 дій. На кожному рівні деталізації дії повинні бути об'єднані загальною логікою. Найменування дій повинні бути короткими і ємними, у доданому словнику короткі імена повинні розшифровуватися. Діям присвоюються номери, що відображають їх положення в ієрархії. Кожна дія має мати підставу для початку (один або кілька входів) і результат (один або кілька виходів). Розгалуження процесу (альтернативні або одночасні результати дій) повинні супроводжуватися описом умов їх настання. Документи, що супроводжують зв'язок між діями, повинні відповідати паперовому документообігу. Записи, що направляються в сховища і витягнуті зі сховищ, повинні описувати накопичення і використання інформації, у тому числі в базах даних. Деталі паперового та електронного документообігу (інформаційні структури документів і записів) повинні розшифровуватися в доданому словнику. Інші діаграми IDEF0 Дерево - оглядова діаграма структури всієї моделі Презентаційні діаграми - (For Exposition Only diagrams - FEO) - моделі, що ілюструють інші точки зору або відносяться до одного функціонального блоку (входу, виходу батьківського блоку). 58 Рисунок 3.9 – Приклад IDEF0 Вся робота виконується блоками найнижчого рівня. Рисунок 3.10 – Представлення ітераційної моделі ЖЦ за допомогою IDEF0 59 Питання для самоперевірки 1. Назвіть основні елементи IDEF ? 2. Які основні принципи методології IDEF ? 3. Що таке декомпозиція ? Які основні правила декомпозиції ? 4. З якою метою виконуються декомпозиція діаграм ? 5. Які обов’язкові інтерфейсні дуги повинні бути присутні в функціональному блоці. 6. Наведіть приклад комбінованої стрілки типу «вхід»-«вихід», «вихід»- «вхід»? Література: [15, с.44-64]; Завдання на СРС: [VI]. 60 3.3 Методологія документування процесів IDEF3 Структура теми : – Одиниці робіт. – Зв’язки та перехрестя. – Декомпозиція робіт. – Функціонально-вартісний аналіз. IDEF3 - Це методологія моделювання, що використовує графічний опис інформаційних потоків, взаємин між процесами обробки інформації та об'єктів, що є частиною цих процесів. Метод, який має основною метою дати можливість аналітикам описати ситуацію, коли процеси виконуються в певній послідовності, а також описати об'єкти, які беруть участь спільно в одному процесі. При інтерпретації DFD-діаграми використовуються наступні правила: – функції перетворюють вхідні потоки даних в вихідні; – сховища даних не змінюють потоки даних, а служать тільки для зберігання об'єктів, що надходять; – перетворення потоків даних у зовнішніх посиланнях ігнорується. Одиниці робіт. Одиниці роботи - Unit of Work (UOW), також звані роботами (activity), є центральними компонентами моделі. Роботи зображуються прямокутниками з прямими кутами і мають ім'я та номер (ідентифікатор). |