Как с помощью технологии UML ускорить цикл разработки приложений

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

Вот тут-то на помощь и приходит унифицированный язык моделирования UML (Unified Modeling Language). Технология UML, одобренная консорциумом Object Management Group, является мощным средством описания бизнес-процессов и представления их в той форме, которая устраивает как разработчиков, так и пользователей. В данном обзоре мы постараемся показать, каким образом с помощью технологии UML можно ускорить цикл разработки и повысить надежность приложений.

От данных к объектам

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

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

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

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

Новый инструмент моделирования

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

Язык UML стал логическим завершением усилий специалистов компании Rational Software, стремившихся интегрировать основные технологии моделирования. Подход, выбранный разработчиками UML (которые создавали язык моделирования, а не язык программирования), позволяет архитекторам систем эффективно описывать классы, методы и связи между ними.

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

Один шаг за пределы блок-схемы

Язык UML — это не просто совокупность альтернативных решений. Его концепция принципиально отличается от «старомодных» технологий (в частности, от блок-схем и электронных таблиц). Вместо того чтобы иллюстрировать изолированные части процесса, UML отдает предпочтение диаграммам верхнего уровня, позволяющим разработчикам скрывать детали и концентрировать внимание на функциональных особенностях, а не на последовательности действий. Данный подход позволяет начать с формирования общего взгляда на приложение, детали же раскрываются позже.

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

Диаграммы объектов и классов описывают статическое состояние элементов системы в каждый конкретный момент, показывают структуру объектов, их атрибуты и взаимные связи. Диаграммы действий отображают управляющие потоки, идущие от одного действия к другому, а диаграммы фактов использования иллюстрируют элементы, находящиеся за пределами системы. (К примеру, внутренние операции новой платежной системы отображаются на диаграмме действий, тогда как работа внешних агентов, в частности отдела обработки почтовых заказов, представлена на диаграмме фактов использования.) Последовательность и взаимные связи диаграмм отражают интерактивные процессы: вы видите не только объекты и классы, но и сообщения, которыми они обмениваются. Таким образом, с помощью системы можно моделировать ситуации, применяя обычную в таких случаях технологию «что, если». Диаграммы состояния используются для описания динамических объектов, часто отправляющих и принимающих сообщения. Наконец, диаграммы компонентов и развертывания предназначены для физического представления системы (в том числе исполняемых модулей, библиотек и интерфейсов).

С помощью инструментального пакета Rational Rose та же самая система управления заказами, описанная ранее, может быть представлена в интуитивном формате, описывающем структуру сверху вниз

Инструментальные пакеты UML (например, комплект разработчика Rational Rose) содержат инструментальные средства, позволяющие легко создавать модели UML для бизнес-процессов и генерировать код на различных языках программирования (в том числе на Java, C++ и Visual Basic). Большинство пакетов отображают подробную информацию о выбранном объекте. Для этого достаточно щелкнуть мышью на его пиктограмме. Войдя, к примеру, в заказ, можно ознакомиться с набором операций по управлению данным заказом и просмотреть последовательную диаграмму действий.

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

Что дальше?

Последний вариант спецификаций UML (версия 1.3) содержит ряд улучшений, к которым относятся новые семантические конструкции, усовершенствованная организация и улучшенная читабельность документов, а также поддержка нового интерфейса XMI (XML Metadata Interchange). Устранены обнаруженные ранее ошибки. Но на этом процесс развития языка не заканчивается. В дальнейшем разработчики намерены предложить интерфейсы для технологий CORBA, Enterprise JavaBeans и XML, средства контроля версий моделей и взаимного обмена диаграммами, более точные обозначения для представлений корпоративной архитектуры, улучшенную семантику для дальнейшей модернизации и отслеживания зависимостей.

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


UML

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

Достоинства: стандартная методология; интуитивно понятные обозначения, мощные описательные средства языка; автоматическая генерация кода

Недостатки: потребность в обучении; необходимость одновременного перехода на данную технологию всех участников проекта


До-объектно-ориентированная графическая нотация

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