1. Модуль

Це активний компонент програми, тобто процедура або функція (або і те, і інше).

Рис. 1.6. Приклад модуля.

2. Виклик

Виклик - це дія, розпочата модулем, який є підмодулем.

Рис. 1.7. Виклик модуля іншим модулем.

3. Модуль бібліотеки

Це готова процедура або функція, яка використовується в системі.

Рис. 1.8. Приклад модуля бібліотеки.

4. Дані

Це відношення в базі даних, файлів або змінних в програмі.

Рис. 1.9. Дані.

5. Прапорці потоку даних

Виклик, пов'язаний з потоком даних від модуля запиту до викликаного модуля і навпаки. Перший відповідає параметрам вводу, останній - параметрам виводу.

Рис. 1.10. Прапорці потоку даних.

Рис. 1.11. Використання даних.

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

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

Високорівневий модуль, який є джерелом даних, викликає модуль нижчого рівня, який є одержувачем даних.

Рис. 1.12. Структурні діаграми проти DFD.

Складова організації даних

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

Постійне зберігання даних виконане в:

• файлах;

• базі даних (зв'язаній, об’єктно - орієнтованій або інший).

Специфічні елементи даних у формі об'єктів або точної копії можуть бути збережені в одній з форм:

• у одному зв'язаному файлі;

• у окремому файлі для кожного типу об'єктів.

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

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

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

Таким чином, файлові системи замінені базами даних. Бази даних - системи, розроблені для зберігання, доступу і управління даними.

База даних характерна постійним зберіганням, обмеженим об'ємом і хорошою організацією.

1. Постійність

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

2. Обмеження баз даних

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

3. Послідовність бази даних

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

4. Зв'язок з реальністю

Цей постулат є критичним у формулюванні вимоги для бази даних. Наприклад, якщо база даних описує тотожність, тобто ім'я, прізвище, адресу, положення і т.д., послідовність означає, що дані зміняться згідно тільки реальним змінам, тобто положення міняється, якщо службовець отримує заохочення. Бази даних повинні оновлюватися згідно з фактичними даними. Якісні зв’язки – це нелегке завдання. Бізнес не може бути повністю комп'ютеризовано. Людина – важливий компонент системи. Процедури повинні розроблятися ретельно і людський фактор повинен бути врахований в системі. Спосіб відправки інформації повинен бути описаний в процедурах. Оновлення даних – одна з найважчих проблем, зокрема, коли є багато баз даних і багато систем в компанії. Таким чином виконується відповідна інтеграція систем (підсистем) в модулі і обмін даними виконується модулями.

5. Приклад реалізації

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

6. Контроль копіювання даних

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

7. Складена модель даних

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

8. Доступність даних

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

9. Безпека даних

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

10. Критерії відбору системи управління базами даних (СУБД)

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

Найважливіші критерії відбору СУБД:

1. Продуктивність

Продуктивність описує швидкість реакції на запити і кількість обслуговуваних завдань.

2. Масштабованість

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

3. Функціональність

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

4. Узгодження із стандартами

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

5. Зручність і простота використання

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

6. Надійність

Надійність позначає частоту відмов. Чим вища надійність - тим вища вартість. Таким чином, повинне бути виконане балансування надійності (або потреба зупинки роботи) і витрат.

7. Підтримка

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

8. Середовище розробки

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

9. Вартість

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

10. Реляційна база даних

Більш загальні бази даних на ринку – реляційні бази даних.

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

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

На рис. 1.13. показано об'єктно-орієнтовану зразкову і реляційну модель для однієї системи. Об'єктно-орієнтована модель ясніша.

Рис. 1.13. Неузгодженість об'єктно-орієнтованої зразкової і реляційної моделі.

Незручність в застосуванні реляційної моделі – також неузгодженість інтерфейсу доступу (наприклад, до SQL) і до мови програмування (наприклад, C++). Цю неузгодженість називають неузгодженістю імпедансу.

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

Оптимізація проекту

Буквальна і прямолінійна реалізація може призвести до дуже низької ефективності системи.

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

Для оптимізації роботи системи застосовуються наступні методи:

• використання статичних змінних замість динамічних;

• застосування вкладеного коду замість процедур, що викликаються;

• вибір типів з мінімальними величинами.

Ці методи можуть призвести до менш зрозумілого коду замість його оптимізації. Обробка помилок може стати складнішою або неможливою.

Кориснішим було б проведення оптимізації ще на етапі дизайну або навіть аналізу.

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

Ще одним важливим моментом в знаходженні вузьких місць і обережному поводженню з ними є розуміння процедур. Загальновідомо, що 20% коду займає 80% часу виконання. Затримки можуть бути усунені шляхом написання часто вживаних функцій на мовах низького рівня, наприклад, C.

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

Оптимізація повинна бути пов'язана з аналізом буферизації в пам'яті та розглядом різних рівнів буферизації.

Обмеження середовища реалізації

Розробник може зустріти багато обмежень в ході реалізації.

Типовими обмеженнями в переході від аналітичної моделі до моделі реалізації є:

• відсутність множинного наслідування;

• відсутність наслідування;

• відсутність віртуальних методів;

• відсутність складних атрибутів;

• відсутність мультимедійних типів.

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

Рис. 1.14. Приклад подолання множинного спадкоємства.

Фізична структура системи

Одне із завдань етапу проектування – описати фізичну структуру системи.

Вона включає:

• Опис структури початкового коду, тобто визначення початкових файлів, їх взаємозв'язків і знаходження компонентів.

• Декомпозиція системи на конкретні програми.

• Фізичний розподіл даних і програм.

Рис. 1.15. Позначення фізичної структури (Booch).

Рис. 1.16. Графічний опис структури апаратури.

Правильність і якість проекту

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

Правильний проект повинен бути:

• завершеним;

• сумісним;

• узгодженим;

• повинна зберегтися семантика позначень.

Рис. 1.17. Приклад компіляції в C++.

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

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

Правильність класу і діаграм станів

Всі діаграми проекту повинні бути верифіковані.

У верифікації діаграм класів потрібно враховувати наступне:

• ациклічні відносини узагальнення-спеціалізації;

• варіанти відносин циклічного об'єднання;

• класи, що не мають відношення до інших класів, не повинні бути включені. Але іноді таке трапляється;

• введення в специфікацію методів, що мають відношення до вводу, виводу і специфікації результату.

Якість системи

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

Узгодженість

Узгодженість описує ступінь відповідності частин системи один одному і взаємини операцій. Критерії декомпозиції дуже важливі. Вони визначають вид узгодженості.

Критерії декомпозиції

1. Випадкова декомпозиція. Розділення на модулі відбувається із-за неможливості охопити всю систему в різних завданнях.

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

3. Часова декомпозиція. Компоненти працюють в однаковий час.

4. Послідовна декомпозиція. Компоненти працюють в певній

послідовності. Вихідні дані одного компоненту є вхідними для іншого.

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

Рівні зв'язку компонентів

У хорошому проекті зв'язки між компонентами повинні бути слабкі. Це визначає декомпозицію проекту на частини, а ПЗ - на модулі.

Рис. 1.18. Рівні зв’язку компонентів.

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

Прозорість

Якісний проект повинен бути прозорим, тобто чітким і легким для розуміння.

Прозорість визначають наступні чинники:

– Відображення реальності;

– Компоненти і їх зв’язки повинні відображати структуру системи.

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

Узгодженість і рівень зв’язків компонентів

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

Зрозуміла термінологія

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

Зрозуміла і повна специфікація

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

Відповідна складність компонентів на кожному рівні

Застосування наслідування і методів в класах спрощує розуміння проекту.

Нефункціональні вимоги на етапі проектування

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

Необхідно врахувати наступні групи вимог:

1. Вимоги до робочих характеристик.

2. Вимоги до інтерфейсу (протоколи, формати файлів).

3. Експлуатаційні вимоги.

4. Вимоги до ресурсів (число процесорів, об'єм вінчестера).

5. Контрольні вимоги.

6. Тестові вимоги.

7. Вимоги документування.

8. Вимоги безпеки.

9. Вимоги портативності.

10. Вимоги якості:

    1. підбір методу проектування;

    2. можливість повторного використання;

    3. підбір інструментів;

    4. можливість зовнішнього доступу.

11. Вимоги по надійності.

12. Інструкція по технічному обслуговуванню.

13. Можливість усунення відмов або несправностей.

Результати етапу проектування

Основними результатами на етапі проектування є:

• Удосконалений документ з описом вимог.

• Удосконалена модель.

• Специфікації проекту, які є в словнику даних.

• Опис проекту, що містить (у разі об'єктно-орієнтованого підходу):

• діаграми класів;

• зв’язки об’єкту;

• структурні зв'язки ;

• модульні діаграми;

• глосарій:

• визначення класів;

• визначень атрибутів;

• визначення комплексних і елементарних даних;

• визначення методів.

72. Ресурси інтерфейсу для меню, діалогів.

73. База даних проекту.

74. Структура фізичної системи проекту.

75. Виконання розкладу.

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

Продукт повинен бути перевірений і верифікований командою програмістів та протестований зі всіх можливих сторін.

Детальний документ проекту

Модель проекту повинна бути записана в документі під назвою «Детальний Документ Проекту» (ДДП).

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

Організація інформації

1. Короткий звіт.

2. Зміст .

3. Статус документа.

4. Опис змін порівняно з минулою версією.