Архитектура UML

Для визуализации, спецификации, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения (views), [16]. Все, кто имеет отношение к проекту, ‑ конечные пользователи, аналитики, разработчики, системные интеграторы, тестировщики, технические писатели и менеджеры проектов ‑ преследуют собственные интересы, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизненного цикла.

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

Архитектура программной системы включает:

· её организацию;

· выбор структурных элементов, составляющих систему, и их интерфейсов;

· поведение этих элементов в кооперациях с другими элементами;

· составление из структурных и поведенческих элементов все более и более крупных подсистем;

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

Архитектура ПС охватывает не только ее структурные и поведенческие элементы, но и её использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические свойства.

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

Рис. 7.1. Модель архитектуры программной системы, [16]

Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры. В UML статические аспекты этого вида передаются диаграммами прецедентов (Use-Case Diagram), а динамические - диаграммами взаимодействия (Sequential Diagram и Collaboration Diagram), состояний (Statechart Diagram) и действий (Activity Diagram).

Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи проектирования и ее решения. Этот вид поддерживает, прежде всего, функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям. С помощью языка UML статические аспекты этого вида можно представляются диаграммами классов (Class Diagram) и объектов (Object Diagram), а динамические - диаграммами взаимодействия, состояний и действий.

Вид с точки зрения процессов (Process view) охватывает нити (threads – параллельно выполняемые ветви процессов) и процессы, формирующие механизмы параллелизма и синхронизации в программной системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность программной системы. В UML его статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы.

Вид с точки зрения реализации (Implementation view) охватывает программные компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий программной системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В языке UML статические аспекты этого вида передают с помощью диаграмм компонентов (Component Diagram), а динамические - с помощью диаграмм взаимодействия, состояний и действий.

Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств программной системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой отдельных частей аппаратной части системы. Его статические аспекты описываются диаграммами развертывания (Deployment
Diagram), а динамические ‑ диаграммами взаимодействия, состоя-ний и действий.

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

В ходе разработки программной системы моделируются архитектурные шаблоны (architectural patterns) и шаблоны проектирования (design patterns), которые являются почти готовыми проектными решениями, подлежащими определённой доработке и настройке.

Необходимо понимать, что системная архитектура не рождается в ходе единичного творческого акта. Напротив, хорошо структурированный процесс применения UML подразумевает последовательное итеративное и инкрементное уточнениеархитектуры на основе анализа прецедентов, реализуемое в Унифицированном Процессе разработки компании Rational (RUP).