15. Язык uml. Назначение.

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

Принципы построения моделей:

1. Идея иерархичности.

2. Идея «черного ящика».

3. Использование визуализации.

4. Абстрагирование частей системы.

5. Принцип формализации.

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

Язык UML предназначен для решения следующих задач:

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

2. Снабдить исходные понятия языка UML возможностью расширения и спе­циализации для более точного представления моделей систем в конкретной предметной области

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

4. Описание языка UML должно включать в себя семантический базис для по­нимания общих особенностей ООАП.

5. Поощрять развитие рынка объектных инструментальных средств.

6. Способствовать распространению объектных технологий и соответствую­щих понятий ООАП.

7. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

Структура языка UML

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

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

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

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

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

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

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

• - Модель

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

16. Статические диаграммы uml (варианты использования, классов)

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

Разработка диаграммы вариантов использования преследует цели:

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

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

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

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

С уть данной диаграммы состоит в следующем: проектируемая система пред­ставляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаи­модействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими слова­ми, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

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

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

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

Актеры

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

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

Отношения на диаграмме вариантов использования

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

В языке UML имеется несколько стандартных видов отношений между ак­терами и вариантами использования:

Отношение ассоциации (association relationship)

Отношение расширения (extend relationship)

Отношение обобщения (generalization relationship)

Отношение включения (include relationship)

Поток действий – это сценарии вариантов использования.

Диаграмма классов (class diagram) служит для представления статической струк­туры модели системы в терминологии классов ООП. Диаграмма клас­сов может также содержать интерфейсы, пакеты, отношения и даже от­дельные экземпляры, такие как объекты и связи.

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

Класс может не иметь экземпляров или объектов. В этом случае он называ­ется абстрактным классом.

Во второй сверху секции прямоугольника класса записываются его атрибу­ты (attributes) или свойства.

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

<квантор видимости><имя атрибута>[кратность]:

<тип атрибута> = <исходное значение>{строка-свойство}

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

-Символ "+" обозначает атрибут с областью видимости типа общедоступ­ный (public).

-Символ "#" обозначает атрибут с областью видимости типа защищенный (protected).

- знак "-" обозначает атрибут с областью видимости типа за­крытый (private).

Имя атрибута является единст­венным обязательным элементом синтаксического обозначения атрибута.

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

В качестве примера рассмотрим следующие варианты задания кратности атрибутов.

• [0..1] означает, что кратность атрибута может принимать значение 0 или 1. При этом 0 означает отсутствие значения для данного атрибута.

• [0.. *] означает, что кратность атрибута может принимать любое положи­тельное целое значение большее или равное 0. Эта кратность может быть записана короче в виде простого символа — [*].

• [1.. *] означает, что кратность атрибута может принимать любое положи­тельное целое значение большее или равное 1.

Опе­рации класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого опе­рацией значения и, возможно, строка-свойство данной операции:

<квантор видимости><имя операции>(список параметров):

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

Квантор видимости(public, protected,private)

Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами.

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

• Отношение зависимости (dependency relationship)

• Отношение ассоциации (association relationship)

• Отношение обобщения (generalization relationship)

отражает взаимосвязи между объектами соответст­вующих классов.

• Отношение реализации (realization relationship)

Отношение зависимости-отношение между двумя элементами модели, которое не является отношением ассоциации, обобщения или реализации.

На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зави­симости к независимому классу или классу-источнику

Для отношения зависимости предопределены ключевые слова, ключевые слова (стереотипы)

Примеры стереотипов для отношения зависимости представ­лены ниже:

• "access" — служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;

• - "bind" — класс-клиент может использовать некоторый шаблон для своей последующей параметризации;

• "derive" — атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;

• "import" — открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредствен­но в нем;

• "refine" — указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется до­полнительная информация в ходе работы над проектом.

Отношение ассоциации соответствует наличию некоторого отношения между классами.

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами — классом "Компания" и классом "Со­трудник"

Отношение обобщения описывает иерархи­ческое строение классов и наследование их свойств и поведения.

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

Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы.

Шаблон (template) или параметризованный класс (parametrized class) предна­значен для обозначения такого класса, который имеет один (или более) не­фиксированный формальный параметр.