· classifier (классификатор) -- все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).
В Базе Данных все классы имеют значение instance.
В данном проекте свойства атрибутов не изменяется при использование в разных классов.
Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов:
· не содержащие ни одного экземпляра -- тогда класс становится служебным ( Abstract );
· содержащие ровно один экземпляр ( Singleton );
· содержащие заданное число экземпляров;
· содержащие произвольное число экземпляров.
В Базе Данных все классы имеют ровно один экземпляр.
Принципиальное назначение классов характеризуют стереотипы. Это, фактически, классификация объектов на высоком уровне, позволяющая определить некоторые основные свойства объекта (пример стереотипа -- класс " действующее лицо "). Механизм стереотипов является также средством расширения словаря UML за счет создания на основе существующих блоков языка новых, специфичных для решения конкретной проблемы.
Диаграммы классов
Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии -- определить типы объектов системы и различного рода статические связи между ними.
Классы отображают типы объектов системы.
Между классами возможны различные отношения, представленные на рисунок 2.3:
· зависимости, которые описывают существующие между классами отношения использования;
· обобщения, связывающие обобщенные классы со специализированными;
· ассоциации, отражающие структурные отношения между объектами классов.
Рисунок 2.3 Отображение связей между классами
Зависимостью называется отношение использования, согласно которому изменение в спецификации одного элемента (например, класса " Контролер ") может повлиять на использующий его элемент ( класс " Учетная запись "). Часто зависимости показывают, что один класс использует другой в качестве аргумента.
Обобщение -- это отношение между общей сущностью (родителем -- класс " Администратор ") и ее конкретным воплощением (потомком -- классы " Учетная запись "). Объекты класса -потомка могут использоваться всюду, где встречаются объекты класса -родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это свойство называют полиморфизмом. Класс, у которого нет родителей, но есть потомки, называется корневым. Класс, у которого нет потомков, называется листовым.
Рисунок 2.4 - Отношение обобщения
Ассоциация -- это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа (" Поверка " может сделать " Учетная запись "). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме (рисунок 2.5). Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи.
Рисунок 2.5 Свойства ассоциации
Рисунок 2.5 иллюстрирует модель формирования заказа на поверку счетчика. Каждый заказ может быть создан единственным клиентом (множественность роли 1...1). Каждый клиент может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть " привязан " к определенному клиенту.
Такого рода ассоциация является простой и отражает отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Если приходится моделировать отношение типа "часть-целое", то используется специальный тип ассоциации -- агрегирование. В такой ассоциации один из классов имеет более высокий ранг (целое -- класс " Поверка ") и состоит из нескольких меньших по рангу классов (частей -- класс " Операция поверки "). В UML используется и более сильная разновидность агрегации -- композиция, в которой объект-часть может принадлежать только единственному целому. В композиции жизненный цикл частей и целого совпадают, любое удаление целого обязательно захватывает и его части.
Для ассоциаций можно задавать атрибуты и операции, создавая по обычным правилам UML классы ассоциаций.
Диаграммы использования
Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (usecase) или просто прецедентов. Прецедент -- это типичное взаимодействие пользователя с системой, которое при этом:
· описывает видимую пользователем функцию,
· может представлять различные уровни детализации,
· обеспечивает достижение конкретной цели, важной для пользователя.
Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актеры, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.
На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: "использование" и "расширение" ( рисунок 2.6). Связь типа "расширение" применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа "использование" позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.
На рисунок 2.6 показано, что при исполнении прецедента " Прием на поверку " возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов " Регистрация " необходимо выполнить одно и то же действие -- создать запись в таблицы "Поверяемое оборудование".
Рисунок 2.6 - Связи на диаграммах прецедентов
Динамические аспекты поведения системы отражаются приведенными ниже диаграммами.
В отличие от некоторых подходов объектного моделирования, когда и состояние, и поведение системы отображаются на диаграммах классов, UML отделяет описание поведения в диаграммы взаимодействия. В UML диаграммы классов не содержат сообщений, которые усложняют их чтение. Поток сообщений между объектами выносится на диаграммы взаимодействия. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках одного варианта использования.
Прямоугольники на диаграмме представляют различные объекты и роли, которые они имеют в системе, а линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения.
Существуют два вида диаграмм взаимодействия: диаграммы последова-тельностей и кооперативные диаграммы.
Диаграммы последовательностей
Этот вид диаграмм используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Эллипсы на вертикальных линиях показывают "время жизни" объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта.
Рисунок 2.7 - Диаграмма Выдача поверенных приборов
· вводятся строки выдачи с поверки;
· по каждой строке проверяется наличие поверки;
· если прибор поверен -- то он выдается с сертификатом о поверке, клиенту;
· если прибор не поверен -- инициируется поверка прибора.
Кооперативные диаграммы
На кооперативных диаграммах объекты (или классы ) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках одного варианта использования. Временная последовательность сообщений отражается их нумерацией.
Диаграммы состояний
Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий.Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.
Эллипсами представляются состояния, через которые проходит объект во время своего поведения. Состояниям соответствуют определенные значения атрибутов объектов. Стрелки представляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта. Имеется также два вида псевдо-состояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел.
Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рисунок 2.8):
Рисунок 2.8 Диаграмма состояний объекта «заказ»
<Событие><[Условие]>< / Действие>.
На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии. Синтаксис метки деятельности:
выполнить/< деятельность >.
Диаграммы деятельности
Диаграмма деятельности -- это частный случай диаграммы состояний. На диаграмме деятельности представлены переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов.
Основными элементами диаграмм деятельности являются (рисунок 2.9):
· овалы, изображающие действия объекта;
· линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И");
· ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия "ИЛИ");
· стрелки -- отражают последовательность действий, могут иметь метки условий.
Рисунок 2.9 - Диаграмма деятельности -- обработка заказа
На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных точек, поскольку они отражают теперь реакцию системы на множество внешних событий. Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы.
Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания).
Диаграммы компонентов
Диаграммы компонентов позволяют изобразить модель системы на физическом уровне.
Элементами диаграммы являются компоненты -- физические замещаемые модули системы. Каждый компонент является полностью независимым элементом системы. Разновидностью компонентов являются узлы. Узел -- это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Узлы делятся на два типа:
· устройства -- узлы системы, в которых данные не обрабатываются.
· процессоры -- узлы системы, осуществляющие обработку данных.
Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML.
Компонентом может быть любой достаточно крупный модульный объект, такой как таблица или экстент базы данных, подсистема, бинарный исполняемый файл, готовая к использованию система или приложение. Таким образом, диаграмму компонентов можно рассматривать как диаграмму классов в более крупном (менее детальном) масштабе. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации.
Основное назначение диаграмм компонентов -- разделение системы на элементы, которые имеют стабильный интерфейс и образуют единое целое. Это позволяет создать ядро системы, которое не будет меняться в ответ на изменения, происходящие на уровне подсистем.