На рис. 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. Назовите основные правила и рекомендации по разработке диаграмм взаимодействия.