Программы поддержки языка UML

Оглавление

 

 

 

 
Введение

Большинство существующих методов  объектно-ориентированного анализа  и проектирования (ООАП) включают как  язык моделирования, так и описание процесса моделирования. Язык моделирования - это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс - это описание шагов, которые необходимо выполнить при разработке проекта

 

 

 

 

 

 

 

 

 

 

 

 

 

Общая характеристика языка UML

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

Краткая история UML

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

По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

UML – это язык

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

Следует подчеркнуть, что UML – это  именно язык, а не метод. Он объясняет, из каких элементов создавать  модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует  разрабатывать. Чтобы создать метод  на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process.

 

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

Язык UML имеет сложную иерархическую  структуру, показанную на Рисунке 3.2.

 

Рисунок 3.2

 

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

На Рисунке 3.3 в качестве примеров показаны пять видов пиктограмм – класс, актер, прецедент, пакет и примечание.

 

Рисунок 3.3

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

Рисунок 3.4

 

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

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

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

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

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

Рассмотрим  теперь пиктограммы отношений, используемых в UML диаграммах. Однонаправленные отношения представляются на UML диаграммах стрелками различных видов, а двунаправленное отношение представляется линией (Рисунок 3.5).

Рисунок 3.5

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

Ассоциация – это структурное двунаправленное отношение, описывающее совокупность взаимоотношений между объектами. Пометка единица (1) на левом конце линии ассоциации означает, что в двунаправленном отношении, наряду с многими работниками участвует один работодатель. Единица и звездочка на правом конце линии означает "единица или больше" (1..*). Если один конец линии ассоциации помечен единицей (1), то пометка на другом конце линий называется кратностью ассоциации. Кратность правого конца ассоциации, равна единице или больше. На линии ассоциации можно также задать кратность равную единице (1), можно указать диапазон кратности: ноль или единица (0..1), много (0..*). Разрешается также указывать кратность определенным числом (например 5). С помощью списков можно задавать и более сложные кратности. Например, список 0..1, 3..4, 6..* означает "любое число объектов кроме 2 и 5".Частным случаем ассоциации является отношение типа "часть/целое". Отношение такого типа называется агрегированием. В языке UML оно причислено к отношениям вида "имеет". Агрегирование изображается в виде ассоциации с незакрашенным ромбом со стороны целого, как показано на Рисунке 3.6

Рисунок 3.6

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

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

Рисунок 3.7

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

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

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

UML диаграммы

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

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

Рисунок 3.8

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

Рисунок 3.9

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

Программы поддержки языка UML

Мы рассмотрели лишь отдельные  фрагменты языка UML. Они дают общее  представление о языке и могут  быть использованы как вспомогательный материал при его изучении по специальной литературе по языку UML. Однако, если пользоваться только литературными источниками, то очень трудно усвоить синтаксис и семантику языка UML. Наилучший способ изучения языка UML заключается в создании UML диаграмм для конкретных систем с помощью инструментальных программ поддержки. Наиболее известной программой поддержки языка UML является пакет Rational Rose 2000. Однако, существуют решения других компаний, например Microsoft Visio и GentleWare Poseidon.

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

Диаграммой классов в терминологии UML называется диаграмма, на которой  показан набор классов (и некоторых других сущностей, не имеющих явного отношения к проектированию БД), а также связей между этими классами (иногда термин relationship переводится на русский язык не как “связь”, а как “отношение”). Кроме того, диаграмма классов может включать комментарии и ограничения. Ограничения могут неформально задаваться на естественном языке или же могут формулироваться на языке OCL (Object Constraints Language), который является частью общей спецификации UML, но, в отличие от других частей языка, имеет не графическую, а линейную нотацию. Мы затронем эту тему ниже немного более подробно.

Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой.

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

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

Рисунок 3.10

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

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

Рисунок 3.11

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

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

Объекты класса-потомка могут использоваться везде, где могут использоваться объекты класса-предка. Это свойство называют полиморфизмом по включению, имея в виду, что объекты потомка можно считать включаемыми в класс-предок. Графически обобщения изображаются в виде сплошной линии с большой незакрашенной стрелкой, направленной к суперклассу. На Рисунке 3.12 показан пример иерархии одиночного наследования: у каждого подкласса имеется только один суперкласс.

 
Рисунок 3.12

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

 
Рисунок 3.13

На этой диаграмме классы Студент и Преподаватель порождены из одного суперкласса «Человек Из Университета». Но как это часто случается, многие студенты уже в студенческие годы начинают преподавать, так что могут существовать такие два объекта классов Студент и Преподаватель, которым соответствует один объект класса «Человек Из Университета». Итак, среди объектов класса Студент могут быть преподаватели, а некоторые преподаватели могут быть студентами. Мы можем определить класс «Студент Преподаватель» путем множественного наследования от суперклассов Студент и Преподаватель. Объект класса «Студент Преподаватель» обладает всеми свойствами и операциями классов Студент и Преподаватель, и может быть использован везде, где могут использоваться объекты этих классов. Так что полиморфизм по включению продолжает работать.

Но множественное наследование, помимо того, что не слишком часто  требуется на практике, порождает ряд проблем, из которых одной из наиболее известных является проблема именования атрибутов и операций в подклассе, полученном путем множественного наследования. Например, предположим, что при образовании подклассов Студент и Преподаватель в них обоих был создан атрибут с именем «номер Комнаты». Очень вероятно, что для объектов класса Студент значениями этого атрибута будут номера комнат в студенческом общежитии, а для объектов класса Преподаватель – номера служебных кабинетов. Как быть с объектами класса «Студент Преподаватель», для которых существенны оба одноименных атрибута? На практике применяется одно из следующих решений:

1. запретить образование подкласса «Студент Преподаватель», пока в одном из суперклассов не будет произведено переименование атрибута «номер Комнаты»;
2. наследовать это свойство только от одного из суперклассов, так что, например, значением атрибута «номер Комнаты» у объектов класса «Студент Преподаватель» всегда будут номера служебных кабинетов;
3. унаследовать в подклассе оба свойства, но автоматически переименовать оба атрибута, чтобы прояснить их смысл; назвать их, например, «номер Комнаты Студента» и «номер Комнаты Преподавателя».

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

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

Связи-ассоциации

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

С понятием ассоциации связаны четыре важных дополнительных понятия: имя, роль, кратность и агрегация. Во-первых, ассоциации может быть присвоено имя, характеризующее природу связи. Смысл имени уточняется черным треугольником, располагаемым над линией связи справа или слева от имени ассоциации. Этот треугольник указывает направление, в котором должно читаться имя связи. Пример именованной ассоциации показан на Рисунке 3.14. Треугольник означает, что именованная ассоциация должна читаться как “Студент учится в Университете”.

Рисунок 3.14

Другим способом именования ассоциации является указание роли каждого класса, участвующего в этой ассоциации. Роль класса задается именем, помещаемым под линией ассоциации ближе к данному классу. На Рисунке 3.15 показаны две ассоциации между классами Человек и Университет, в которых эти классы играют разные роли. Как мы видим, объекты класса Человек могут выступать в роли РАБОТНИКОВ при участии в ассоциации, в которой объекты класса Университет играют роль НАНИМАТЕЛЯ. В другой ассоциации объекты класса Человек играют роль СТУДЕНТА, а объекты класса УНИВЕРСИТЕТ – в роли ОБУЧАЮЩЕГО.

Рисунок 3.15 

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

Кратностью (multiplicity) роли ассоциации называется характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации (в UML экземпляр ассоциации называется соединением – link). Наиболее распространенным способом задания кратности роли ассоциации является указание конкретного числа или диапазона. Например, указание “1” говорит о том, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, причем в каждом экземпляре ассоциации может участвовать ровно один объект класса с данной ролью. Указание диапазона “0..1” говорит о том, что не все объекты класса с данной ролью обязаны участвовать в каком-либо экземпляре данной ассоциации, но в каждом экземпляре ассоциации может участвовать только один объект. Аналогично, указание диапазона “1..*” говорит, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должен участвовать хотя бы один объект (верхняя граница не задана). Толкование диапазона “0..*” является очевидным расширением случая “0..1”.

В более сложных (но крайне редко  встречающихся на практике) случаях  определения кратности можно  использовать списки диапазонов. Например, список “2, 4..6, 8..*” говорит, что все объекты класса с указанной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должны участвовать два, от четырех до шести или более восьми объектов класса с данной ролью (Рисунок 3.16).

 
Рисунок 3.16

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

Обычная ассоциация между двумя  классами характеризует связь между  равноправными сущностями: оба класса находятся на одном концептуальном уровне. Иногда в диаграмме классов требуется отразить тот факт, что ассоциация между двумя классами имеет специальный вид “часть-целое”. В этом случае класс “целое” имеет более высокий концептуальный уровень, чем класс “часть”. Ассоциация такого рода называется агрегатной. Графически агрегатные ассоциации изображаются в виде простой ассоциации с незакрашенным ромбом на стороне класса-“целого”. Простой пример агрегатной ассоциации показан на Рисунке 3.17.

 
Рисунок 3.17

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

Бывают случаи, когда связь “части”  и “целого” настолько сильна, что  уничтожение “целого” приводит к уничтожению всех его “частей”. Агрегатные ассоциации, обладающие таким свойством, называются композитными, или просто композициями. При наличии композиции объект-часть может быть частью только одного объекта-целого (композита). При обычной агрегатной ассоциации “часть” может одновременно принадлежать нескольким “целым”. Графически композиция изображается в виде простой ассоциации, дополненной закрашенным ромбом со стороны “целого”. Пример композитной агрегатной ассоциации показан на Рисунке 3.18.

 
Рисунок 3.18

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

Заметим, что в контексте проектирования реляционных БД агрегатные и в  особенности композитные ассоциации влияют только на способ поддержки ссылочной целостности. В частности, композитная связь является явным указанием того, что ссылочная целостность между “целым” и “частями” должна поддерживаться путем каскадного удаления частей при удалении целого. При наличии простой ассоциации между двумя классами предполагается возможность навигации между объектами, входящими в один экземпляр ассоциации. Если известен конкретный объект-студент, то должна обеспечиваться возможность узнать соответствующий объект-университет. Если известен конкретный объект-университет, то должна обеспечиваться возможность узнать все соответствующие объекты-студенты. Другими словами, если не оговорено противное, то навигация по ассоциации может проводиться в обоих направлениях. Однако бывают случаи, в которых желательно ограничить направление навигации для некоторых ассоциаций. В этом случае на линии ассоциации ставится стрелка, указывающая направление навигации. Возможный пример показан на Рисунке 3.19.