Унифицированный язык моделирования (UML) и его поддержка в Rational Rose 98i – CASE-средстве визуального моделирования

В работах, описывающих средства разработки программных проектов, то и дело мелькает сокращение UML, которое означает Unified Modeling Language — Унифицированный Язык Моделирования. Естественно возникает вопрос: что это за новый язык, и нужно ли с ним знакомиться? В статье делается попытка ответить на этот вопрос. Краткий ответ прост — знакомиться с UML в той или иной степени придется, поскольку UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированным CASE продуктами, включая Rational Rose 98i.

Визуальное моделирование. Итак, что же такое UML, и почему этому языку моделирования уделяется в последнее время столь большое внимание? Нужно ли его изучать? Как его использовать при разработке программных проектов?

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

• — компонентную технологию разработки моделей ИС,
• — визуальное программирование (RAD средства),
• — использование образцов (patterns) при проектировании ИС,
• — визуальное представление различных аспектов проекта (визуальное моделирование, CASE — средства).

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

Построение модели корпоративной ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. Сложность разрабатываемых систем продолжает увеличиваться, и поэтому возрастает актуальность использования «хороших» методов моделирования ИС. Язык моделирования, как правило, включает в себя:

• — элементы модели — фундаментальные концепции моделирования и их семантику;
• — нотацию — визуальное предоставление элементов моделирования;
• — принципы использования — правила применения элементов в рамках построения тех или иных типов моделей ИС.

Построение визуальных моделей позволяет решить сразу несколько типичных проблем. Во-первых, и это главное, технология визуального моделирования, позволяет работать со сложными и очень сложными системами и проектами. И не важно, преобладает ли в проекте «техническая сложность» (статическая) или «динамическая сложность управления». Сложность программных систем возрастает по мере создания новых версий. И в какой-то момент наступает «эффект критической массы», когда дальнейшее развитие ИС становиться невозможным, поскольку уже никто не представляет в целом «что и почему происходит». Происходит потеря управлением проектом. Внешней причиной или толчком возникновения этого неприятного эффекта может послужить, например, увольнение ведущего программиста или системного аналитика. Во-вторых, визуальные модели позволяют содержательно организовать общение между заказчиками и разработчиками. Шутка о том, что «заказчик что-то хочет, но точно не знает, чего именно», с завидным постоянством часто оказывается былью. А если на начальном этапе работы над проектом ИС заказчик думает, что точно знает, что хочет, то, как правило, и об этом свидетельствует богатый опыт, его требования изменяются («плывут») в ходе выполнения проекта. С одной стороны, аппетит приходит во время еды, а с другой, высокая динамика бизнеса объективно заставляет менять требования к разрабатываемой (или поддерживаемой) ИС.

Визуальное моделирование не является «серебряной пулей», способной раз и навсегда решить все проблемы, однако его использование существенно облегчает достижения таких целей как:

• — повышение качества программного продукта;
• — сокращение стоимости проекта;
• — поставка системы в запланированные сроки.

Как разбивать сложную систему на части. При проектировании сложной ИС ее разбивают на части, каждая из которых затем рассматривается отдельно. Возможны два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция.

Суть функционального разбиения хорошо отражена в известной формуле:

" Программа=Данные + Алгоритмы" .

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

Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: «разработка, основанная на компонентах» (Component Based Development — CBD). При этом используется иной принцип декомпозиции — система разбивается на «активные сущности» — объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая друг к другу в отношении «клиент/сервер». Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения «объекту-серверу» эквивалентна вызову соответствующего метода объекта.

Так вот, если при проектировании информационная система разбивается на объекты (компоненты), то UML может быть использован для ее визуального моделирования. Если используется функциональная декомпозиция ИС, то UML не нужен, и следует использовать другие (структурные) нотации.

Отдельная тема для обсуждения — нужно ли программировать в объектах (компонентах)? Споры на эту тему относятся к разряду «религиозных войн». Есть убежденные сторонники в обоих лагерях. Уместно заметить, что все современные RAD-средства программирования используют библиотеки компонент, позволяющие повторно использовать отлаженный программный код, что значительно облегчает сборку программных приложений. Такое «сборочное программирование» стало возможным за счет использования объектов и привело к изменению квалификационной оценки программистов за рубежом — «программист — это тот, кто умеет программировать в компонентах», т. е. это не «писатель программного кода», как принято считать у нас.

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

Унифицированный Язык Моделирования (UML):

• — не зависит от объектно-ориентированных (ОО) языков программирования;
• — не зависит от используемой методологии разработки проекта;
• — может поддерживать любой ОО язык программирования.

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

Как создавался UML. В середине 90-х существовало более 50 различных объектно-ориентированных языков моделирования. И разработчики, и заказчики испытывали беспокойство при выборе метода проектирования ИС, который, как правило, включал в себя и собственную нотацию. В это время стали появляться новые версии таких распространенных методов как: Booch'93, OMT-2 (Object Modelling Technique), Fusion, OOSE (Object-Oriented Software Engineering). Возникла насущная потребность в стандартизации и унификации.

Разработка UML была начата в октябре 1994 Грэди Бучем (Grady Booch) и Джимом Рамбо (Jim Rumbaugh) в Rational Software Corporation как унификация двух методов: Booch'93 и OMT. Первая версия Унифицированного Метода (Unified Method 0.8) была опубликована в октябре 1995. Осенью 1995 к работе присоединился Айвер Якобсон (Ivar Jacobson), включив в процесс унификации свой метод OOSE. Таким образом, на первом концептуальном этапе UML имел трех авторов: Буча, Рамбо и Якобсона, каждый их которых являлся идеологом своего ОО метода визуального моделирования.

В октябре 1996 года была выпущена редакция UML 0.91, в которой были отражены многочисленные пожелания, которые «три друга» получили в течение 1996 года. В это же время выяснилось, что ряд влиятельных организаций, связанных с компьютерным бизнесом, стал рассматривать UML как стратегический элемент своей деятельности. Катализатором объединения усилий по унификации UML стал выпуск консорциумом OMG (Object Management Group) «запроса на предложения» по UML (RFP — Request for Proposal). Известно, что выпуск RFP является первым шагом процедуры принятия OMG того или иного стандарта. После этого Rational Software под своей эгидой создала организацию.

" Консорциум UML партнеров" («UML Partners consortium») для выработки формального определения UML 1.0 как стандарта. В работе консорциума приняли участие представители таких известных компаний как: Digital Equipment Corp., Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, Unisys.

В результате в январе 1997 г. в OMG был представлен вариант UML 1.0. как первый RFP-отклик. В это же время второй RFP-отклик независимо от «UML Partners consortium» представили такие организации как: ObjecTime; Platinum Technology; Ptech; Taskon & Reich Technologies и Softeam. Для объединения предложений по двум представленным проектам UML эти компании также присоединились к «UML Partners consortium», и в результате был подготовлен вариант UML 1.1. Именно этот вариант в ноябре 1997 года был утвержден как стандарт. Формальное описание UML 1.1 в виде семи pdf-файлов можно найти, например, на сайтах OMG, Rational Software, Platinum Technology. По заголовкам можно судить о составе официальной документации по UML:

• — UML Summary;
• — UML Notation Guide;
• — UML Semantics;
• — UML OCL (Object Constraint Language Specification);
• — UML Objectory (UML Extension for Objectory Process for Software Engineering);
• — UML Business (UML Extension for Business Modeling);
• — UML Metamodel_Diagram.

В настоящее время на рассмотрении OMG находится версия UML 1.3, которая будет принята как стандарт в середине этого года.

Описание UML и его использование можно найти в многочисленных англоязычных изданиях, включая следующие:

• — Fowler, M. and Scott, K. UML Distilled: Applying the Standard Object Modeling Language (1997) Addison-Wesley;
• — Ambler, S. W Building Object Applications That Work: Your Step-by-Step Handbook for Developing Robust Systems With Object Technology. (1997, 1998) Cambridge University Press/SIGS Books;
• — Booch, G. et. al. Unified Modeling Language User Guide (1998) Addison-Wesley;
• — Larman, C Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (1998) Prentice-Hall;
• — Eriksson, H. and Penker, M. UML Toolkit (1997) John Wiley & Sons;
• — Quatrani, T. Visual Modeling With Rational Rose and UML (1998) Addison-Wesley; Rumbaugh, J., Jacobson, I., and Booch G. Unified Modeling Language Reference Manual (1998) Addison Wesley.

Ожидается выход на русском языке в издательстве «Мир» перевода книги «UML Distilled» .

Что можно рисовать на UML. При визуальном моделировании на UML используются восемь видов диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы. Рассмотрим некоторые диаграммы.

Диаграммы использования. Эти диаграммы описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействия пользователя с системой, которое при этом:

• — описывает видимую пользователем функцию;
• — может представлять различные уровни детализации;
• — обеспечивает достижение конкретной цели, важной для пользователя.

Прецедент рисуется как овал, связанный с типичными пользователями, называемыми «актерами» (actors). Актеры используют систему (или используются системой) в данном прецеденте. Актер, представляющий человека-пользователя, характеризуется ролью в данном прецеденте. На диаграмме изображается только один актер, однако, реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, с помощью которых может быть сформулировано техническое задание.

Диаграммы классов (class diagrams) описывают статическую структуру классов. Эти диаграммы могут описывать «словарь предметной области» на концептуальном уровне. С другой стороны, на детальном уровне (уровне спецификаций и уровне реализаций) диаграммы определяют структуру программных классов. Они используются для генерации каркасного программного кода на заданном языке программирования, а также для генерации SQL DDL предложений, определяющих логическую структуру реляционных таблиц БД.

Для описания динамики используются диаграммы поведения (behavior diagrams), которые подразделяются на:

диаграммы состояний· (statechart diagrams);

диаграммы активностей (activity diagrams);

диаграммы взаимодействия· (interaction diagrams), состоящие из:

• — диаграмм последовательности· (sequence diagrams);
• — диаграмм взаимодействий· (collaboration diagrams).

И, наконец, диаграммы реализации (implementation diagrams) состоят из компонентных диаграмм· (component diagrams) и диаграмм развертывания· (deployment diagrams). На рисунке 5 показаны элементы и отношения для диаграмм взаимодействий, диаграмм последовательности· и диаграмм состояний.

Как проектировать ИС в объектах/компонентах. Если вы программируете в MS Visual Studio 6.0, и у вас установлена версия Enterprise Edition, то, может быть, вы уже познакомились с UML диаграммами в программе Visual Modeller, которая представляет собой усеченный вариант системы Rational Rose 98. С помощью Visual Modeller вы можете рисовать диаграммы классов в трех различных нотациях — нотации Буча, нотации ОМТ и в унифицированной нотации, т. е. на UML. По диаграммам классов вы можете провести генерацию каркасного программного кода (на C++, VB или Java), который не будет содержать кода, реализующего методы. Код правильно представит определения классов и их взаимосвязи, изображенные на диаграммах. Такая генерация программного кода называется прямым проектированием (forward engineering). Взаимозависимости классов, изображенные на «картинке» диаграммы классов, отображается в программный код.

Большой интерес представляет обратное проектирование (reverse engineering), когда по исходному программному коду, написанному в объектах, восстанавливается диаграмма классов, которая позволяет понять структуру программы. Visual Modeller не поддерживает диаграммы использования, описывающие внешнюю функциональность проектируемой ИС. uml моделирование визуальная проектирование Процесс проектирования с использованием той или иной визуальной нотации принято называть методологией проектирования, и все нотации, предшествующие UML, использовались в рамках соответствующей методологии. Методологию трудно стандартизировать, и UML — это только нотация, которая может использоваться в рамках разных методологий. Одной из таких методологий является Rational Unified Process (RUP) — методология фирмы Rational Software. RUP описывает успешно проверенные на практике подходы к созданию ИС и определяет организацию коллективной работы над проектом на основе следующих принципов:

• — итерационная разработка проекта;
• — управление требованиями;
• — использование компонентной архитектуры;
• — визуальное моделирование;
• — тестирование качества ИС;
• — контроль конфигураций и изменений в ИС.

Порядок использования UML диаграмм упрощенно можно представить следующим образом. Вначале для ИС определяется ее внешняя функциональность, выделяются все актеры и все прецеденты. Отношения между ними изображаются на серии диаграмм использования. Дальнейшая работа над проектом «управляется прецедентами». Для каждого прецедента строится описание его динамики в виде серии диаграмм взаимодействия и диаграмм активностей. Из этого описания определяются те объекты, которые задействованы в реализации данного прецедента. Далее диаграммы классов определяют статическую структуру, описывающую взаимоотношения соответствующих объектов друг с другом. Поведение классов, со сложной динамикой реагирования на события, определяется на диаграмме состояний. Размещение объектов по программным модулям описывается в компонентных диаграммах, а программных модулей по сети и компьютерам — в диаграммах распределения.

Rational Rose 98i — поддержка UML 1.1. В начале года Rational Software выпустила новую версию своего средства визуального моделирования Rational Rose 98i. Литера «i» обозначает «интегрированный», поскольку Rose 98i является важной составной компонентой интегрированного семейства продуктов Rational Suite 1.0, поддерживающих групповую разработку проектов ИС. Rose 98i поддерживает нотацию UML 1.1 и обеспечивает тесное взаимодействие с Microsoft Visual Studio 6.0. Предыдущая версия Rose 98 не позволяла использовать диаграммы активностей, входящих в спецификацию UML 1.1. Кроме этого, имеется возможность публикации визуальных моделей в Web для унификации групповой разработки приложений. В Rose 98i расширены возможности контроля версий на основе интеграции с продуктом Rational ClearCase — системой управления конфигурациями программного обеспечения уровня предприятия.

Теперь компоненты COM, ActiveX и JavaBean могут быть использованы в Rose 98i для проведения обратного проектирования (reverse engineering), т. е. для определения в UML моделях интерфейсов и взаимосвязи компонент, необходимых для построения проекта. Rose 98i Enterprise позволяет в одном проекте смешивать компоненты, разработанные на различных языках программирования: C ++, Visual Basic и Java.

" Бесшовная" интеграция с Microsoft Visual Studio. Rose 98i поддерживает «плотную» интеграцию с Microsoft Visual Studio 6.0. и обеспечивает полную безмаркерную генерацию кода и обратное проектирование для Microsoft Visual Basic 6.0 и Visual C ++ 6.0. Кроме этого, Rose 98i позволяет более качественно генерировать код и проводить обратное проектирование для приложений на основе Microsoft Foundation Classes (MFC). Rose 98i предоставляет разработчикам Visual Studio возможность «перетаскивания» (drag-and-drop) в UML диаграммы объектные компоненты прямо из среды Windows Explorer. Поддерживается интеграция с Visual Component Manager, Microsoft Репозиторием и системой управления версиями Microsoft Visual SourceSafe.

Групповая разработка, основанная на Web. Для поддержки больших, распределенных проектов ИС, в Rose 98i включен Web Publisher, новый «встраиваемый» компонент (Add-In), который предоставляет свободный доступ ко всем аспектам проектной документации через Web. С помощью Web Publisher визуальные модели экспортируются в HTML формат. Каждую модель можно рассматривать как Web сайт, доступный всем членам группы разработчиков. Используя стандартный браузер типа Internet Explorer или Netscape Navigator, диаграммы модели и описания классов могут быть просмотрены как Web страницы. Web Publisher можно использовать для Web публикации последовательно создаваемых версий модели проекта и распространения этой информации среди разработчиков, пользователей и заказчиков.

Улучшенная интеграция с Rational ClearCase. Rose 98i поддерживает плотную интеграцию с продуктом Rational ClearCase, средством управления конфигурациями уровня предприятия. Новый Интегратор Моделей (Model Integrator Add-In) позволяет выполнять операции управления конфигурациями (типа «check in» /" check out"), проводить визуальное сравнение и слияние моделей, обеспечивает параллельную разработку. Rose 98i поддерживает «бесшовную» интеграцию с ClearCase и выполняет операции управления конфигурациями непосредственно на модельных элементах, например, операции «check in» /" check out". В дополнение к ClearCase, Интегратор Моделей поддерживает Visual SourceSafe, а также и другие продукты, совместимые с Source Code Control (SCC).

Продукт Rational Rose 98i доступен на платформах Windows NT 4.0, Windows 95/98 как в однопользовательском, так и многопользовательском варианте. Rational Rose 98i поставляется в трех вариантах: Enterprise, Professional и Modeler (подробности см. здесь).

Дополнительную информацию об особенностях Rational Rose 98i, а также оценочную версию продукта можно получить в компании Интерфейс.