Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

Примеры построения диаграмм взаимодействия



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

Рис. 4. Пример диаграммы кооперации

Рис. 5. Пример диаграммы последовательности

Табличные данные после загрузки заносятся в атрибут data объекта propertyTable, представляющий собой двумерный массив объектов Object[][].

Во взаимодействии участвуют следующие объекты:

- Object – инициирует загрузку данных;

- propertyTable – хранит описание таблицы и ее полей, а также загруженные данные в атрибуте data;

- connectDB – отвечает за установку, поддержку и закрытие соединения с БД;

- statement – выполняет и возвращает результаты запросов к БД.

Инициировать загрузку могут объекты разных классов, поэтому объект Object не сопоставлен с каким-либо классом. Остальные объекты относятся к конкретным классам. После двоеточия у этих объектов показана вложенность по пакетам, а после последней точки – имя класса, экземпляром которого они являются.

Во взаимодействии следующая последовательность сообщений (вызова методов):

- Object инициирует загрузку данных getData();

- создается соединение с БД в виде объекта connectDB посредством вызова конструктора класса ConnectDB. Созданный объект запоминается в переменной connect;

- создается объект statement для выполнения запросов к БД и запоминается в переменной statement;

- посредством вызова метода checkChangeData() проверяется признак изменения данных на сервере. Если данные изменились, то;

o из атрибута data объекта propertyTable удаляются старые данные clear();

o выполняется запрос к БД executeQuere() и запрошенные данные запоминаются в переменной rs;

o в цикле while() записи из переменной rs переносятся в атрибут data с помощью метода add();

- удаляется объект statement – на диаграмме указано стереотипное сообщение «destroy»;

- закрывается соединение с БД closeConnect().

В качестве иллюстрации правил построения диаграммы последовательности на ней показаны:

- два варианта создания объекта – с помощью конструктора <constructor>() для объекта connectDB и с помощью стереотипного сообщения «create» для объекта statement;

- два варианта уничтожения объекта – с помощью вызова деструктора closeConnect() для объекта connectDB и с помощью стереотипного сообщения «destroy» для объекта statement;

- два варианта вызова методов, возвращающих значения – вызов конструктора объекта connectDB с занесением результата (созданного объекта) в переменную connect с помощью двух сообщений и выполнением запроса к БД executeQuere() с занесением результата в переменную rs с помощью одного сообщения.

Пакеты

В результате разработки диаграмм классов анализа, кооперации и последовательности определяется набор основных классов, определяющих внутреннюю архитектуру системы. На стадии анализа выявляются основные характеристики классов (атрибуты) и их поведение (методы). Выявленные классы должны быть распределены по пакетам (англ. package) – сущностям, используемым для семантической группировки других сущностей. отображение пакета в UML см. на рис. 6.

Рис. 6. Пакет

 

Допускается (как правило, имеет место) вложенность пакетов, т. е. пакет может состоять из подпакетов, подпакеты – из подподпакетов и т. д. Содержимое пакета может отображаться двумя способами (рис. 7).

Рис. 7. Способы отображения содержимого пакетов

 

Между пакетами могут указываться отношения наследования и зависимости (рис. 8).

Рис. 8. Примеры отношений между пакетами

Отношение наследования означает, что дочерний пакет (WindowsGUI или MacGUI) включает в себя все элементы родительского (GUI) и допускает определение новых (дополнительных) элементов и/или переопределение существующих. Зависимость между пакетами означает, что класс, входящий в зависимый пакет (table), связан отношением с классом, определенным в независимом пакете (db). Отношение зависимости часто помечают стереотипом «import».

При группировке классов по пакетам можно использовать следующие подходы :

- группировать классы по стереотипу. В одном пакете будут находиться классы сущностей, в другом – граничные, в третьем – управляющие;

- группировать по семантической однородности. Например, пакет «Безопасность» будет содержать все классы, отвечающие за безопасность системы;

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

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

Рис. 9. Фрагмент диаграммы пакетов

На рис. 9 на верхнем уровне используется группировка по функциональности. Так, пакет ru состоит из трех подсистем1 (iskraPUT – подсистема расчета и ведения допускаемых скоростей, iskraPTR – подсистема тягово-экономических расчетов и iskraSMI – подсистема расчета станционных и межпоездных интервалов) и пакета library, содержащего подпакеты и классы общего назначения. В подпакетах db, table, field, window, panel и obrData классы сгруппированы по семантической однородности.

Связи между классами, входящими в разные пакеты, на диаграмме могут обозначаться в общем виде (на уровне пакетов с использованием зависимостей) или непосредственно между классами (например, на рис. 9 между классами WindowNormat и InternalWindowDB).

В пределах одного уровня вложенности имена элементов (подпакетов и классов) должны быть уникальными. Допускается в разных пакетах определять подпакеты и классы с одинаковыми именами (например, подпакет window в пакетах iskraPUT и library). В дальнейшем (на других диаграммах и при непосредственном программировании), чтобы избежать разночтений, у одноименных подпакетов и классов указывается полная спецификация имен, включая все пакеты верхнего уровня. В имени вложенность обозначается с использованием «.» или «::» (например, ru.iskraPUT.window.WindowNormat или ru::library::window::InternalWindowDB).

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

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

- добиться лучшей структурной организации модели (сильнее формализовать модель);

- более четко и продуманно распределить обязанности между отдельными разработчиками или их командами;

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

1В UML система, подсистема и модель являются разновидностями пакета.

 

Вопросы для самопроверки

1. Перечислите элементы диаграмм взаимодействия.

2. Перечислите и дайте характеристику видам сообщений.

3. Как обозначается активность объекта на диаграмме последовательности.

4. Какие отношения могут быть между пакетами?

5. Назовите способы группировки классов по пакетам.

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

 




Поиск по сайту:

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.