На этом шаге рассмотрим типичные приемы моделирования статических и динамических типов в UML.
Большинство объектно-ориентированных языков программирования статически типизировано. Это означает, что с объектом в момент его создания связывается определенный тип (даже несмотря на то, что объект, вероятно, будет впоследствии играть различные роли). Следовательно, клиенты, использующие объект, взаимодействуют с ним через разные наборы интерфейсов, которые представляют интересующие их множества операций (возможно, перекрывающиеся).
Моделирование статической природы объекта может быть показано на диаграмме классов. Однако когда вы моделируете, скажем, бизнес-объекты, которые обычно изменяют свой тип в потоке работ, иногда целесообразно подчеркнуть динамическую природу их типа, задав ее явным образом. При таких обстоятельствах в течение своего жизненного цикла объект может принимать и терять типы. Смоделировать жизненный цикл объекта можно при помощи машины состояний (конечного автомата).
Чтобы смоделировать динамический тип, необходимо:
- специфицировать возможные типы данного объекта, представляя каждый из них в виде класса (если абстракция требует структуры и поведения) или же интерфейса (если абстракция требует только поведения);
- смоделировать все роли, которые может играть класс объекта в любой момент времени. Вы можете пометить их стереотипом <dynamic> (он не предусмотрен в UML изначально – вы создаете его сами);
- на диаграмме взаимодействия правильно изобразить каждый экземпляр динамически типизированного класса. Отобразить тип экземпляра как состояние, – в фигурных скобках прямо под именем объекта.
На рис. 1 показано, какие роли исполняют экземпляры класса Person (Человек) в системе управления персоналом.
Рис.1. Моделирование динамических типов
По диаграмме видно, что экземпляры класса Person могут быть одного из следующих типов: Candidate (Кандидат), Employee (Работник) или Retiree (Пенсионер).
Когда вы моделируете интерфейсы в UML, помните, что каждый из них должен представлять соединение в системе, отделяющее спецификацию от реализации. Хорошо структурированный интерфейс обладает следующими свойствами:
- прост, но полон – представляет все необходимые операции для описания отдельного сервиса;
- понятен – дает достаточно информации как для использования, так и для реализации, чтобы не нужно было исследовать имеющиеся случаи использования и реализации;
- доступен – представляет информацию пользователю по ключевым свойствам, без перегрузки деталями множества операций.
Изображая интерфейс в UML, учитывайте следующее:
- используйте нотацию "леденца" или сокета (socket) всякий раз, когда нужно показать наличие соединения в системе. В основном это понадобится для компонентов, а не для классов;
- используйте расширенную форму, когда необходимо представить детали самого сервиса. В большинстве случаев это понадобится для описания соединений между пакетами и подсистемами.
На следующем шаге рассмотрим один из способов организации элементов модели в UML - пакеты.
