Объектно-ориентированное моделирование поведения

При создании программной системы недостаточно ответить на вопросы "что делает система?" (глава 2) и "из чего она состоит?" (глава 3) — требуется ответить на вопрос "как работает система?". Ответ на этот вопрос называется (в UML) моделью поведения. Поведение реальной программной системы целиком и полностью определяется кодом ее программы — как программа составлена, так она и выполняется (с точностью до сбоев) — "от себя" компьютер ничего не придумывает. Таким образом, модель поведения — это описание алгоритма работы системы.

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

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

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

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

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

• Средства моделирования поведения в UML должны быть знакомы и привычны большинству пользователей языка и не должны противоречить требованиям наиболее ходовых парадигм программирования.

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

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

Для пользователя поведение приложения проявляется прежде всего в интерфейсе. В принципе возможны два архитектурных решения интерфейса с пользователем:

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

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

В настоящее время более распространенным, особенно в наиболее массовых приложениях для бизнеса, является второе решение (т. е. пассивный интерфейс). Это обусловлено целым рядом причин, в том числе:

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

• наличием в современных системах программирования и операционных системах для данной архитектуры развитого механизма поддержки, называемого событийным управлением, который описан ниже;

• устоявшейся за последние несколько лет привычкой массового пользователя к пассивному интерфейсу.

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

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

Различаются однопоточные (т. е. с одним потоком управления) и многопоточные программы. Характерным признаком однопоточной программы является то, что в каждый момент времени можно указать единственный оператор программы, который выполняется в данный момент — говорят, что этот оператор имеет фокус управления. В многопоточной программе имеется несколько потоков управления и сосуществуют несколько фокусов управления, соответственно. При этом совершенно необязательно, чтобы различные потоки управления выполнялись физически одновременно на разных процессорах: достаточно иметь в операционной системе механизм, обеспечивающий переключение процессора на выполнение разных потоков управления.

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

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

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

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

В следующих разделах рассматриваются все указанные средства более детально.