Билет №25

1. Правила та способи декомпозиції. Робочі потоки

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

Для снижения сложности используют принцип декомпозиции.

Правила декомпозиции:

1 При правильной декомпозиции количество связей должно быть имитационным.

2. Связность подсистемы должна быть макс.

3.Каждая подсистема должна обладать интерфейсом, интерфейс должен быть дружественным и однозначно отображать протекание процессов, не должен ограничивать права пользования:

Способы декомпозиции: функционально-модульный/структурный и объектно-ориентированный

Рабочие потоки – определяют набор артефактов(мн-ва вещественных событий, которые реализуются искусственно, т.е. человеком)

В состав каждой итерации входят все рабочие потоки:

- сбор требований

- анализ

- вычислительные процессы

- тестирование

Рабочие потоки системы имеют следующее содержимое:

- сбор требований

- анализ и преобразование требований к системе, выделение классов, объектов, которые относятся к ПО

- проектирование реализация, создание статического (системы, эскизное представление) + динамического (необходимая привязка ко времени) представления

- реализация – построение программного кода

- тестирование {A(оп)}={A(ср)}

2. Наведіть основні результати та критично проаналізуйте побудову та результати досліджень моделей по нотації dfd

Д іаграми потоків даних (Data Flow Diagrams) представляють мережу зв'язаних між собою робіт. Їх зручно використовувати для опису документообігу й обробки інформації. Для побудови діаграм DFD в BPwin використовується нотація Гейна-Сарсона (таблиця 1).

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

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

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

Кожний процес повинен мати унікальний номер для посилань на нього усередині діаграми. Цей номер може використовуватися разом з номером діаграми для одержання унікального індексу процесу у всій моделі.

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

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

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

Діаграми DFD можна використовувати як доповнення до діаграм IDEF0 для опису документообігу й обробки інформації.

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

Альтернативним підходом є підхід, популярний при створенні програмного забезпечення, який називається подійним поділом (event partitioning), у якому різні діаграми DFD будують модель системи. По-перше, логічна модель будується як сукупність робіт і документування того, що вони (ці роботи) повинні робити.

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

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

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

Нумерація об'єктів. В DFD номер кожної роботи може включати префікс, номер батьківської роботи (А) і номер об'єкта. Номер об'єкта - це унікальний номер роботи на діаграмі. Наприклад, робота може мати номер А.12.4. Унікальний номер мають сховища даних і зовнішні сутності незалежно від їхнього розташування на діаграмі. Кожне сховище даних має префікс D і унікальний номер, наприклад D5. Кожна зовнішня сутність має префікс Е и унікальний номер, наприклад Е5.

3 Методы системного анализа

Классы методов

1) строгоформализованные

• методы классической математики(диф. исчислесния, анализы экстремумов)

• методы стохастической математики(методы динамики + вероятностные процессы +время)

• методы дискретной математики(предикаты 1,2,n - порядков(n - местный предикат - предикат,кот. зависит от своих составляющих)

• методы оптимизации (линейное/нелинейное программирование)

2) методы, направленныена формализацию

• метод построения модели

• планирование и проведение эксперимента

3)слабоформализованные

• экспертные оценки

• социологические исследования

• нечеткая логика и теория нечетких мн-в->работает эксперт

• субоптимизационные методы

4) неформализованные методы(методы,направленные на творческое начало,на них держится проектирование при выборе систем):

• формулировка проблемы(вербальное изложение)

• выявление и выбор целей системы

• разбивка и выбор целей системы + критерии различных уровней

• генерированные альтернативы (интернет - ресурсы и др. сетевые ресурсы)

• морфологический анализ(рассматривает составные части и их взаимодействие)