История создания UML

Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method.

К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. В январе 1997 был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. В 2003 была принята версия 1.5. 2004 г. – принята версия 2.0

Структура UML

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт использующий графические обозначения для создания абстрактной модели системы, которая называется UML моделью. UML был создан для определения, визуализации, проектирования и документирования по большей части программных систем.

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

Прежде всего, UML наследует техники Booch, OMT и OOSE.

Во-вторых, перекрывает их.

В-третьих, надо отметить, что UML - это стандарт языка, а не стандарт процесса.

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

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

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

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

Диаграммы UML

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

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

· Диаграмма вариантов (прецедентов) использования (use case diagram)

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

· Диаграммы поведения (behavior diagrams)

o Диаграмма состояний (statechart diagram)

o Диаграмма активности (activity diagram)

o Диаграммы взаимодействия (interaction diagrams)

§ Диаграмма последовательности (sequence diagram)

§ Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

o Диаграмма компонентов (component diagram)

o Диаграмма размещения (развертывания) (deployment diagram)

3.1. Диаграмма вариантов (прецедентов) использования (use case diagram)

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:

описывает видимую пользователем функцию,

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

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

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

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

На рис. 3.1.1 показано, что при исполнении прецедента «формирование заказа» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие — рассчитать стоимость заказа.

Рис. 3.1.1. Связи на диаграммах прецедентов