Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
4ый семестр / 7. Учебно-исследовательская работа / Программная инженерия 1 Часть 1.ppt
Скачиваний:
9
Добавлен:
18.07.2023
Размер:
1.12 Mб
Скачать

How to Find Actors? (4)

Возможный список акторов системы менеджмента больницы (hospital management system (HMS)) представлен на рисунке 5.2.

Отметим три категории акторов на этой диаграмме.

Здесь отмечены роли, играемые человеческими акторами, взаимодействующими с системой, внешние системы и устройства.

Для лучшего восприятия эти категории разделены на рисунке пунктирными линиями.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

How to Find Actors? (5)

Figure 5.2 Potential list of actors for.

Рисуное 5.2 Потенциальный список акторов в проекте HMS

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Abstract versus Concrete Actors (1)

UML допускает обобщение акторов.

Это означает, что актор может наследовать определение другого актора.

Например, “private patient” и “public patient” могут наследовать все характеристики patient.

В результате актор patient становится абстрактным, а private patient и public patient становятся конкретными акторами.

Абстрактные акторы находятся на общем или верхнем (обобщающем) уровне модели, из которой потом выводятся конкретные (индивидуальные,

специализированные) акторы.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Abstract versus Concrete Actors (2)

Обобщение/специализация обеспечивают возможности для уменьшения

сложности в диаграммах сценариев.

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

Поскольку «доктор» наследует свойства от «персонала», нет необходимости отдельно моделировать процедуру входа в систему для «доктора», если она уже была определена для «персонала».

Таким образом, обобщение для акторов имеет своим результатом иерархию акторов, которая уменьшает сложность и неупорядоченность диаграммы сценариев.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Abstract versus Concrete Actors (3)

Иерархии акторов могут представлены на отдельной диаграмме.

Рисунок 5.3 показывает две отдельные иерархии акторов: иерархию

пациентов и иерархию персонала.

Неодушевленные акторы могут не показываться на диаграммах иерархии акторов, если они не связаны отношением наследования.

Взаимоотношения между абстрактными и конкретными акторами

определяется наследованием (заметьте использование стрелок наследования, формализованных в UML).

Абстрактные акторы A10-Patient и A50-Staff показаны курсивом, как это требуется для абстрактных сущностей в UML.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Abstract versus Concrete Actors (4)

Figure 5.3 Abstract versus concrete actors and a corresponding actor hierarchy in HMS. Рисунок 5.3 Абстрактные и конкретные акторы и их иерархии в систему управления госпиталем.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Clarifying Actor-Class Confusion (1)

Рисунок 5.4 представляет актора A10-Patient.

Пациент - это пользователь системы.

Пользователь будет взаимодействовать с системой - и поэтому он находится

вне системы.

У пациента есть различные атрибуты: имя, адрес, номер медицинской

страховки.

Эти атрибуты пациента необходимо сохранять внутри системы.

Класс, который сохраняет эти атрибуты в системе, вероятно, будет также

назван Patient.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Clarifying Actor-Class Confusion (2)

Этот класс с названием Patient – это не тоже самое, что настоящий пользователь системы, который находится вне ее, так как этот класс создается и

сохраняется в системе.

Важно, чтобы класс Patient не отождествлялся с актором Patient.

Хороший способ разделения этих сущностей – использование префикса actor перед его именем (actorPatient) , или, как это реализовано здесь – с

использованием простой нумерации.

Префикс A10 для пациента относится к актору – A10- Patient , в то время, как Patient – относится к классу.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Clarifying Actor-Class Confusion (3)

Figure 5.4 Distinguishing actors from classes. Рисунок 5.4 Различение акторов и классов.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018

Use Cases (1)

Сценарии (прецеденты, варианты использования) документируют

последовательности взаимодействия актора с системой.

Эти взаимодействия своим результатом должны иметь некоторые конкретные, измеряемые ценности.

Сценарии описывают что система делает, но не определяют как она это

делает.

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

некоторые детали: пред- и постусловия для сценария, ссылки на пользовательский интерфейс, и альтернативные сценарии.

Bhuvan Unhelkar Software Engineering with UML CRC Press 2018