UML. Диаграмма пакетов
Объяснить команде разработчиков с помощью диаграммы вариантов использования (use case diagram) последовательность шагов, с помощью которых они смогли бы разработать диаграмму пакетов для своей существующей системы.
Диаграмма пакетов служит, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы. Например, все элементы, связанные с 3D-моделированием, можно разместить в пакете с именем 3DGraphics. Диаграммы пакетов обеспечивают отличную возможность визуального представления зависимостей между частями вашей системы и часто используются для диагностики или определения порядка компиляции.В пакетах могут группироваться практически любые элементы UML (в том числе и сами пакеты). Каждый пакет обладает именем, уточняющим область видимости каждого элемента пакета. Например, если класс с именем Timer принадлежит пакету Utilities, полное имя класса имеет вид Utilities::Timer. Элементы, входящие в один пакет, могут обращаться друг к другу без уточнения имен.
Пакет изображается в виде прямоугольника с «корешком» в левому верхнему углу. Существуют два разных способа показа элементов, входящих в пакет. В первом варианте элементы рисуются внутри большого прямоугольника. Во втором варианте записи пакет соединяется с каждым содержащимся в нем элементом сплошной линией. Ближний к пакету конец линии помечается кружком
со знаком «+», обозначающим включение. При использовании этой записи имя пакета указывается в большом прямоугольнике, а не на корешке. Такой вариант записи позволяет отображать более подробную информацию о содержимом пакета.
Ниже представлены способы отображения пакетов.
-1. Оценить потребность в применении к системе диаграммы пакетов:
1.1. Решить необходимо ли выделять новые зависимости между объектами системы
1.2. Оценить сложность тестирования без диаграммы пакетов
1.3. По масштабам текущего проекта /итогового проекта оценить его сложность и "запутанность"
Если было принято положительное решение, то переходим к послудующим этапам:
-2. Распределить различные модельные конструкции /диаграммы по пакетам:
2.1. Определить названия пакетов
2.2. Определить нужно ли вкладывать пакеты друг в друга
Если модельными конструкциями являются диаграммы классов, то приступаем к действиям:
-3. Поместить классы в пакеты:
3.1. Задать классам полностью определенное имя
3.2. Определить по какому принципу будем вкладывать классы в пакеты
3.3 Указать тип класса в пакете:
3.3.1. Выделить закрытые классы
3.3.2 Выделить открытые классы
Пакеты наполнены. Осталось определить связи между ними (если они существуют):
-4. Устанавливаем зависимости между пакетами:
4.1. Общий анализ диаграмм классов в пакетах (можем добавить пояснительные метки на связи для ясности картины)
4.2. Ищем зависимости между классами в разных пакетах:
4.2.1. На основе найденных отношений указываем верное их направление
.png)
###Пример использования UML-диаграммы пакетов: Например, руководитель проекта может нарисовать примерно такую пакетную диаграмму веб-приложения, как показано на рисунке ниже. Данная диаграмма сама по себе передает очень мало полезной информации. К ней должен прилагаться текстовый документ с описанием основных принципов разбиения на пакеты. Такой документ, например, может содержать список следующего вида:
- web — требует специальных навыков: HTML, CSS и Struts, технология представления; максимум зависимостей;
- database — требует навыков управления базами данных и моделирования; минимум зависимостей;
- user — будет создаваться сторонней группой разработчиков;
- search — требует знакомства с технологией и методами использования поисковых систем; автономная подсистема;
- editing — основные функции редактирования, включаемые в первую версию; разные навыки, отдельная команда;
- rtf-editing — функции редактирования, запланированные к выходу версии 2.
- x-editing — функции редактирования, запрашиваемые конкретным клиентом.
Функциональность может быть отозвана или отложена в зависимости от клиента. Риски не зависят от других компонентов. На данной диаграмме не показан полный набор пакетов системы. Того, что показано, достаточно только для отслеживания и руководства проектом. Программисты создают пакеты более низкого уровня, если того потребует архитектура кода.