Добавил:
СПбГУТ * ИКСС * Программная инженерия Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Письменные лекции по дисциплине «Разработка и анализ требований».docx
Скачиваний:
101
Добавлен:
30.11.2021
Размер:
7.15 Mб
Скачать

4.8. Предметы поведения uml

  • Взаимодействие

  • Конечный автомат (элемент диаграммы состояния; состояние — конечный набор значений какого-либо атрибута рассматриваемого объекта)

  • Вид деятельности

4.9. Отношения uml

  • Зависимость (например, один объект зависит от данных другого объекта; стрелка идет от зависимого объекта к независимому)

  • Ассоциация

  • Агрегация («простое включение», внутренний объект может существовать автономно; ромб на стороне внешнего класса)

  • Композиция («жесткое включение», внутренний объект не может существовать автономно; ромб на стороне внешнего класса)

  • Обобщение («наследование в ООП», стрелка указывает на базовый/родительский класс)

  • Реализация (важно: не укладывается в концепцию классов, поэтому никогда не присутствует в диаграмме классов)

4.10. Диаграмма Use Case

Между актером и прецедентом — ассоциативная связь.

Диаграмма вариантов использования показывает основные функции (прецеденты) проекта и действующие лица, в интересах которых эти функции реализованы.

4.11. Диаграмма Use Case (2)

На данной диаграмме добавлена логическая часть между прецедентами.

На концах ассоциативных связей были добавлены обозначения (1..n, 0..n, 1) мощностей связей.

4.12. Диаграмма (видов) деятельности

Прямоугольник с закруглениями — «вид деятельности». Потоки данных и управления имеют направление сверху-вниз.

Первый ромбик — узел decision («решение») — разветвляет потоки. Второй ромбик (ниже первого) — узел merge («слияние») — сливает потоки в один. Из всех направлений (между двумя ромбиками) будет выполнено ровно одно.

Блок-схема похожа на диаграмму деятельности тем, что также описывает алгоритм работы.

4.13. Элементы диаграммы деятельности

  • Управляющий узел

  • Объектный узел

  • Исполняемый узел

4.14. Управляющие узлы

  • Решение/слияние (decision/merge)

  • Начало/завершение параллельного исполнения (fork/join) (завершение этого блока происходит после завершения всех параллельных процессов)

  • Начало сценария

  • Окончание сценария

  • Остановка исполнения (например, какое-нибудь исключение)

4.15. Объектные узлы

  • Объект

  • Объект и информация о нем («объект со стереотипом»)

Состояние объекта — перечисление значений всех его атрибутов.

  • Сигнал (в Qt Framework для обработки событий)

  • Слот (в Qt Framework для обработки событий)

4.16. Исполняемые узлы

  • Вид деятельности

  • Обработка исключительной ситуации

  • Узел, принимающий данные

  • Узел, передающий данные

4.17. Дуги диаграммы деятельности

  • Дуга между видами деятельности, объектом и видом деятельности

  • Дуга из области прерывания

  • Именованная дуга

  • Соединение дуг (если схема большая, можно разделить)

  • Примеры дуг:

Объект является источником управления либо данных для одного из двух видов деятельности.

4.18. Роли на диаграмме деятельности

Две роли — покупатель и продавец.

4.19. Пример диаграммы деятельности

4.20. Диаграмма состояний

Состояние — конечный набор значений какого-либо атрибута рассматриваемого объекта.

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

4.21. Диаграмма классов

4.22. Диаграмма объектов: обозначения

  • Объект и анонимный объект

  • Объект с атрибутом

  • Связь объектов (атрибут не указан)

  • Связь объектов (атрибут указан)

— первый вариант

— второй вариант

4.23. Диаграмма объектов: пример

4.24. Диаграмма компонентов

Используется для показа структуры ПО.

Компонент: программная реализация класса или нескольких классов (файлы с исходным кодом).

Артефакт: таблицы, файлы данных, рисунки, исполняемые файлы, документы, динамически загружаемые библиотеки (кроме файлов с исходным кодом).

Компонент и артефакт могут быть связаны связью «зависимость».

Компонент и компонент могут быть связаны связями «зависимость» либо «реализация».

4.25. Диаграмма компонентов UML 1.4

4.26. Диаграмма компонентов (UML 2.0)

main зависит от component, а component зависит от mmm.dll.

Order зависит от Product и Account.

4.27. Интерфейс на диаграмме компонентов

Далее представлены два варианта отображения интерфейса на диаграмме.

Calculator реализует интерфейс, от которого зависит Robot.

Calculator предоставляет интерфейс, который используется Robot'ом.

4.28. Интерфейс на диаграмме компонентов (2)

Далее представлены два варианта отображения интерфейса на диаграмме.

4.29. Диаграмма развертывания

Моделирует физическое развертывание артефактов на узлах.

4.30. Диаграмма последовательности

Диаграмма последовательности (англ. sequence diagram) — UML-диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл объекта (создание-деятельность-уничтожение некой сущности) и взаимодействие актеров (действующих лиц) информационной системы в рамках прецедента.

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники с названиями объектов), вертикальные «линии жизни» (англ. lifeline), отображающие течение времени, прямоугольники, отражающие деятельность объекта или выполнение им определенной функции (прямоугольники на пунктирной «линии жизни»), и стрелки, показывающие обмен сигналами или сообщениями между объектами.

Рекомендуется не использовать более 7-ми объектов. В данном случае представлены два: Иван Иванович и Вася.

4.31. Диаграмма взаимодействия (кооперации, collaboration)

Диаграмма взаимодействия показывает поток сообщений между объектами системы и основные ассоциации между ними и по сути является альтернативой диаграммы последовательностей.

В данном случае временной интервал оценить трудно.

4.32. Диаграмма последовательности (2)

4.33. Диаграмма обзора взаимодействия

Interaction Overview diagram

4.34. Диаграмма синхронизации

Timing diagram

4.35. Диаграмма пакетов

Лекция 5. Анализ требований на основе моделирования бизнес-процессов

5.1. Моделирование бизнес-процессов

Бизнес-процесс — совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы и представляющая ценность для потребителя.

Бизнес-модель — это формализованное (графическое, табличное, текстовое) описание бизнес-процессов, отражающее реально существующую или предполагаемую деятельность предприятия.

На основе бизнес-модели формируются требования к ПО.

5.2. Процесс разработки требований

DFD-диаграмма:

5.3. Процессы обработки данных варианта использования

DFD-диаграмма:

В виде прямоугольников — сущности, в виде овалов — процессы / виды деятельности / работы.

Бизнес-процесс представляет собой преобразование исходных данных в далее используемые выходные данные.

5.4. Категории бизнес-процессов

Основные процессы — процессы, составляющие основную деятельность предприятия и приносящие доход.

Например, обучение по программам высшего образования.

Вспомогательные процессы — процессы, обеспечивающие выполнение основных процессов (администрирование, обеспечение безопасности, закупка материалов, комплектующих ...).

Например, закупка оборудования (столы, стулья и др.), обеспечение энергетическими ресурсами (вода).

Процессы управления — процессы, оказывающие влияние на все другие процессы.

Например, работа личного кабинета университета, финансовое планирование.