Лабораторно упражнение 3: Софтуерни изисквания и спецификации с UML диаграми
Цел на упражнението
Целта на това упражнение е студентите да се запознаят с езика за моделиране UML (Unified Modeling Language) и неговото приложение при документирането и проектирането на софтуерни изисквания. Ще бъдат разгледани основните видове диаграми и тяхната роля в процеса на разработка.
1. Въведение в UML
UML (Unified Modeling Language) е стандартен език за визуално моделиране на софтуерни системи. Той предоставя формален начин за проектиране и документиране на софтуерни архитектури, използвайки графични елементи за описване на структурата и поведението на системата.
В контекста на софтуерното инженерство, UML служи като “архитектурен план” (blueprint), който улеснява комуникацията между програмисти, системни архитекти и заинтересовани страни, преди да се премине към фазата на реализация (писане на код).
2. Класификация на UML диаграмите
UML диаграмите се разделят на две основни категории в зависимост от аспекта на системата, който моделират:
- Структурни диаграми: Описват статичните елементи на системата и техните взаимовръзки (архитектурната композиция).
- Поведенчески диаграми: Описват динамичните процеси, взаимодействията и промяната на състоянията във времето (функционалната логика).
3. Структурни диаграми
3.1 Диаграма на класовете (Class Diagram)
Това е фундаментална диаграма в обектно-ориентираното проектиране. Тя описва структурата на системата чрез нейните класове, техните атрибути (характеристики), методи (поведение) и връзките между тях.
Елементи на класа:
- Име: Идентификатор на класа.
- Атрибути: Данни или състояние на обектите.
- Методи: Операции или действия, които обектите могат да извършват.
Видове връзки между класовете
Връзките дефинират как обектите от различните класове си взаимодействат:
- Асоциация (Association): Обща структурна връзка. Показва, че обектите се “познават” и си взаимодействат. Често се придружава от кратност (напр. 1..* — един към много).
- Наследяване / Обобщаване (Generalization): Позволява на подклас да наследи свойства и методи от суперклас. Означава се с линия с празна триъгълна глава (▲), сочеща към базовия клас.
- Агрегация (Aggregation): Връзка “цяло-част”, при която частите могат да съществуват самостоятелно (слаба свързаност). Означава се с празен ромб (♢) при “цялото”.
- Композиция (Composition): Силна форма на агрегация, при която частите не могат да съществуват без “цялото”. Означава се със запълнен ромб (♦) при “цялото”.
| Връзка | Символ | Описание | Пример |
|---|---|---|---|
| Асоциация | — | Взаимодействие | Преподавател — Студент |
| Наследяване | —▷ | Йерархия (“е вид”) | Студент —▷ Човек |
| Агрегация | ♢— | Колекция (независима) | Университет ♢— Преподавател |
| Композиция | ♦— | Силна зависимост | Сграда ♦— Етаж |
4. Поведенчески диаграми
4.1 Диаграма на случаите на употреба (Use Case Diagram)
Моделира функционалните изисквания на системата от гледна точка на крайните потребители.
- Актьор (Actor): Потребител или външна система.
- Случай на употреба (Use Case): Конкретна функционалност на системата.
4.2 Диаграма на последователността (Sequence Diagram)
Визуализира взаимодействието между обектите в хронологичен ред. Изключително важна за проектиране на логиката на софтуерните интерфейси и API съобщенията.
4.3 Диаграма на активностите (Activity Diagram)
Описва последователността от действия и логическите разклонения в даден процес, подобно на алгоритмична блок-схема.
5. Инструменти за моделиране
За практическата част на упражнението се препоръчват следните инструменти:
- diagrams.net (Draw.io): Свободен онлайн инструмент.
- Visual Paradigm: Професионална среда за системно проектиране.
- StarUML: Специализиран софтуер за UML моделиране.