• Позволять моделировать не только программное обеспечение, но и более широкие классы систем и бизнес-приложений, с использованием объектно-ориентированных понятий.
• Явным образом обеспечивать взаимосвязь между базовыми понятиями для моделей концептуального и физического уровней.
• Обеспечивать масштабируемость моделей, что является важной особенностью сложных многоцелевых систем.
• Быть понятен аналитикам и программистам, а также должен поддерживаться специальными инструментальными средствами, реализованными на различных компьютерных платформах.

    Разработка  системы обозначений или нотации  для ООАП оказалась непохожей  на разработку нового языка программирования. Во-первых, необходимо было решить две  проблемы:

1. Должна ли данная нотация включать в себя спецификацию требований?
2. Следует ли расширять данную нотацию до уровня языка визуального программирования?

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

    В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group). Хотя консорциум OMG был  образован еще в 1989 году с целью  разработки предложений по стандартизации объектных и компонентных технологий CORBA, язык UML приобрел статус второго  стратегического направления в  работе OMG. Именно в рамках OMG создается команда разработчиков под руководством Ричарда Соли, которая будет обеспечивать дальнейшую работу по унификации и стандартизации языка UML. В июне 1995 года OMG организовала совещание всех крупных специалистов и представителей входящих в консорциум компаний по методологиям ООАП, на котором впервые в международном масштабе была признана целесообразность поиска индустриальных стандартов в области языков моделирования под эгидой OMG.

    Усилия  Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.). Имевшие статус запроса предложений RTP (Request For Proposals), эти документы послужили  своеобразным катализатором для  широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали  на необходимость его дополнения отдельными понятиями и конструкциями.

    В это же время стало ясно, что  некоторые компании и организации  видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы  для разработки строгого определения  версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально  вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей  работы по более точному и строгому определению нотации, что привело  к появлению версии 1.0 языка UML. В  январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный  вариант ответа на запрос предложений RTP. Эта версия языка моделирования  была достаточно хорошо определена, обеспечивала требуемую выразительность и  мощность и предполагала решение  широкого класса задач.

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

    Из  более чем 800 компаний и организаций, входящих в настоящее время в  состав консорциума OMG, особую роль продолжает играть Rational Software Corporation, которая стояла у истоков разработки языка UML. Эта  компания разработала и выпустила  в продажу одно из первых инструментальных CASE-средств Rational Rose 98, в котором был  реализован язык UML.

    В январе 1997 года целый ряд других компаний, среди которых были IBM, ObjecTime, Platinum Technology и некоторые другие, представили на рассмотрение OMG свои собственные ответы на запрос предложений RFP. В дальнейшем эти компании присоединились к партнерам UML, предлагая включить в язык UML некоторые свои идеи. В  результате совместной работы с партнерами UML была предложена пересмотренная версия 1.1 языка UML. Основное внимание при разработке языка UML 1.1 было уделено достижению большей ясности семантики языка  по сравнению с UML 1.0, а также учету  предложений новых партнеров. Эта  версия языка была представлена на рассмотрение OMG и была одобрена и  принята в качестве стандарта OMG в ноябре 1997. года.

    В настоящее время все вопросы  дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG. Соответствующая  группа специалистов обеспечивает публикацию материалов, содержащих описание последующих  версий языка UML и запросов предложений RFP по его стандартизации. Очередной  этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3 (alpha R5). Последней версией языка UML на момент написания книги является UML 1.3, которая описана в соответствующем  документе - "OMG Unified Modeling Language Specification", опубликованном в июне 1999 года. История разработки и последующего развития языка UML графически представлена на рис:

    Рис.1 История развития языка UML 

    Статус  языка UML определен как открытый для всех предложений по его доработке  и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо, хотя указанный  выше документ защищен законом об авторском праве. В то же время  аббревиатура UML, как и некоторые  другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев, о чем следует  упомянуть в данном контексте.

    Язык UML ориентирован для применения в  качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач  ООАП. Многие специалисты по методологии, организации и поставщики инструментальных средств обязались использовать язык в своих разработках. При  этом термин "унифицированный" в  названии UML не является случайным и имеет два аспекта. С одной стороны, он фактически устраняет многие из несущественных различий между известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, создает предпосылки для унификации различных моделей и этапов их разработки для широкого класса систем, не только программного обеспечения, но и бизнес-процессов. Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования.

    В этой связи следует отметить внимание гиганта компьютерной индустрии  компании Microsoft к технологии UML. Еще  в октябре 1996 г. Microsoft и Rational Software Coiporation объявили о своем стратегическом партнерстве, которое, по их общему мнению, способно оказать решающее влияние  на рынок средств объектно-ориентированной  разработки программ. При этом Microsoft лицензировала у Rational Software некоторые  технологии визуального моделирования, в результате чего был разработан Microsoft Visual Modeler for Visual Basic. В свою очередь Rational Software лицензировала у Microsoft Visual Basic и Microsoft Repositoiy, разрабатываемые вместе с Texas Instruments. При создании языка UML Microsoft внесла свой вклад в интеграцию UML со своими стандартами типа ActiveX и  СОМ и в использование языка UML со своей технологией Microsoft Repository.

    На  основе технологии UML Microsoft, Rational Software и  другие поставщики средств разработки программных систем разработали  единую информационную модель, которая  получила название UML Information Model. Предполагается, что эта модель даст возможность  различным программам, поддерживающим идеологию UML, обмениваться между собой  компонентами и описаниями. Все это  позволит создать стандартный интерфейс  между средствами разработки приложений и средствами визуального моделирования.

    Уже в настоящее время разработаны  средства визуального программирования на основе UML, обеспечивающие интеграцию, включая прямую и обратную генерацию  кода программ, с наиболее распространенными  языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Поскольку при разработке языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на очередные версии языка UML также окажут влияние и другие перспективные технологии и концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные методы. Язык UML может быть расширен без переопределения его ядра.

    Подводя итог анализу методологии ООАП и  исторических предпосылок появления UML, можно утверждать следующее. Имеются  все основания предполагать, что  в ближайшие годы язык UML в его  современном виде станет основой  для разработки и реализации во многих перспективных инструментальных средствах: в RAD-средствах визуального и имитационного  моделирования, а также в CASE-средствах  самого различного целевого назначения. Более того, заложенные в языке UML потенциальные возможности могут  быть использованы не только для объектно-ориентированного моделирования систем, но и для  представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические  комплексы.

4. Виды диаграмм

    4.1 Диаграмма классов

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

    • ассоциации (например, клиент может  сделать заказ);

    • подтипы (частный клиент является разновидностью клиента). 

    Рис.2 Диаграмма классов 

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

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

    Построение  диаграмм классов можно рассматривать  в различных аспектах:

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

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

    аспект  реализации - модель действительно  определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

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

    Точка зрения на диаграммы классов, не будучи собственно формальной частью UML, однако при построении и анализе моделей является крайне важной. Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают аспект реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.