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

Проектирование для программиста

Сергей Шмаков

Моделирование поведения системы – двойная работа

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

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

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

Рисунок 1.

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

Суть проблемы

Давайте разберем следующую задачу: «Найти элемент в наборе данных, максимально удовлетворяющий некоему условию».

Не правда ли, знакомая задача? О, да. А теперь ответьте, как вы ее решите практически? Знаю, знаю – вы скажете, что решение зависит от того, что это за набор данных, каковы его элементы, и как проверяется данное условие.

В каждой более-менее сложной программной системе встречаются подобные задачи. Тривиальной ее разновидностью является поиск максимального значения. Алгоритм для поиска максимума на языках высокого уровня, например, C, будет выглядеть примерно так:

maxElement = 0;
for( i = 0; i < count ; i++)
  if (maxElement < array[i])
    maxElement = array[i];

Та же задача на языке SQL записывается гораздо проще:

SELECT max(NumField) FROM ArrayTable

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

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

Но ведь цель моделирования поведения системы состоит не в том, чтобы в деталях описать простейшие алгоритмы! Все, что действительно показывает модель, содержится в самом определении задачи – «Найти элемент в наборе …». А работу по конкретному воплощению задачи хотелось бы оставить автоматическим средствам разработки, и не забивать себе этим голову.

Но, увы, даже современные CASE-средства не настолько умны, чтобы самим думать за человека...

Поиск решения проблемы

Теперь я сообщу вам приятные новости.

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

Над этой задачей работали компании, занимающие заметное положение на рынке CASE-средств, такие как Project Technology, Rational, Telelogic и еще несколько компаний. Результатом работы стал документ Action Semantics for UML. Этот двухсотстраничный документ весьма тщательно определяет семантику элементов, добавляемых в стандарт языка UML для моделирования действий системы.

К сожалению, документ Action Semantics for the UML стандартизирует лишь семантику языка, и не определяет его синтаксис. С практической точки зрения это означает, что собственно язык моделирования действий системы так и не был разработан. Участники проекта лишь приняли соглашение о принципах разработки такого языка. Отсутствие стандартного синтаксиса, тем не менее, не помешало нескольким участникам проекта разработать собственный инструментарий моделирования поведения.

Принцип решения проблемы – отчуждение модели системы от реализации

Давайте запишем приведенную выше задачу в виде выражения...

Прочитать статью полностью вы можете в печатной версии журнала

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