Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Екзаменаційні питання до Моделювання та реінж.docx
Скачиваний:
7
Добавлен:
16.09.2019
Размер:
801 Кб
Скачать
☆
  1. Які стадії, етапи та/або життєві цикли створення іус та/або їх програмного забезпечення передбачено у державних та міжнародних стандартах?

В Україні діє державний стандарт на стадії створення автоматизованих систем ГОСТ 34.601-90. Існує і міжнародний стандарт на стадії життєвого циклу програмної продукції (ISO 12207:1995). Серед інструментальних CASE-систем розрізняють інтегровані комплекси інструментальних засобів для автоматизації всіх етапів життєвого циклу ПЗ (такі системи називають Workbench) і спеціалізовані інструментальні засоби для виконання окремих функцій (Tools). Найчастіше використовується низхідний стиль блочно-ієрархічного проектування. Розглянемо етапи низхідного проектування АС. Верхній рівень проектування АС часто називають рівнем концептуального проектування. Концептуальне проектування виконують в процесі передпроектних досліджень, формулювання ТЗ, розробки ескізного проекту та прототипування (згідно з ГОСТ 34.601-90, ці стадії називають формуванням вимог до АС, розробкою концепції АС і ескізним проектом).

  1. Які типи моделей використовуються при проектуванні іус?

У структурному аналізі використовуються в основному дві групи засобів, що ілюструють функції, виконувані системою і відносини між даними. Кожній групі засобів відповідають певні види моделей (діаграм), найбільш поширеними серед яких є наступні [2,7,10]:

• SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми;

• DFD (Data Flow Diagrams) діаграми потоків даних;

• ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок".

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

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

  1. Наведіть класифікацію та охарактеризуйте типи зв’язків між функціями в SADT-моделях.

Щоб бути корисним, опис будь-якого блоку повинен, як мінімум, включати опис об'єктів, які блок створює в результаті своєї роботи ("виходу"), і об'єктів, які блок споживає або перетворює ("вхід").

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

I (Input) — вхід: те, що споживається в ході виконання

процесу;

C (Control) — управління: обмеження і інструкції, що впливають на хід виконання процесу;

O (Output) — вихід: щось, що є результатом виконання процесу;

М (Mechanism) — виконуючий механізм: щось, що використовується для виконання процесу, але не споживається саме по собі. Рис. 2.3 показує 4 можливих типу стрілок в IDEF0, кожний з типів з'єднується з своєю стороною функціонального блоку.

SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми;

Найбільш відомою методикою функціонального проектування складних систем є методика SADT (Structured Analysis and Design Technique), запропонована в 1973 р. Р. Россом і згодом стала основою міжнародного стандарту IDEF0 (Integrated DEFinition 0).

  1. Охарактеризуйте сукупність методик IDEF для концептуального проектування ІУС.

IDEF - методології сімейства ICAM (Integrated Computer-Aided Manufacturing) для вирішення завдань моделювання складних систем, дозволяє відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними. IDEF - методології створювалися в рамках запропонованої ВВС США програми комп'ютеризації промисловості - ICAM, в ході реалізації якої виявилася потреба в розробці методів аналізу процесів взаємодії у виробничих (промислових) системах. Принциповою вимогою при розробці даного сімейства методологій була можливість ефективного обміну інформацією між всіма фахівцями - учасниками програми ICAM (звідси назва: Icam DEFinition - IDEF інший варіант - Integrated DEFinition). Після опублікування стандарту він був успішно застосований в самих різних областях бізнесу, показавши себе ефективним засобом аналізу, конструювання і відображення бізнес-процесів (до слова сказати, він активно застосовується і в російських держструктурах, наприклад в Державній Податковій Інспекції). Більше того, власне з широким застосуванням IDEF (і попередній методолoгіі - SADT) і зв'язано виникнення основних ідей популярного нині поняття - BPR (бізнес-процес реінжиніринг). Сімейство стандартів На даний момент до сімейства IDEF можна віднести такі стандарти:     IDEF0 - Function Modeling - методологія функціонального моделювання. За допомогою наглядного графічного мови IDEF0 досліджувана система постає перед розробниками та аналітиками у вигляді набору взаємозалежних функцій (функціональних блоків - у термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомого графічного мови опису функціональних систем SADT (Structured Analysis and Design Technique);     IDEF1 - Information Modeling - методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їх структуру і взаємозв'язки;     IDEF1X (IDEF1 Extended) - Data Modeling - методологія побудови реляційних структур (баз даних), відноситься до типу методологій «Сутність-взаємозв'язок» (ER - Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до розглянутої системі;     IDEF2 - Simulation Model Design - методологія динамічного моделювання розвитку систем. У зв'язку з вельми серйозними складнощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток призупинився на самому початковому етапі. В даний час присутні алгоритми та їх комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 у динамічні моделі, побудовані на базі «розфарбованих мереж Петрі» (CPN - Color Petri Nets);     IDEF3 - Process Description Capture - Документування технологічних процесів,     IDEF3 - методологія документування процесів, що відбуваються в системі (наприклад, на підприємстві), описуються сценарій та послідовність операцій для кожного процесу. IDEF3 має пряму взаємозв'язок з методологією IDEF0 - кожна функція (функціональний блок) може бути представлена ​​у вигляді окремого процесу засобами IDEF3;