Диаграмма композитной/составной структуры

Доклад

по дисциплине «Объектно-ориентированные языки в ГИС»

на тему: Язык UML. UML-диаграммы.

Выполнили:		студенты группы ИСТ-513 Валиева Э.И. Сулейманова Г.Ф.
Проверил:		доцент каф. ГИС, к.т.н. Ефремова О.А.

Уфа 2012

Содержание

Введение. 3

1. История появления UML. 5

2. Структура языка UML. 5

3.UML диаграммы.. 9

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

3.2 Диаграмма компонентов. 10

3.3 Диаграмма объектов. 11

3.4 Диаграмма композитной/составной структуры.. 12

3.5 Диаграмма развертывания. 12

3.6 Диаграммы пакетов (package diagrams) 13

3.7 Диаграммы активностей (activity diagrams) 14

3.8 Диаграммы случаев использования (use case diagrams) 15

3.9 Диаграммы конечных автоматов (statechart diagrams) 16

3.10 Диаграммы последовательностей (sequence diagrams). 17

3.11 Диаграммы схем взаимодействия (interaction overview diagram) 18

3.12 Диаграммы коммуникаций (communication diagrams) 18

3.13 Временные диаграммы (timing diagrams) 19

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

Заключение. 23

Список литературы.. 24

Введение

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

Рисунок 1 – Ситуация, существовавшая в области технологий программирования до создания языка UML

Рисунок 2 – Ситуация после появления UML

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

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

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

История появления UML

Язык Unified Modelling Language (UML) можно считать результатом довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна.

В 90-х годах наиболее популярными были три объектно-ориентированных подхода:

• OMT (автор Джеймс Рамбо), сильной стороной которого является анализ, а слабой — дизайн;

• OODA (автор Гради Буч) — сильная сторона этого языка — дизайн, а слабая — анализ;

• OOSE (автор Айвар Якобсон) — сильной стороной данного языка является анализ поведения (behavior analysis), однако в остальных областях он достаточно слаб.

В результате соперничества этих методов авторы вышеперечисленных методологий создали унифицированный язык моделирования UML (рис. 1), который унаследовал присутствовавшие в других языках элементы. Далее приведена оригинальная терминология заимствованных/унаследованных элементов языка этой методологии — дело в том, что сейчас существует несколько вариантов переводов этих терминов на русский язык.

Рисунок 3 – UML и его предшественники

Данная унификация преследовала три основные цели:

• моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик;

• разрешение проблем масштабирования в сложных системах;

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

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

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

Рисунок 4 – Структура языка UML

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

Язык UML имеет четыре вида сущностей: структурные, поведенческие, группирующие и аннотационные сущности. Они показаны на втором уровне структурного дерева языка UML, представленного на рисунке 4.

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

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

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

Рисунок 5 – Виды пиктограмм

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

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

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

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

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

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

Рисунок 7 – Виды отношений

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

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

Пометка единица (1) на левом конце линии ассоциации на рисунке 7 означает, что в двунаправленном отношении, наряду с многими работниками участвует один работодатель. Единица и звездочка на правом конце линии означает " единица или больше" (1..*). Если один конец линии ассоциации помечен единицей (1), то пометка на другом конце линий называется кратностью ассоциации. Кратность правого конца ассоциации, показанной на рисунке 7, равна единице или больше.

На линии ассоциации можно также задать кратность равную единице (1), можно указать диапазон кратности: ноль или единица (0..1), много (0..*). Разрешается также указывать кратность определенным числом (например 5). С помощью списков можно задавать и более сложные кратности. Например, список 0..1, 3..4, 6..* означает " любое число объектов кроме 2 и 5".

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

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

Рисунок 8 – Пиктограммы

Интерфейс – это совокупность операций, предоставляемых классом или компонентом. Интерфейс описывает поведение класса или компонента, видимое извне.

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

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

UML диаграммы

Виды UML диаграмм представлено на рисунке 9.

Рисунок 9 – Виды UML диаграмм

Структурные диаграммы:

o диаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных приложений - классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом;

o диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонентаможет быть реализована с помощью множества классов;

o диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;

o диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей - коопераций, композитных компонент и т.д.;

o диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

o диаграммы пакетов (package diagrams) служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

Поведенческие диаграммы:

o диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;

o диаграммы случаев использования(use case diagrams) предназначены для " вытягивания" требований из пользователей, заказчика и экспертов предметной области;

o диаграммы конечных автоматов (state machine diagrams) применяются для задания поведения реактивных систем;

Диаграммы взаимодействий:

§ диаграммы последовательностей (sequence diagrams) используются для моделирования временных аспектов внутренних и внешних протоколов ПО;

§ диаграммы схем взаимодействия (interaction overview diagrams) служат для организации иерархии диаграмм последовательностей;

§ диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой, манере);

§ временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.

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

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

Рисунок 10 – Диаграмма классов

Диаграмма компонентов

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

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

· устройства — узлы системы, в которых данные не обрабатываются.

· процессоры — узлы системы, осуществляющие обработку данных.

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

Рисунок 11 – Диаграмма компонентов фрагмента КИС

Диаграмма объектов

Диаграмма объектов (object diagram) – это снимок объектов системы в какой-то момент времени. Поскольку она показывает экземпляры, а не классы, то диаграмму объектов часто называют диаграммой экземпляров.

Диаграмму объектов можно использовать для отображения одного из вариантов конфигурации объектов (на рисунке 12 показано множество классов, а на рисунке 13 представлено множество связанных объектов.)

Рисунок 12 – Диаграмма классов показывающая структуру класса Party

Рисунок 13 – Диаграмма объектов с примером экземпляра класса Party

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

Диаграмма развертывания

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

Рисунок 15 – Диаграмма развертывания

На диаграмме развертывания, или применения (Deployment diagram), показана конфигурация обрабатывающих узлов, на которых выполняется система, и компонентов, размещенных в этих узлах. Диаграмма развертывания представлена в виде графа с ребрами и вершинами.

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

Диаграммы развертывания обычно включают в себя:

· узлы;

· отношения зависимости и ассоциации.

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

Заключение

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

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

Список литературы

1. Booch G., Rumbaugh J. UML 1.1 Semantics. (http: //www.rational.com/uml/) 1997.

2. Booch G. Object-oriented analysis and design with applications. Second edition. The Benjamin/Cummings Publishing Company, Inc. 1994. 589 p.// Русский перевод: Г.Буч. Объектно-ориентированный анализ и проектирование: с примерами приложений на C++. " Издательство Бином", " Невский диалект", 1998, 560 с., ил.

3. Rumbaugh J., Blacha M. Premerlani W., Eddy F. Lorensen W. Object-Oriented Modeling and Design. Prentice-Hall, Inc., 1991

4.Фаулер, Скотт UML. Основы., СПб.: Символ, 2006, 184 с.

5. Буч Г., Якобсон А., Рамбо Дж. UML 2.0., СПб.: Питер, 2006, 735 с.