Архів якісних рефератів

Знайти реферат за назвою:         Розширений пошук

Меню сайту

Головна сторінка » Інформатика, програмування

Відповіді на питання з предмету "Автоматизовані інформаційні системи" (АІС) (шпора)

1 Поняття системи, середовища, архітектури середовища. Приклади.

2 Поняття концептуальної моделі системи. Концептуальне проектування складних або слабо структурованих автоматизованих інформаційних систем.

3 Поняття методології. Причини виникнення методології IDEF. Зміст та призначення методологій групи IDEF; взаємний зв'язок між ними.

4 Життєвий цикл програмного забезпечення AIC. Каскадна модель життєвого циклу.

5 Життєвий цикл програмного забезпечення AIC. Спіральна модель життєвого циклу.

6 Програмний продукт підтримки методологій концептуального проектування DESIGN/IDEF, його призначення і можливості застосування у моделях життєвого циклу.

7 Методологія IDEF0; її призначення; склад і характеристика компонент.

8 Графічна мова опису моделей в методології IDEF; її властивості та переваги перед іншими мовами опису моделей.

9 Поняття функціональної моделі IDEF0. Компоненти моделі IDEF0, зв'язок між ними. Структура моделі IDEF0.

10 Поняття відкритої і замкнутої системи та спосіб їх подавання моделлю IDEF0. Приклади.

11 Мета утворення системи. Мета утворення моделі IDEF0 і точка зору на зміст моделі. Приклади.

12 Поняття функції; функціонального блоку та інтерфейсних дуг блоку. Призначення інтерфейсних дуг блоку та їх вміст.

13 Функція та її обмеження. Порядок роботи функцій залежно від дуг. Процеси, що перекриваються у часі. Ітерація. Зворотній зв'язок. Приклади.

14 Поняття діаграми декомпозиції. Зміст діаграми. Вузол діаграми. Батьківська діаграма та діаграми декомпозиції.

15 Семантика локальних структур. Синтаксичні правила побудови локальних структур.

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

17 Граничні, внутрішні и зовнішні дуги. ICOM - коди і їх призначення. Область дії ICOM – кодів. Правила утворення ICOM – кодів.

18 Семантика конструкції діаграма. Синтаксичні правила побудови діаграми.

19 Семантика конструкції модель. Синтаксичні правила побудови конструкції - модель.

20 Поняття контексту моделі та контексту діаграми. Призначення контекстів. Приклади контекстів моделі та діаграми.

21 Текст до діаграми; його структура; вміст; розташування. Мова посилань.

22 Глосарій; структура глоссарію; його призначення. Визначення ціни та частоти виконання функцій. Форми звіту. Компіляція моделі.

23 Діаграми FEO; їх призначення. Спосіб пов‘язування IDEF0-діаграми з FEO-діаграмою.

24 Дерево вузлів(Індекс моделі). Читання моделі в різних ситуаціях. Основні етапи при читанні діаграми. Правила інтерпретації змісту діаграми.

25 Основні етапи розробки моделі; їх характеристика.

26 Поняття мети, точки зору і контексту моделі; їх використання при розробці IDEF0 - моделі.

27 Побудова контекстної діаграми А-0. Взаємозв'язок між діаграмами А-0 та А0.

28 Розробка діаграми декомпозиції. Основні етапи побудови діаграми.

29 Розробка функцій та розташування блоків при утворенні діаграми декомпозиції.

30 Утворення дуг при розробці діаграми декомпозиції.

3) Поняття методології. Причини виникнення методології IDEF. Зміст та призначення методологій групи IDEF; взаємний зв'язок між ними.

Методологія вчення про структуру, логічну організацію, методи та засоби діяльності. Під діяльністю ми будемо розуміти концептуальне проектування системи.

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

Стандартна методологія має мову утворення моделі, що дозволяє подавати модель у формалізованому вигляді; критерії контролю якості утвореної моделі, використовуючи які, якість моделі системи може аналізуватись програмно.

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

Існує два підходи до моделювання систем: структурний та об'єктно-орієнтований. Ми вивчатимемо структурний підхід реалізований у методологіях функціонального та інформаційного моделювання IDEF0 та IDEF1X.

Розглянемо причини створення групи стандартних методологій IDEF. У 1981 році в галузі ВПС США була запропонована «Програма інтегрованої комп'ютеризації виробництва - ICAM». Метою було збільшення продуктивності виробництва шляхом впровадження комп'ютерних технологій.

Програма передбачала розробку систем загального призначення, тобто типових для всіх підприємств галузі: диспетчерські служби; складування матеріалів; бухгалтерський облік, планування, тощо. Але цього було мало.

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

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

Так була створена стандартна методологія розробки складних систем IDEF(Integrated Definition).

, методології групи IDEF - група взаємопов'язаних і взаємозалежних методологій. Кожна методологія призначена для створення моделі, що визначає певний аспект системи, на різних етапах її проектування.

В IDEF існують такі методології концептуального проектування:

- IDEF0 створення функціональної моделі системи, середовища системи;

- IDEF1X створення інформаційної моделі системи, середовища системи;

- IDEF2 створення моделі поведінки системи. Модель описує зміну станів системи у часі залежно від параметрів;

- IDEF3 моделювання безперервних процесів системи;

- IDEF4 створення об'єктно-орієнтованих моделей системи.

- IDEF5 систематизування об'єктів виробництва. Моделювання загальних категорій та закономірностей об'єктів виробництва(онтологія);

- IDEF6 зберігання раціонального досвіду розробки систем;

- IDEF8 моделювання діалогу людини з технічною системою з метою створення оптимальних умов праці, що збільшують продуктивність;

- ІDEF9 аналіз умов і обмежень майбутньої системи, їх впливу на рішення, які приймаються в процесі реінжінірінга;

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

Для підтримки правил методологій концептуального проектування систем і прискорення побудови моделей існує спеціальне програмне забезпечення.

Такі системи називають CASE-системами. Абревіатуру CASE розуміють у поширеному та вузькому сенсі. У вузькому сенсі Computer Aided Software Engineering означає автоматизоване проектування програмного забезпечення. У поширеному сенсі Computer Aided System Engineering означає концептуальне проектування складних систем.

1 BPWIN – застосовують для розробки функціональних моделей. Методологія IDEF0.

2 ERWIN - застосовують для розробки інформаційних моделей. Методологія IDEF1Х.

3 OOWIN - застосовують для об'єктно-орієнтованого проектування інформаційних моделей. Методологія IDEF4.

DESIGN/IDEF - застосовують для розробки функціональних та інформаційних моделей.

4) Життєвий цикл програмного забезпечення AIC. Каскадна модель життєвого циклу.

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

Структура життєвого циклу системи визначається міжнародною організацією зі стандартизації International Organization of Standardization за стандартом ISO/IEC 12207. Моделі життєвого циклу системи визначають вміст і послідовність етапів розробки та супроводження системи, тобто визначають технології розробки систем.

Існують такі стратегії конструювання програмного забезпечення: водоспадна(лінійна послідовність етапів розробки ПЗ), інкрементна(циклічна послідовність етапів конструювання ПЗ), еволюційна(циклічна послідовність етапів конструювання ПЗ). Ми розглянемо водоспадну та еволюційну стратегії на прикладі каскадної та спіральної моделі життєвого циклу.

1.2.1 Каскадна модель

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

Системний аналіз. На етапі визначають роль кожного елементу системи: програм, користувачів, БД, апаратури, виявляють взаємодію елементів. Визначають вимоги до кожного системного елементу. Кожну підмножину системних вимог призначають певному програмному елементу системи. На етапі системного аналізу планують об'єми проектних робіт. Утворюють графік робіт. Визначають ступінь ризику.

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

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

Кодування(реалізація). Застосовують проект, утворюють програмний код на обраній мові програмування. Вибір мови програмування залежить від вимог до ПЗ.

Тестування. Під час виконання тестування ПЗ визначають дефекти у функціях системи, реалізованій логіці, обраних алгоритмах, структурі системи, зроблених під час концептуального проектування.

Супроводження. Виправляють помилки, адаптують ПЗ до середовища системи; удосконалюють ПЗ. При виконанні вказаних дій використовують етапи, які виконували при утворенні нового програмного продукту, але виконують етапи для існуючої системи.

При реалізації каскадної моделі етапи розробки системи виконують послідовно. Кожний етап закінчують повним набором узгодженої документації. Після чого виконують наступний етап. Каскадну схему зображено на рисунку 1.1. Але реально відбувається процес на рисунку 1.2.

Рисунок 1.1 - Каскадна модель розробки ПЗ

Рисунок 1.2 - Реальна каскадна схема розробки ПЗ

Перевагою каскадної моделі є можливість планувати строки всіх робіт і витрат.

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

Недоліки каскадної моделі

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

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

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

5) Життєвий цикл програмного забезпечення AIC. Спіральна модель життєвого циклу.

1.2.2 Спіральна модель

Щоб перебороти переліченні проблеми була запропонована спіральна модель.

Спіральна модель базується на понятті прототипу. Прототип – загальний вигляд системи без деталізації. Розробку системи виконують за витками спіралі, де кожний наступний виток реалізує прототип, більше деталізований, ніж попередній.

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

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

Для кожного витку спіралі виконують такі етапи: планування; аналіз ризику; конструювання; оцінювання замовником.

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

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

Конструювання. Реалізують концептуальне проектування, кодування. Якщо виявилась невизначеність вимог на першому витку, то утворюють макет, який показують замовнику. Макетом можна вважати меню системи. На інших витках спіралі при конструюванні виконують моделювання системи та опит замовника.

Оцінювання. Замовник оцінює поточні результати конструювання на витку, робить зауваження, уточнює вимоги. Спіральну модель подано на рисунку 1.3.

Рисунок 1.3 - Спіральна модель розробки ПЗ

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

Недоліками спіральної моделі є підвищені вимоги до замовника, важкість контролю та керування часом розробки. Модель достатньо нова(виникла у 90 роки) і тому невідома статистика ефективності моделі.

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

Вибір моделі ЖЦ системи залежить від можливостей розроблювача та замовника.

7) Методологія IDEF0; її призначення; склад і характеристика компонент.

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

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

Методологія IDEF0 містить провідні документи: про графічну мову подавання моделі; методики збору інформації для утворення моделі, по утворенню та переробці моделі, по читанню моделі, по керуванню колективом розроблювачів моделі, по контролю якості моделі; подає правила ведення та оформлення документації.

Існують два підходи до структурного концептуального проектування систем: інформаційний та процедурний. Ми розглянемо процедурний підхід – від функцій до даних. Реально обидва підходи застосовуються залежно від виду роботи.

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

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

Графічна мова подає зміст системи у природній для людини формі.

8) Графічна мова опису моделей в методології IDEF; її властивості та переваги перед іншими мовами опису моделей.

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

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

Графічна мова подає зміст системи у природній для людини формі.

9) Поняття функціональної моделі IDEF0. Компоненти моделі IDEF0, зв'язок між ними. Структура моделі IDEF0.

11) Мета утворення системи. Мета утворення моделі IDEF0 і точка зору на зміст моделі. Приклади.

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

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

Функціональне моделювання різних точок зору дозволяє реалізувати різні моделі, що відповідають кожній точці зору. Після чого всі точки зору враховують у одній моделі. Такий підхід дозволить реалізувати якісний програмний продукт.

12) Поняття функції; функціонального блоку та інтерфейсних дуг блоку. Призначення інтерфейсних дуг блоку та їх вміст.

Базовою одиницею діаграм функціональної моделі є функція. Функцією являється будь-яка виробнича операція. На діаграмі назву функції розташовують у середині блоку та записують дієсловом у інфінітиві або дієслівним зворотом.

Блок називають функціональним. Він має ідентифікатор, який розташовано в правому нижньому куту блока. Ідентифікатор блока складається з ідентифікатору діаграми, на якій його розташовано, та номеру блока на діаграмі. Ідентифікатор завжди починається з букви A(activity). Дивись рисунок 3.1.

Рисунок 3.1 - Приклад функціонального блоку

Функцію зображують разом з об‘єктами, що використовуються нею у роботі, керують нею, виконують її або виробляються нею. Об'єкти називають обмеженнями виконання функції. Функція виконується лише при наявності необхідних об'єктів.

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

На діаграмі обмеження подають у вигляді дуг проведених до сторін блоку.

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

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

13) Функція та її обмеження. Порядок роботи функцій залежно від дуг. Процеси, що перекриваються у часі. Ітерація. Зворотній зв'язок. Приклади.

14) Поняття діаграми декомпозиції. Зміст діаграми. Вузол діаграми. Батьківська діаграма та діаграми декомпозиції.

26) Поняття мети, точки зору і контексту моделі; їх використання при розробці IDEF0 - моделі.

27) Побудова контекстної діаграми А-0. Взаємозв'язок між діаграмами А-0 та А0.

Модель IDEF0 - це ієрархічна структура з діаграм, які визначають що робить система, разом з пояснюючим текстом, глосарієм і діаграмами FEO.

 

3.2 Ієрархічна структура з діаграм

Вершиною ієрархічної структури з діаграм є діаграма А-0. На діаграмі А-0 зображують одну функцію, яка визначає призначення системи. Мету утворення системи, мету утворення функціональної моделі та точку зору на утворення моделі розташовують під функціональним блоком. (Дивись рисунок 3.2.)

Рисунок 3.2 - Приклад діаграми А-0: „Профогляд”

На діаграмі А-0 функція має дуги тільки для відкритих систем. Дуги на діаграмі А-0 називають зовнішніми дугами, вони являються інтерфейсом між середовищем і системою. Замкнена система не має середовища і тому не має дуг для спілкування.

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

На діаграмі декомпозиції можна розмістити від 3 до 6 блоків. Кожен блок має свій ідентифікатор, який складається з ідентифікатору діаграми та номера блоку на діаграмі. Виняток - ідентифікатори блоків на діаграмі А0, вони записуються без 0. Наприклад, А15 – блок номер 5 на діаграмі А1, але блок А2 на діаграмі А0. Приклад діаграми декомпозиції дивися на рисунку 3.3.

Рисунок 3.3 - Приклад діаграми декомпозиції А0: „Провести Профогляд”

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

Зв'язок діаграм моделі за ідентифікаторами вузлів та іменами функцій дозволяє розглядати функціональну модель, як єдине ціле, не тільки за змістом, а й формально.

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

Діаграми моделі зображують на стандартній майстер-сторінці. Верхні поля сторінки – робоча інформація, яку використовують тільки під час розробки діаграми, а потім відрізають. Нижні поля сторінки використовують для ідентифікації діаграми. На середній частині сторінки зображують саму діаграму: функціональні блоки та їх дуги.


 

 

3.3 Зв'язок функцій дугами на діаграмі декомпозиції

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

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

Одну дугу може використовувати декілька функцій діаграми. Така дуга має мітку на спільній частині, а мітка відноситься до всіх гілок. Дивися рисунок 3.4.

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

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

Рисунок 3.4 - Приклад використання дуги різними функціями

Рисунок 3.5 - Приклад деталізації дуги

Дуги, які породжуються на діаграмі декомпозиції, та мають два кінця на сторонах блоків називають внутрішніми дугами. На рисунку 3.5 дуга „Програмна система” внутрішня.

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

На рисунку 3.5 прикордонні дуги: гроші, керівництво підприємства, системний програміст, пояснювальна записка, впроваджена система.

 

3.4 Порядок виконання функцій на діаграмі декомпозиції

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

З рисунку 3.5 видно, що функція „Впровадити” не виконається раніше, ніж виконається функція „Купити”. Поки не з'явиться дуга „програмна система”, функція „Впровадити” не може працювати. Рисунок 3.5 - приклад послідовного виконання функцій.

Про порядок виконання функцій „Ввести” і „Надрукувати” на рисунку 3.4 не можна нічого сказати. Функції можуть виконуватися одночасно або послідовно, бо невідомо, коли поступить дуга „документ”.

Функції, які зображено на рисунку 3.6 виконуються паралельно. Для них дуги „директива” та „гроші” поступають одночасно.

Рисунок 3.6 - Приклад паралельного виконання функцій

На рисунку 3.7 зображено конкуренцію функцій за матеріал, що користується попитом.

Рисунок 3.7 - Приклад конкуренції функцій за матеріальні об'єкти

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

Рисунок 3.8 - Приклад діаграми із зворотним зв'язком

10) Поняття відкритої і замкнутої системи та спосіб їх подавання моделлю IDEF0. Приклади.

Системи бувають відкриті та замкнені. Реально замкнених систем немає, всі системи відкриті. Замкнена системи абстракція, яку використовують у випадку, якщо середовищем не цікавляться. У замкнених систем середовища немає.

15) Семантика локальних структур. Синтаксичні правила побудови локальних структур.

Семантика функціонального блоку

1 Локальна конструкція - функціональний блок призначена для подавання на діаграмі функції системи у блоці.

2 Назва функції повинна точно та однозначно відображати призначення функції.

3 Формулювання назви повинно бути стислим.

Синтаксис функціонального блоку

1 Назва функції записується дієсловом у інфінітиві або дієслівним зворотом.

2 Назва розміщується у середині блоку.

3 Блок має ідентифікатор. Ідентифікатор блоку складається з ідентифікатору діаграми та номеру блока на діаграмі.

4 Ідентифікатор блоку починається з букви А, що означає функцію – Activity. Наприклад, ідентифікатор блоку А12 означає, що функціональний блок з номером 2 розташовується на діаграмі А1.

Семантика дуг

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

2 Дуги ідентифікуються мітками. Мітка та дуга утворюють разом локальну конструкцію.

3 Мітки вказують на зміст дуги. Мітки точно та однозначно відображують зміст дуг.

4 Дуги класифікуються за призначенням: вхідні, вихідні, керуючі, механізми.

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

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

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

8 Якщо дуга містить вхідні дані та керуючі, то її роблять керуючою дугою.

Синтаксис дуг

1 Дуги бувають одно сегментні та багато сегментні. Сегмент будується на основі двох точок і має один напрям.

2 Не можливо побудувати дугу, у якій обидві точки - вхідна та вихідна, розташовані не на стороні блоку.

3 На діаграмі мітки прив'язуються до дуги для наочності. У базі даних, що описує модель, дуга подається тільки міткою. А відношення встановлюються між об'єктами: функція – мітка дуги. Причому кожна мітка має властивості.

4 Мітка записується іменником у початковій формі або групою іменника.

16) Дуги, що розгалужуються або об'єднуються. Мітки дуг; їх призначення та зміст. Поняття трубопроводу. Конкуренція блоків за вміст дуги. Синтаксичні правила розміщення міток на дугах вказаного типу. Тунельні дуги. Мости.

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

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

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

17) Граничні, внутрішні и зовнішні дуги. ICOM - коди і їх призначення. Область дії ICOM – кодів. Правила утворення ICOM – кодів.

Основні поняття IDEF0

1. Блок –це функціональна одиниця виробництва (функція, виробнича операція).

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

3. Імена функцій записуються усередині блоків в інфінітивній, активній формі. Дивись рис.1.

Наприклад:

Рисунок 1 – Назва функції

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

4. Кожен блок має ідентифікатор. Наприклад А21. Він записується в нижньому правому куті. Якщо блок деталізується, то він ідентифікується як вузол. Ідентифікатор вузла складається з ідентифікатора діаграми, якій належить блок і номера блоку. Буква "А” означає , що модель функціональна (activity).Наприклад: На діаграмі А2 рис.2 номер блоку 1. Тому ідентифікатор вузла буде А21.

Рисунок 2 – Дуги функції

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

Місце входу дуги визначає тип інтерфейсу.

Якщо дуга входить у блок ліворуч – вона подає вхідні дані, які оброблюються цією функцією.

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

Якщо дуга входить знизу, то вона подає механізм або людину, що виконує функцію.

Якщо дуга виходить із блоку праворуч, то це результат роботи функції.

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

6. Діаграми будуються з блоків за допомогою дуг. Діаграма – це головний компонент моделі.

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

7. Діаграма, що визначає детально яку-небудь функцію(вузол), називається діаграмою декомпозиції. Діаграма, що містить вузол, називається батьківською. Ім'я діаграми збігається з ім'ям вузла. Батьківська діаграма забезпечує контекст для діаграми декомпозиції.

Наприклад на рис.3 показана діаграма декомпозиції вузла.

Рисунок 3 – Декомпозиція вузла

8. Дуги мають текстові мітки, які записуються над дугами. Мітки записують іменником чи іменником з поясненнями. Приклад мітки подано на рис.3.

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

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

11. Вихідна дуга обов'язкова. Вихідними дугами можуть бути: інформація, продукти які виробляє функція.

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

Якби функція блоку А0 з діаграми А-0 рис.4.1 не була деталізована, то не можна було б зрозуміти взаємини входів, інформації що керує, виходів. Такі функції обов'язково деталізують. Комбінації дуг, які викликають певну дію функції називають активаціями блоку. Деталізація функції зображена на рисунку 4.2.

Рисунок 4.1 Функція з декількома режимами роботи

Рисунок 4.2 Активації функції

13. Дуги вузла називають інтерфейсом. Інтерфейси можуть відрізнятися не тільки типом, але і просто обсягом і матеріальних об'єктів чи інформації. Порядок виконання функцій діаграми не вказується явно, він залежить від обмежень(дуг). Якщо на діаграмі для декількох функцій одночасно є умови їх роботи, то вони можуть виконуватися одночасно.

Розглянемо приклад на рисунку 5. Функції „Розробити план робіт” і „Розробити документацію” з рисунку 5 можуть виконуватися одночасно, а для виконання функції „Затвердити” треба щоб спочатку виконалися функція „Розробити план робіт” і (або) „Розробити документацію”.

Рисунок 5 –Взаємини між функціями

14. За допомогою дуг і блоків на діаграмах можна показувати зворотні зв'язки між функціями, організовувати ітерації.

Дуги можуть розгалужуватися, якщо одна дуга використовується декількома функціями. Кожна гілка буде тим же самим об'єктом.

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

Керуюча дуга „файли” може бути деталізована: дуга „запис клієнтів” і „податкових таблиць”.

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

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

Блоки можуть конкурувати за інформацію. Якщо з діаграми не видно чи конкурують блоки за інформацію, чи їхні функції запускаються паралельно, то для визначення цього потрібна додаткова інформація. Така інформація може подаватисяу тексті або діаграмах FEO.

16. Для формування несуперечливої моделі необхідні додаткові відомості про модель:

- ICOM-коди дуг;

- зв'язок між діаграмами моделі (ієрархічна структура моделі);

- супровідна інформація про кожну діаграму;

- відомості про тунельні дуги на діаграмах .

ICOM – коди дуг

Назва ICOM – коди відбулося від перших літер типів дуг на діаграмі:

- I – input вхідні дуги;

- C – сontrol керуючі дуги;

- O – output вихідні дуги;

- M – mechinism дуги механізмів.

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

18) Семантика конструкції діаграма. Синтаксичні правила побудови діаграми.

Семантика діаграми

Існує два типа діаграм: діаграма А-0 і діаграма декомпозиції.

1 Діаграма А-0 містить одну функцію, що є призначенням системи.

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

3 На діаграмі зображують мету утворення моделі та точку зору на модель.

4 Діаграма декомпозиції деталізує функцію - вузол. Функції діаграми декомпозиції розкривають зміст функції – вузла.

5 Зміст вузла передається через зв'язок функцій діаграми декомпозиції за цим змістом. Зв'язок функцій діаграми декомпозиції зображується дугами.

6 Інтерфейсом вузла є дуги вузла, тому дуги вузла переносяться на діаграму декомпозиції, як прикордонні дуги.

Синтаксис діаграми

1 На діаграмі розташовують від 3 до 6 функціональних блоків. Діаграма, що містить менше 3 блоків, вважається не інформативною, а більше 6 блоків, складною для розуміння. Винятком є діаграма А-0. На ній розташований один функціональний блок.

2 Кожен функціональний блок має назву функції.

3 Кожен функціональний блок має унікальний номер.

4 Нумерація блоків починається з 1 і збільшується для кожного наступного блоку на 1. Винятком є блок на діаграмі А-0, він має номер 0.

5 Кожен функціональний блок має ідентифікатор.

6 Ідентифікатори усіх блоків складаються з ідентифікатору діаграми та номеру блоку. Винятками є ідентифікатори блоків на діаграмі А0, вони записуються А1, А2, а не А01, А02.

7 Кожен функціональний блок має хоча б одну керуючу та одну вихідну дугу.

8 До кожної сторони всіх блоків діаграми не може проводитися більше 4 дуг.

9 Всі вільні кінці дуг мають ICOM-коди або тунелі. Виняток зовнішні дуги діаграми А-0.

19) Семантика конструкції модель. Синтаксичні правила побудови конструкції - модель.

Семантика моделі

Модель подається ієрархічною структурою з діаграм і супроводжуючою інформацією: глосарієм, текстовою структурою, діаграмами FEO.

Синтаксис моделі

1 Кожен вузол діаграми IDEF0 деталізується на одній діаграмі IDEF0 і декількох діаграмах FEO. Верхній вузол моделі А0.

2 При декомпозиції вузла назва функції стає назвою діаграми декомпозиції, а ідентифікатор вузла стає ідентифікатором діаграми декомпозиції.

3 Існують діаграми рівня вище ніж А-0, А-1, А-2, тощо.

4 Взаємозв'язок між дугами вузла та прикордонними дугами діаграми декомпозиції встановлюється через ICOM-коди.

20) Поняття контексту моделі та контексту діаграми. Призначення контекстів. Приклади контекстів моделі та діаграми.

Зовнішні дуги на діаграмі А-0 визначають контекст моделі. Вони пов'язують модель з її середовищем. Діаграму А-0 із зовнішніми дугами називають контекстною діаграмою моделі. Як ми бачили, замкнені системи не мають контексту.

Контекстом діаграми декомпозиції являються функції та дуги, які розташовані разом з вузлом на батьківській діаграмі. Для функції „Виробити” на рисунку 3.12, контекстом її діаграми декомпозиції „Виробити” будуть функції „Замовити” і „Знайти” разом з їх дугами. Контекст діаграми декомпозиції „Виробити” зображується у верхньому її полі „CONTEXT”. Дивися рисунок 3.13.

 

21) Текст до діаграми; його структура; вміст; розташування. Мова посилань.

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

Текст до діаграми А-0 відносять до всієї моделі, він дає загальну характеристику всієї моделі. Текст записується у формі змістовного оповідання.

Всі текстові сторінки, структуровані так, як структурована модель. Текст роз'яснює, як досягається мета утворення моделі та точку зору розроблювача.

Текст утворювати необов'язково. Але, якщо його утворюють, то після закінчення розробки діаграми(моделі).

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

Для посилання на дугу використовують її код. Для цього дугу ідентифікують, як дуги вузла. Наприклад, перша керуюча дуга позначається С1. Ідентифікатор 4І2 означає другу вхідну дугу до блоку А4. Першу вихідну дугу блоку А2, яка стає першою вхідною дугою блоку А3 ідентифікують 2О1 до 3І1. Друге зауваження рецензента ідентифікують 2. Посилання на діаграму іншої моделі проекту може записуватися М01/А12, де М01 ідентифікатор моделі.

Приклад тексту до моделі „Профогляд”

При профоглядах різні категорії робітників підприємства проходять обстеження за своїм маршрутом. Всі категорії робітників обов'язково проходять обстеження у фахівців: терапевта, хірурга, окуліста, отоларинголога, а жінки додатково гінеколога. Робітники підприємства, що працюють на місцях з шкідливими умовами праці, обов'язково додатково обстежуються у відповідних вузьких фахівців. Додаткове обстеження робітників загальної категорії залежить від відповідей на питання анкети. Анкетування проводиться в залі анкетування і містить питання про: вік, стать, умови життя, скарги (анамнез) працівника, що обстежується. Маршрутизація працівників дозволяє збільшити пропускну здатність системи «Профогляд». Застосування автоматизованої системи «Профогляд» дозволяє швидко одержати загальну картину стану робітників підприємства, своєчасно провести лікування та профілактику.

Рисунок 3.13 - Контекст діаграми декомпозиції „Виробити”

На рисунку 3.13 блоки показують функціональні блоки батьківської діаграми та порядок розташування вузла і функцій з контексту.

22) Глосарій; структура глоссарію; його призначення. Визначення ціни та частоти виконання функцій. Форми звіту. Компіляція моделі.

Глосарій – словник, в якому визначають спеціальні терміни тексту, абревіатури, поняття графічної моделі(назви функцій, дуг). Визначення необхідні для однозначного розуміння змісту моделі. Поняття визначають через атрибути або текстом.

У середовищі DESIGN/IDEF структура глосарію утворюється автоматично для назв функцій та дуг. Означення назв вводить користувач. Наприклад медпрацівники: лікарі, медсестри, лаборанти.

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

DESIGN/IDEF дозволяє фіксувати ціну виконання та ціну утворення функцій. Визначаючи ціну виконання для функцій, що не є вузлами, можна автоматично підрахувати ціну виконання вузлів або всієї системи. Функція може виконуватися під час роботи її вузла декілька разів. Частоту виконання функції можна вказувати у глосарію. Крім того, у глосарію вказують для функцій тривалість виконання. Це дає можливість підрахувати тривалість виконання всієї системи.

23) Діаграми FEO; їх призначення. Спосіб пов‘язування IDEF0-діаграми з FEO-діаграмою.

Діаграми FEO(For Exposition Only) використовують тільки для ілюстрації деяких моментів зображених на діаграмах IDEF0. На діаграмі FEO можна подавати графіки, креслення, малюнки, тощо.

У DESIGN/IDEF є засоби прив'язки діаграм FEO до об'єктів діаграм IDEF0.

24) Дерево вузлів(Індекс моделі). Читання моделі в різних ситуаціях. Основні етапи при читанні діаграми. Правила інтерпретації змісту діаграми.

Структуру функціональної моделі можна зобразити деревом вузлів, або у вигляді змісту книги, де сторінки - діаграми. Структуру моделі називають індексом моделі або змістом моделі.

Індекс моделі використовують для читання моделі. Його зручно використовувати для першого знайомства з моделлю, для глибокого вивчення частини моделі, всієї моделі.

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

Для читання діаграми декомпозиції треба спочатку розглянути діаграму, потім розглянути вузол діаграми і визначити головний вхід, керування та вихід. Використовуючи головні дуги, знайти на діаграмі декомпозиції головний шлях – від головного входу до головного виходу. Визначити, чи є на діаграмі побічні шляхи. Ознайомитися з текстом, глосарієм, діаграмою FEO.

25) Основні етапи розробки моделі; їх характеристика.

Основні етапи розробки моделі.

1 Вибір точки зору, мети та контексту моделі.

2 Розробка контекстної діаграми А-0.

3 Розробка діаграми верхнього рівня А0.

4 Розробка діаграм декомпозиції.

5 Розробка супроводжуючого тексту, глосарію, діаграм FEO.

28) Розробка діаграми декомпозиції. Основні етапи побудови діаграми.

Вимоги до розробки діаграми декомпозиції:

- мета та точка зору діаграми повинні відповідати меті та точці зору всієї моделі;

- прикордонні дуги діаграми повинні відповідати дугам вузла на батьківській діаграмі;

- зміст діаграми повинен відповідати змісту вузла.

Утворення діаграми – індивідуальна, творча робота. Нижче подано примірний план робіт.

Діаграму можна утворювати в такому порядку.

1 Утворюють список даних, які використовуються функцією вузла, керують нею, виконують її або виробляються нею. Близькі за змістом дані об'єднують.

2 Групують список даних за принципом „із - в”, що вказує на переробку певних даних у інші дані. За кожною групою даних формують імена функцій діаграми декомпозиції та розміщують їх у блоки на діаграмі. Блоки з функціями розташовують діагоналлю від лівого верхнього кута до нижнього правого кута.

3 Креслять дуги біля кожного функціонального блоку і надають дугам імена - мітки.

4 З'єднують функції діаграми дугами природними для них зв'язками.

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

6 Перевіряють рівень деталізації дуг. Рівень деталізації дуг повинен відповідати рівню деталізації функцій. Об'єднуйте споріднені дуги, якщо потрібно.

7 Аналізують імена функцій та дуг, щоб зробити їх конкретнішими та зрозумілішими. Спеціальні терміни заносять в глосарій.

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

9 Порівнюють всі дуги зі списком даних, щоб не загубити дані.

10 Малюють остаточний варіант діаграми за правилами синтаксису.

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

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

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





Реферат на тему: Відповіді на питання з предмету "Автоматизовані інформаційні системи" (АІС) (шпора)


Схожі реферати



5ka.at.ua © 2010 - 2016. Всі права застережені. При використанні матеріалів активне посилання на сайт обов'язкове.    
.