Технология Клиент-Сервер 1998'3
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Унифицированный язык моделирования обретает форму

Что, если вам скажут, что существует подход к моделированию как данных, так и процессов, в котором воплощена практика многих профессионалов отрасли? Более того, что, если эта система обозначений в моделировании устраняет необходимость в одновременном использовании различных систем, объединявшихся методологией существующих программных средств? Что, если эта система обозначений в моделировании принята более чем 700 различными организациями? Кроме того, уже существует несколько различных поставщиков CASE-средств, предоставляющих поддержку этой системы обозначений, а так же и расширений, которые могут создавать СУБД, реализующие смоделированные связи, по реляционной и объектно-ориентированной схемам. Что, если эти средства CASE могут генерировать исходный код во множестве различных языков, что обеспечивает поддержку при создании программного обеспечения, реализующего функциональность приложения? Возможно, вы захотите узнать, действительно ли это так (и как можно узнать об этом больше).

Многие думают, что все эти задачи выполняет Унифицированный Язык Моделирования (Unified Modeling Language — UML). Object Management Group в ноябре 1997 года UML приняла в качестве официальной объектно-ориентированной системы обозначений моделирования при описании доменов приложений. В этой статье мы рассмотрим фундаментальные компоненты UML и то, что могут предоставить различные способы представления (views). Кроме того, будут объяснены способы преобразования объектно-ориентированных моделей в реализации с необъектно-ориентированными решениями, главным образом, реляционные СУБД. UML является основой репозитория Microsoft и расширяется для обеспечения поддержки корпоративного моделирования.

Первоначально UML появился из комбинации усилий Грейди Буча (Grady Booch) - метод Буча, Джеймса Румбо (James Rumbaugh) - Техника Объектного Моделирования (Object Modeling Technique - OMT) и Ивара Якобсона (Ivar Jacobson) - метод конструирования объектно-ориентированного программного обеспечения (Object-Oriented Software Engineering — OOSE). UML начал приобретать форму начиная с 1994 года, под покровительством Rational Software Inc. Несмотря на то, что большое влияние на его развитие оказывали Буч, Румбо и Якобсон, в эволюции UML приняли участие и такие организации, как Hewlett-Packard и IBM. Кроме этого, официально UML рассматривался и как ответ на запрос OMG об объектно-ориентированной системе обозначений.

Невозможно переоценить значимость того, что UML был принят OMG. Для тех, кто работал со структуральным анализом и проектированием (SA/SD), существовал выбор множества диаграммных обозначений и несколько моделей процессов, с которыми эти обозначения применялись. Было бы гораздо лучше, если бы еще в конце 70-х - начале 80-х Эд Йордон (Ed Yourdon), Джеймс Мартин (James Martin) и Том ДиМарко (Tom DeMarco) оставили свои амбиции в стороне и приняли единые условные обозначения для SA/SD при разработке приложений. Увы, этого не произошло. В этом случае не только модели в одной организации были бы одинаковы, но был бы единый фундаментальный стандарт и во всех организациях, а также и при переходе от одного домена приложения к другому.

Кого-то может удивить полезность объектно-ориентированного анализа и проектирования (object-oriented analysis and design - OOAD). Несмотря на детальное обсуждение преимуществ OOAD-подхода в этой статье, исходя из исторической перспективы можно сделать вывод, что официальное разделение данных и функций делает многие наши попытки в разработке приложений, в лучшем случае, недолговечными.

Как сказал д-р Дэвид Тейлор (David Taylor) в книге "Объектная технология: справочник управления", программная отрасль во многом схожа с отраслью строительства коттеджей в конце 18 - начале 19 веков. Каждое изделие создавалось вручную, не было взаимозаменяемых деталей, все делалось вразнобой. Это продолжалось до появления четких спецификаций, сделавших массовое производство продукции реальностью. Этот "сдвиг парадигмы" известен как Техническая Революция. Программная отрасль находится в аналогчном печальном положении. Все делается по-своему, а повторное использование компонентов, которое привело бы к экономии времени на написании кода, по прежнему недоступно. Единственный способ получить больше систем с меньшими затратами на написание кода - это рассмотрение проекта сквозь призму объектно-ориентированного подхода.

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

Многие модели процессов (те, которые описывают поэтапную разработку проекта) и системы разработки жизненного цикла (описывающие шаги, необходимые для завершения фаз проекта), могут использовать UML в качестве системы обозначений. Кроме того, многие из существующих методологий, включая Hewlett-Packard Fusion, Microsoft Soluions Framework и Rational Software Objectory, либо уже воспользовались, либо используют UML.

UML предоставляет три способа представления приложения - статическое представление, моделируемое с использованием диаграмм классов и использования условий (use-case); динамическое представление, использующее последовательности, коллективное использование и диаграммы изменения статусов; и функциональное представление, использующее диаграммы активности и более традиционные описывающие комментарии - такие, как псевдокод и миниспецификации. Существует и четвертое представление, комбинированное со статическим - архитектурное представление. Это представление при моделировании использует такие понятия, как пакет (package), компонент (component) и диаграммы распределения (deployment diagram).

Статическое
представление

Статическое представление содержит главное во всех диаграммах, предлагаемых UML, - диаграмму классов. В отличие от моделей, созданных при помощи SA/SD, диаграмма классов продолжает развиваться на всем протяжении жизненного цикла проекта. В итоге статическое представление не является полностью неизменным - оно меняется по мере добавления к проекту новой информации. На самом деле, классическая диаграмма сущность-связь (entity-relationship diagram - ERD) - это модель, которая развивается и при традиционном подходе SA/SD; однако, ERD представляет только связи между данными и не предоставляет ничего, что касалось бы функциональности. В этом заключается отличие от диаграммы классов, которая отражает данные и операции, являющиеся реальными сущностями, и объекты, необходимые для поддержки.

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

Каждое условие использования содержит полный набор событий, инициируемых участником и определяемых взаимодействием, которое будет происходить между участником и системой. Здесь не описывается, "как". Это будет разъясняться в функциональном представлении системы. Вместо этого, диаграмма условий использования моделирует, когда возникает условие, что оно делает и где - завершается. На рис.1 приведен пример диаграммы условий использования, в которой идентифицированы участники и использование условий.

Рис.1. Диаграмма условий использования

Следующим шагом будет сбор всех этих описаний, получение объектов и создание списка потенциальных классов. Знакомо звучит? Это именно та практика, которая используется многими разработчиками моделей при подходе ERD в SA/SD. Разница заключается в источнике объектов. Раньше эта информация бралась из блиц- или совместного сеанса разработки приложений вместе с пользователями системы, в течение которого определялись ключевые сущности. Разработчики просили пользователей сфокусироваться на субъектах системы, а сами строили матрицу, определяющую связи на высоком уровне и их параметры (такие, как один-ко-многим и многие-ко-многим).

Из списка объектов выделяются главные, после чего строится первоначальная диаграмма классов. На рис.2 представлен пример диаграммы классов. ERD может отразить большую часть информации, получаемой на этом этапе. Однако в ERD такие понятия, как аггрегации (aggregation) и композиции (composition) (полные и частичные связи) моделируются без отличия от обычных связей. ERD не осуществляет обобщений, несмотря на то, что подтипы и надтипы могут говорить о наличии наследования.

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

Думается, что хороший разработчик моделей в ERD может очень легко извлечь объекты и изучить условные обозначения стандарта ERD, а затем - быстро перейти к данным диаграммы классов URL.

Динамическое представление

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

Динамическое представление начинает работать с условий использования. Заметьте, что условие использования описывает работу участника в системе. Условия использования могут иметь много различных способов взаимодействия. Например, "обработка транзакций" учитывает то, что участник "teller" может иметь несколько способов взаимодействия или сценариев. Один из них может быть копировать информацию, второй - получать ее, а третий - обеспечивать баланс запросов. Каждый из этих сценариев будет взаимодействовать со множеством различных объектов домена приложения, таких как счет, потребитель или транзакция.

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

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

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

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

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

Функциональное представление

Функциональное представление концентрируется на том, "как" работает то, что изображено. Например, статическое и динамическое представление описывает, "что" делает операция, называемая calcInterest, не фокусируясь на алгоритме, необходимом для выполнения этих действий. На алгоритме концентрируется именно функциональное представление.

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

Архитектурное представление

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

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

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

От моделей к коду: СУБД

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

Фреймворк UML дает разработчикам CASE необходимую информацию о метамодели, что позволяет генерировать схемы реляционных СУБД с учетом спецификаций языка описания данных (Data Definition Language - DDL). Как минимум, большинство этих CASE-средств генерируют ANSI DDL, а некоторые из них - DDL, предназначенные для определенных баз данных - таких как Oracle и SQL Server.

Поставщики ERD и средств моделирования объектов связаны между собой, как, например, Rational (производитель Rational Rose) и LogicWorks Inc. (ERWin). Например, бесплатно рапространяемый мост, доступный с Web-сайта Rational, позволяет генерировать схему СУБД непосредственно в ERWin. Это очень полезно, поскольку ERWin может генерировать DDL СУБД во многих различных языках, что, разумеется, расширяет диаграмму классов UML - источников схемы СУБД. Однако, если был выбран не ERWin, то можно воспользоваться средствами ERD, большинство которых предоставляют возможность обратной разработки. Можно использовать другой подход. С помощью объектных средств генерируется ANSI DDL, а затем эти файлы передаются средству ERD, и в дальнейшем они могут обрабатываться базой данных.

Чтобы почувствовать, как работает преобразование реляционных СУБД, имеющееся в диаграмме классов UML, посмотрите на DDL, сгенерированный для класса SavingsAccount (рис.4).

Рис.4. DDL, сгенерированный для класса SavingsAccount

Давайте вспомним из рис.2, что связи для счетов были смоделированы в UML как обобщение, а это предполагает общие операции и атрибуты для счетов любого типа. ANSI DDL, созданный Rational Rose, генерирует пять физических таблиц: Account, CheckingAccount, SavingsAccount, Transaction и Customer. Кроме того, он генерирует два представления. Представление SavingsAccount_V включает в себя как атрибуты класса Account (надтип - с точки зрения ERD), так и атрибуты класса SavingsAccount (подтип - с точки зрения ERD). То же самое сделано и для класса CheckingAccount.

От моделей к коду: Бизнес-правила

UML формализует то, что разработчикам объектов было известно давно: реальные объекты лучше всего моделировать как самодостаточные сущности, содержащие данные и выполняемые функции. В UML это выражено атрибутами и операциями. Мы рассмотрели, как следует работать с преобразованием диаграммы классов в данные. А что можно сказать о функциональности системы?

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

Некоторые поставщики CASE рассматривают большее число аспектов сценариев системы. Они могут обрабатывать сценарии из диаграммы статусов, что само по себе не является новой концепцией — многие поставщики считают такое преобразование простым. Примером может послужить недавно анонсированная ObjectTime попытка поддержки UML, причем это произошло после долгих лет генерирования кода С и С++ из диаграммы статуса . Другим подходом, не получившим особого развития, является генерация кода из других диаграмм, а именно — диаграмм последовательностей и совместной работы. Сценарий, первоначально оговоренный условиями использования, является связующим звеном системы. Его детализация в диаграмме последовательностей — это схема обмена между объектами, позволяющая завершить сценарий. Это, так сказать, жизненный цикл одного из сценариев системы.

От моделей к коду: Распределение

Это обсуждение будет неполным, если не упомянуть о влиянии UML на распределенные приложения. Опять же, UML предоставляет конструкции, которые получают поставщики CASE. Большинство поставщиков CASE производят заглушки языка описания интерфейсов (IDL) из диаграммы классов. OMG CORBA (Common Object Request Broker Architecture) и Microsoft DCOM (Distributed Component Object Model) для осуществления взаимодействия между объектами опираются именно на файлы IDL.

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

Что нас ждет в будущем?

На момент публикации, UML версии 1.1 можно получить на Web-сайте Rational. Несмотря на то, что официально признанной OMG версией является 1.0, отличия между 1.0 и 1.1 — невелики. UML будет развиваться в унисон развитию рынка. OMG имеет специально созданные группы, в задачу которых входит наблюдение за развитием UML. Rational считает, что изменения UML будут носить характер дополнений к существующему ядру, преимущественно в областях бизнес- и корпоративного моделирования.

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

Сам UML тоже нашел свой путь в стан Microsoft, в основном благодаря репозиторию. Этот репозиторий в качестве своего фундамента использует именно UML, и Platinum Technology переносит его для Microsoft на платформы - AS/400 и Unix. Кроме того, поддержку репозитория анонсировали свыше 65 различных поставщиков. Используя UML в качестве ядра, репозиторий усиливает его роль на рынке.

Другим предложением Microsoft, подтверждающим его признание UML, является продукт Visual Modeler, поставляемый с корпоративной редакцией Visual Basic 5.0. Это - упрощенная версия Rational Rose для Visual Basic. В ней не будет поддерживаться динамическое представление модели, но из диаграммы классов будет генерироваться код Visual Basic.

Число средств, поддерживающих UML, быстро увеличивается. И, что более важно, поддержка UML будет развиваться и дальше. Как уже говорилось, UML поддерживается такими популярными средствами моделирования процессов, как Hewlett-Packard Fusion и Microsoft Solutions Framework. UML поддерживается и Rational Software Objectory.

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

UML вооружил отрасль разработки приложений весьма серьезным оружием. Его вклад - это поддержка объектно-ориентированной концепции приложений, что позволяет создавать лучшее программное обеспечение и предоставление общей системы обозначений для выражения потребностей конкретного проекта.

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

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

Copyright © 1994-2016 ООО "К-Пресс"