1.3.2. Система графических обозначений
Документирование процесса проектирования выполняется в соответствии с моделями объектно-ориентированного подхода. Документы должны фиксировать проектные решения, касающиеся логической структуры (структуры классов и структуры объектов) и физической структуры (архитектура модулей и архитектура процессов) разрабатываемой системы в статическом и динамическом аспектах. Наглядное представление проектных решений дают графические диаграммы: классов (рис. 1, 2, 3), объектов (рис. 4, 5, 6), взаимодействий (рис. 7), переходов состояний (рис. 8), модулей (рис. 9), процессов (рис. 10).
На диаграмме классов изображаются классы и отношения между ними. Элементами диаграммы являются классы, утилиты, параметризованные классы, конкретные классы. На верхнем уровне абстракции используют обозначения категорий классов, каждая из которых представляет собой скрытую диаграмму классов, либо состоит из категорий классов более низкого уровня. Для классов и утилит указываются имя и, если есть необходимость, абстракции сущности и поведения. Для категории классов указывается ее имя и имена классов, которые она включает в себя. Для параметризованного класса указываются формальные параметры, а для конкретных классов - фактические параметры, которыми параметризуется соответствующий обобщенный класс.
На диаграммах классов показывают отношения наследования (см. рис. 1), использования (см. рис. 2) и наполнения (см. рис. 3). Связи могут иметь имена (метки). Если при множественном наследовании возникает повторное наследование, то соответствующим значком помечается виртуальное наследование.
Различаются обозначения отношения использования интерфейсом класса (на рис. 2 интерфейс класса C9 использует класс C10) и реализацией класса (на рис. 2 реализация класса C9 использует класс C12). Иногда количество взаимодействующих объектов рассматриваемых классов предопределено условиями задачи (для классов C9 и C10 на рис.2). Соответствующие значения называются кардинальными числами и могут трактоваться как отношения "один к одному", "один ко многим" и другие.
Использование в реализации означает, что экземпляр класса содержит в себе экземпляр используемого класса (использование по значению) либо ссылку на экземпляр используемого класса (использование по ссылке). Эти отличия использования могут быть отражены на диаграмме. На рис. 2 класс C10 использует ссылки на экземпляры класса C11 и непосредственно экземпляры класса C13. Возможна ситуация, при которой экземпляры используемого класса (класса C13 на рис. 2) являются атрибутами некоторого класса (класса C12 на рис. 2), причем создаются и уничтожаются одновременно с экземпляром использующего класса. Этот способ использования отображается соответствующим значком как статическое свойство отношения между классами. Если некоторый класс или утилита используют другой класс так, что имеется доступ к защищенным полям и методам последнего, то такое отношение называется дружественным и помечается соответствующим значком (на рис. 2 между утилитой U2 и классом C13).
Отношение наполнения показывает, что конкретный класс (на рис. 3 класс C8) имеет такую же структуру, как обобщенный класс (класс C7 на рис.3) при замене формальных параметров (параметра P1) фактическими параметрами (параметром F1).
На диаграмме объектов показывают выявленные и синтезированные объекты и их взаимосвязь в логическом проекте системы. Обычно для полного документирования проекта необходимо иметь несколько диаграмм объектов. Каждая диаграмма объектов представляет собой "мгновенный снимок" динамических событий и цель ее построения - показать семантику ключевых механизмов логического проекта.
Имя объекта должно отражать соответствие объекта какой-либо абстракции. Связь между объектами определяется только возможностью одного объекта послать сообщение другому объекту. На диаграмме (см. рис. 4) рядом с линией, обозначающей взаимодействия объектов, указывается список сообщений, направление их передачи, номера сообщения во временном порядке их передачи, направление передачи данных (оно может быть противоположно направлению сообщения).
Для программных систем, которые реализуют параллельные процессы, важно показать способы синхронизации сообщений (см. рис. 5). При синхронной передаче сообщений операция активизируется только при готовности передающего и принимающего объектов, ожидание взаимной готовности может быть неопределенно долгим. Отсроченная передача сообщений соответствует в основном синхронной, но, в случае неготовности принимающего объекта, передающий не выполняет передачу. Задержанная передача сообщений - это вид синхронной с оговоренным временем ожидания готовности принимающего объекта. При асинхронной передаче сообщений объект посылает сообщение вне зависимости от готовности принимающего объекта.
Для уточнения структуры классов может быть полезным детальное рассмотрение механизмов взаимодействия объектов с определением в явном виде их взаимной видимости. Возможны следующие реализации видимости, показанные на рис. 6: объект (X10) является глобальным и поэтому находится в области видимости другого объекта (X9); объект (X10) является локальным, то есть создается и удаляется в процессе выполнения операции другого объекта (X8); объект (X10) передается в качестве параметра какой-либо операции другого (X11); объект (X8) является полем другого объекта (X11). На диаграмме можно дополнительно показать, что видимый объект является разделяемым, то есть другие объекты используют его альтернативные имена (объект X9). Обозначение объекта при необходимости сопровождается указанием его устойчивости: динамический, статический или устойчивый.
На диаграмме взаимодействия (см. рис. 7) указывают порядок передачи сообщений между объектами во времени (ось времени направлена вниз). Обычно диаграмма взаимодействия является дополнением к определенной диаграмме объектов, например, диаграмма на рис.7 получена из диаграммы объектов рис.6.
Диаграмма переходов состояний (рис. 8) предназначена для отображения динамического поведения объекта определенного класса. На ней показываются состояния объекта, события, приводящие к переходу из одного состояния в другое и результаты переходов. На диаграмме стартовым узлом помечается начальное состояние и конечным узлом - конечное состояние. Часто начальное и конечное состояния не указываются, так как вновь созданный объект принимает состояние, зависящее от окружения, а при уничтожении объекта диаграмма переходов теряет смысл. Переход помечается именем события, инициирующим данный переход, условием перехода и именем результирующего действия. Указанный способ указания перехода состояний соответствует конечному автомату Мили. Необходимость введения понятия состояния возникает в том случае, если поведение объекта, точнее алгоритмы выполнения некоторых операций, различаются при разных значениях атрибутов объекта данного класса.
На диаграмме модулей (см. рис. 9) указывается распределение классов и объектов по модулям. В проект входит не менее одного головного модуля, который активизирует всю программу. Отношение между модулями есть отношение компиляционной зависимости. Модуль (Main) может компилироваться, если перед этим был откомпилирован тот модуль (Modul1), интерфейс которого использует данный модуль. Имеются обозначения для интерфейса модуля и для реализации модуля. Если количество модулей велико, то вводятся обозначения подсистем. Отдельная подсистема представляет собой набор логически связанных модулей.
Элементы процессорной архитектуры - это процессоры, устройства и соединения. Обычно необходимость в диаграмме процессов (рис. 10) возникает при создании программной системы, выполняемой одновременно на различных ЭВМ, либо для однопроцессорной системы при наличии активных устройств и существовании параллельных процессов. На диаграмме под каждым обозначением процессора проставляются имена процессов, выполняемых на нем, и способы их диспетчеризации. Соединения соответствуют физическим соединениям между процессорами и устройствами.