Добавлен: 25.10.2018
Просмотров: 2231
Скачиваний: 19
сообщение, а Аргументы являются параметрами посылаемого сообщения.
Деятельность может также выполняться в результате получения
объектом некоторого события. При получении некоторого события
выполняется определенная деятельность.
Переходом (Transition) называется перемещение из одного состояния в
другое. Совокупность переходов диаграммы показывает, как объект может
перемещаться между своими состояниями. На диаграмме все переходы
изображают в виде стрелки, начинающейся на первоначальном состоянии и
заканчивающейся последующим.
Переходы могут быть рефлексивными. Объект может перейти в то же
состояние, в котором он в настоящий момент находится. Рефлексивные
переходы изображают в виде стрелки, начинающейся и завершающейся на
одном и том же состоянии.
У перехода существует несколько спецификаций. Они включают
события, аргументы, ограждающие условия, действия и посылаемые
события.
События
Событие (event) – это то, что вызывает переход из одного состояния в
другое. Событие размещают на диаграмме вдоль линии перехода.
На диаграмме для отображения события можно использовать как имя
операции, так и обычную фразу.
Большинство переходов должны иметь события, так как именно они,
прежде всего, заставляют переход осуществиться. Тем не менее, бывают и
автоматические переходы, не имеющие событий. При этом объект сам
перемещается из одного состояния в другое со скоростью, позволяющей
осуществиться входным действиям, деятельности и выходным действиям.
Ограждающие условия
Ограждающие условия (guard conditions) определяют, когда переход
может, а когда не может осуществиться. В противном случае переход не
осуществится.
Ограждающие условия изображают на диаграмме вдоль линии
перехода после имени события, заключая их в квадратные скобки.
Ограждающие условия задавать необязательно. Однако если
существует несколько автоматических переходов из состояния, необходимо
определить для них взаимно исключающие ограждающие условия. Это
поможет читателю диаграммы понять, какой путь перехода будет
автоматически выбран.
Действие
Действием
(action)
является
непрерываемое
поведение,
осуществляющееся как часть перехода. Входные и выходные действия
показывают внутри состояний, поскольку они определяют, что происходит,
когда объект входит или выходит из него. Большую часть действий, однако,
изображают вдоль линии перехода, так как они не должны осуществляться
при входе или выходе из состояния.
Действие рисуют вдоль линии перехода после имени события, ему
предшествует косая черта.
Событие или действие могут быть поведением внутри объекта, а могут
представлять собой сообщение, посылаемое другому объекту. Если событие
или действие посылается другому объекту, перед ним на диаграмме
помещают знак « ^ ».
Пример диаграммы состояний представлен на рисунке 1.
Диаграммы состояний не надо создавать для каждого класса, они
применяются только в сложных случаях. Если объект класса может
существовать в нескольких состояниях и в каждом из них ведет себя по-
разному, для него может потребоваться такая диаграмма.
Рис. 1 Пример диаграммы состояний
-mspisit1018.png)
Примеры диаграмм состояний:
Содержание отчета:
-
Титульный лист;
-
Цель работы;
-
Постановка задачи;
-
Описание выбранной исследуемой области;
-
Одна диаграмма кооперации;
-
Минимум 2 диаграммы состояния;
-
Выводы.
Лабораторная работа №4
«Методология объектно-ориентированного моделирования
(диаграмма классов)
1. Цель работы:
получить навыки построения диаграмм классов, создания пакетов и
группировки классов в пакеты.
2. Задание.
Необходимо создать диаграмму классов для одного из сценариев диаграммы
прецедентов, созданной в предыдущей лабораторной работе. Для каждого
класса необходимо задать атрибуты и операции. Каждый класс должен быть
подробно описан - необходимо задать текстовое описание самого класса,
описания его атрибутов и операций;
3. Теоретический материал и пример выполнения работы.
Диаграммы классов (class diagram) используются для моделирования
статического вида системы с точки зрения проектирования. Диаграмма
классов - диаграмма, на которой показано множество классов, интерфейсов,
коопераций и отношений между ними. Используется в следующих целях:
-
для моделирования словаря системы: предполагает принятие решения о том,
какие абстракции являются частью системы, а какие - нет. С помощью
диаграмм классов можно определить эти абстракции и их обязанности;
-
для моделирования простых коопераций. Кооперация - это сообщество
классов, интерфейсов и других элементов, работающих совместно для
обеспечения некоторого кооперативного поведения;
-
для моделирования логической схемы базы данных.
Существуют три различные точки зрения на построение диаграмм классов
или любой другой модели:
-
концептуальная точка зрения - диаграммы классов служат для представления
понятий изучаемой предметной области. Эти понятия будут соответствовать
реализующим их классам, но прямое соответствие может отсутствовать.
Концептуальная модель может иметь слабое отношение или вообще не иметь
никакого отношения к реализующему ее программному обеспечению,
поэтому ее можно рассматривать без привязки к какому-то языку
программирования;
-
точка зрения спецификации - рассматривается программная система, при
этом рассматривается только ее интерфейсы, но не реализация;
-
точка зрения реализации - классы диаграммы соответствуют реальным
классам программной системы.
Пример выполнения работы.
1. Создание диаграммы классов для сценария "Добавить новый заказ"
прецедента "Работа с заказом"
Диаграммы классов будем рассматривать с концептуальной точки зрения. Для
упрощения задачи и чтобы не загромождать диаграммы несущественными
деталями методы setX, getX для каждого атрибута Х классов задавать не
будем.
Создадим в Логическом представлении браузера новую диаграмму классов и
назовем ее "Add New Order". В поле документации запишем для нее
следующий текст: "Диаграмма классов для сценария "Добавить новый заказ"
прецедента "Работа с заказом"".
Заполнение диаграммы начнем с определения классов-сущностей.
Рассматриваемый сценарий состоит из:
-
самого заказа;
-
клиента, который делает заказ;
-
комплектующих изделий, которые входят в заказ.
Создадим классы-сущности Order (Заказ), Client (Клиент) и ComponentPart
(Комплектующее изделие). Поскольку в один заказ может входить много
разных комплектующих изделий, и одно комплектующее изделие может
входить во много заказов, то введем еще один класс-сущность OrderItem
(Состав заказа). Опишем каждый класс.