Міністерство освіти і науки України

Одеський національний політехнічний університет

Методичні вказівки та завдання до курсовоi роботи

з дисципліни

"Конструювання програмного забезпечення"

для студентів інституту комп’ютерних систем

з базової підготовки за напрямком 05.01.03

«Програмна інженерія»

Затверджено

На засiданнi кафедри

системного програмного забезпечення

протокол № 12 вiд 30.06.09

Одеса ОНПУ 2009

Методичні вказівки та завдання до курсовоi роботи з дисципліни «Конструювання програмного забезпечення» для студентів з базової підготовки за напрямком 05.01.03

«Програмна інженерія»

Укладач:

О. Б. Кунгурцев,

канд. техн. наук,

професор.

1. Короткі теоретичні зведення

Осмислення вимог

Вимоги - це умови, яким повинна відповідати система або проект.

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

Типи вимог

Звичайно вимоги поділяють на дві великі групи: функціональні (стосовні до поводження) і нефункціональні (всі інші).

Функціональні вимоги досліджуються і формулюються в процесі розробки моделі прецедентів, а також у процесі осмислення бачення системи. Інші вимоги формулюються при більш детальному описі прецедентів або в додатковій специфікації. Вимоги високого рівня фіксується в документі «Бачення». Потім вони уточнюються і конкретизуються. У словнику термінів роз'ясняються терміни, що фігурують при описі вимог.

Опис вимог у контексті моделі прецедентів

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

Прецеденти - це механізм спрощення етапу формулювання вимог для всіх зацікавлених осіб. По істоті це розповіді про використання системи в процесі рішення поставлених задач.

Прецеденти і відчутний результат

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

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

Основна увага при описі прецеденту потрібно сфокусувати на питанні : «Як використання системи забезпечить відчутний для користувача результат або вирішить його задачу? », а не на обмірковуванні системних вимог у термінах властивостей або функцій.

Типи і формати прецедентів

Самий типовий і рекомендований тип прецедентів - це «чорна шухляда» (black bow use case).

Є декілька ступенів формалізації прецедентів:

• стиснута анотація у виді одного абзаца. Звичайно описує тільки головний успішний сценарій.

• вільний - неформальний стиль. Опис прецеденту займає декілька абзаців і охоплює різні сценарії.

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

Задача і рамки прецеденту

На якому рівні деталізації варто формувати прецедент? Наприклад, який із наступних пунктів варто вважати прецедентом?

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

• опрацювання повернення товару

• реєстрація

Для відповіді на поставлене питання варто зосередити увагу на рівні елементарних бізнес процесів EBP (Elementary Business Process).

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

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

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

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

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

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

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

• об'єкти предметної області або концептуальні класи;

• асоціації між концептуальними класами;

• атрибути концептуальних класів.

Концептуальний клас може представляти ідею або об'єкт реального світу, але не модель програмних компонентів. На рис.1 приведене уявлення концептуального класу «Продаж».

Рис. 1. Концептуальний клас