Когда читаешь о таких проектах, как создание системы управления полетами или контроля
запуска ракет, невольно поражаешься масштабам работ. Десятки и сотни человеко-лет,
затраченные на создание сложнейших программных систем, гигантские бюджеты, огромные
коллективы и колоссальная ответственность. Еще большие проблемы связаны с поддержанием
работоспособности и модернизацией написанных ранее программ. Сегодня по сложности
промышленные разработки прошлого десятилетия вполне могут соперничать с потребительскими
ОС и офисными пакетами. Необходимость управлять, контролировать и описывать программное
обеспечение вынудила сообщество разработчиков искать средство моделирования, которое
не зависело бы от конкретного языка или платформы. В результате долгой эволюции
появился UML — Unified Modeling Language. До сих пор не утихают споры о том,
является ли его универсальность достоинством или недостатком, но именно эта особенность
языка позволила разработчикам аппаратного обеспечения использовать плоды труда
Гради Буча (Grady Booch), Джима Рамбауха (Jim Rumbaugh) и Айвара Якобсона (Ivar
Jacobson). Знакомые имена, не правда ли?
Three Amigos
Именно так Буч, Рамбаух и Якобсон решили называть себя (существует ли здесь
связь с одноименным фильмом со Стивом Мартином, Чеви Чейзом и Мартином Шортом,
история об этом умалчивает), но назвали они свою группу просто и без затей —
"The Amigos". Идея создания объектно-ориентированного языка моделирования
оформилась в период между серединой 70-х и 80-х годов. Количество языков быстро
возросло до семидесяти, и пользователи стали испытывать ощутимые неудобства с
выбором и обменом моделями.
Заварил кашу Гради Буч — в январе 1991 г. увидела свет его знаменитая книга "Object Oriented Design with Applications", где он затронул такие аспекты, как описание и проектирование объектно-ориентированного ПО. Являясь основателем компании Rational Software, Буч настойчиво продолжал разрабатывать эту сложную тематику. К 1994 г. его подход получил всеобщее признание и стал известен под названием — Booch’93. Метод объединял в себе все лучшее из языков OMT (Object Modeling Technique) и Fusion. Появившийся в компании Rational Software Айвар Якобсон застал Буча и Рамбауха в процессе унификации развивавшихся независимо друг от друга OMT и Booch’93. Необходимо отметить, что оба они являлись на тот момент признанными де-факто стандартами объектно-ориентированного моделирования.
Ученые поставили перед собой сложную задачу — в случае объединения этих подходов язык, названный ими Unified Method, занял бы лидирующие позиции на рынке. Однако к осени 1995 г. компания сделала еще одно выгодное приобретение в виде фирмы Objectory, получив "в нагрузку" выдающийся ум Якобсона, автора метода OOSE (Object-Oriented Software Engineering). Вместе они принялись за намного более скромное, но не менее полезное дело — формирование спецификаций UML, которые в 1997 г. были представлены на рассмотрение OMG (Object Management Group). Этому знаменательному событию предшествовало широкое обсуждение предложенных спецификаций языка крупнейшими компаниями программной индустрии.
Когда стало ясно, что UML становится важной составляющей планов большинства влиятельных поставщиков инструментальных средств разработки, Request For Proposal, направленный в OMG, стал логичным шагом на пути к официальной стандартизации. В работе над первой версией спецификаций, помимо собственно Rational Software, приняли участие корпорации Digital Equipment, HP, i-Logix, IBM, Microsoft, Oracle, Unisys и др. В результате их совместной деятельности к сентябрю 1997 г. версия 1.1 была принята OMG. Взятый темп оказался чересчур высоким, и конечный документ, несмотря на солидный теоретический базис, содержал большое количество недоработок. UML страдал неполнотой и иногда некорректностью семантики, огромным числом плохо упорядоченных стандартных элементов. Самым же прискорбным оказалось то, что разработчикам так и не удалось уложиться в четырехуровневую метамодель с соблюдением точных правил метамоделирования. Впрочем, это и неудивительно, учитывая невероятную сложность и искусственную "раздутость" языка. В его базовые конструкции постарались втиснуть все элементы, необходимые для описания широкого круга систем. Исправить большинство упомянутых недостатков (кроме, конечно, несоответствия четырехуровневому метамоделированию) предполагалось в релизе 1.3, который планировался на нынешний год. А в 2001 г. ожидается появление так называемого major-релиза с номером 2.0, содержащего серьезные изменения. В связи с этим в специализированной прессе разворачивается дискуссия, посвященная проблеме, именуемой не иначе как "Высечение или лепка?". Цель ее выяснить, следует ли добавлять все необходимые элементы в обязательную для реализации основу языка или отдать это "на откуп" конкретных разработчиков (UML имеет достаточно средств для расширения). Но оставим эти споры искушенным специалистам и опытным функционерам OMG, а сами же обратимся к его основам. Ведь в ближайшие годы именно он будет задавать "правила игры" для всей индустрии программного обеспечения.
Мета-мета-метамодель…
800 страниц — много это или мало? Именно таков объем PDF-файла, содержащего
спецификации языка UML. Если, конечно, сравнивать со стандартом PC2001, то нет.
Автор статьи очень долго не мог взять в толк: почему большинство публицистических
материалов, озаглавленных, например, как "Понимание UML", — очень трудны
для осмысления неподготовленным читателем. Даже известный писатель Синан Си Алхир
(Sinan Si Alhir), автор книги "UML in a Nutshell", не придумал ничего
лучшего, чем просто составить свою обзорную публикацию из… ряда отвлеченных
цитат, взятых из вступления к тексту спецификации. Впрочем, все прояснила популярная
статья Брюса Поуэлла Дугласа (Bruce Powel Douglas), в которой сказано: "UML
— это нечто очень большое и сложное, способное устрашить новичка… У нас нет
места, чтобы обсудить весь UML или отдельные его части в подробностях". Данный
материал занимал 12 страниц… Уважаемый читатель, у нашего издания нет возможности
отвести даже такое количество журнальной площади.
Основная цель, которую преследовали Буч, Рамбаух и Якобсон, состояла в создании формальной базы для обмена моделями. До сих пор проблема заключалась не столько в сложностях моделирования, сколько в принципиальной невозможности их перемещать из организации в организацию без сопровождающей документации. Однозначность трактования и полнота описания оставляли желать лучшего.
"The Amigos" в своих изысканиях решили с самого начала исходить из принципов четырехуровневого метамоделирования. Здесь уровень символизирует степень абстракции. Наиболее высокий из них (под названием мета-метамодель) содержит правила, по которым конструируется язык (например, MetaClass). Лежащая уровнем ниже метамодель отображает основные типы и элементы языка (например, Class). Подчиненная ей модель — это описания базовых объектов программы (например, StockShare). Они приходятся младшими "родственниками" объектам метамодели. И наконец, пользовательские объекты (данные) находятся на самом нижнем уровне схемы и являют собой конкретные программные объекты (например, <Microsoft_MSFT_Share>).
Все конструкции языка разбиты на три больших пакета (packages): образующий (Foundation), поведенческий (Behavioral Elements) и основные механизмы (General Mechanisms). В первый пакет входят ядро (Core), механизмы расширения (Extension Mechanisms) и типы данных (Data Types). Ядро — это формальное описание всех конструкций языка за исключением типов данных, использующихся для записи атрибутов, дополняющих графические элементы языка, и трех механизмов расширения языка новой семантикой (Constraints, Stereotypes, TaggedValues), поскольку информация о них содержится в двух других вышеупомянутых субпакетах. Суть основных механизмов заключается в определении таких понятий, как пакет (package), подсистема (subsystem), модель (model), и правил, которым они должны подчиняться. Эти понятия помогают разработчику разбить общее пространство имен моделируемой системы на отдельные фрагменты. В основе поведенческого пакета и выражений UML лежат графические диаграммы нескольких видов: последовательности действий (use case diagram), классов (class diagram), поведения (behavior diagrams) и реализации (implementation diagram). Рассмотрим эти виды диаграмм, полагаясь, в основном, на их описание на естественном языке, в то время как авторы спецификации, понимая неизбежность неточностей в трактовании выражений английского языка, используют наравне с ним язык Object Constraint Language (OCL).
Предназначение OCL — в получении точной математической оценки правильности построения выражений на других языках. Применяя его, разработчик может однозначно определить допустимость той или иной конструкции, вычислив значения соответствующих формул OCL. В свое время язык был разработан страховым подразделением корпорации IBM для бизнес-моделирования.
 |
| Рис. 1 |
Мы начнем с диаграммы последовательности действий (рис. 1). Каждый логически связанный
между собой набор действий представлен прямоугольником (например, "Заполнение
заказов"). Все наборы действий вынесены на отдельный участок диаграммы и
помещены в прямоугольник. Объекты и модули, которые взаимодействуют (пользуются)
с этими наборами, обозначены изображениями человечков, соединенных линиями с прямоугольниками.
Эти объекты и модули называются действующими лицами, или актерами (actors). Предусмотрено
и взаимодействие актеров между собой. Диаграмма в целом может представлять собой
более детализированную версию другой диаграммы или быть с ней связанной.
 |
| Рис. 2 |
К диаграммам поведения относятся различные элементы: диаграммы состояний (statechart
diagram), активности (activity diagram), взаимодействия (interaction diagrams).
Первые (рис. 2) показывают объект (класс, модуль, актера) как набор состояний
и условий, согласно которым происходит переход от одного из них к другому. Состояние
может включать в себя подсостояния, и, в принципе, число вложений не ограничено.
Соответственно каждая система имеет основное состояние (не обязательно отображенное
на графике), где содержатся все прочие элементы его модели. В целях экономии места
подсостояния разрешается опускать. Такие композитные состояния идентифицируются
по особому значку ("composite" icon), напоминающему символ бесконечности.
Переходы происходят по событиям (events), которыми являются: условие перехода,
получившее значение "истина"; получение внешнего сигнала; вызов операции,
реализованной в объекте как переход или прохождение определенного промежутка времени.
Событие может сгенерировать переход (он будет выполнен), несколько переходов (только
один из них случайным образом выбирается и осуществляется) и ни одного перехода
(событие отбрасывается). Возможен множественный переход (concurrent transition),
который произойдет лишь в том случае, если все состояния-источники заняты, после
чего "инициатива" перейдет ко всем состояниям-приемникам. Контроль за
соблюдением выполнения условий перехода, если таковые имеются, отводится предохранительным
выражениям (guard conditions). Переход к композитному состоянию означает множественный
переход к каждому из его подсостояний.
Существуют и так называемые субмашинные состояния (submachnine states) — они играют роль, в чем-то аналогичную прерыванию в OC или подпрограмме обработки исключительных ситуаций. Субмашинные состояния доступны во всех ситуациях в рамках единого контекста. Для синхронизации процессов, протекающих в системе, предназначены синхросостояния (synch states). Переход из такого состояния возможен только в случае завершения работы на другом участке машины.
 |
| Рис. 3 |
Диаграмма активности представляет собой разновидность диаграммы состояний, функцию
которых в ней выполняют операции, а переход происходит в момент завершения одной
операции и начала действия другой (рис. 3). Так же, как и в предыдущем рассмотренном
нами случае, возможны вложенные операции (subactivity state) и условные разветвленные
переходы (decisions). Диаграмма активности разделяется на "дорожки"
(swimlanes), в каждой из которых размещены элементы, принадлежащие одной подсистеме
(например, "дорожки" клиент-сервер и ПО промежуточного слоя). Объекты,
над которыми совершаются операции, могут быть размещены на графике в разрывах
соединений между элементами диаграммы с указанием их текущего состояния (например,
заказ [пустая форма], заказ [заполненный] и т. д.).
 |
| Рис. 4 |
Диаграммы взаимодействия бывают двух видов: последовательностей (sequence) и сотрудничества
(collaboration). Диаграмма сотрудничества представляет объекты и все виды возможных
взаимодействий между ними, в то время как диаграмма последовательностей отображает
процесс работы системы в виде набора операций (рис. 4). Последняя состоит из ряда
параллельных осей (objects lifelines), каждая из которых представляет объект,
участвующий во взаимодействиях. Обмен сигналами и вызовами (signals and stimulus)
обозначен горизонтальными стрелками. Вдоль оси откладывается шкала времени. Объекты
могут создаваться и разрушаться — это также учтено в системе обозначений.
Перейдем к диаграмме классов. Она описывает статическую структуру модели и взаимосвязь ее компонентов. Диаграмма объектов (object diagram) является ее подвидом и характеризует отношения конкретных объектов системы, включая данные, в определенный момент времени. Классы, интерфейсы и типы данных (DataType) изображаются прямоугольниками, поскольку относятся к одному прародительскому метаклассу — Classifier. Описание класса может включать в себя перечисление относящихся к нему атрибутов, операций и методов и т. д.
Интерфейс (Interface) — еще один элемент, входящий в вышеупомянутый метакласс. Как говорится в спецификации, интерфейс характеризуется только операциями и является виртуальным аналогом класса, овеществляя доступные извне операции других элементов (классов, подсистем, компонентов). Объект, главный персонаж диаграммы, также изображается прямоугольником, но уже разделенным на две секции. Верхняя содержит названия объекта и класса, производным которого он является. В нижней размещен список атрибутов и их значений.
Объекты вполне могут включать в себя другие объекты — Composite Object. Они связаны ассоциациями, которые изображаются линиями (бинарные — сплошными, XOR — сплошными, соединенными пунктиром и т. д.) и имеют смысловые окончания (с определенным направлением движения — стрелка, агрегация — пустой ромб и т. д.). Ассоциации позволяют определить объекты, участвующие во взаимодействии. Роль соединений играют также связи (links), описывающие ссылки, и обобщения (generalizations), показывающие отношения между родственными элементами различного уровня (например, класс-объект). Пунктирные стрелки обозначают зависимости между объектами (когда изменения в одном повлекут изменения в другом).
Наконец, обратимся к диаграммам реализации. Они бывают двух видов: компонентные (component diagrams), касающиеся внутреннего устройства кода, и развертывания или внедрения (deployment diagrams), описывающих структуру системы. Компонентная диаграмма отражает физическую модель программного проекта с его исходными кодами, объектными и исполняемыми файлами, а также их взаимными превращениями, слияниями и т. д. Термин "внедрение" достаточно точно характеризует суть второго типа диаграмм: здесь рассматриваются уже готовая, скомпилированная программа и ее структура, как логическая, так и физическая (сервер, клиент, удаленный ПК и т. д.).
Программисту и… инженеру
UML оказался очень сложным языком. Несмотря на все его недостатки, необходимо
признать, что работа была проделана огромная и важная. Ранее в процессе описания
систем приходилось пользоваться разнообразными средствами: языками моделирования,
математическими выражениями, схемами и пояснениями на естественных языках. Складывающаяся
пестрая картина значительно осложняла понимание, трактование и реализацию заложенных
в модель принципов. UML практически исключает из арсенала программиста эти ненадежные
средства. Строгость и стройность его конструкций позволяют разработчикам создавать
настолько детализированные модели, что возможна прямая их компиляция. Например,
Грегори Икмэн (Gregory T. Eakman) из фирмы Pathfinder Solutions предлагает отлаживать
программы не на этапе их реализации в функциональном коде, а в виде описаний на
языке UML. Модель компилируется, c ней интегрируется отладочный код, и разработчик
получает возможность работать с логикой приложения именно в том виде и на том
уровне абстракции, на котором он ее спроектировал. Еще дальше в этом направлении
продвинулась компания i-Logix, которая продает пакет Rhapsody, сопровождающий
модель на всех стадиях ее развития вплоть до кода на C/C++ или Java. На самом
деле Rhapsody не избавляет пользователя от необходимости писать свой код, хотя
и несколько облегчает ему задачу. Rational Software в своем "фирменном"
продукте Rational Rose предлагает более совершенный подход — разработчик волен
смешивать C/C++, Java, Visual Basic с UML-моделями в любых пропорциях.
И, похоже, что программист вовсе не единственная профессия, которая выиграет от
появления единого языка моделирования. Инженеры уже стоят в очереди. Так, Cadence
Design Systems более года изучает UML и собирается использовать его как входной
язык для свой системы комплексного программно-аппаратного проектирования Cadence
VCC. Но некоторые "горячие" головы не желают ждать — Project Technology
завершила разработку компилятора UML в VHDL и теперь занимается маркетинговыми
исследованиями инженерного рынка. Впрочем, в этой среде предостаточно и скептиков,
полагающих, что универсальный и сыроватый UML не может конкурировать с такими
признанными специализированными языками, как SDL (System Design Language). Только
время покажет…