Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Моделювання потоків даних.
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Лабораторна робота
Предмет:
Системний аналіз
Частина тексту файла (без зображень, графіків і формул):
Моделювання потоків даних
В основі цієї методології лежить побудова моделі аналізованої ІС - проектованої або реально існуючої. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних (ДПД або DFD), що описують асинхронний процес перетворення інформації від її введення у систему до видачі користувачу. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС із зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція продовжується, створюючи багаторівневу ієрархію діаграм, доти, поки не буде досягнутий такий рівень декомпозиції, на якому процеси стають елементарними і деталізувати їх далі неможливо.
Джерела інформації (зовнішні сутності) породжують інформаційні потоки (потоки даних), що переносять інформацію до підсистем або процесів. Ті у свою чергу перетворюють інформацію і породжують нові потоки, які переносять інформацію до інших процесів або підсистем, нагромаджувачів даних або зовнішніх сутностей - споживачам інформації. Таким чином, основними компонентами діаграм потоків даних є:
зовнішні сутності;
системи/підсистеми;
процеси;
нагромаджувачі даних;
потоки даних.
Рис. 1 Приклад ДПД
1. Зовнішні сутності
Зовнішня сутність є матеріальним предметом або фізичною особою, яка виступає джерелом або приймачем інформації, наприклад, замовники, персонал, постачальники, клієнти, склад тощо. Визначення деякого об'єкту або системи як зовнішня сутність вказує на те, що вона знаходиться за межами аналізованої ІС. У процесі аналізу деякі зовнішні сутності можуть бути перенесені всередину діаграми аналізованої ІС, якщо це необхідно, або, навпаки, частина процесів ІС може бути винесена за межі діаграми і представлені як зовнішні сутності.
Зовнішня сутність позначається квадратом (рис. 2), який розташовується над діаграмою і відкидає на неї тінь, для того, щоб можна було виділити цей символ серед інших позначень:
Рис. 2 Зовнішня сутність
2. Системи і підсистеми
При побудові моделі складної ІС вона може бути представлена у найзагальнішому вигляді на так званій контекстній діаграмі у вигляді однієї системи як єдиного цілого, або може бути декомпонована на низку підсистем.
Підсистема (або система) на контекстній діаграмі зображається наступним чином (рис. 3).
Рис. 3 Підсистема
Номер підсистеми служить для її ідентифікації. У полі імені вводиться назва підсистеми у вигляді речення з підметом і відповідними визначеннями і доповненнями.
3. Процеси
Процес є перетворенням вхідних потоків даних у вихідні відповідно до певного алгоритму. Фізично процес може бути реалізований різними способами: це може бути підрозділ організації (відділ), що виконує обробку вхідних документів і випуск звітів, програма, апаратно реалізований логічний пристрій тощо.
Процес на діаграмі потоків даних зображається, як показано на рис. 4.
а) б)
а)Нотація процесу за Gane and Sarson
б) Нотація процесу за Yourdon and Coad
Рис. 4 Процес
Номер процесу служить для його ідентифікації. У полі імені вводиться назва процесу у вигляді речення з активним недвозначним дієсловом у невизначеній формі (обчислити, розрахувати, перевірити, визначити, створити, отримати), за яким іде іменники в знахідному відмінку, наприклад:
"Ввести відомості про клієнтів";
"Видати інформацію про поточні витрати";
"Перевірити кредитоспроможність клієнта".
Використовування таких дієслів, як "обробити", "модернізувати" або "відредагувати" означає, як правило, недостатньо глибоке розуміння даного процесу і вимагає подальшого аналізу.
Інформація у полі фізичної реалізації показує, який підрозділ організації, програма або апаратний пристрій виконує даний процес.
4. Нагромаджувачі даних
Нагромаджувач даних є абстрактним пристроєм для зберігання інформації, яку можна у будь-який момент помістити у нагромаджувач і через деякий час витягнути, причому способи розміщення і витягання можуть бути будь-якими.
Нагромаджувач даних може бути реалізований фізично у вигляді мікрофіші, шухляди у картотеці, таблиці в оперативній пам'яті, файлу на магнітному носії тощо. Нагромаджувач даних на діаграмі потоків даних зображається, як показано на рис. 5.
Рис. 5 Нагромаджувач даних
Нагромаджувач даних ідентифікується буквою "D" і довільним числом. Назва нагромаджувача вибирається із міркування найбільшої інформативності для проектувальника.
Нагромаджувач даних у загальному випадку є прообразом майбутньої бази даних і опис даних, які зберігаються у ньому повинен бути пов'язаний із інформаційною моделлю.
5. Потоки даних
Потік даних визначає інформацію, яка передається через деяке з'єднання від джерела до приймача. Реальний потік даних може бути інформацією, яка передається по кабелю між двома пристроями, листами, що пересилаються поштою, магнітними стрічками або дискетами, які переносяться з одного комп'ютера на іншій тощо.
Потік даних на діаграмі зображається лінією, що закінчується стрілкою, яка показує напрямок потоку (рис. 6). Кожний потік даних має назву, що відображає його зміст.
Рис. 6 Потік даних
6. Побудова ієрархії діаграм потоків даних
Першим кроком при побудові ієрархії ДПД є побудова контекстних діаграм. Звичайно при проектуванні простих ІС будується єдина контекстна діаграма із зіркоподібною топологією, у центрі якої знаходиться так званий головний процес, який сполучений із приймачами і джерелами інформації, за допомогою яких з системою взаємодіють користувачі та інші зовнішні системи.
Якщо ж для складної системи обмежитися єдиною контекстною діаграмою, то вона міститиме дуже велику кількість джерел і приймачів інформації, які важко розташувати на листі паперу нормального формату, і крім того, єдиний головний процес не розкриває структури розподіленої системи. Ознаками складності (у значенні контексту) можуть бути:
наявність великої кількості зовнішніх сутностей (десять і більше);
розподілена природа системи;
багатофункціональність системи із групою функцій, яка вже склалася або виявлеою, в окремі підсистеми.
Для складних ІС будується ієрархія контекстних діаграм. При цьому контекстна діаграма верхнього рівня містить не єдиний головний процес, а набір підсистем, сполучених потоками даних. Контекстні діаграми наступного рівня деталізують контекст і структуру підсистем.
Ієрархія контекстних діаграм визначає взаємодію основних функціональних підсистем проектованої ІС як між собою, так і з зовнішніми вхідними і вихідними потоками даних і зовнішніми об'єктами (джерелами і приймачами інформації), з якими взаємодіє ІС.
Розробка контекстних діаграм вирішує проблему строгого визначення функціональної структури ІС на першій стадії її проектування, що особливо важливо для складних багатофункціональних систем, у розробці яких беруть участь різні організації і колективи розробників.
Після побудови контекстних діаграм отриману модель необхідно перевірити на повноту початкових даних про об'єкти системи та ізольованість об'єктів (відсутність інформаційних зв'язків з іншими об'єктами).
Для кожної підсистеми, присутньої на контекстних діаграмах, виконується її деталізація за допомогою ДПД. Кожний процес на ДПД, у свою чергу, може деталізуватися за допомогою ДПД або мініспецифікації. При деталізації повинні виконуватися наступні правила:
правило балансування - означає, що при деталізації підсистеми або процесу деталізуюча діаграма у ролі зовнішніх джерел/приймачів даних може мати тільки ті компоненти (підсистеми, процеси, зовнішні сутності, нагромпджувачі даних), з якими має інформаційний зв'язок підсистема або процес на батьківській діаграмі;
правило нумерації - означає, що при деталізації процесів повинна підтримуватися їхня ієрархічна нумерація. Наприклад, процеси, що деталізують процес з номером 12, одержують номери 12.1, 12.2, 12.3 і т.д.
Мініспецифікація (опис логіки процесу) повинна формулювати його основні функції так, щоби у подальшому фахівець, що виконує реалізацію проекту, зміг їх виконати або розробити відповідну програму.
Мініспецифікація є кінцевою вершиною ієрархії ДПД. Рішення про завершення деталізації процесу і використання мініспецифікації ухвалюється аналітиком виходячи з таких критеріїв:
наявність у процесу відносно невеликої кількості вхідних і вихідних потоків даних (2-3 потоки);
можливості опису перетворення даних процесом у вигляді послідовного алгоритму;
виконання процесом єдиної логічної функції перетворення вхідної інформації у вихідну;
можливості опису логіки процесу за допомогою мініспецифікації невеликого об'єму (не більше 20-30 рядків).
При побудові ієрархії ДПД переходити до деталізації процесів слід тільки після визначення змісту всіх потоків і нагромаджувачів даних, який описується за допомогою структур даних. Структури даних конструюються з елементів даних і можуть містити альтернативи, умовні входження і ітерації. Умовне входження означає, що даний компонент може бути відсутній у структурі. Альтернатива означає, що в структуру може входити один з перерахованих елементів. Ітерація означає входження будь-якої кількості елементів у вказаному діапазоні. Для кожного елемента даних може вказуватися його тип (безперервні або дискретні дані). Для безперервних даних може вказуватися одиниця вимірювання (кг, см тощо), діапазон значень, точність уявлення і форма фізичного кодування. Для дискретних даних може вказуватися таблиця допустимих значень.
Після побудови закінченої моделі системи її необхідно верифікувати (перевірити на повноту і узгодженість). У повній моделі всі її об'єкти (підсистеми, процеси, потоки даних) повинні бути детально описані. Виявлені об'єкти, які не деталізуються, слід деталізувати, повернувшись на попередні кроки розробки. В узгодженій моделі для всіх потоків даних і нагромаджувачів даних повинно виконуватися правило збереження інформації: всі дані які поступають куди-небудь повинні бути прочитані, і всі прочитані дані повинні бути записаний.
Проект “Система керування Бібліотекою”
Функціональна діаграма (ФД):
Функціональна діаграма використовується, щоб показати розроблювані функції системи, процес реалізації діаграми даних. Крім того, функціональна діаграма використовуватиметься для визначення частоту появи меншого процесу у ДПД. Якщо протягом побудови функціональної діаграми аналітики виявлять нові функції, їм потрібно визначити, чи буде правильно нехтувати виявлені функції. Це необхідно, щоб у найкращий спосіб вирішити питання додавання або виключення функції. Функціональний аналіз за допомогою інструментів моделювання забезпечує важливі деталі, які часто використовуватимуться на пізніших стадіях аналізу. ФД допомагає аналітикам чіткіше зрозуміти системні вимоги за допомогою детального опису роботи, інформаційною обробкою і процесом обміну, входами і виходами кожної функції. Проте, необхідно зауважити, що функціональний підхід не є всестороннім підходом. Функціональна діаграма тільки показує, що робити, а не як робити. У функціональній діаграмі, функція ділиться на багато менших функцій і кожна менша функція містить багато дрібніших функцій. Побудова діаграми полягає у процесі поділу, від вищої функції до необхідних менших функцій. Діаграми потрібно представляти чітко, просто, точно, повністю і збалансовано. Функція того ж рівня має мати той самий рівень сткладності, що і решта на цьому рівні.
В даному прикладі діаграма ієрархії функції показана нижче:
1. Діаграма потоку даних: опис інформаційного потоку у системі
Наступний крок аналізу системи є вирішення у деталях, яка інформація є необхідною для втілення розглянутих вище функцій і також для покращення цих функцій. Для цих цілей як знаряддя моделювання часто застосовуються діаграми потоків даних. Діаграма потоків даних підтримує 4 головних види діяльності:
Аналіз: ДПД використовується для визначення вимог користувачів.
Поектування: ДПД використовується для визначення і оформлення плану та відображення рішень для аналітика та корстувача у процесі проектування нової системи.
Комунікування: Однією із сильних сторін ДПД є простота та легкість у розумінні аналітиками і користувачами;
Документи: ДПД використовуються для оформлення спеціального опису вимог і проектування системи. ДПД надає огляд ключових функціональних компонент системи, але не представляє жодних деталей цих компонент. Необхідно використовувати інші засоби, такі як словник даних, специфікацію процесів для отримання поняття про те якою інформацією будемо обмінюватися і як.
Словник даних є організованим переліком всіх елементів даних, причетних до системи, із точними, строгими визначеннями, такими що як користувач так і системний аналітик матимуть спільне розуміння всіх входів, виходів, компонентів нагромаджувачів, і проміжних обчислень. Словник баз даних визначає елементи даних наступним чином:
Опис значення потоків і нагромаджувачів, показаних у ДПД;
Опис композиції складуваних пакетів даних, що переміщаються уздовж потоків;
Опис композиції пакетів даних у нагромаджувачах;
Конкретизація доречних значень і одиниць елементарних частин інформації в потоках даних і нагромаджувачах даних.
Опис деталей взаємин між нагромаджувачами, які використовуватимуться у діаграмі сутність-зв’язок (ER-діаграма).
Аналіз системи може гарантувати, що словник є повним, послідовний, і несуперечливим. Системний аналітик також може аналізувати cловник і формулювати наступні запитання:
Чи кожний потік даних на ДПД був визначений у словнику баз даних?
Чи всі компоненти складених елементів даних є визначиними?
Чи якийсь елемент даних був визначилося більше одного разу?
Чи було правильно використано нотації (позначення) для всього словника баз даних?
Чи є якісь елементи даних в словнику баз даних які не використовуються в функціональних діаграмах, діаграмах потоку даних, або сутність-зв’язок (ER-діаграма).
Побудова словника баз даних є одним з найважлививіших аспектів системного аналізу і забирає дуже багато часу. Але, без формального словника, який визначає значення всіх термінів, не може бути жодної надії на точністі.
Специфікація процесу:
Існує велика кількість інструментів, які можна використовувати для проведення специфікації процесу: таблиці рішення, структурована англійська, перед/пост умови, календарні графіки процесу (flowcharts) тощо. Все найбільше використовування аналітиків систем, структуроване англійський. Можна використовувати будь-який метод, доки він задовольняє дві важливі вимоги:
Специфікація процесу повинна виражатися у формі, яка може перевірятися споживачем і системними аналітиками;
Специфікація процесу повинна виражатися у формі, яка може дієво використовуватися із різними залученими у проект фахівцями.
Специфікація процесу відображає найбільшу кількість деталізованої роботи в побудові моделі системи. Через об’єм витраченої роботи, можна розглянути підхід до виконання “згори – вниз”: розпочати проект і етап реалізації проекту раніше закінчення оформлення специфікації всіх процесів.
Дії по написанню специфікацій процесу вважаються перевіркою вже розроблених ДПД.
ДПД можна описати наступним чином:
Які функції повинні виконуватися системою?
Взаємодія між функціями?
Що системі доведеться передавати?
Які входи передаються і до яких виходів?
Який вид роботи виконує система?
Звідки система одержує інформацію для функціонування?
Куди система передає отримані результати?
ДПД вищого рівня
ДПД (Функція 1)
ДПД (Функція 2)
ДПД (Функція 3)
ДПД (Функція 4)
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора