4.1 Розробка виду з погляду прецедентів

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

Для цих цілей використовуються діаграми прецедентів. Як уже говорилося, на діаграмах прецедентів вказуються прецеденти й актори, а також відносини між ними.

Прецедент (Use case) - це опис послідовності виконуваних системою дій, що робить спостережуваний результат, значимий для якогось певного актора

(Actor). Прецедент застосовується для структурування поведінкових сутностей моделі. Прецедент тільки декларує опис якої-небудь дії системи, відповідаючи на запитання «що робити?», але не вказує якими засобами. Конкретна реалізація специфицируемого прецедентом поводження забезпечується класом, кооперацією класів або компонентом. Актор являє собою зв'язну безліч ролей, які користувачі прецедентів виконують під час взаємодії з ними. Звичайно актор представляє роль, що у даній системі грає людина, апаратний пристрій або навіть інша система. У розроблювальній системі «АРМ секретаря кафедри» акторами є адміністратор (админ) і користувач.

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

Вертаючись до моделювання АРМ секретаря кафедри, виділимо прецеденти: Редагування даних, Пошук студента, Пошук викладача, Видача списку преподаваних дисциплін, Авторизація.

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

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

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

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

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

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

Діаграма прецедентів АРМ секретаря кафедри показана на рис. 4.1.

Прецедент пошук студента припускає пошук на прізвище й пошук за підсумками успішності.

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

Потоки подій можуть бути описані за допомогою неструктурованого тексту, структурованого тексту (утримуючого службові слова: ЯКЩО, ДОКИ й т.п.), спеціалізованого формальної мови (псевдокоду).

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

Рисунок 4.1 - Діаграма прецедентів АРМ секретаря кафедри

Основний потік подій. Прецедент починається, коли система запитує в користувача його вхідне ім'я (Login) і пароль (Password). Користувач може ввести його із клавіатури. Завершується уведення натисканням клавіші Enter.

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

Винятковий потік подій. Клієнт може припинити шипик у будь-який момент, нажавши клавішу Cancel. Ця дія починає прецедент заново. Уведення в систему не виробляється. Винятковий потік подій. Клієнт може в будь-який момент до натискання клавіші Enter стерти свої Login і пароль. Винятковий потік подій. Якщо клієнт увів Login і пароль не відповідному адміністраторові, йому пропонується призвести повторне уведення або ввійти в систему на правах рядового користувача.

Рисунок 4.2 - Авторизація користувача. Діаграма діяльності

Очевидно, що опис прецеденту потоком подій припускає деякий алгоритм, якому можна представити на діаграмі діяльності (рисунок 4.2).

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