Унифицированный язык моделирования UML

Лекция 1

Основные этапы развития UML

· Отдельные языки объектно-ориентированного моделирования

стали появляться в период между серединой 1970-х и концом

1980-х годов, когда различные исследователи и программисты предлагали свои подходы к объектно-ориентированному

анализу и проектированию (ООАП). В период между 1989-1994

гг. общее число наиболее известных языков моделирования

возросло с 10 до более чем 50. Многие пользователи

ссппыыттыыввааллии ссееррььееззнныыее ззааттррууддннеенниияя ппррии ввыыббооррее яяззыыккаа ООООААПП,,

поскольку ни один из них не удовлетворял всем требованиям,

предъявляемым к построению моделей сложных систем. Принятие отдельных методик и графических нотаций в качестве

стандартов (IDEF0, IDEF1X) не смогло изменить сложившуюся

ситуацию непримиримой конкуренции между ними в начале 90-х

годов, которая получила название "войны методов".

Многообразие методов 90-х годов, которые повлияли на UML

Основные этапы развития UML

К середине 1990-х некоторые из методов были существенно улучшены и приобрели самостоятельное значение при решении различных задач ООАП. Наиболее известными в этот период становятся:

· Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch Lite (позже - Booch'93).

· Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling Technique - ОМТ (позже - ОМТ-2).

ееттоодд ААййвваарраа ДДжжееккооббссооннаа IIvvaarr JJaaccoobbssoonn)),, ппооллууччииввшшиийй ннааззввааннииее Object-Oriented Software Engineering - OOSE.

Каждый из этих методов был ориентирован на поддержку отдельных этапов ООАП:

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

· метод ОМТ-2 наиболее подходил для анализа процессов обработки данных в информационных системах.

· метод Booch'93 нашел наибольшее применение на этапах проектирования и разработки различных программных систем.

Основные этапы развития UML

· История развития языка UML берет начало с октября 1994 года,

когда Гради Буч и Джеймс Румбах из Rational Software

Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно

популярны, совместная работа была направлена на изучение

всех известных объектно-ориентированных методов с целью

объединения их достоинств. При этом Г. Буч и Дж. Румбах

ооссррееддооттооччииллии ууссииллиияя ннаа ппооллнноойй ууннииффииккааццииии ррееззууллььттааттоовв

своей работы.

· Проект так называемого унифицированного метода (Unified

Method) версии 0.8 был подготовлен и опубликован в октябре

1995 года. Осенью того же года к ним присоединился А.

Джекобсон, главный технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя

предыдущими.

Основные этапы развития UML

Начиная работу по унификации своих методов, Г. Буч, Дж.

Румбах и А. Джекобсон сформулировали следующие

требования к языку моделирования. Он должен:

· Позволять моделировать не только программное

обеспечение, но и более широкие классы систем и бизнес-

приложений, с использованием объектно-ориентированных

понятий.

· Явным образом обеспечивать заимосвязь между базовыми

понятиями для моделей концептуального и физического

уровней.

· Обеспечивать масштабируемость моделей, что является

важной особенностью сложных многоцелевых систем.

· Быть понятным аналитикам и программистам и

поддерживаться специальными инструментальными

средствами, реализованными на различных компьютерных

платформах.

Основные этапы развития UML

· Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML версии 0.9 (июнь 1996 г.) и версии

.91 (октябрь 1996 г.). Эти документы послужили своеобразным катализатором для широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.

Основные этапы развития UML

· В это же время компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix,Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к

оояяввллееннииюю ввееррссииии 11..00 яяззыыккаа UUMMLL..

· В январе 1997 года был опубликован документ с описанием языка UML 1.0. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.

· В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group).

· С поддержкой консорциума OMG была разработана версия UML 1.3. Она описана в соответствующем документе - "OMG Unified Modeling Language Specification", опубликованном в июне 1999 года.

История развития языка UML

Основные этапы развития UML

· Сейчас разработчики используют версию UML 2.0

· Статус языка UML определен как ткрытый для всех предложений по его

доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо. В то же время аббревиатура UML, как и некоторые другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев.

Основные определения языка UML

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

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

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

Революционные перемены в области технологий программирования, вызванные появлением языка

ML.

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

а ис. б иаграммы и спецификации языка UML вязали исходный текст программы с

характеристиками объекта автоматизации. При этом UML диаграммы опираются на теоретический фундамент в виде теории множеств и теории графов.

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

Основные определения языка UML

· UML —это формальный язык, поэтому он предоставляет словарь и правила комбинирования слов в этом словаре.

· UML — это язык визуализации. Написание моделей на UML преследует одну простую цель — облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Yx» и т.п. будут достаточно прозрачны).

· UML — это язык спецификаций и точных определений. В этом смысле ооддееллииррооввааннииее ннаа UUMMLL ооззннааччааеетт ппооссттррооееннииее ммооддееллеейй,, ккооттооррыыее ттооччнныы,,

недвусмысленны и полны.

· UML — это язык конструирования. UML не является визуальным языком программирования, но модели в терминах UML могут быть отображены на определенный набор объектно-ориентированных языков программирования. UML предоставляет возможности прямого (существующая модель Ò новый код) и обратного (существующий код Ò новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk.

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

Основные определения языка

UML

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

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

Основные определения языка UML

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

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

Основные определения языка UML

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

ссххооддннааяя ииллии ппееррввооннааччааллььннааяя ммооддеелльь ссллоожжнноойй системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы.

Основные определения языка UML

Процесс ООАП можно представить как поуровневый спуск от

наиболее общих моделей и представлений

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

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

этом на каждом из этапов ООАП данные модели

последовательно дополняются все большим количеством

деталей, что позволяет им более адекватно отражать

ааззллииччнныыее аассппееккттыы ккооннккррееттнноойй ррееааллииззааццииии ссллоожжнноойй ссииссттееммыы..

Физическая модель в терминах ООАП и языка UML отражает

компонентный состав проектируемой системы с точки

зрения ее реализации на некоторой технической базе и

вычислительных платформах конкретных производителей.

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

Программист Отношения между Компонентами Программного обеспечения

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

Системный администратор Топология взаимосвязей и Коммуникаций компонентов системы

Задачи языка UML

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

1. Предоставить в распоряжение ользователей легко воспринимаемый и

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

Задачи языка UML

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

онкретной предметной области В описании языка UML заложен механизм расширения базовых понятий, который является самостоятельным элементом языка и имеет собственное описание в форме правил расширения.

Задачи языка UML

3. Описание языка UML должно поддерживать

такую спецификацию моделей, которая не

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

инструментальных средств

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

4. Описание языка UML должно включать в

себя семантический базис для

понимания общих принципов ООАП.

5. Интегрировать в себя новейшие и

наилучшие достижения практики

ООАП.

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

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

частей, таких как:

ееммааннттииккаа яяззыыккаа UUMMLL.. ррееддссттааввлляяеетт

собой некоторую метамодель, которая определяет абстрактный синтаксис и

семантику понятий объектного

моделирования на языке UML.

· Нотация языка UML. Представляет собой

графическую нотацию для визуального

представления семантики языка UML.

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

· Структурные модели, известные также как статические модели, описывают структуру

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

отношения.

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

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

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

· Модель

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

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

· Метамодель является экземпляром или

конкретизацией мета-метамодели.

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

уровень является более конструктивным, чем

ррееддыыддуущщиийй,, ппооссккооллььккуу ооббллааддааеетт ббооллееее

развитой семантикой базовых понятий. Все основные понятия языка UML - это

понятия уровня метамодели.

· Примеры таких понятий - класс, атрибут,

операция, компонент, ассоциация и многие

другие.

· Модель в контексте языка UML является экземпляром метамодели в том смысле, что любая конкретная модель системы должна использовать только понятия метамодели, конкретизировав их применительно к данной ситуации. Это уровень для описания

ннффооррммааццииии оо ккооннккррееттнноойй ппррееддммееттнноойй области.

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

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

тносительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 100-0000".

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

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

· Первый иерархический уровень языка UML составляют

сущности, отношения между сущностями и наглядные

диаграммы.

· Язык UML имеет четыре вида сущностей (2 иерархический

уровень):

– структурные, – поведенческие, – группирующие

ааннннооттааццииоонннныыее..

· На третьем уровне дерева показано, что понятие "структурные

сущности" является именем семи видов пиктограмм, которые

называются классами, интерфейсами, кооперациями,

прецедентами, активными классами, компонентами и

узлами.

· Поведенческие сущности делятся на два вида диаграмм:

диаграммы взаимодействия и автоматы.

· Группирующие сущности имеют только один вид пиктограмм,

называемых пакетами.

· Аннотационные сущности также имеют один вид пиктограмм,

называемых примечаниями.

Сущности

Структурные сущности являются существительными языка.

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

рямоугольника, включающего имя класса, имена трибутов, операций, примечание;

· интерфейсы (Interface) — это набор операций, которые определяют сервис класса или компоненты. Интерфейс графически изображается в виде круга и, как правило, присоединяется к классу или к компоненту, который реализует данный интерфейс;

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

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

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

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

модели;

· активные классы (Active class) — это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Графически такой класс изображается

аакк ккллаасссс сс жжииррнноойй ггррааннииццеейй;;

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

Поведенческие сущности

· Поведенческие сущности — это динамические части моделей

UML.

· взаимодействия (Interaction) — включают набор сообщений, которыми обмениваются указанные объекты с целью

достижения определенной цели. Взаимодействие описывается

в контексте кооперации и изображается направленной линией,

маркируется именем операции сверху;

· автоматы (State machine) — спецификации поведения,

представляющие собой последовательности состояний,

через которые проходит в течение своей жизни объект, или

взаимодействие в ответ на происходящие события. Автомат

прикреплен к исходному элементу (классу, кооперации или

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

углами.

руппирующие и

аннотационные сущности

· Группирующие сущности — это организационные

составляющие моделей UML. К ним относятся пакеты

(Package) — обобщенный механизм для организации

элементов в группы. Структурные, поведенческие,

группирующие сущности могут быть помещены в пакет. Пакеты

являются чисто концептуальными сущностями — в отличие от

компонентов, существующих во время исполнения программы.

Изображается пакет как папка с ярлыком сверху и, как правило,

имеет только имя.

· Аннотационные сущности это пояснительные

составляющие моделей UML, к которым относятся примечания

(Note) — пояснительные элементы языка. Они содержат текст комментария, изображаются в виде прямоугольника с загнутым

уголком страницы.

Отношения

1. .

Отношения

· Зависимость - это семантическое отношение между двумя сущностями, такое при котором изменение одной (первичной) сущности вызывает изменение семантики другой, зависимой сущности.

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

ррааввоомм ккооннццее ллииннииии ооззннааччааеетт ""ееддииннииццаа ииллии ббооллььшшее"" ((11....**))..

· Обобщение - это однонаправленное отношение, называемое "потомок/прародитель", в котором объект "потомок" может быть подставлен вместо объекта прародителя (родителя или предка). Потомок наследует структуру и поведение своего родителя. Стрелка всегда указывает на родителя.

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

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

Диаграмма прецедентов (use case diagram)

· Диаграммы прецедентов (диаграммы вариантов использования,

use case diagrams) – это обобщенная модель

функционирования системы в окружающей среде.

· Сущности, с которыми взаимодействует система в процессе

своей работы, называются экторами

· Эктор (actor) - это множество логически связанных ролей,

сполняемых при взаимодействии с прецедентами или

сущностями (система, подсистема или класс). Эктором может

быть человек или другая система, подсистема или класс,

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

· Эктор – это кто-то (или что-то) внешний по отношению к

компьютерной системе, кто взаимодействует с ней.

· Диаграммы прецедентов относятся к той группе диаграмм,

которые представляют динамические или поведенческие

аспекты системы. Это отличное средство для достижения

взаимопонимания между разработчиками, экспертами и

конечными пользователями продукта

Диаграмма прецедентов (use case diagram)

Графически эктор изображается либо " человечком ", либо символом класса с соответствующим стереотипом

· Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).

· Прецедент (use case) - описание множества последовательных событий (включая варианты),

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

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

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

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

Пример диаграммы прецедентов

Пример диаграммы прецедентов

Цели создания диаграмм прецедентов:

· определение границы и контекста

моделируемой предметной области на

ранних этапах проектирования;

ооррммииррооввааннииее ооббщщиихх ттррееббоовваанниийй кк

поведению проектируемой системы;

· разработка концептуальной модели системы

для ее последующей детализации;

· подготовка документации для

взаимодействия с заказчиками и

пользователями системы.

Диаграмма классов (class diagram)

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

ннффооррммаацциияя сс ддииааггррааммммыы ккллаассссоовв ннааппрряяммууюю отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++). Таким образом, диаграмма классов -конечный результат проектирования и отправная точка процесса разработки.