В работах, описывающих средства разработки программных проектов, то и дело мелькает сокращение UML, которое означает Unified Modeling Language - унифицированный язык моделирования. Естественно возникает вопрос: что это за новый язык и нужно ли с ним знакомиться? Начнем с определения. UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами, включая Rational Rose98i и Platinum Paradigm Plus 3.6.

Визуальное моделирование

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

- компонентную технологию разработки моделей ИС;

- визуальное программирование (RAD-средства);

- использование образцов (patterns) при проектировании ИС;

- визуальное представление различных аспектов проекта (визуальное моделирование, CASE-средства).

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

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

- элементы модели - фундаментальные концепции моделирования и их семантику;

- нотацию - визуальное представление элементов моделирования;

- принципы использования - правила применения элементов в рамках построения тех или иных типов моделей ИС.

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

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

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

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

Как разбить сложную систему на части?

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

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

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

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

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

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

С точки зрения визуального моделирования язык 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 г. Тогда же к работе присоединился Айвер Якобсон (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 Partners consortium, и в результате был подготовлен вариант UML 1.1. Именно он и был утвержден в ноябре 1997 г. в качестве стандарта. Формальное описание UML 1.1 в виде семи pdf-файлов можно найти, например, на сайтах OMG (www.omg.com), Rational Software (www.rational.com/uml/), Platinum Technology (www.platinum.com). По заголовкам этих документов можно судить о составе официальной документации по 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 используются восемь видов диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграмм.

Рис. 1. Вид диаграммы использования в Rational Rose98i

Диаграммы использования (use case diagrams - см. рис. 1 и 2) описывают функциональность ИС, которая будет видна пользователям системы. “Каждая функция” изображается в виде “прецедентов использования” (use case) или просто прецедентов. Прецедент определяет типичное взаимодействие пользователя с системой, которое:

Рис. 2. Элементы и отношения, допустимые в диаграммах использования в Paradigm Plus

- описывает видимую пользователем функцию;

- может представлять различные уровни детализации;

- обеспечивает достижение конкретной цели, важной для пользователя.

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

Рис. 3. Пример диаграммы классов в Rational Rose98i

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

Рис. 4. Элементы и отношения между ними на диаграмме классов Paradigm Plus

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

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

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

- диаграммы взаимодействия (interaction diagrams), состоящие из диаграмм последовательности (sequence diagrams) и диаграмм взаимодействий (collaboration diagrams).

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

Рис. 5. Элементы и отношения для диаграмм взаимодействий, диаграмм последовательности и диаграмм состояний

Как проектировать ИС в объектах/компонентах?

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

Большой интерес представляет обратное проектирование (reverse engineering), когда по исходному программному коду, написанному в объектах, восстанавливается диаграмма классов, которая позволяет понять структуру программы. Visual Modeller не поддерживает диаграммы использования, описывающие внешнюю функциональность проектируемой ИС

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

- итерационная разработка проекта;

- управление требованиями;

- использование компонентной архитектуры;

- визуальное моделирование;

- тестирование качества ИС;

- контроль конфигураций и изменений в ИС.

Порядок использования UML-диаграмм упрощенно можно представить следующим образом. Вначале для ИС определяется ее внешняя функциональность - выделяются все актеры и все прецеденты. Отношения между ними изображаются на серии диаграмм использования. Дальнейшая работа над проектом “управляется прецедентами”.

Для каждого прецедента строится описание его динамики в виде серии диаграмм взаимодействия и диаграмм активностей; выбираются объекты, которые задействованы в его реализации. Далее диаграммы классов определяют статическую структуру, описывающую взаимоотношения соответствующих объектов друг с другом. Поведение классов со сложной динамикой реагирования на события определяется на диаграмме состояний. Размещение объектов по программным модулям описывается в компонентных диаграммах, а самих программных модулей в сети - в диаграммах распределения.

Rational Rose98i - поддержка UML 1.1

В начале года Rational Software выпустила новую версию своего средства визуального моделирования Rational Rose98i (см. PC Week/RE, № 37/98, с. 20). Литера “i” обозначает “интегрированный”, поскольку Rose98i является важным составным компонентом интегрированного семейства продуктов Rational Suite 1.0, поддерживающих групповую разработку проектов ИС. Rose98i поддерживает нотацию UML 1.1 и обеспечивает тесное взаимодействие с Microsoft Visual Studio 6.0. Предыдущая версия (Rose98) не позволяла использовать диаграммы активностей, входящих в спецификацию UML 1.1. Кроме этого имеется возможность публикации визуальных моделей в Web для унификации групповой разработки приложений. В Rose98i расширены возможности контроля версий на основе интеграции с продуктом Rational ClearCase - системой управления конфигурациями программного обеспечения уровня предприятия.

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

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

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

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

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

Дополнительную информацию об особенностях Rational Rose98i, а также оценочную версию продукта можно получить в компании “Интерфейс” (http://www.interface.ru).

Михаил Кумсков, эксперт по объектным CASE-средствам компании “Интерфейс”. С ним можно связаться по адресу: kumskov@interf.mx.orc.ru.* В журнале Rose Architect, издаваемом фирмой Rational Software и посвященном визуальному моделированию на UML в среде Rational Rose98, Буч, Рамбо и Якобсон называются “три друга” (Three Amigos). Электронную полнотекстовую версию этого журнала можно найти по адресу: http://www.rosearchitect.com.