7.2. Унифицированный язык моделирования uml

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания объектно-ориентированного унифицированного языка моделирования (Unified Modeling Language, UML), [16]. За основу языка были взяты методы моделирования, разработанные Бучем и Рамбо. Методика Рамбо (Object Modeling Technique ‑ OMT) была ориентирована на анализ, а методика Буча ‑ на проектирование программных систем. Осенью 1995 года к компании Rational присоединился Айвар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев (вариантов) использования. Методика OOSE была также интегрирована в UML.

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i‑Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. В итоге UML версии 1.4.2 был принят в качестве международного стандарта ISO/IEC 19501:2005.

Формальная спецификация последней версии этого языка ‑ UML 2.0, ‑ опубликована в августе 2005 года. Семантика языка этой версии была значительно уточнена и расширена для поддержки методологии модельно-управляемой разработки (Model Driven Development, MDD), а также модельно- и сервис-ориентированных архитектур (Model-Driven Architecture и Service-Oriented Architecture, MDA и SOA).

В настоящее время UML:

• Принят и поддержан большинством производителей средств моделирования.

• Стал важнейшей частью компьютерной науки и инженерных учебных планов в университетах по всему миру и различных профессиональных программ обучения.

• Используется академическими и другими исследователями как удобный общий язык моделирования.

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

7.2.1. Архитектура 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).