Моделирование систем

Построение диаграмм классов  можно рассматривать в различных  аспектах:

• концептуальный аспект – диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как не зависимую от средств реализации (языка программирования);
• аспект спецификации– модель спускается на уровень программного обеспечения, но рассматриваются только интерфейсы, а не программная реализация классов;
• аспект реализации– модель действительно определяет реализацию классов программного обеспечения. Этот аспект наиболее важен для программистов.

Диаграммы классов будем рассматривать с концептуальной точки зрения.

Класс в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Каждый класс имеет название, атрибуты и операции. Класс на диаграмме показывается в виде прямоугольника, разделенного на 3 области. В верхней содержится название класса, в средней – описание атрибутов (свойств), в нижней – названия операций – услуг, предоставляемых объектами этого класса.

Атрибуты класса определяют состав и структуру данных, хранимых в объектах этого класса. Каждый атрибут имеет имя и тип, определяющий, какие данные он представляет. При реализации объекта в программном коде для атрибутов будет выделена память, необходимая для хранения всех атрибутов, и каждый атрибут будет иметь конкретное значение в любой момент времени работы программы. Объектов одного класса в программе может быть сколь угодно много, все они имеют одинаковый набор атрибутов, описанный в классе, но значения атрибутов у каждого объекта свои и могут изменяться в ходе выполнения программы.

Для каждого атрибута класса можно задать видимость. Эта характеристика показывает, доступен ли атрибут для других классов.

В UML определены следующие  уровни видимости атрибутов:

• открытый (public) – атрибут виден для любого другого класса (объекта);
• защищенный (protected) – атрибут виден для потомков данного класса;
• закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим.

Класс содержит объявления операций, представляющих собой определения запросов, которые должны выполнять объекты данного класса. Каждая операция имеет сигнатуру, содержащую имя операции, тип возвращаемого значения и список параметров, который может быть пустым. Реализация операции в виде процедуры – это метод, принадлежащий классу. Для операций, как и для атрибутов класса, определено понятие «видимость». Закрытые операции являются внутренними для объектов класса и недоступны из других объектов. Остальные образуют интерфейсную часть класса и являются средством интеграции класса в проектируемую систему.

Кроме внутреннего устройства или структуры классов на соответствующей  диаграмме указываются различные  отношения между классами. При  этом совокупность типов таких отношений  фиксирована в языке UML и предопределена семантикой этих типов отношений.

Базовыми отношениями  или связями между классами являются:

• отношение зависимости;
• отношение ассоциации;
• отношение обобщения;
• отношение реализации.

Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.

Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.

Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольником, направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.

Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.

При создании диаграмм классов часто пользуются понятием «стереотип».

Стереотип класса – это элемент расширения словаря UML, который обозначает отличительные особенности в использовании класса. Стереотип имеет название, которое задается в виде текстовой строки. При изображении класса на диаграмме стереотип показывается в верхней части класса в двойных угловых скобках.

В языке UML определены три  основных стереотипа классов:

• граничные классы;
• классы-сущности;
• управляющие классы.

Граничными  классами (boundary classes)  называются  такие  классы, которые  расположены  на  границе  системы  и  всей  окружающей  среды. Это экранные  формы,  отчеты,  интерфейсы  с  аппаратурой (такой  как принтеры или сканеры) и интерфейсы с другими системами.

Классы-сущности (entity classes)  содержат  хранимую  информацию. Они  имеют  наибольшее  значение  для  пользователя,  и  потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных.

Управляющие  классы (control classes)  отвечают  за  координацию действий  других  классов.  Управляющий  класс  отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером.

Построим диаграмму классов  для Интернет-магазина "Vipcom".

Заполнение диаграммы  начнем с определения классов-сущностей. Рассматриваемый сценарий состоит  из:

• самого заказа; 
• покупателя, который делает заказ;
• товаров, которые входят в заказ.

Создадим классы-сущности «Заказ», «Покупатель», «Товар». Поскольку в один заказ может входить много разных комплектующих изделий, и одно комплектующее изделие может входить во много заказов, то введем еще один класс-сущность «Состав заказа».

Добавим отношения между  классами:

• класс «Покупатель» и «Заказ» имеют отношение ассоциации, поскольку данные два класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя. Один покупатель может сделать несколько заказов, каждый заказ поступает только от одного покупателя, поэтому кратность связи со стороны класса «Покупатель» - 1, со стороны «Заказа» - 1..n;
• класс «Заказ» и «Состав заказа» имеют отношение композиции, поскольку строка заказа является частью заказа, и без него существовать не может. В один заказ может входить несколько строк заказа, строка заказа относится только к одному заказу, поэтому кратность связи со стороны «Заказа» - 1, со стороны «Состав заказа» - 1..n;
• класс «Состав заказа» и «Товар»  имеют отношение агрегации, поскольку комплектующие заказа являются частями строки заказа, но и те, и другие, являются самостоятельными классами. Одно комплектующее изделие может входить во много строк заказа, в одну строку заказа входит только одно комплектующее изделие, поэтому кратность связи со стороны «Состав заказа» - 1, со стороны «Товар» - 1..n.

Добавим теперь на диаграмму граничные и  управляющие классы. Рассматриваемый  сценарий - это только одно из действий, которые обеспечивает прецедент "Работа с заказом". Прецедент также  позволяет просмотреть, отредактировать  или удалить заказ. Это означает, что необходимо предусмотреть механизм, который позволяет выбирать необходимое  действие. Создадим для этого граничный  класс «Параметры работы с заказом». Также создадим граничный класс  «Новый заказ», который будет служить для добавления новых заказов. Отношение между этими классами - агрегация,  поскольку в данном случае класс «Новый заказ» рассматривается как часть класса «Параметры работы с заказом», частями которого также будут классы для просмотра, редактирования и удаления заказов. Кратность связи 1 к 1, поскольку в состав класса «Параметры работы с заказом»  входит только один класс «Новый заказ».

Перейдем  теперь к управляющим классам. Добавим  управляющий класс «Администратор» - управляющий класс для обработки потока событий прецедента "Параметры работы с заказами", который будет обеспечивать обработку потока событий для рассматриваемого прецедента. Данный класс будет связан с классами «Новый заказ» и «Заказ». Отношение между классами «Новый заказ» и «Администратор» - однонаправленная ассоциация с кратностью связи 1 к 1, поскольку один экземпляр класса «Новый заказ» взаимодействует только с одним экземпляром класса «Администратор»

Отношение между классами «Администратор»  и «Заказ» однонаправленная ассоциация с кратностью связи 1 к 1..n, поскольку один класс «Администратор» может взаимодействовать с несколькими классами «Заказов».

Построим  диаграмму классов для Интернет-магазина "Vipcom" с помощью Microsoft Visio 2010 (рис.2).

Рисунок 2 – Диаграмма  классов для Интернет-магазина "Vipcom" .

Данная  диаграмма содержит один управляющий класс, четыре класса-сущности и два граничных класса, между которыми установлены связи ассоциации, композиции и агрегации.

3.3. Диаграмма состояний.

Диаграммы состояний используются для описания поведения, реализуемого в рамках варианта использования, или поведения экземпляров  класса (объектов), компонента, узла или  системы в целом. Поведение моделируется черезавтомат, описывающий возможные последовательности состояний экземпляра сущности и переходы между ними на протяжении его жизненного цикла, начиная от создания и заканчивая уничтожением.

Диаграмма состояний (автомат) представляет собой  связный ориентированный граф, вершинами  которого являются состояния, а дуги служат для обозначения переходов  из состояния в состояние.

Под состоянием понимается ситуация в ходе жизни экземпляра сущности, когда эта ситуация удовлетворяет некоторому условию, экземпляр выполняет некоторые операции или ждет наступления некоторого события.

Событие – это спецификация существенного факта, который занимает некоторое положение во времени и в пространстве. В контексте диаграмм состояний событие – это спецификация факта, который может привести к смене состояния. События могут быть внутренними или внешними. Внешние события передаются между системой и актерами. Внутренние события передаются между объектами внутри системы.

В UML можно моделировать четыре вида событий:

• сигналы;
• вызовы;
• истечение промежутка времени;
• изменение состояния.

Состояние отображается в виде прямоугольника со скругленными углами, внутри которого записывается имя. Рекомендуется в качестве имени использовать глаголы в настоящем времени (звонит, печатает, ожидает) или причастия (занято, передано, получено).

Начальное состояние – состояние, в котором находится экземпляр сущности после своего создания или, перейдя в составное состояние. Из начального состояния могут только исходить переходы.