UML. Общие сведения об языке UML.

Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем.

Общие принципы моделирования сложных систем:

• Принцип абстрагирования – в модель включать только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения.
• Принцип многомодельности – никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы.
• Принцип иерархического построения моделей сложных систем: процесс построения модели необходимо рассматривать на разных уровнях абстрагирования или детализации в рамках фиксированных представлений.

 

 

Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования.

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

Назначение языка UML:

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

· Снабдить исходное понятие языка возможностью расширения.

· Описание языка UML не зависит от конкретных языков программирования.

· Описание языка UML должно включать в себе семантический базис для понимания общих особенностей объектно-ориентированного анализа и проектирования.

Общая структура языка UML:

· Семантика языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

· Нотация языка UML. Представляет собой графическую нотацию для визуального представления семантики языка UML.

Семантика определяется для двух видов объектных моделей:

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

· модели поведения (динамические модели):описывают поведение или функционирование объектов системы, включая их методы, взаимодействие и сотрудничество между ними, а также процесс изменения состояний отдельных компонентов и системы в целом.

Формальное описание самого языка UML основывается на общей иерархической структуре модельных представлений:

· Мета-метамодель

· Метамодель

· Модель

· Объекты пользователя

Набор диаграмм для моделирования:

· диаграммы вариантов использования – для моделирования бизнес-процессов организации (требований к системе)

· диаграммы классов – для моделирования статической структуры классов системы и связей между ними

· диаграммы поведения системы:

- диаграммы состояний – для моделирования поведения объектов системы при переходе из одного состояния в другое

- диаграммы деятельностей – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей

- диаграммы взаимодействия – для моделирования процесса обмена сообщениями между объектами.

Существует два вида диаграмм взаимодействия:

1) диаграммы последовательности

2) диаграммы кооперации

· диаграммы реализации:

- диаграммы компонентов – для моделирования иерархии компонентов (подсистем) системы

- диаграммы развертывания – для моделирования физической архитектуры системы.

Процесс объектно-ориентированного анализа программирования в контексте языка UML получил специальное название – рациональный унифицированный процесс.

 

33. UML. Диаграмма вариантов использования (usecasediagram)

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

Цели разработки диаграммы:

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

· Сформулировать общие требования к функциональному поведению проектируемой системы.

· Разработать исходную концептуальную модель системы для её последующей детализации в форме логических и физических моделей.

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

Базовыми элементами являются:

· Вариант использования – это последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии её с соответствующим актером.

Графическое обозначение варианта использования.

· Актер- это любая внешняя по отношению к системе сущность, которая взаимодействует с системой и использует её функциональные возможности для достижения определенных целей или решения частных задач.

Графическое обозначение актера

· Интерфейс – служит для спецификации параметров модели, которые видимы из вне без указания их внутренней структуры. Приминительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для актеров.

Графическое обозначение интерфейса:

Датчик Устройство считывания штрих-кода

· Примечание – предназначены для включения произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта.

Графическое обозначение примечания.

На диаграмме вариантов использования изображается 4 типа связей:

· Отношение ассоциации

· Отношение расширения

· Отношение обобщения

· Отношение включения

Отношение ассоциации служит для обозначения специфической роли актера в отдельном варианте использования. Обозначается сплошной линией между актером и вариантом использования. Между однородными связи не существует.

1.

Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Рисуется только между двумя вариантами использования.

Обозначается пунктирной линией со стрелкой, направленной от базового варианта использования к включаемому.

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

 

 

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

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

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

В рамках одного проекта строится одна диаграмма вариантов использования.

 

UML.Диаграмма классов.

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

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

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

<Имя_пакета>::<Имя_класса>

Например:«Банк::Счет».

Атрибуты класса: <квантор видимости><имя атрибута>[кратность]:<тип атрибута> = <исходное значение>{строка-свойство}

Квантор видимости может принимать одно из трех возможных значений и отображается при помощи соответствующих специальных символов:

· «+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма;

· «#» обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса;

· «-» обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

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

Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. В общем случае кратность записывается в форме строки текста в квадратных скобках после имени соответствующего атрибута:

[нижняя_граница1.. верхняя_граница1, нижняя_граница2.. верхняя_грашца2,..., нuжняя_гpaнuцak.. верхняя_границаk],

Например: [0..1]-кратность атрибута может принимать значение 0 или 1.

[1..3,5,7] – кратность атрибута может принимать любое значение из чисел 1, 2, 3, 5, 7.

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

Исходное значение служит для задания начального значения соответствующего атрибута в момент создания отдельного экземпляра класса.

Например: цвет: Color=(255,0,0)

имя_сотрудника [1..2]: String=Иван Иванович.

Строка-свойство служит для указания значений атрибута, которые не могут быть изменены в программе при работе с данным типом объектов. (в {} скобках).

Пример: «заработная_плата: Currency = $500» означает, что при создании нового экземпляра «Сотрудник» (например, прием на работу нового сотрудника) для него устанавливается по умолчанию заработная плата в $500.

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

<квантор видимости><имя операции>(список параметров):<выражение типа возвращаемого значения>{строка-свойство}

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

Список параметров является перечнем разделенных запятой формальных параметров, каждый из которых может быть представлен в следующем виде:

<вид параметра><имя параметра>:<выражение типа>=<значение параметра по умолчанию>.

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

Строка-свойство служит для указания значений свойств, которые могут быть применены к данному элементу. Строка-свойство не является обязательной, она может отсутствовать, если никакие свойства не специфицированы.

Например: +создать()

+нарисовать(форма:Многоугольник=прямоугольник, цвет, цвет_заливки:Color=(0,0,255))

 

Отношения между классами

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

· зависимости (dependency relationship);

· ассоциации (association relationship);

· обобщения (generalization relationship)

· реализации ( практически не используется)

Отношения зависимости

Показывает, что при изменении в одном классе (источник) происходит изменение в другом классе (клиент).

Клиент Источник

 

Класс С-объект, Классы А и Б – источники.

Ключевые слова отнош.зависимости (стереотипы):

• «access» - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
• «bind» - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
• «derive» - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника; «import» — открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
• «refine» - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

2.Отношения ассоциации. Показывает существование связи между двумя классами.

Бинарная связь

Тренарная связь

Исключающая ассоциация между 3 классами

Отношения ассоциации имеют 2 разновидности:

· Агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. При уничтожении целого, часть не уничтожается. (например: Коллекция----Монеты)

 

· Композиции является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения «часть-целое», при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, то есть с уничтожением целого уничтожаются и все его составные части. (например:Накладная----Строки накладной)

 

3.Отношения обобщения.

 

Показывает, что некоторый класс предок обобщает схожие классы потомки, которые наследуют все атрибуты и операции класса «предок».

В качестве ограничений могут быть использованы следующие ключевые слова языка UML:

o {complete} - означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может;

 

o {disjoint} - означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов;

 

o {incomplete}- означает случай, противоположный первому, то есть, что на диаграмме указаны не все классы-потомки. В дальнейшем возможно восполнить их перечень не изменяя уже построенную диаграмму;

 

 

o {overlapping} - означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

 

 

 

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

Описывают процесс изменения состояния только одного класса.Назначение:описать возможные последовательности состояний и переходов, характеризующих жизненный цикл класса. Диагр.состояний бывает несколько штук в рамках одного проекта. Зависит от количества классов на диаграмме классов.

Диаграмма состояний основана на теории автоматов:

1. Автомат не запоминает историю перемещения из состояния в состояние. Другими словами, автомат «забывает» все состояния, которые предшествовали текущему в данный момент времени. Образно говоря, существует непрозрачная стена, отделяющая текущее состояние от прошлого поведения объекта.

2. В каждый момент времени автомат может находиться в одном и только в одном из своих состояний. Это означает, что формализм автомата предназначен для моделирования последовательного поведения, когда объект в течение своего жизненного цикла последовательно проходит через все свои состояния. При этом автомат может находиться в отдельном состоянии как угодно долго, если не происходит никаких событий.

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

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

5. Граф автомата не должен содержать изолированных состояний и переходов. Это условие означает, что для каждого из состояний, кроме начального, должно быть определено предшествующее состояние. Каждый переход должен обязательно соединять два состояния автомата. Допускается переход из состояния в себя, такой переход еще называют «петлей».

6. Автомат не должен содержать конфликтующих переходов, т. е. таких переходов из одного и того же состояния, когда объект одновременно может перейти в два и более последующих состояния (кроме случая параллельных подавтоматов). В языке UML исключение конфликтов возможно на основе введения так называемых сторожевых условий.

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

Действие – некоторая атомарная операция, выполнение которой приводит к изменению состояния или возврату некоторого значения («истина» или «ложь»).

Имя состояния представляет собой строку текста, которая раскрывает содержательный смысл данного состояния. Имя всегда записывается с заглавной буквы. 9Глагол или причастие). Имя может и отсутствовать.

Список внутренних действий

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

<метка-дёйствия '/' выражение-действия>

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

Если список выражений действия пустой, то разделитель в виде наклонной черты '/' может не указываться.

Перечень меток действия имеет фиксированные значения в языке UML, которые не могут быть использованы в качестве имен событий. Эти значения следующие:

• entry — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);
• exit — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);
• do — эта метка специфицирует выполняющуюся деятельность ("doactivity"), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия.

В последнем случае при завершении события генерируется соответствующий результат;

• include — эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата.

Состояние бывает 2 типов:

· Начальное – представляет собой процесс инициации. На одной диаграмме только 1 состояние.

· Конечное – может быть несколько штук. Не содержит последействий.

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

<сигнатура события>'['<сторожевое условие>']' <выражение действия>.

Имя события идентифицирует каждый отдельный переход на диаграмме состояний и может содержать строку текста, начинающуюся со строчной буквы.

Если вся стрелка (переход) подписана, то он называется триггерным, в противном случае – нетригеррным.

Сторожевое условие (guardcondition), всегда записывается в прямых скобках, представляет собой некоторое булевское выражение (1/0, да/нет).

Состояния бывают 2 видов:

· Составное (имеет внутреннее состояние)

· подсоставное

Принято выделять последовательное и параллельное подсостояние.

Последовательное

Параллельное

Диаграмма деятельности

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

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

Основными элементами являются:

1.состояние действия – специальный случай состояния.

2.переход – обозначается стрелкой над которой может быть записано сторожевое условие.

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