ТРПО-лекции

Скачано с сайта http://ivc.clan.su

Рис. 1-17. Класс ассоциа-

ции как участник другой ассоциации

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

Если требуется создание нескольких или многих объектов для одной и той же пары участников, используется отдельный класс. Пусть необходимо регистрировать результаты не только основного экзамена, но ещѐ двух дополнительных, которые могут сдавать некоторые студенты. Для решения задачи класс ассоциации преобразован в обычный класс, как показано на рис. 1-18.

Рис. 1-18. Диаграмма с

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

Здесь класс Экзамен уже не является классом ассоциации. Это обычный класс, который участвует в трѐх следующих ассоциациях:

1.Студент – Экзамен: Один студент не сдаѐт экзаменов вообще или экзаменуется не более трѐх раз.

2.Дисциплина – Экзамен: По одной дисциплине проводится много экзаменов.

3.Преподаватель – Экзамен: Один преподаватель (являющийся экзаменатором) принимает много экзаменов.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 1-19. При-

мер делегирования

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

Отношения между актѐрами и вариантами использования

Отношение между актѐром и прецедентом называют коммуникативной ассоциаци-

ей (communicate association).

Обычно отношение направлено от актѐра к прецеденту (рис. 1-20).

Рис. 1-20. Коммуникативная ассоциация

Между прецедентами существует отношение зависимости двух типов:

1.Включение (include relationship).

2.Расширение (extend relationship).

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 23

дент никогда не существует автономно, он всегда рассматривается как часть базозового прецедента.

В UML отношение включения обозначается в виде зависимости со стереотипом <<include>>, которая направлена от базового к включаемому прецеденту. Пример отношения включения показан на рис. 1-21.

Рис. 1-21. Пример включения

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

что базовый прецедент не полон без включаемого прецедента.

Отношение расширения добавляет к базовому прецеденту дополнительное поведение другого прецедента.

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

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

Расширение применяется для моделирования:

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

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

3.Частей прецедента, которые актѐр воспринимает как необязательное поведение системы.

Базовый прецедент в отношении расширения дополняется одной или несколькими точками расширения (extension points).

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 24

В UML отношение расширения изображается в виде зависимости со стереотипом <<extend>>, которая направлена от расширяющего прецедента к базовому. На рис. 1-22 показаны примеры отношения расширения.

Рис. 1-22. Примеры

расширения

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

Отношения между компонентами и пакетами

Между компонентами и пакетами существуют только зависимости.

Если компонента зависит от второй, а вторая от первой, между ними будет существовать два отношения зависимости (рис. 1-23).

Рис. 1-23. Отношения между

компонентами

В модели пакетов следует избегать циклических зависимостей. Если один пакет зависит от другого и наоборот, то лучше перестроить отношения зависимости. Следует или объединить пакеты в один, или попытаться вынести общие элементы в отдельный пакет так, как показано на рис. 1-24.

Рис. 1-24. Устранение

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Любая диаграмма состоит из набора элементов и является частью UML-модели. Все диаграммы делятся на две группы: диаграммы структуры, диаграммы поведения.

1.1.3.1. Диаграммы структуры

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

Язык UML включает следующие базовые диаграммы структуры:

−Диаграммы классов (Class diagram).

−Диаграмма компонентов (Component diagram).

−Диаграмма развѐртывания (Deployment diagram).

−Диаграмма объектов (Object diagram).

−Диаграмма пакетов (Package diagram).

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

Представляет собой граф, вершинами которого являются классы, между которыми установлены разные отношения.

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

Существует три различные точки зрения на диаграмму классов:

1.Концептуальная точка зрения. Диаграмма классов отображает понятия предметной области и не имеет никакого отношения к реализующему еѐ программному обеспечению. Классы показывают без атрибутов и операций. Эти диаграммы полезны на стадии анализа. Пример концептуальной диаграммы классов показан на рис. 1-25.

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

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 1-25. Пример кон-

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

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

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

Эта диаграмма изображает состав типов системных компонентов (исходного кода, исполняемых) и зависимости между ними. Пример диаграммы компонентов показан на рис. 1-26.

Рис. 1-26. Пример диаграммы компонентов

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

Эта диаграмма имеет дескрипторную и экземплярную форму.

Первая форма (рис. 1-27) изображает конфигурацию узлов, где производится обработка данных, и развѐрнутые на узлах исполняемые компоненты.

Рис. 1-27. Дескрипторная форма

диаграммы развѐртывания

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 1-28. Экземплярная форма

граммы развѐртывания

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

Эта диаграмма изображает объекты и их связи в некоторый момент времени. Еѐ используют для иллюстрации сложности структуры данных или чтобы показать поведение в виде последовательности примеров. Диаграмму объектов можно считать особым случаем диаграммы классов. Пример диаграммы приведѐн на рис. 1-29.

Рис. 1-29. Пример диаграммы

объектов

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

Диаграмма изображает пакеты и зависимости между ними. Пакеты позволяют разбить UML-модель на части, что упрощает еѐ понимание и поддержку. Пакеты образуют дерево, уровень абстракции которого увеличивается в направлении корня – системы (пакет верхнего уровня). Пример диаграммы пакетов показан на рис. 1-30.

Рис. 1-30. Пример диаграммы пакетов

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

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

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

−Диаграмма прецедентов (Use Case diagram).

−Диаграмма видов деятельности (Activity diagram).

−Диаграмма последовательности (Sequence diagram).

−Диаграмма состояний (Statechart diagram).

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

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

Между актѐром и прецедентом существует отношение коммуникативной ассоциации, которое показывает, что между ними существует какое-то взаимодействие. Между двумя прецедентами устанавливается отношение зависимости, чтобы показать использование <<include>> включаемого прецедента базовым или расширение <<extend>> базового прецедента. Между актѐрами отношений не существует, поскольку они находятся вне границ системы. Пример диаграммы прецедентов показан на рис. 1-31.

Рис. 1-31. Пример диаграм-

мы прецедентов

В представлении Use Case View диаграмма отражает требования к системе с точки зрения пользователя.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

В представлении Logical View – отражает требования к системе с точки зрения раз-29 разработчика и детализирует диаграмму из представления Use Case View.

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

−для управления процессом разработки ПС;

−для определения границ ПС;

−для определения требований к ПС:

выявление основных функций (Use Case View), спецификация функций (Logical View),

спецификация дополнительных функций (Logical View); − для составления тестов.

Следует помнить, что use case (прецедент) – это документ, который описывает последовательность связанных с актѐром событий (а не отдельное событие). Эта последовательность используется системой для выполнения требуемого сервиса.

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

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

В представлении Logical View для каждой диаграммы прецедентов должна быть создана своя диаграмма классов.

Диаграмма видов деятельности

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

На диаграмме обязательно указывается одно начальное состояние (закрашенный круг) и одно или несколько конечных состояний (символ бычий глаз).

Действия (прямоугольники с закруглѐнными углами) моделируют поведение участ-

ников.

На диаграмме могут использоваться синхронизаторы (жирные линии) для моделирования параллельных действий.

Для участников на диаграмме создаются отдельные дорожки (swimlane), или участ-

ки (partition).

Показанная на рис. 1-32 диаграмма моделирует обслуживание клиентов для получения ими заказа.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 1-32. Пример диаграммы

видов деятельности с потоком объектов

Диаграмма последовательности

Эта диаграмма изображает упорядоченное во времени взаимодействие объектов.

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

Диаграммы последовательности особенно полезны для моделирования операций классов. Пример диаграммы приведѐн на рис. 1-33.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011