- •Содержание
- •Предисловие
- •Краткая история uml
- •1. Зачем мы моделируем
- •Значение моделирования
- •Принципы моделирования
- •Объектное моделирование
- •2. Введение в язык uml
- •Обзор uml
- •Где используется uml
- •Концептуальная модель uml
- •Строительные блоки uml
- •Правила языка uml
- •Общие механизмы языка uml
- •Жизненный цикл разработки по
- •4. Классы
- •Термины и понятия
- •Атрибуты
- •Операции
- •Организация атрибутов и операций
- •Обязанности
- •Другие свойства
- •5. Отношения
- •Термины и понятия
- •Зависимости
- •Обобщения
- •Ассоциации
- •Другие свойства
- •Типичные приемы моделирования Простые зависимости
- •Одиночное наследование
- •6. Диаграммы классов
- •Термины и понятия
- •Общие свойства
- •Типичные примеры применения
- •Типичные приемы моделирования Простые кооперации
- •Прямое и обратное проектирование
- •7. Диаграммы объектов
- •Термины и понятия
- •Общие свойства
- •Типичные примеры применения
- •Типичные приемы моделирования Объектные структуры
- •Прямое и обратное проектирование
- •8. Диаграммы деятельности
- •Термины и понятия
- •Общие свойства
- •Наполнение
- •Состояния действия и состояния деятельности
- •Переходы
- •Ветвление
- •Разделение и слияние
- •Дорожки
- •Траектория объекта
- •Операция
- •9. Диаграммы состояний
- •Термины и понятия
- •Типичные примеры использования
- •Типичные приемы моделирования Реактивные объекты
- •29. Диаграммы компонентов
- •11. Диаграммы развертывания
- •Термины и понятия
- •Общие свойства
- •Типичное применение
- •Клиент-серверная система
- •12. Применение uml
- •Переход к uml
- •Литература
Прямое и обратное проектирование
Хотя прямое проектирование диаграммы объектов (создание кода на основе модели) теоретически возможно, на практике его ценность невелика. В объектно-ориентированных системах экземпляры создаются и разрушаются приложением во время работы, поэтому вы не сможете создать точно такие объекты извне. Исключением из этого правила являются диаграммы, содержащие экземпляры компонентов и узлов. Те и другие представляют собой разновидность соответственно диаграмм компонентов и развертывания и рассматриваются ниже. Здесь отметим только, что экземпляры компонентов и узлов существуют вне работающей системы и до некоторой степени поддаются прямому проектированию. Обратное проектирование диаграмм объектов (создание модели на основе кода) -это совершенно другое дело. Фактически, отлаживая вашу систему, вы непосредственно или с помощью каких-либо инструментов непрерывно осуществляете этот процесс. Например, чтобы отыскать "висячую" связь, необходимо реально или мысленно нарисовать диаграмму взаимодействующих объектов, которая и позволит определить, в каком месте нарушилось состояние одного из них или его отношения с другими. Обратное проектирование объектной диаграммы осуществляется так:
Выберите, что именно вы хотите реконструировать. Обычно базовой точкой является какая-либо операция или экземпляр конкретного класса.
С помощью инструментальных средств или просто пройдясь по сценарию, зафиксируйте выполнение системы в некоторый момент времени.
Идентифицируйте множество интересующих вас объектов, сотрудничаю щих в данном контексте, и изобразите их на диаграмме объектов.
Если это необходимо для понимания семантики, покажите состояния объ ектов.
Чтобы обеспечить понимание семантики, идентифицируйте связи, суще ствующие между объектами.
Если диаграмма оказалась слишком сложной, упростите ее, убрав объекты, не существенные для прояснения данного сценария. Если диаграмма слиш ком проста, включите в нее окружение некоторых представляющих интерес объектов и подробнее покажите состояние каждого объекта.
8. Диаграммы деятельности
Диаграммы деятельности - это один из пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов поведения системы. Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой.
Диаграммы деятельности можно использовать для моделирования динамических аспектов поведения системы. Как правило, они применяются, чтобы промоделировать последовательные (а иногда и параллельные) шаги вычислительного процесса. С помощью диаграмм деятельности можно также моделировать жизнь объекта, когда он переходит из одного состояния в другое в разных точках потока управления. Диаграммы деятельности могут использоваться самостоятельно для визуализации, специфицирования, конструирования и документирования динамики совокупности объектов, но они пригодны также и для моделирования потока управления при выполнении некоторой операции. Если в диаграммах взаимодействий акцент делается на переходах потока управления от объекта к объекту, то диаграммы деятельности описывают переходы от одной деятельности к другой. Деятельность (Activity) - это некоторый относительно продолжительный этап выполнения в автомате. В конечном итоге деятельность сводится к некоторому действию, которое составлено из атомарных вычислений, приводящих к изменению состояния системы или возврату значения. Диаграммы деятельности важны не только для моделирования динамических аспектов поведения системы, но и для построения выполняемых систем посредством прямого и обратного проектирования.
Рассмотрим последовательность операций при постройке дома. Сначала выбирается место. Затем вы нанимаете архитектора, который проектирует дом. После согласования проекта подрядчик предоставляет смету. После того как договорились о цене и проекте, начинается строительство. Местные власти дают разрешение, роется котлован, заливается фундамент, возводится каркас и так далее, пока работа не будет завершена. Наконец, вам вручают ключи и удостоверение на право проживания, и вы вступаете во владение домом. Хотя в действительности процесс строительства намного сложнее, все же это описание дает представление об основных операциях. В реальном проекте ведется множество параллельных работ. Скажем, электрики могут работать одновременно с водопроводчиками и плотниками. Встречаются также условия и ветвления.
Рис.
19.1 Диаграмма деятельности
