- •Поняття пз
- •Поняття трпз
- •К ласифікація методів проектування пп
- •Класичний життєвий цикл
- •Макетування
- •Стратегії конструювання пз
- •Інкрементна модель конструювання пз
- •Кодування.
- •Тестування.
- •Модель швидкої розробки додатків rad
- •Спіральна модель конструювання пз
- •Компонентно-орієнтована модель конструювання пз
- •Важковагові та полегшені процеси
- •Xp процес
- •4 Базові дії:
- •Кодування.
- •Тестування.
- •Робота з замовником.
- •Проектування.
- •Моделі якості процесів конструювання пз
- •Процес керування проектом
- •Планування проектних задач
- •Розмірно-орієнтовані метрики (ром)
- •Функціонально-орієнтовані метрики (фом)
- •Коефіцієнти Fi
- •Виконання оцінки проекту на основі loc та фп метрик
- •Конструктивна модель вартості
- •Модель композиції додатку
- •Модель раннього етапу проектування
- •Модель етапу послідовної архітектури
- •Класичні методи аналізу
- •1. Послідовна
- •3. Ітерація
- •Надійні динамічні системи
- •Основи проектування програмних систем
- •Супровід.
- •Проектування
- •Кодування
- •Тестування
- •Декомпозиція підсистем на модулі
- •Модульність
- •Інформаційна закритість
- •Зв'язність модуля
- •Визначення зв'язності модуля
- •Зчеплення модулів
- •Класичні методи проектування
- •1. Метод структурного проектування
- •2. Проектування для потоку даних типу «запит»
- •Основні поняття та принципи тестування
- •Структурне тестування
- •1. Спосіб тестування базового шляху.
- •2. Спосіб тестування умов
- •3. Тестування циклів
- •Функціональне тестування
- •1. Спосіб розбиття по еквівалентності
- •2. Спосіб аналізу граничних значень
- •3. Спосіб діаграм причин-наслідків
- •3Ауважння:
- •Організація процесу тестування пз
- •1. Методика тестування програмних систем
- •2. Тестування елементів
- •3. Тестування інтеграції
- •Спадне тестування інтеграції
- •Зростаюче тecтування інтеграції
- •Порiвияиня спадного I зростаючого тестування інтеграції
- •4. Тестування правильності
- •5. Системне тестування
- •Основні принципи об’єктно-орієнтованої методології розробки програмної системи (оом пс)
- •Об’єкти та класи
- •ОоАналіз
- •1999Р. Березень-липень uml 1.3
- •Діаграма варіантів використання (use case diagram)
- •Діаграма класів (Class diagram)
- •Послідовна
- •Паралельна
- •2. Асоціації:
- •Діаграма станів (Statechart diagram)
- •Діаграма діяльності (Activity diagram)
- •Діаграма послідовності (Sequence diagram)
- •Діаграма кооперації (Collaboration diagram)
- •Діаграма компонентів (Component diagram)
- •Діаграма розгортування (Deployment diagram)
- •Особливості реалізації мови uml у середовищі Rational Rose
- •Головне меню
- •Вікно діаграми
- •Стандартна пі
- •Уніфікований процес компанії Rational Rose
- •3 Неправильних підходи до розробки пз
- •Водоспадний процес
- •Спрощений процес системного проектування
- •Автоматичний підхід та швидке макетування
Визначення зв'язності модуля
Приведемо алгоритм визначення рівня зв'язності модуля.
1. Якщо модуль — одинична проблемно-орієнтована функція, то рівень зв'язності — функціональний; кінець алгоритму. Інакше перейти до пункту 2.
2. Якщо дії усередині модуля зв'язані, то перейти до пункту 3. Якщо дії усередині модуля ніяк не зв'язані, то перейти до пункту 6.
3. Якщо дії усередині модуля зв'язані даними, то перейти до пункту 4. Якщо дії усередині модуля зв'язані потоком управління, перейти до пункту 5.
4. Якщо порядок дій усередині модуля важливий, то рівень зв'язності — інформаційний. Інакше рівень зв'язності — комунікативний. Кінець алгоритму.
5. Якщо порядок дій усередині модуля важливий, то рівень зв'язності — процедурний. Інакше рівень зв'язності — тимчасовою. Кінець алгоритму.
6. Якщо дії усередині модуля належать до однієї категорії, то рівень зв'язності — логічний. Якщо дії усередині модуля не належать до однієї категорії, то рівень зв'язності — по збігу. Кінець алгоритму.
Можливі складніші випадки, коли з модулем асоціюються декілька рівнів зв'язності. У цих випадках слід застосовувати одне з двох правив:
правило паралельного ланцюга. Якщо всі дії модуля мають декілька рівнів зв'язності, то модулю привласнюють найсильніший рівень зв'язності;
правило послідовного ланцюга. Якщо дії в модулі мають різні рівні зв'язності, то модулю привласнюють найслабкіший рівень зв'язності.
Наприклад, модуль може містити деякі дії, які зв'язані процедурно, а також інші дії, зв'язкові по збігу.В цьому випадку застосовують правило послідовного ланцюга і в цілому модуль вважають зв'язним по збігу.
Зчеплення модулів
Зчеплення (Coupling) — міра взаємозалежності модулів по даним. Зчеплення - зовнішня характеристика модуля, яку бажано зменшувати.
Кількісне зчеплення вимірюється ступенем зчеплення (СЗ).
Виділяють 6 типів зчеплення:
Зчеплення по даним (СЦ=1). Модуль А викликає модуль В. Всі вхідні і вихідні параметри модуля, що викликається, — прості елементи даних.
Елементи даних
Зчеплення за зразком (СЦ=3). Як параметри використовуються структури даних.
Структруктури даних
Зчеплення по управлінню (СЦ=4). Модуль А явно управляє функціонуванням модуля В (за допомогою прапорів або перемикачів), посилаючи йому керівники дані.
Зчеплення по зовнішніх посиланнях (СЦ=5). Модулі А і В посилаються на один і той же глобальний елемент даних.
Зчеплення по загальній області (СЦ=7). Модулі розділяють одну і ту ж глобальну структуру даних.
Зчеплення за змістом (СЦ=9). Один модуль прямо посилається на зміст іншого модуля (не через його точку входу).
Наприклад, коди їх команд перемежаються один з одним.
На малюнку нижче бачимо, що модулі В і D зчеплені за змістом, а модулі С, Е і N зчеплені по загальній області.
Класичні методи проектування
1. Метод структурного проектування
Початковими даними для методу структурного проектування є компоненти моделі аналізу ПС, яка представляється ієрархією діаграм потоків даних. Результат структурного проектування — ієрархічна структура ПС. Дії структурного проектування залежать від типу інформаційного потоку:
Потік переривань (складається з вхідного, вихідного та перетворювальних потоків).
Потік запитів (має на меті запустити потік даних по одному з декількох шляхів).
Проектування для потоку даних типу переривання:
Крок 1. Перевірка основної системної моделі.
Крок 2. Перевірки і уточнення діаграм потоків даних рівнів 1 і 2.
Крок 3. Визначення типу основного потоку діаграми потоків даних. Основна ознака потоку перетворень — відсутність перемикання по шляхах дій.
Крок 4. Визначення меж вхідних потоків, що виходять, відділення центру перетворень.
Крок 5. Визначення початкової структури ПС. Початкова структура стандартна та включає головний контролер та 3 підлеглих йому контролери: вхідного і перетворюючого та вихідного потоків.
Крок 6. Деталізація структури ПС. Здійснюється відображення перетворювачів ПДД у модулі. Відображення здійснюється від меж центру перетворень для вхідного та вихідного потоків. Центр потоків відображується інакше: кожний перетворювач відображається в модуль підпорядкований в контролер центру.
Крок 7. Уточнення ієрархічної структури ПС. Модулі роз’єднуються та з’єднуються для спрощення реалізації, тестування, зручності супроводу.