- •Введение о достоинствах визуального моделирования
- •Глава 1 Активные субъекты
- •Создание активного субъекта
- •Варианты использования
- •Создание варианта использования
- •Поток событий для варианта использования
- •Связи вариантов использования
- •Диаграммы вариантов использования
- •Создание коммуникативной ассоциации
- •Создание включающей связи
- •Создание расширяющей связи
- •Создание основной диаграммы вариантов использования
- •Как создать дополнительную диаграмму вариантов использования
- •Диаграммы действий
- •Создание диаграммы действий
- •Как создать точку принятия решения
- •Как создать контролируемый переход
- •Как привести линии диаграммы к ортогональному виду
- •Полосы синхронизации
- •Kак создать полосу синхронизации
- •Как поделить диаграмму действий на зоны
- •Исходное и завершающее действия
- •Как создать исходное (завершающее) действие
- •Резюме к главе 1
- •Глава2 Что такое объект
- •Характеристики объекта
- •Понятие класса
- •Как создать класс
- •Стереотипы и классы
- •Как "находить" классы
- •Классы сущностей
- •Классы границ
- •Классы управления
- •Как определить или создать стереотип класса
- •Документирование классов
- •Как документировать класс
- •Как создать пакет
- •Как разместить класс в пакете
- •Диаграммы классов
- •Как создать основную диаграмму классов
- •Как создать основную диаграмму классов пакета
- •Как установить признак отображения принадлежности класса пакету
- •Резюме к главе 2
- •Глава 3 Реализации вариантов использования
- •Документирование сценариев
- •Диаграммы последовательностей
- •Как создать диаграмму последовательностей
- •Как создать объекты и сообщения в диаграмме последовательностей
- •Как связать объект диаграммы последовательностей с классом
- •Диаграммы последовательностей и классы границ
- •Сложность диаграмм последовательностей
- •Резюме к главе 3
Классы управления
Классы управления (control classes) находят применение при реализации характеристик поведения системы, присущих одному или нескольким вариантам использования, и координируют события, возникающие по мере функционирования системы в рамках этих вариантов. Класс управления можно воспринимать как абстракцию, отображающую динамику варианта использования системы. Классы управления обычно тесно "привязаны" к особенностям конкретного приложения.
На ранних стадиях жизненного цикла системы для каждой пары вида "активный субъект/вариант использования" создается по одному классу управления, на который возлагаются обязанности по контролю за потоком событий, происходящих по мере выполнения этого варианта.
Мнения по поводу целесообразности применения классов управления весьма разноречивы. Многие полагают, что подобные классы способствуют необоснованному разделению функционального и качественного компонентов моделируемой сущности. Да, такие опасения действительно оправданны, но только в том случае, если подходить к выбору классов поспешно и небрежно.
Конструирование классов управления для различных пар "активный субъект/вариант использования" — это только первый шаг; в ходе дальнейшего анализа и проектирования классы могут расчленяться, сочетаться и удаляться.
Как определить или создать стереотип класса
Расположить курсор мыши над элементом окна Browser, соответствующим требуемому классу, и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.
Выбрать элемент меню Open Specification.
Перейти на вкладку General диалогового окна Class Specification.
Щелкнуть на кнопке со стрелкой в правой части поля Stereotype, чтобы раскрыть список опций, и выбрать нужную опцию либо создать новый стереотип, введя в поле соответствующее наименование.
Закрыть окно Class Specification щелчком на кнопке ОК.
Документирование классов
При создании классы следует документировать. Описание должно характеризовать назначение класса, а не его структуру.
Как документировать класс
Если окно документирования (Documentation) не отображается, открыть его, активизировав элемент меню View=>Documentation.
В окне Browser выбрать элемент дерева, соответствующий требуемому классу.
Позиционировать курсор в окне Documentation и ввести текстовое описание класса.
Пакеты
Если система содержит небольшое количество классов, с ними, вероятно, удастся управиться относительно легко. В большинстве случаев, однако, программные системы состоят из многих классов, поэтому совершенно необходим некий механизм группирования классов, который позволил бы облегчить их интерпретацию, поддержку и повторное использование. В этом смысле концепция пакетов (packages), реализованная в Rational Rose, весьма уместна и убедительна. Пакет в контексте логического представления модели — это собрание "родственных" вложенных пакетов и/или классов. Распределение классов по пакетам дает возможность подняться на более высокий уровень восприятия модели; напротив, "углубляясь" в содержимое пакета, мы переходим к отдельным элементам модели.
Каждый пакет обычно содержит интерфейс, образованный множеством общедоступных (public) классов. К таким классам разрешено обращаться из кода классов, принадлежащих другим пакетам. Остальные классы пакета связаны со спецификой реализации и потому не допускают обращения извне.
Если проектируемая система отличается особой сложностью, пакеты могут конструироваться уже на ранних фазах ее жизненного цикла. В простых ситуациях созданные классы группируются в единственный пакет, "границы" которого определяются системой в целом.
