ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 05.12.2023
Просмотров: 21
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
-
Диаграмма вариантов использования
Рис. 1
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. Действующие лица делятся на три основных типа – пользователи системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Для наглядного представления вариантов использования в качестве основных элементов процесса разработки программного обеспечения (ПО) применяются диаграммы вариантов использования. На рис. 1 показан пример такой диаграммы для компании по производству шкафов. На данной диаграмме человеческие фигурки обозначают действующих лиц, овалы – варианты использования, а линии и стрелки – различные связи между действующими лицами и вариантами использования.
На этой диаграмме показаны четыре действующих лица: продавец, бухгалтерская система, клерк в магазине и управляющий. Существует также шесть основных действий, выполняемых моделируемой системой: ввести новый заказ, изменить существующий заказ, напечатать инвентарную опись, обновить инвентарную опись, оформить заказ и отклонить заказ.
-
Диаграмма последовательности
Рис.2
Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Например, вариант использования «Ввести новый заказ» предусматривает несколько возможных последовательностей, такие как создание нового заказа, сохранение нового заказа и некоторые другие. Нормальный сценарий снятия денег со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счете) показан на рис. 2. Эта диаграмма последовательности показывает поток событий в рамках варианта использования «Ввести новый заказ». Все действующие лица показаны в верхней части диаграммы; в приведенном выше примере изображено действующее лицо Продавец. Объекты, требуемые системе для выполнения варианта использования «Ввести новый заказ», также представлены в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций.
На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
-
Диаграмма кооперативности
Рис. 3
Вторым видом диаграммы взаимодействия является кооперативная диаграмма. Подобно диаграммам последовательности, кооперативные диаграммы (collaborations) отображают поток событий через конкретный сценарий варианта использования. Диаграммы последовательности упорядочены по времени, а кооперативные диаграммы больше внимания заостряют на связях между объектами. На рис. 3 приведена кооперативная диаграмма, описывающая, как продавец создает новый заказ. Как видно из рисунка, здесь представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами
, однако, труднее уяснить последовательность событий .
По этой причине часто для какого-либо сценария создают диаграммы обоих типов. Хотя они служат одной и той же цели и содержат одну и ту же информацию, но представляют ее с различных точек зрения. На кооперативной диаграмме так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временнáя последовательность, однако, указывается путем нумерации сообщений.
-
Диаграмма классов
Рис. 4
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
На этой диаграмме классов показаны связи между классами, реализующими вариант использования «Ввести новый заказ». В этом процессе задействованы шесть классов: Заказ, Менеджер заказов, Менеджер транзакций, Детали заказа, Выбор заказа и Позиция заказа. Каждый класс на диаграмме выглядит в виде круга, разделенного на три части. В первой содержится имя класса, во второй – его атрибуты. В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом).
Стереотипы классов
Стереотипы – это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница), Entity (сущность) и Control (управление).
Граничные классы
Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды.
Классы-сущности
Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области.
Управляющие классы
Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования.
Атрибуты
Атрибут – это элемент информации, связанный с классом. У атрибута можно определить четыре возможных значения этого параметра.
-
Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами -
Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом -
Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. -
Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета.
Операции
Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения. Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.
Множественность
Множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени.
-
Диаграмма состояний
Рис. 5
Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий
-
Диаграмма размещения
Рис.6
Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы.
Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Из нее видно, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. На такой диаграмме показано соответствие классов реализованным компонентам. Она нужна там, где начинается генерация кода.
-
Создание диаграммы размещения
Рис. 7
Диаграмма размещения (deployment diagram) отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства – в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов Диаграмма размещения на рис. 7