шпоры-2модуль

2.5. Диаграммы пакетов
При
создании
крупных
программных
систем
разработчики работают с большим количеством классов,
интерфейсов, диаграмм и других элементов. При
масштабировании таких систем возникает необходимость
организовывать эти элементы в более крупные блоки. В
языке UML для организации моделирующих элементов в
группы применяют пакеты. Пакет – это способ
организации элементов модели в более крупные блоки,
которыми потом можно манипулировать как единым
целым. Хорошо спроектированный пакет группирует
семантически близкие элементы, которые имеют
тенденцию изменяться совместно. С помощью пакетов
можно представлять различные виды архитектуры
системы.
Можно
контролировать
видимость
принадлежащих пакету элементов точно так же, как
видимость атрибутов и операций классов. Пакеты не
имеют экземпляров. Чаще всего пакеты применяются для
группировки классов.
Диаграмма пакетов – это модель, содержащая пакеты
классов и зависимости между ними.
Зависимость – это вид связи между элементами модели
(наряду с ассоциациями и обобщениями). Зависимость
между двумя элементами есть в том случае, если
изменения в спецификации одного элемента могут
повлечь за собой изменения в другом, причем обратное
необязательно. Причины зависимостей между классами
могут быть следующими:
- Один класс посылает сообщение другому
-Один класс включает часть данных другого класса
-Один класс ссылается на другой, как на параметр
операции.
Графически зависимость изображается пунктирной
линией со стрелкой, направленной в сторону того
элемента, от которого зависит данный элемент.
При проектировании больших систем зависимости
должны минимизироваться – таким способом снижается
воздействие изменений и требуется меньше усилий на их
внесение.
На рисунке 2.10 приведен пример диаграммы пакетов.
Здесь AWT – это Средство Разработки Графического
Интерфейса Пользователя.
Рисунок 2.10. Диаграмма пакетов.
На этой диаграмме классы предметной области,
моделирующие
деятельность
организации,
сгруппированы в 2 пакета: Заказа и Клиенты. Приложение
Сбора Заказов имеет зависимости с обоими пакетами
Предметной области. Пользовательский Интерфейс Сбора
Заказов имеет зависимости с пакетами Приложение Сбора
Заказов и Средство разработки Графического Интерфейса
Пользователя.
Зависимости между двумя пакетами существуют, если
существует какая-либо зависимость между любыми
двумя классами в пакетах. Например, если любой класс в
пакете Список Рассылки зависит от какого-то класса в
пакете Клиенты, то между соответствующими пакетами
существует зависимость.
Пакеты не дают ответа на вопрос, каким образом можно
уменьшить количество зависимостей в системе, однако
они помогают выделить эти зависимости. После того, как
все зависимости окажутся на виду, разработчику остается
только поработать над снижением их количества.
Диаграммы пакетов являются основным средством
управления общей структурой системы.
Если нужно показать содержимое пакета, то имя пакета
помещается в верхнюю «этикетку», а содержимое
помещается внутрь основного прямоугольника. Это
содержимое может быть перечнем классов, другой
диаграммой пакетов или диаграммой классов. По
отношению к пакетам можно использовать механизм
обобщения.
Применение диаграмм пакетов.
Пакеты являются необходимым средством для больших
проектов. Их нужно использовать в тех случаях, когда
диаграмма классов, охватывающая всю систему в целом и
размещенная на листе формата А4, становится трудно
читаемой.
Сведение
к
минимуму
количества
зависимостей позволяет снизить степень связности
компонентов системы.
2.6. Диагр-ы взаимодействия
2.6.1. Общая характеристика
Взаимодействие – это поведение, выражающееся в
обмене сообщениями между объектами, в результате
чего достигается определенная цель. Чаще всего
сообщение сводится к вызову операции или посылке
сигнала, но оно может также создавать и уничтожать
другие объекты.
Для моделирования динамических аспектов системы
используют диаграммы взаимодействия. Диаграммы
взаимодействия – это модели, которые описывают
поведение взаимодействующих групп объектов.
Обычно диаграмма взаимодействия (ДВ) охватывает
поведение только одного варианта использования. На
ДВ отображается ряд объектов и те сообщения,
которыми они обмениваются между собой в рамках
данного ВИ.
Существует
2
вида
ДВ:
1
–
диаграммы
последовательностей;
2 – кооперативные диаграммы.
2.6.2. Диаграммы последовательностей.
Диаграммы
последовательностей
акцентируют
внимание на временной упорядоченности сообщений.
На
диаграмме
последовательностей
объект
изображается в виде прямоугольника на вершине
пунктирной вертикальной линии. Она называется
линией жизни объекта. Линия жизни описывает
существование объекта в определенный промежуток
времени, возможно, включая моменты создания и
уничтожения объекта. Объекты на диаграмме
располагаются по горизонтали, слева располагается
объект, инициирующий взаимодействие. Сообщения,
посылаемые объектами друг другу, размещаются по
вертикали, сверху вниз, в порядке их появления.
Пример диаграммы последовательностей приведен на
рисунке 2.11.
Эта диаграмма изображает следующий ВИ:
1. объект Окно Ввода Заказа посылает объекту Заказ
сообщение «приготовиться»;
2. объект Заказ посылает данное сообщение каждой
Строке Заказа в данном Заказе;
3. каждая Строка Заказа проверяет состояние
определенного Запаса Товара. Если проверка
удовлетворяется (true), то Строка Заказа удаляет
соответствующее количество товара из Запаса. В
противном случае количество Запаса снижается до
уровня Повторного Заказа и Запас запрашивает новую
поставку товара.
Каждое сообщение представляется в виде стрелки
между линиями жизни двух объектов.
Рисунок 2.11. Диаграмма последовательностей.
Сообщения появляются в том порядке, как они
показаны (сверху вниз). Каждое сообщение имеет имя,
можно добавить также аргументы и некоторую
управляющую информацию. На диаграмме показано
самоделегирование – это сообщение, которое объект
посылает самому себе. В качестве управляющей
информации может быть:
условие, показывающее, в каком случае посылается
сообщение (например, нужен Повторный Заказ ()= true);
маркер итерации, показывающий, что сообщение
посылается много раз для множества объектов
(например, * приготовиться).
На одной диаграмме последовательностей можно показать
только один поток управления (хотя с помощью нотации
UML для итераций и ветвлений можно проиллюстрировать
простые вариации). Поэтому, как правило, создают
несколько диаграмм взаимодействий, одни из которых
считаются
основными,
а
другие
описывают
альтернативные пути и исключительные условия. Такой
набор диаграмм последовательностей можно организовать в
пакет, дав каждой диаграмме подходящее имя, отличающее
ее от остальных.
2.6.3. Кооперативные диаграммы.
Кооперативные диаграммы акцентируют внимание на
структурной организации объектов, участвующих во
взаимодействии. Примеры кооперативных диаграмм
приведены на рисунках 2.12.и.2.13. На кооперативной
диаграмме экземпляры объектов показаны в виде
пиктограмм. Стрелки обозначают сообщения, обмен
которыми осуществляется в рамках данного ВИ. Их
временная последовательность указывается путем
нумерации сообщений. Для кооперативных диаграмм
можно использовать различные варианты нумерации
(см. рис 2.12 и 2.13).
Рисунок 2.12. Кооперативная диаграмма с простой
нумерацией
Независимо от схемы нумерации, на диаграмме можно
поместить управляющую информацию, как и на
диаграмме последовательностей.
В этих примерах показаны различные схемы
именования объектов, принятые в UML. Общая форма
имени имеет вид: <имя объекта: имя класса>. Любая
часть этой конструкции может отсутствовать. При
отсутствии имени объекта нужно оставить двоеточие,
чтобы было понятно, что это имя класса, а не объекта.
Например, имя «строка Маккалана: Строка Заказа»
означает, что экземпляр класса Строка Заказа
называется строка Маккалана.
Рисунок 2.13. Кооперативная диаграмма с десятичной
нумерацией
Обе формы диаграмм взаимодействия отличаются
простотой. Если на диаграмме изображен единственный
последовательный процесс, то . посмотрев на нее,
можно увидеть все сообщения.
Если же процесс
содержит множество условных переходов или циклы, то
в таком случае нужно строить отдельные диаграммы для
каждого сценария или сопровождать сообщения
условиями, показывающими поведение объектов.
2.6.4. Рекомендации по использованию диаграмм
взаимодействия.
Диаграммами взаимодействия следует пользоваться,
когда нужно описать поведение нескольких объектов в
рамках одного ВИ. Они удобны для отображения
взаимодействия между объектами, а для точного
описания поведения объектов они не годятся.
2.6.
Диаграммы состояний
Диаграммы состояний определяют все возможные
состояния, в которых может находиться конкретный
объект, а также процесс смены состояний объекта в
результате влияния некоторых событий. В большинстве
объектно-ориентированных
методов
диаграммы
состояний строятся для единственного класса и отражают
динамику поведения единственного объекта.
Существует несколько форм диаграмм состояний (ДС).
Пример ДС, отражающей поведение объекта Заказ в
Системе Обработки Заказов, приведен на рисунке 2.15. На
этой диаграмме изображены различные состояния, в
которых может находиться объект Заказ. Процесс
начинается с Начальной точки, затем следует первый
переход в состояние Проверка Позиции Заказа. Метка
этого перехода «/получить позицию Заказа». Синтаксис
метки: <событие>[<условие>]/ <действие>. Каждая из
этих трех частей является необязательной. В данном
случае метка включает только действие. После
выполнения этого действия объект попадает в состояние
Проверка Позиции Заказа. С этим состоянием связана
деятельность, которая обозначается меткой «выполнить/
проверить
позицию».
Синтаксис
этой
метки:
выполнить/<деятельность>.
В
данном
случае
деятельность называется «проверить позицию».
Рисунок 2.15. Диаграмма состояний
Термин «действие» используется для перехода, термин
«деятельность» – для состояния. Хотя и то и другое – это
процессы, реализуемые некоторым методом класса Заказ,
но они различаются между собой.
Действия связаны с переходами и рассматриваются как
мгновенные и непрерываемые.
Деятельности связаны с состояниями и могут длиться
достаточно долго. Деятельность может быть прервана в
результате наступления некоторого события. Если метка
перехода не содержит никакого события, то переход
происходит,
как
только
завершается
какая-то
деятельность, связанная с данным состоянием (как только
завершится Проверка Позиции Заказа).
Из состояния Проверка Позиции Заказа возможны 3
перехода. Метка каждого из них включает только
условие. Условие это логическое, оно может принимать 2
значения – «истина» и «ложь». Если условие принимает
значение «истина», то выполняется условный переход.
Из конкретного состояния в данный момент времени
может произойти только 1 переход, т.е. условия являются
взаимно исключающими. В нашем примере 3 условия:
1если проверены не все позиции, входящие
в Заказ, то мы получаем следующую позицию и
возвращаемся в состояние Проверка Позиции Заказа;
2если проверены все позиции и все они
имеются на складе, то переходим в состояние Выдача
Заказа на Поставку;
3если проверены все позиции, но не все
имеются на складе, то переходим в состояние Ожидание.
Рассмотрим состояние Ожидание. В этом состоянии нет
деятельностей, поэтому Заказ находится в состоянии
Ожидания, пока не наступит некоторое событие. Оба
перехода из состояния Ожидание отмечены событием
«позиция получена». Заказ ожидает до тех пор, пока он не
обнаружит наступления данного события.
В состоянии Выдача Заказа на Поставку есть
деятельность, которая инициирует поставку. Переход из
этого состояния произойдет, если произойдет событие
«поставлен».
Рисунок 2.16 Диаграмма состояний без суперсостояний.
В рассмотренном примере нет перехода под названием
«отмена». У нас должна быть возможность отменить
любой Заказ в любой момент времени до завершения
его выполнения. На рисунке 2.16 добавлено состояние
«отмена Заказа». Чтобы отменить Заказ, нужно
изобразить переходы из каждого состояния (Проверка
Позиции Заказа, Выдача Заказа и Ожидание).
Рисунок
2.17.
Диаграмма
состояний
с
суперсостояниями.
На диаграмме 2.17 изображен другой вариант – для 3
вышеперечисленных
состояний
определено
суперсостояние и единственный переход из него.
Подсостояния
наследуют
любые
переходы
суперсостояния.
Когда использовать диаграммы состояний.
Диаграммы состояний хорошо использовать для
описания поведения некоторого объекта в нескольких
различных ВИ. Для описания поведения нескольких
взаимодействующих объектов эти диаграммы не
удобны. С помощью диаграмм состояний полезно
изображать поведение пользовательского интерфейса и
управляющих объектов.
2.7. Диаграммы деятельностей.
2.7.1. Простые диаграммы деятельностей
На диаграммах деятельности основным элементом
является деятельность. Значение этого термина зависит
от точки зрения, с которой строится данная диаграмма.
На концептуальной диаграмме деятельность – это
некоторая задача, которую необходимо выполнить. На
диаграммах, построенных с т.з. спецификации и
реализации,
деятельность
представляет
собой
некоторый метод над классом. Диаграммы деятельности
полезны в описании поведения, включающего большое
количество параллельных процессов.
Рисунок 2.18. Диаграмма деятельностей.
На рисунке 2.18 приведен пример диаграммы
деятельностей.
За каждой деятельностью может следовать другая
деятельность. За деятельностью Положить Кофе в
Фильтр следует деятельность Вставить Фильтр в
Автомат. Это простая последовательность. Деятельность
Поискать Напиток активизирует 2 действия. Каждое
действие содержит условие – логическое выражение,
которое может принимать 2 значения – «истина» и
«ложь».
В
приведенном
примере
Личность
осуществляет деятельность Поискать Напиток, выбирая
между Кофе и Колой.
Предположим, что Личность выбрала Кофе и идем вниз
по кофейному маршруту. Этот путь ведет к линейке
синхронизации, с которой связана активизация 3
деятельностей: Положить Кофе в Фильтр, Добавить
Воду в Емкость и Достать Чашки. Диаграмма
показывает, что эти 3 деятельности могут выполняться
параллельно. Порядок их выполнения не играет роли.
Таким
образом,
диаграммы
деятельностей
поддерживают
параллельные
процессы.
Такая
возможность важна для моделирования бизнеспроцессов. (Среди этих процессов есть такие, которые
не обязаны выполняться последовательно.) Этот метод
побуждает людей искать возможность делать дела
параллельно. Диаграммы деятельностей полезны также
при параллельном программировании, т.к. они
позволяют графически изобразить все ветви и
определить, когда их необходимо синхронизировать.
Если при описании поведения системы существуют
параллельные деятельности, то их необходимо
синхронизировать. Результаты этих деятельностей
сводятся вместе к одной линейке синхронизации.
Линейка синхронизации показывает, что ее выходная
деятельность активизируется только тогда, когда
выполнены все входные деятельности (в нашем примере
их две). На диаграмме есть еще одна линейка
синхронизации, которая показывает, что Кофе должен
быть готов и Чашки должны стоять на месте до того, как
мы сможем налить Кофе.
Из деятельности Поискать Напиток существует 2
выхода. Если Кофе нет, выбирается второе решение,
связанное с Колой. При такой последовательности
решений второе решение обозначается ромбом. Такое
обозначение позволяет описывать вложенные решения,
их количество м.б. любым.
Деятельность Выпить Напиток имеет 2 входа, что
означает ее выполнение в любом из случаев. Эту
ситуацию можно рассматривать как условие «ИЛИ».
Линейку синхронизации можно рассматривать как
условие «И».
Конечная точка на диаграмме – это точка, в которой
заканчивается выполнение всех деятельностей.
2.7.2. Диаграммы деятельностей для вариантов
использования
Диаграммы деятельности можно применять для описания
вариантов использования. Рассмотрим ВИ, связанный с
обработкой Заказа. Он заключается в следующем:
Когда мы получаем заказ, то проверяем каждую
содержающуюся в нем позицию, чтобы убедиться в
наличии соответствующих товаров на складе. Затем
выписываем товары для реализации заказа. Если
количество
присланного
товара
оказывается
недостаточным, выполняется повторный заказ товаров.
Во время выполнения этих процедур проверяется
прохождение платежа. Если платеж прошел и товары есть
на складе, то они поставляются. Если платеж прошел, но
товаров на складе нет, то заказ ставится в ожидание. Если
платеж не прошел, то заказ аннулируется.
Диаграмма деятельностей для этого ВИ приведена на
рисунке 2.19.
Рисунок 2.19. Получение заказа
На этой диаграмме появился маркер множественности
«*». Он показывает, что при получении Заказа нужно
выполнить деятельность Проверить Позицию Заказа для
каждой строки заказа. За деятельностью Получить Заказ
следует один вызов деятельности Проверить Платеж и
много вызовов деятельности Проверить Позицию Заказа.
Все эти вызовы производятся параллельно. Таким
образом, параллельные деятельности могут быть связаны
не только с линейкой синхронизации, но и с
множественной активизацией.
Для множественной
активизации нужно показать на диаграмме её основу. В
нашем примере это - «для каждой строки заказа».
Линейка синхронизации перед деятельностью Выполнить
Поставку сопровождается условием. Оно проверяется
каждый раз при выполнении входящей в линейку
деятельности. Если условие истинно, то выполняется
выходная деятельность.
Диаграмма деятельностей не обязательно должна
включать явно определенную конечную точку. В данном
примере указание конечной точки не дает никакой
пользы. Данный пример содержит тупик – деятельность
Повторно заказать Позицию. Для диаграммы, не
имеющей конечной точки это нормально. У деятельности
Проверить Позицию Заказа только один выход, который
содержит условие. Если условие не выполняется, то
ничего не произойдет – такая ветвь отсутствует. Мы не
можем выполнить заказ, пока не пополнится запас на
складе. Этой деятельности может соответствовать
отдельный ВИ.
Когда производится поставка на склад, мы просматриваем
невыполненные заказы, чтобы узнать, какие из них можно
удовлетворить. Каждый из поступивших товаров
распределяется по соответствующим заказам. После
выполнения
этих
заказов
оставшиеся
товары
направляются на склад. Этот ВИ отражен на диаграмме
(рисунок 2.20)
Рисунок 2.20. Получение комплектующей поставки.
Каждый из двух вариантов использования отражает свою
часть общей картины. Их можно объединить в одну
диаграмму (рисунок 2.21).
Здесь отдельные диаграммы деятельности для обоих ВИ
наложены друг на друга, и можно видеть, как действия в
одном из ВИ вызывают соответствующие действия в
другом. Такие диаграммы содержат несколько начальных
точек, т.к. они отражают реакцию системы на множество
внешних событий.
Рисунок 2.21. Получение заказа и комплектующей
поставки
2.7.3. «Плавательные дорожки»
Диаграммы деятельностей отражают происходящие
события, но не сообщают, какой класс отвечает за
выполнение каждой деятельности. Можно снабдить
каждую деятельность меткой соответствующего класса.
Другой способ – т.н. «плавательные дорожки» (рисунок
2.22).
В этом случае диаграмма деятельностей с помощью
пунктирных линий разделяется на вертикальные зоны.
Каждая зона представляет собой зону ответственности
конкретного класса или конкретного функционального
подразделения.
Преимущество «плавательных дорожек» заключается в
том, что они соединяют логику диаграмм деятельностей
с ответственностью, выражаемой с помощью диаграмм
взаимодействий.
При построении диаграмм деятельностей можно сразу
связывать деятельность с объектами. Другой вариант –
строить диаграмму деятельностей, а связать поведение
с конкретными объектами позже.
Рисунок 2.22. Плавательные дорожки.
2.7.5. Применение диаграмм деятельностей
Главное достоинство диаграмм деятельностей – это
поддержка параллелизма. Они являются мощным
средством
моделирования
потоков
работ
и
параллельного программирования.
Главный недостаток заключается в том, что в
диаграммах деятельностей нечетко просматриваются
связи между действиями и объектами.
Диаграммы деятельностей используют в следующих
ситуациях:
1. Анализ варианта использования. На этом этапе
нужно понять, какие действия должны иметь место и
каковы зависимости в поведении системы. Связать
действия с объектами можно позже.
2. Анализ потоков работ в различных ВИ. Когда
варианты использования взаимодействуют друг с
другом, диаграммы деятельностей являются мощным
средством представления и анализа их поведения. В
ситуациях, где преобладают потоки работ, эти
диаграммы незаменимы.
3. Диаграммы деятельностей хорошо подходят для
работы с мультипроцессорными приложениями.
Диаграммы деятельностей не используются для:
4. выяснения взаимодействия объектов (лучше
использовать диаграммы взаимодействия);
5. изучения поведения объекта в течение его
жизненного цикла (здесь лучше использовать
диаграммы состояний).
2.5. Диаграммы пакетов
Применение диаграмм пакетов.
2.7. Диагр-ы взаимодействия
2.6.1. Общая характеристика
2.6.2. Диаграммы последовательностей.
2.6.3. Кооперативные диаграммы.
2.6.4. Рекомендации по использованию диаграмм
взаимодействия.
2.7.
Диаграммы состояний
2.7. Диаграммы деятельностей.
2.7.1. Простые диаграммы деятельностей
2.7.2. Диаграммы деятельностей для вариантов
использования
2.7.3. «Плавательные дорожки»
2.7.5. Применение диаграмм деятельностей