- •Технологія проектування програмних систем методичні вказівки
- •1. Опис навчальної дисципліни
- •Теми і зміст лекційних занять
- •3. Практичні заняття з дисципліни
- •6. Розподіл балів за змістовими модулями для визначення оцінки за результатами вивчення навчальної дисципліни
- •Шкала оцінювання
- •Лабораторна робота № 1
- •Короткі теоретичні відомості:
- •Моделювання взаємодій
- •Лабораторна робота № 2
- •Короткі теоретичні відомості:
- •Виявлення вимог
- •Прототипування
- •Системні сервіси
- •Системні обмеження
- •Проектні питання
- •Додатки
- •Специфікації станів
- •Моделювання класів
- •Виявлення класів
- •Підхід на основі використання іменних груп
- •Підхід на основі використання загальних шаблонів для класів
- •Підхід на основі використання прецедентів
- •Комплексний підхід
- •Деякі правила виявлення класів
- •Лабораторна робота № 3
- •Короткі теоретичні відомості
- •Архітектура програмного забезпечення
- •Розподілена архітектура
- •Триланкова архітектура
- •Програмування баз даних
- •Взаємодія "додаток - база даних"
- •Стратегія повторного використання
- •Компоненти
- •Розгортання
- •Проект розгортання
- •Моделі даних
- •Модель об'єктної бази даних
- •Об'єктно-реляційна модель бази даних
- •Елементарні типи моделі рбд
- •Реляційні таблиці
- •Лабораторна робота № 4
- •Короткі теоретичні відомості
- •Зв'язність і ув'язування класів
- •Види ув’язування класів
- •Закон Деметра
- •Методи відкриття доступу і безглузді класи
- •Проектування клієнт-серверних кооперативних взаємодій
- •Збережені процедури
- •Тригери
- •Проектування транзакцій
- •Песимістичне керування паралельністю
- •Точка збереження
- •Триггерный відкат
- •Тестування баз даних
- •Тестування авторизації
- •Тестування інших обмежень
- •Документація по тестуванню і керуванню змінами
Лабораторна робота № 2
Тема: Специфікації вимог. Прототипування і розробка додатків
Ціль: Придбання практичних навичок проведення специфікації вимог, прототипування і розробка додатків
Короткі теоретичні відомості:
У порівнянні з іншими етапами розробки системи встановлення вимог у найменшому ступені стосується технічних сторін проекту. У дійсності мова йде про успішне рішення соціальних, комунікативних і управлінських питань. Недостатньо ретельне виконання цього етапу може привести до більш серйозних наслідків, ніж у випадку з іншими етапами. Лавиноподібне зростання витрат, спричинених не зафіксованими, упущеними або невірно понятими вимогами замовників, може з часом виявитися просто нестерпним для процесу розробки.
Принципи встановлення вимог
Встановлення вимог - перший етап життєвого циклу розробки системи. Система, що підлягає розробці, визначається за допомогою виду діяльності, який одержав назву системного планування. Ціль встановлення вимог полягає в тому, щоб дати розгорнуте визначення функціональних - а також нефункціональних - вимог, які учасники проекту очікують затвердити в системі що реалізовується і розгортається.
Вимоги визначають послуги, очікувані від системи (формулювання сервісів) і обмеження, яким система повинна підкорятися (формулювання обмежень). Ці формулювання сервісів можна об'єднати в кілька груп: одна з груп описує границі системи, друга - необхідні бізнес-функції (функціональні вимоги), а третя - необхідні структури даних (вимоги до даних). Формулювання обмежень можна класифікувати відповідно до різних категорій обмежень, що накладаються на систему, такі як необхідне "враження і відчуття від використання програми", продуктивність, безпека і т.д.
Вимоги необхідно отримати від замовників (користувачів і власників системи). Цей вид діяльності, називаэмий виявленням вимог (requirements elicita-tion), здійснюється аналітиком бізнес-процесів (або системним аналітиком). Для цього підходять різні методи, починаючи з традиційних інтерв'ю з замовником і закінчуючи (при необхідності) побудовою програмного прототипу, за допомогою якого розкриваються додаткові вимоги.
Зібрані вимоги повинні бути піддані ретельному аналізу для виявлення в них повторів і протиріч. Це незмінно приводить до перегляду вимог і їх повторному узгодженню з замовниками.
Вимоги, задовільні з точки зору замовника, документуються. При цьому вимогам дають визначення, класифікують, нумерують і привласнюють їм пріоритети. Структура документа, що описує вимоги, відповідає шаблону (template), обраному в організації для цієї мети.
Хоча документ, що фіксує вимоги, носить значною мірою описовий характер, цілком можливо включити в нього високорівневу схематичну бізнес-модель. Як правило, бізнес-модель складається з моделі границь системи, моделі бізнес - прецедентів і моделі бізнес-класів.
Вимоги користувача подібні рухомій цілі. Щоб упоратися з мінливими вимогами, необхідно вміти управляти змінами. Керування вимогами включає такі види діяльності як оцінка впливу змін одних вимог на інші, а також на незмінну частину системи.
