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


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

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



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

Малюнок 7.9.2. Рівні зв'язку між компонентами.

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

Прозорість

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

· Представлення реальності

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

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

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

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

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

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

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

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

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

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

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

Повинні бути враховані такі вимоги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Покращений документ з описом вимог

· Покращена модель

· Специфікації проекту, які містяться в словнику даних

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

o класові діаграми

o зв'язки об'єкту

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

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

o глосарій:

§ класових визначень

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Зміст

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

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

ЧастинаI – Загальний опис

Вступ:

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

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

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

· Визначення, акроніми, абревіатури.

· Посилання.

Основні положення.

2. Стандарти, правила і порядок здійснення дій проекту:

· Стандарти проекту

· Стандарти документа

· Термінологія

· Стандарти програмування

· Засоби розробки ПЗ



Поделиться:


Последнее изменение этой страницы: 2017-02-07; просмотров: 114; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 50.17.63.57 (0.005 с.)