Клига Л.Ф.
«ОСНОВИ ПРОГРАМНОЇ ІНЖЕНЕРІЇ»
МЕТОДИЧНІ ВКАЗІВКИ
ЩОДО ВИКОНАННЯ ЛАБОРАТОРНИХ РОБІТ
Первомайськ, 2015
ББК 32.973
К49
Укладач:Клига Лариса Федорівна – викладач вищої категорії ПК НУК імені адмірала Макарова,
Розглянуто та ухвалено цикловою комісією «Обслуговування комп’ютерних систем і мереж»
Протокол № від
Рекомендовано до друку навчально-методичною радою ПК НУК імені адмірала Макарова
Протокол № від
Методичні вказівки відповідають програмі з дисципліни “Основи програмної інженерії” для підготовки молодших спеціалістів за спеціальністю 5.05010201 “Обслуговування комп'ютерних систем та мереж”. Вказівки містять загальні правила організації, проведення та виконання лабораторного практикуму з дисципліни, короткі рекомендації щодо виконання, оформлення та моделювання задач, будова діаграм засобами UML.
Вказівки призначені для студентів IY курсу ПК НУК імені адмірала Макарова спеціальності 5.05010201 „Обслуговування комп’ютерних систем і мереж”.
Л.Ф.Клига. Основи програмної інженерії. Методичні вказівки щодо виконання лабораторних робіт. – Первомайськ: ПК НУК, 2015.- 48 с.
© Клига Л.Ф., 2015
© ПК НУК, 2015
ВСТУП
Розробка і використання ПЗ на сьогодні стали масовою діяльністю. Практично немає жодної сфери діяльності людини, де б ПЗ не використовувалося як засіб автоматизації і покращання робіт. Попит на нього постійно збільшується, складність зростає, а кількість помилок не зменшується.
Накопичений до теперішнього часу досвід створення систем ПЗ показує, що це складна і трудомістка робота, яка вимагає високої кваліфікації фахівців, що беруть участь в ній. Проте до теперішнього часу створення таких систем нерідко виконується на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на мистецтві, практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ПЗ. За останніми даними до 80% всього експлуатованого ПЗ розроблялося взагалі без використання якої-небудь дисципліни проектування, методом "Code And Fix" (кодування і виправлення помилок).
Знання розробників ПЗ відрізняються різноманітністю і, як правило, є неповними, неузгодженими і різнорідними, орієнтованими на реалізацію різних предметних областей, починаючи від ОС і закінчуючи прикладними бізнес-системами. І найголовніше, знання в процесі інженерної діяльності поступово уточнюються, видозмінюються і поповнюються, і їх необхідно враховувати розробникам нового ПЗ.
Внаслідок зростання сфер застосування і відповідальності функцій, що виконуються програмами, різко зросла необхідність гарантування високої якості програмних продуктів, регламентації і коректного формування вимог до характеристик реальних комплексів програм і їх достовірного визначення. В результаті фахівці в області теорії і методів, що визначають якість продукції, вимушені освоювати область розвитку і застосування нового, специфічного продукту – програмних засобів і систем в цілому, і їх якість при використанні. Складність аналізованих об'єктів – комплексів програм і психологічна самовпевненість ряду програмістів у власній «непогрішності», часто призводять до того, що реальні характеристики якості функціонування програмних продуктів залишаються невідомими не тільки для замовників і користувачів, але також для самих розробників. Відсутність чіткого декларування в документах понять і необхідних значень характеристик якості ПЗ викликає конфлікти між замовниками-користувачами і розробниками-постачальниками через різне трактування одних і тих же характеристик.
Метою дисципліни є визначення і систематизація тих аспектів діяльності, які складають суть професії розробника програмного забезпечення (ПЗ). Предметом дисципліни є коло питань і проблем, що виникають при промисловій розробці ПЗ. Особливість такої розробки пов’язана з комерційним характером ПЗ, його конструктивною складністю, колективним характером роботи та низкою інших специфічних характеристик. Завдання дисципліни: опанування студентами теоретичних знань і практичних навичок у сфері розробки сучасного ПЗ.
Теоретична частина
Модель життєвого циклу - це схема виконання робіт і завдань на процесах, забезпечують розробку, експлуатацію та супровід програмного продукту, і відображає життя ПС, починаючи від формулювання вимог до неї до припинення її використання
Історично в цю схему робіт включають:
- Розробку вимог або технічного завдання,
- Розробку системи або технічного проекту,
- Програмування або робоче проектування,
- Пробну експлуатацію,
- Супровід та поліпшення,
- Зняття з експлуатації.
Вибір і побудова моделі ЖЦ ПС базується на концептуальній ідеї проектованої системи, її складності і стандартів, що дозволяють формувати схему виконання робіт на розсуд розробника і замовника. Модель ЖЦ розбивається на процеси реалізації, які повинні включати окремі роботи і завдання, реалізовані в даному процесі, і при їх завершення здійснювати перехід до наступного процесу моделі.
При виборі загальної схеми моделі ЖЦ для конкретної предметної області, вирішуються питання включення або невключення окремих робіт, дуже важливих для створюваного виду продукту. На сьогодні основою формування нової моделі ЖЦ для конкретної прикладної системи є стандарт ISO / IEC 12207, який включає повний набір процесів (більше 40), що охоплює всі можливі види робіт і завдань, пов'язаних з побудовою ПС.
Кожна з моделей життєвого циклу має свої переваги, недоліки і області застосування. Тому в кожному конкретному випадку вибирати модель життєвого циклу слід дуже обачно і бажано за участю групи розробників, якій доручено виконання проекту. Вибір моделі життєвого циклу розробки можна здійснювати виходячи з результатів аналізу таких характеристик:
- групи розробників проекту;
- пред'являються до проектованої системи вимог;
- колективу передбачуваних користувачів (замовників);
- ймовірних ризиків і типу проекту.
Застосовність тієї чи іншої моделі життєвого циклу істотно залежить від характеру вимог, що пред'являються до проектованої системи (табл..1).
Таблиця 1. Вибір моделі ЖЦ ПЗ в залежності від характеру вимог до системи.
| Характеристика Вимог | Модель | ||
| Каскадна | Інкрементна | Спиральна | |
| Чи є вимоги легко визначених та / або добре відомими? | Так | Ні | Ні |
| Чи можуть бути вимоги заздалегідь визначені? | Так | Так | Ні |
| Чи часто будуть змінюватися вимоги? | Ні | Ні | Так |
| Чи потрібно демонструвати вимоги з метою їх визначення? | Ні | Ні | Так |
| Чи потрібна для демонстрації можливостей перевірка концепції? | Ні | Ні | Так |
| Чи будуть вимоги відображати складність системи? | Ні | Так | Так |
| Чи відображають вимоги на ранньому етапі функціональні властивості системи? | Ні | Так | Так |
Таблиця 2. Вибір моделі ЖЦ ПЗ на основі характеристик учасників команди розробників.
| Характеристика команди розробників проекту | Модель | ||
| Каскадна | Інкрементна | Спиральна | |
| Чи є проблеми предметної області проекту новими для більшості розробників? | Ні | Ні | Так |
| Чи є технологія предметної області проекту нової для більшості розробників? | Так | Так | Так |
| Чи є інструменти, використовувані проектом, новими для більшості розробників? | Так | Ні | Так |
| Чи змінюються ролі учасників проекту під час життєвого циклу? | Ні | Так | Так |
| Чи можуть розробники проекту пройти навчання? | Ні | Так | Ні |
| Чи є структура більш значущою для розробників, ніж гнучкість? | Так | Так | Ні |
| Чи буде менеджер проекту строго відстежувати прогрес команди? | Так | Так | Так |
| Чи важлива легкість розподіл ресурсів? | Так | Так | Ні |
| Чи приймає команда рівноправні огляди та інспекції, менеджмент / огляди замовника, а також стадії? | Так | Так | Так |
Оскільки при використанні ряду моделей успіх реалізації проекту залежить від ступеня злагодженості роботи єдиної команди розробників і користувачів, то вже на початкових етапах роботи, вибираючи модель життєвого циклу, слід отримати повне уявлення про характеристиках колективу користувачів як комплексному факторів, що впливають на вибір моделі.
Колектив користувачів. На початкових фазах проекту можна отримати чітке уявлення про колектив користувачів (див. табл. 3) і його майбутньої взаємозв'язку з командою розробників протягом всього проекту. Таке уявлення допоможе при виборі підходящої моделі, оскільки деякі моделі вимагають посиленого участі користувачів в процесі розробки та вивчення проекту.
Таблиця 3. Вибір моделі ЖЦ ПО на основі характеристик колективу користувачів
| Характеристика колективу користувачів | Модель | ||
| Каскадна | Інкрементна | Спиральна | |
| Чи буде присутність користувачів обмежена в життєвому циклі? | Так | Так | Так |
| Чи будуть користувачі знайомі з визначенням системи? | Ні | Так | Так |
| Чи будуть користувачі ознайомлені з проблемами предметної області? | Ні | Так | Ні |
| Чи будуть користувачі залучені в усі фази життєвого циклу? | Ні | Ні | Ні |
| Чи буде замовник відслідковувати хід виконання проекту? | Ні | Ні | Так |
Порядок виконання роботи
Студенти розбиваються на групи по 4 та обирають одну із запропонованих тем, або самостійно обирають тему і виконують пункти 2-3.
Побудувати моделі ЖЦ.
Теми:
Операційна система.
Задача.
Оформлення звіту
Зобразити моделі ЖЦ.
Лабораторна робота №2.Структурно-функціональний аналіз і моделювання. Методологія SADT
Мета:Визначити поняття структурно-функціонального аналізу. Визначити основні елементи для будування методології SADT. Навчитися будувати SADT-модель для ПЗ.
Теоретична частина
Структурним аналізом прийнято називати такий метод дослідження системи, що починається з її загального огляду й потім деталізується, здобуваючи ієрархічну структуру із все більшим числом рівнів. Для таких методів характерна розбивка на рівні абстракції з обмеженням кількості елементів на кожному з рівнів (від 3 до 6 – 7); обмежений контекст, що включає лише істотні на кожному рівні деталі; дуальність даних і операцій над ними; використання суворих формальних правил запису; послідовне наближення до кінцевого результату.
Усі методології структурного аналізу базуються на ряді загальних принципів, частина з яких регламентує організацію робіт на початкових етапах ЖЦ системи або об’єкта управління, а частина використовується під час вироблення рекомендацій щодо організації робіт.
Методологія SADT – це сукупність методів, правил і процедур, призначених для побудови функціональної моделі об’єкта чи системи. Функціональна модель SADT відображає функціональну струк туру об’єкта, тобто виконані ними функції, дії і зв’язки між ними.
Основні елементи даної методології ґрунтуються на наступних положеннях:
1. Графічне подання блокового моделювання. Графіка блоків і дуг SADT-діаграми відображає функцію у вигляді блоку, а інтерфейси входу/виходу зображуються дугами, що відповідно входять у блок і виходять з нього. Взаємодія блоків один з одним описується за допомогою інтерфейсних дуг, котрі виражають "обмеження" блоків, які у свою чергу визначають: коли, в якій послідовності і яким чином функції виконуються й управляються.
2. Обмежене деталювання. Кількість рівнів декомпозиції повинна бути достатньою для досягнення мети розбудови проблеми чи завдання.
3. Суворість і точність. Виконання правил SADT вимагає достатньої суворості й точності, не накладаючи в той же час надмірних обмежень на дії аналітика.
Результатом застосування методології SADT є модель, яка складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного. Діаграми – головні компоненти моделі, на якій показані всі функції ІС і інтерфейси за допомогою блоків і дуг. Місце з’єднання дуги із блоком визначає тип інтерфейсу. Керівна інформація входить у блок зверху, у той час як інформація, що піддається обробці, показана з лівого боку блоку, а результати виходу показані із правого боку. Механізм (людина, автоматизована система, засіб), що здійснює операцію, зображується дугою, що входить у блок знизу (рис.2.1).
Рисунок 2.1 Механізм методології
На рис. 2.2 зображена базова структура SADT-моделі, компоненти якої можуть бути декомпозовані на іншій діаграмі (діаграмах) – діаграмі нижчого рівня декомпозиції. Кожна діаграма ілюструє "внутрішню побудову", складові блоку на батьківській діаграмі.
Рисунок 2.2 Базова структура SADT-моделі
Побудова SADT-моделі починається з подання всієї системи у вигляді найпростішого компонента – одного блоку й дуг, що зображують інтерфейси з функціями поза системою, який має назву контекстного. Оскільки єдиний блок відображає всю систему як єдине ціле, ім’я, зазначене в блоці, є загальним. Це визначається й для інтерфейсних дуг – вони також показують повний набір зовнішніх інтерфейсів системи в цілому. Потім блок, що зображує систему як єдиний модуль, деталізується на іншій діаграмі за допомогою декількох блоків, з’єднаних між собою інтерфейсними дугами. Ці блоки становлять основні підфункції реалізованої функції. Дана декомпозиція виявляє повний набір підфункцій, кожна з яких подана як блок, межі котрого визначені інтерфейсними дугами. Кожна інтерфейсна дуга визначає межу взаємодії з іншими дугами та блоками (підфункціями). Структура SADT декомпозована подібним чином для більш детального подання.
Порядок виконання роботи
1. Пояснити поняття методології SADT, визначити її механізм та основні її елементи.
2. Обрати тему за варіантом.
3. Дослідити роботу системи.
4. Побудувати функціональну модель об’єкту.
Теми:
1. Програмне забезпечення банкомата.
2. Інформаційна система бібліотеки.
3. Інформаційна система поліклініки.
4. Інформаційна система відділення
5. Інформаційна система складу
6. Система миттєвого обміну повідомленнями.
7. Система обліку робочого часу.
8. Система продажу білетів для проїзду.
9. Організація і ведення спортивних змагань.
10. Побудова розкладу занять в начальному закладі.
11. Автоматизація відділу кадрів підприємства.
12. Система обліку товару.
13. Автоматизація роботи автосалону.
14. Програмна система банку.
15. Програма ведення власної бібліотеки.
16. Програму обліку транспортних засобів підприємства
Теоретична частина
В основі цієї методології лежить побудова моделі аналізованої ІС - проектованої або реально існуючої. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних (ДПД або DFD), що описують асинхронний процес перетворення інформації від її введення у систему до видачі користувачу. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС із зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція продовжується, створюючи багаторівневу ієрархію діаграм, доти, поки не буде досягнутий такий рівень декомпозиції, на якому процеси стають елементарними і деталізувати їх далі неможливо.
Джерела інформації (зовнішні сутності) породжують інформаційні потоки (потоки даних), що переносять інформацію до підсистем або процесів. Ті у свою чергу перетворюють інформацію і породжують нові потоки, які переносять інформацію до інших процесів або підсистем, нагромаджувачів даних або зовнішніх сутностей - споживачам інформації. Таким чином, основними компонентами діаграм потоків даних є (рис.3.1):
- зовнішні сутності;
- системи/підсистеми;
- процеси;
- нагромаджувачі даних;
- потоки даних.
Рисунок 3.1 Приклад діаграми потоку даних
Зовнішня сутність є матеріальним предметом або фізичною особою, яка виступає джерелом або приймачем інформації, наприклад, замовники, персонал, постачальники, клієнти, склад тощо.
Зовнішня сутність позначається квадратом (рис. 3.2), який розташовується над діаграмою і відкидає на неї тінь, для того, щоб можна було виділити цей символ серед інших позначень.
Рисунок 3.2 Зовнішня сутність
Системи і підсистеми при побудові моделі складної ІС можуть бути представлені у найзагальнішому вигляді на так званій контекстній діаграмі у вигляді однієї системи як єдиного цілого, або може бути декомпоновані на низку підсистем.
Підсистема (або система) на контекстній діаграмі зображується наступним чином (рис. 3.3).
Рисунок 3. 3 Підсистема
Номер підсистеми служить для її ідентифікації. У полі імені вводиться назва підсистеми у вигляді речення з підметом і відповідними визначеннями і доповненнями.
Процес є перетворенням вхідних потоків даних у вихідні відповідно до певного алгоритму (рис.3.4). Фізично процес може бути реалізований різними способами: це може бути підрозділ організації (відділ), що виконує обробку вхідних документів і випуск звітів, програма, апаратно реалізований логічний пристрій тощо.
а) б)
а) Нотація процесу за Gane and Sarson
б) Нотація процесу за Yourdon and Coad
Рисунок 3.4 Процес
Номер процесу служить для його ідентифікації. У полі імені вводиться назва процесу у вигляді речення з активним недвозначним дієсловом у невизначеній формі (обчислити, розрахувати, перевірити, визначити, створити, отримати), за яким іде іменники в знахідному відмінку, наприклад:
"Ввести відомості про клієнтів";
"Видати інформацію про поточні витрати";
"Перевірити кредитоспроможність клієнта".
Використовування таких дієслів, як "обробити", "модернізувати" або "відредагувати" означає, як правило, недостатньо глибоке розуміння даного процесу і вимагає подальшого аналізу.
Інформація у полі фізичної реалізації показує, який підрозділ організації, програма або апаратний пристрій виконує даний процес.
Нагромаджувач даних є абстрактним пристроєм для зберігання інформації, яку можна у будь-який момент помістити у нагромаджувач і через деякий час витягнути, причому способи розміщення і витягання можуть бути будь-якими.
Нагромаджувач даних може бути реалізований фізично у вигляді мікрофіші, шухляди у картотеці, таблиці в оперативній пам'яті, файлу на магнітному носії тощо. Нагромаджувач даних на діаграмі потоків даних зображується, як показано на рисунку 3.5.
Рисунок 3.5 Нагромаджувач даних
Нагромаджувач даних ідентифікується буквою "D" і довільним числом. Назва нагромаджувача вибирається із міркування найбільшої інформативності для проектувальника.
Нагромаджувач даних у загальному випадку є прообразом майбутньої бази даних і опис даних, які зберігаються у ньому повинен бути пов'язаний із інформаційною моделлю.
Потік даних визначає інформацію, яка передається через деяке з'єднання від джерела до приймача. Реальний потік даних може бути інформацією, яка передається по кабелю між двома пристроями, листами, що пересилаються поштою, магнітними стрічками або дискетами, які переносяться з одного комп'ютера на іншій тощо.
Потік даних на діаграмі зображується лінією, що закінчується стрілкою, яка показує напрямок потоку (рис. 3.6). Кожний потік даних має назву, що відображає його зміст.
Рисунок 3.6 Потік даних
Побудова ієрархії діаграм потоків даних (ДПД).
Першим кроком при побудові ієрархії ДПД є побудова контекстних діаграм. Звичайно при проектуванні простих ІС будується єдина контекстна діаграма із зіркоподібною топологією, у центрі якої знаходиться так званий головний процес, який сполучений із приймачами і джерелами інформації, за допомогою яких з системою взаємодіють користувачі та інші зовнішні системи.
Ієрархія контекстних діаграм визначає взаємодію основних функціональних підсистем проектованої ІС як між собою, так і з зовнішніми вхідними і вихідними потоками даних і зовнішніми об'єктами (джерелами і приймачами інформації), з якими взаємодіє ІС.
Після побудови контекстних діаграм отриману модель необхідно перевірити на повноту початкових даних про об'єкти системи та ізольованість об'єктів (відсутність інформаційних зв'язків з іншими об'єктами).
При побудові ієрархії ДПД переходити до деталізації процесів слід тільки після визначення змісту всіх потоків і нагромаджувачів даних, який описується за допомогою структур даних. Структури даних конструюються з елементів даних і можуть містити альтернативи, умовні входження і ітерації. Умовне входження означає, що даний компонент може бути відсутній у структурі.
Після побудови закінченої моделі системи її необхідно верифікувати (перевірити на повноту і узгодженість). У повній моделі всі її об'єкти (підсистеми, процеси, потоки даних) повинні бути детально описані. Виявлені об'єкти, які не деталізуються, слід деталізувати, повернувшись на попередні кроки розробки. В узгодженій моделі для всіх потоків даних і нагромаджувачів даних повинно виконуватися правило збереження інформації: всі дані які поступають куди-небудь повинні бути прочитані, і всі прочитані дані повинні бути записаний.
Порядок виконання роботи
1. Вивчити теоретичну частину.
2. Проаналізувати побудову ДПД.
3. За своїм варіантом з лабораторної роботи №2 побудувати діаграму потоків даних.
4. Деталізувати побудовану діаграму.
5. Відповісти на контрольні питання.
Приклад.Розробити ієрархію діаграм потоків даних системи обліку успішності студентів.
Як зовнішня сутність для системи виступають Декан, Заступник декана по курсу і Співробітник деканату.Визначимо потоки даних між цими сутностями і системою.
Декан повинен отримувати:
• зведення успішності по факультету (відсоток успішності груп, курсів і в цілому по факультету) на теперішній або вказаний момент часу;
• повні відомості про навчання конкретного студента (успішність по всіх вивчених предметам всіх завершених семестрів навчання з урахуванням перездач).
Заступник декана по курсу повинен отримувати:
• зведення успішності по курсу (відсоток успішності по групах) на поточний або вказаний момент;
• зведення про здачу іспитів і заліків вказаною групою;
• поточні відомості про успішність конкретного студента;
• повні відомості про навчання конкретного студента (успішність по всіх вивчених предметам всіх завершених семестрів навчання з урахуванням перездач);
• список боржників по факультету з вказівкою груп і незданих предметів.
Співробітник деканату повинен забезпечувати:
· введення списків студентів, зарахованих на перший курс;
· коректування списків студентів відповідно до наказів про зарахування, відрахування перекладі і т. п.;
· введення учбових планів кафедр;
· введення розкладу сесії;
· введення результатів здачі заліків і іспитів на підставі відомостей і напрямів.
Крім того, співробітник декана повинен мати можливість отримувати:
• довідку про предмети, що прослуховують студентом, з вказівкою годинника і підсумкових оцінок;
• додаток до диплома випускника також з вказівкою годинника і підсумкових оцінок.
Рисунок 3.7 Діаграма потоків даних
Далі деталізуємо процеси в системі. На рисунку 3.8 представлена деталізуюча діаграма потоків даних, де виділено дві підсистеми: Підсистема наповнення бази даних і Підсистема формування звітів, а також сховище даних, яке може бути реалізоване як за допомогою засобів СУБД, так і без них. Вирішення про доцільність використання засобів СУБД може бути прийняте пізніше, після аналізу структур даних, що зберігаються. Подальшу деталізацію процесів можна не виконувати, оскільки їх суть для розробника очевидна. Проте стає ясно, що повна специфікація даної розробки повинна включати опис бази даних. Окрім цього, для даної системи доцільно виконати моделювання керуючих процесів, що дозволить уточнити організацію процесу обробки даних.
Рисунок 3.6 Деталізуюча діаграма потоків даних
Контрольні питання
1. Визначить поняття та призначення діаграми потоків даних.
2. Поясніть призначення основних компонентів діаграми потоків даних.
Теоретична частина
Під інформаційною моделлю розуміється сукупність об’єктів (сутностей) ПрО, їхніх характеристик (атрибутів) і зв’язків між ними. Вона створюється за реляційним принципом: подання зв’язків між об’єктами і їхніми атрибутами у вигляді відношень.
Елементами інформаційної моделі (рис.4.1) можуть бути об’єкти, їхні атрибути й ідентифікатори, а також зв’язки між об’єктами.
Об’єктом може бути довільний предмет реального світу (людина, подія, місце. Документ або поняття), про який потрібно мати дані. Відомості про об’єкт, які мають значення для даної ІМ, називаються атрибутами об’єкту. Значення даних – це дійсні дані, що містяться в кожному атрибуті.
Наприклад, об’єкт – викладач, атрибут – прізвище, ім’я, по батькові, адреса, телефон, значення – Коротков Іван Петрович, вул.Одеська 57, 0681245689.
Для об’єктів ПрО визначаються їхні характерні ознаки або властивості, що називають атрибутами. Кожен атрибут – це абстракція певної характеристики об’єкта, властива всім представникам класу об’єктів, яка одержує унікальне ім’я. Розрізняються описові, додаткові атрибути та атрибути-посилання.
Описовий атрибут установлює реальну характеристику, що може визначатися одним з таких можливих способів:
– завданням числового діапазону;
– перерахуванням можливих значень, що може набувати атрибут;
– посиланням на документ, що визначає можливі значення;
– встановленням правил генерації припустимих значень.
Додатковий атрибут може набувати значень не в усіх об’єктах класу. Наприклад, для об’єктів класу «персональний комп’ютер» атрибут «тип монітора» є обов’язковим, а «тип принтера» — додатковим.
Атрибут-посилання визначає призначення або посилання на інший об’єкт. Наприклад, наукова стаття може містити у собі посилання на інші статті, книги тощо. На діаграмі, де наведено інформаційну модель, зв’язки між об’єктами зображуються стрілками. Зв’язок 1:1 позначається двонаправленою стрілкою, що має по одному «наконечнику» з кожного боку; зв’язок 1:N показується стрілкою, що має один «наконечник» з боку об’єкта, який має зв’язок з декількома об’єктами, і два «наконечники» з боку іншого об’єкта; і, нарешті, по два «наконечники» з кожної сторони має стрілка, що характеризує зв’язок N:M. Над стрілкою вказується ім’я зв’язку.
Зв’язки можуть бути умовними. Коли окремі екземпляри певного класу об’єктів можуть не брати участь у зв’язку, то відповідний кінець стрілки позначається літерою у. За звичайну назву зв’язку використовують літеру R, за якою міститься номер елемента.
У прикладі інформаційної моделі з діаграмним відображенням зв’язків зв’язок R3 є логічним наслідком зв’язків R1 і R2.
Рисунок 4.1 Приклад діаграми інформаційної моделі
Модель станів призначена для відображення динамічної поведінки, зміни станів об’єктів інформаційної моделі і життєвого циклу поведінки об’єктів. Стан моделі залежить від ситуації, обумовленої правилами і лінією поведінки об’єкта. Подія – це інцидент, що змушує об’єкт переходити з одного стану в інший. Усі екземпляри одного класу мають однакову поведінку, яка визначається:
– станом, залежним від поточних значень окремих його атрибутів;
– станом, що змінюється внаслідок виконаних над об’єктами дій;
– станом ПрО, залежним від сукупності станів її об’єктів;
– деякими процесами і діями, що змінюють стан об’єкта протягом його життєвого циклу.
Побудова моделі станів починається з виділення в інформаційній моделі об’єктів, що мають динамічну поведінку (наприклад, зміна стану з часом), визначення часу створення екземпляра об’єкта або його видалення (наприклад, електрична лампочка перегоріла, закінчився її ЖЦ).
У даному методі передбачені дві нотації для подання динамічних аспектів поведінки об’єктів:діаграма переходу станів і таблиця переходу в стани.
При побудові моделі станів для кожного об’єкта інформаційної моделі визначається:
1) множина станів, у яких об’єкт може перебувати;
2) множина інцидентів або подій, що примушують екземпляри класу змінювати свій стан;
3) правила переходу об’єкта з зафіксованого стану в новий стан за умови, що відбудеться деяка подія з множини подій;
4) дія, що виконується при переході об’єкта в новий стан.
Ця інформація подана на діаграмі переходу станів таким чином:
– кожний стан для класу об’єктів одержує назву, номер та унікальний ідентифікатор (ІD);
– стан позначається рамкою, що містить у собі номер і назву;
– початковий стан позначається стрілкою у напрямку до об’єкта, який змінює стан;
– перехід від стану до стану зображується дугою, позначеною міткою і назвою події, пов’язаною з цим переходом;
– заключний стан позначається штриховою лінією;
| Вихід із ладу |
| справний |
| Не справний |
| ремонт |
Рисунок 4.2 Простий приклад діаграми станів для технічного пристрою
Рисунок 4.3 Приклад виділення станів і переходу в UML
Рисунок 4.4 Приклад складної діаграми станів
Порядок виконання роботи
1. Вивчити теоретичний матеріал.
2. За допомогою UML виконати завдання п.3, 5.
3. За своїм завданням (лабораторна робота №2) побудувати діаграму інформаційної моделі із повним описом.
4. Побудувати таблицю із стовпцями: об’єкт, атрибути, значення для завдання і внести дані.
5. Побудувати діаграму станів для задачі за варіантом.
Теоретична частина
Діаграма варіантів використання.
Візуальне моделювання в UML можна представити як певний процес порівневого спуску від найбільш загальної та абстрактної концептуальної моделі до логічної, а потім і до фізичної моделі відповідної інформаційної системи. Для досягнення цих цілей спочатку будується модель варіантів використання, яка описує функціональне призначення системи, тобто призначена для функціонального моделювання системи.
Основна мета побудови цієї моделі – досягти взаєморозуміння між розробниками і замовниками (користувачами) за призначенням, можливостям і технології використання майбутньої інформаційної системи. Визначити межі її застосування. У зв'язку з тим, що замовник бере активну участь у побудові цієї моделі, вона повинна бути описана на його мові.
Побудова цієї моделі необхідно для виявлення:
- Зовнішнього оточення, що взаємодіє з системою (акторів);
- Основних функцій системи (варіантів використання) з можливим уточненням технології їх виконання;
- Нефункціональних вимог (платформи, продуктивності, надійності, захищеності і т. д.).
- Згідно уніфікованому процесу послідовність дій при побудові моделі варіантів використання (ВВ) можна виразити наступною схемою.
Рисунок 5.1 Узагальнена схема технологічного процесу «Формування вимог»
Згідно зі схемою спочатку розробляється діаграма варіантів використання.
Діаграми варіантів використання показують взаємодії між варіантами використання і діючими особами, відображаючи функціональні вимоги до системи з точки зору користувача.
Мета побудови – документування функціональних вимог в загальному вигляді (вимога – простота).
Варіант використання – послідовність дій (транзакцій), виконуваних системою у відповідь на подію, що ініціюється деяким зовнішнім об'єктом (дійовою особою).
Варіант використання описує типове взаємодія між користувачем і системою і відображає уявлення про поведінку системи з точки зору користувача.
Найпростіший випадок варіант використання визначається в процесі обговорення з користувачем тих функцій які він хотів би реалізувати або цілей які він переслідує по відношенню до розроблюваної системи.
Між елементами діаграми варіантів використання можуть існувати різні відносини, які описують взаємодію акторів і варіантів використання.
У мові UML існує кілька стандартних видів відносин між акторами і варіантами використання:
асоціації;
розширення (extend);
узагальнення;
включення (include).
Рисунок 5.1 Приклад діаграми варіантів використання
Рисунок 5.2 Діаграма варіантів використання
Порядок виконання роботи
1. Вивчити теоретичну частину.
2. За своїм варіантом завдання побудувати діаграму варіантів використання в UML.
3. Здійснити аналіз поставленої задачі.
4. Відповісти на контрольні питання.
Завдання.
1. Відкриття рахунку клієнта в банку та рух його коштів.
2. Створення програми користувачем.
3. Замовлення товару по телефону
4. Робота відділення навчального закладу
5. Система продажу товару по каталогу.
6. Система оплати податку.
7. Система будови мережі
8. Система роботи менеджера.
9. Система роботи банкомата.
10. Система роботи автомата напоїв.
Контрольні питання
1. Визначити мету будови діаграми варіантів використання.
2. Види відносин та їх призначення в діаграмі варіантів використання.
3. Деталізація діаграми варіантів використання.
Теоретична частина
Реалізація окремого варіанта використання вимагає участі і взаємодії певни
<Дата: 2016-10-02, просмотров: 380.
