 |
Диаграммы размещения (deployment diagrams)
|
|
|
|
Диаграммы размещения (deployment diagrams) отражают физические взаимосвязи между программными и аппаратными компонентами системы, а также используются для изображения маршрутов перемещения объектов в распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев, часть аппаратуры. Соединения между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные взаимодействия. Компоненты на диаграмме размещения представляют собой физические модули программного кода. Зависимости между компонентами должны совпадать с зависимостями между пакетами. Эти зависимости показывают каким образом одни компоненты взаимодействуют с другими.
1. Компоненты
Компоненты на диаграмме размещения представляют компоненты ПО. Компоненты представляются на диаграмме как прямоугольник, с небольшим эллипсом и двумя небольшими прямоугольниками, расположенными на одной из боковых сторон (рис.2.34).
Тип компоненты описывается следующим выражением:
<тип компоненты>
Экземпляр компоненты описывается строкой с подчеркиванием, содержащей собственное имя и тип:
<имя компоненты>‘:’<тип компоненты>
2. Узлы
Узел (node) - это физический объект, имеющий вычислительный ресурс, память и возможность обработки информации.
Узел представляется на диаграмме параллелепипедом (2.35). Тип узла описывается следующим выражением:
<тип узла>
Экземпляр узла описывается строкой с подчеркиванием, содержащей собственное имя и тип:
<имя>‘:’<тип узла>
Тип узла описывает разновидность данного узла. Пунктирная линия, проведенная от узла к компоненте, показывает возможность данного типа узла поддерживать данный тип компонент. Узлы могут содержать экземпляры компонент - это означает, что компонента "живет" или запускается в данном узле. Компоненты могут содержать в себе объекты; это говорит о том, что объект является частью компонента. Компоненты соединяются между собой пунктирными линиями, возможно использование интерфейсов. Это говорит о том, что один компонент использует другой компонент. Использование стереотипа уточняет вид данной зависимости.
|
|
|
Диаграммы размещения могут быть использованы для представления того, какие компоненты запускаются в каких узлах. Для этого используется связь со стереотипом "supports". Перемещение компонента из узла в узел или объекта из компонента в компонент может быть представлено с помощью связи со стереотипом “becomes".
Узлы могут быть связаны соединениями. Соединение может иметь стереотип, указывающий тип данной связи (например, тип канала в сети).
Представленный ниже пример представляет два узла, содержащие объект (cluster), переходящий из одного узла в другой, и также объект, располагающийся в узле постоянно.
Билет 71. UML и RUP.
Rational Unified Process (RUP) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software. Одним из основных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).
рис. 1 Фазы и потоки работ RUP
Определение требований
Унифицированный процесс – это процесс, управляемый прецедентами, которые отражают сценарии взаимодействия пользователей. Фактически, это взгляд пользователей на программную систему снаружи. Пользователи часто сами не представляют, что они должны получить в конечном итоге. Для облегчения этого процесса аналитики используют диаграммы прецедентов (рис. 2)
|
|
|
рис 2. Пример диаграммы Прецедентов
Диаграмма представляет собой отражение действующих лиц (актантов), которые взаимодействуют с системой, и реакцию программных объектов на их действия. Актантами могут быть как пользователи, так и внешние агенты, которым необходимо передать или получить информацию. Значок варианта использования отражает реакцию системы на внешнее воздействие и показывает, что должно быть сделано для актанта.
Для детализации конкретного прецедента используется диаграмма Активности (Activity Diagram), пример которой дан на рис 3.
рис. 3 Пример диаграммы Активности
Простота диаграммы прецедентов позволяет аналитикам легко общаться с заказчиками в процессе определения требований, выявлять ограничения, налагаемые на систему и на выполнение отдельных требований, такие, например, как время реакции системы, которые в дальнейшем попадают в раздел нефункциональных требований.
Также диаграмма прецедентов может использоваться для создания сценариев тестирования, поскольку все взаимодействие пользователей и системы уже определено.
Для того чтобы верно определить требования, разработчики должны понимать контекст (часть предметной области) в котором будет работать будущая система. Для этого создаются модель предметной области и бизнес-модель, что является различными подходами к одному и тому же вопросу. Часто создается что-то одно: модель предметной области или бизнес-модель.
Для создания модели предметной области используется обычная диаграмма классов (рис 6), однако для создания бизнес-модели ее уже явно недостаточно. В этом случае применяется диаграмма прецедентов с использованием дополнительных значков, которые отражающие сущность бизнес-процессов – это бизнес-актант, бизнес-прецедент, бизнес-сущность и бизнес-управление. Эта модель намного ближе к следующей модели, создаваемой в процессе разработки – модели анализа.
Анализ
Эта модель позволяет понять, как система должна быть спроектирована, какие в ней должны быть классы и как они должны взаимодействовать между собой. Основное ее назначение - определить направление реализации функциональности, выявленной на этапе сбора требований и сделать набросок архитектуры системы.
|
|
|
Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества (Collaboration) (рис 4). Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» – отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.
рис 4. Пример диаграммы сотрудничества
Нумерация сообщений показывает их порядок, однако назначение диаграммы не в том, чтобы рассмотреть порядок обмена сообщениями, а в том, чтобы наглядно показать связи классов друг с другом.
Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности (Sequence), показанная на рис 5. Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса. При использовании такого инструмента для создания моделей как Rational Rose, эти два вида диаграмм могут быть созданы друг из друга автоматически (подробнее о Rational Rose можно прочитать, например, в [5]).
Рис. 5 Пример диаграммы последовательности действий
Решение о том, какую из двух диаграмм нужно создавать первой, зависит от предпочтений конкретного разработчика. Поскольку эти диаграммы являются отображением одного и того же процесса, то и та и другая позволяют отразить взаимодействие между объектами.
Проектирование
Следующим этапом в процессе создания системы будет проектирование, в ходе которого на основании моделей, созданных ранее, создается модель проектирования. Эта модель отражает физическую реализации системы и описывает создаваемый продукт на уровне классов и компонентов. В отличие от модели анализа, модель проектирования имеет явно выраженную зависимость от условий реализации, применяемых языков программирования и компонентов. Для максимально точного понимания архитектуры системы, эта модель должна быть максимально формализована, и поддерживаться в актуальном состоянии на протяжении всего жизненного цикла разработки системы.
|
|
|
Для создания модели проектирования используются целый набор UML диаграмм: диаграммы классов (рис. 5), диаграммы кооперации, диаграммы взаимодействия, диаграммы активности.
рис 6. Пример диаграммы классов
Дополнительно в этом рабочем процессе может создаваться модель развертывания, которая реализуется на основе диаграммы развертывания (Deployment Diagram). Это самый простой тип диаграмм, предназначенный для моделирования распределения устройств в сети. Для отображения используется всего два варианта значков процессор и устройство вместе со связями между ними.
Реализация
Основная задача процесса реализации – создание системы в виде компонентов – исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т.д. На этом этапе создается модель реализации, которая описывает то, как реализуются элементы модели проектирования, какие классы будут включены в конкретные компоненты. Данная модель описывает способ организации этих компонентов в соответствии с механизмами структурирования и разбиения на модули, принятыми в выбранной среде программирования и представляется диаграммой компонентов (рис. 7).
рис. 7 Пример диаграммы компонентов
Тестирование
В процессе тестирования проверяются результаты реализации. Для данного процесса создается модель тестирования, которая состоит из тестовых примеров, процедур тестирования, тестовых компонентов, однако не имеет отображения на UML диаграммы, поэтому не будем на ней останавливаться.
|
|
|
