Процедурного программирования. Следует отметить, что хотя подход Statemate является в чистом виде процедурным, диаграммы состояний входят также в состав объектно-ориентированного языка спецификации UML и используются в объектно-ориентированном методе разработки Unified Rational Process В соответствии с подходом Statemate предлагается рассматривать проектируемую систему с трех точек зрения и, соответственно, использовать для спецификации три различные графические нотации. Структурный вид системы предлагается описывать с помощью диаграмм модулей, функциональный вид — с помощью диаграмм деятельностей, а поведенческий — с помощью диаграмм состояний.
На диаграмме модулей изображается структура системы в виде множества взаимодействующих аппаратных и программных компонентов (модулей, подсистем) и элементов внешней среды. На рис. 2.26 приведен пример диаграммы модулей для системы раннего оповещения. На диаграмме деятельностей1 отображается иерархия функциональных возможностей (функций, деятельностей) системы, порожденная путем декомпозиции сверху вниз. Пример такой диаграммы приведен на рис. 2.27.Диаграммы состояний — это графическая нотация, как и диаграммы переходов, основанная на графах и предназначенная для отображения определенной автоматной модели. Если автоматная модель, используемая в программировании с явным выделением состояний, расширяет традиционное понятие конечного автомата такими дополнительными возможностями, как вложенные и вызываемые автоматы, группы состояний, переходы с приоритетами и т. д., то в подходе Statemate используются другие расширения. Среди наиболее употребительных: вложенные состояния, ортогональные состояния, исторические состояния, действия при входе в состояние и при выходе из него, деятельности. С концепциями и терминологией диаграмм состояний можно познакомиться в работах [28, 30, 36]. Пример диаграммы состояний приведен на рис. 2.28.1* Не следует путать с диаграммой с тем же названием в языке UML.В программировании с явным выделением состояний, в отличие от метода Statemate, используется всего два основных вида диаграмм: на схемах связей отражают структурные и функциональные свойства системы, а на диаграммах переходов — ее поведение. Трудно судить объективно, какой из подходов к описанию системы лучше. Отметим только, что в подходе Statemate диаграммы модулей и деятельностей в некотором смысле конфликтуют друг с другом, поскольку первые навязывают разработчику объектную декомпозицию, а вторые — функциональную декомпозицию сверху вниз. Во избежание противоречия авторы подхода рекомендуют брать за основу архитектуры диаграмму деятельностей, а с помощью диаграммы модулей изображать систему только на самом верхнем уровне абстракции. При использовании схем связей такого противоречия не возникает. Многие различия между языками спецификации метода Statemate и автоматного программирования обусловлены тем, что автоматное программирование имеет более широкую область применения. Подход Statemate предназначен для создания реактивных систем, а это частный случай систем со сложным поведением. По этой причине диаграммы состояний изобилуют понятиями, специфичными для таких систем: сторожевое условие, деятельность, действие при входе в состояние и при выходе из состояния. Аналогов этих понятий нет ни в теории формальных языков, ни в теории автоматов, ни в теории управления. С другой стороны, автоматное программирование основывается на классических автоматных моделях (автоматах Мили и Мура) и вносит только два основных расширения (вложенные и вызываемые автоматы), которые, однако, являются весьма выразительными. Таким образом, нотация диаграмм переходов является более простой по сравнению с языком Statecharts, но при этом позволяет выражать те же поведенческие свойства. Среди ограничений, которые характерны для диаграмм состояний и отсутствуют у диаграмм переходов, отметим следующие: ориентированность на проектирование событийных систем; условием перехода может быть только единичное событие, охраняемое стороyyжевым условием; выходное воздействие на переходе может состоять только из единичного действия. Эти ограничения представляются авторам неоправданными. Одно из главных свойств любой графической нотации, предназначенной для описания сложных программных систем, — это поддержка декомпозиции. В диаграммах переходов этой цели служат вложенные и вызываемые автоматы, а в языке Statecharts — вложенные и ортогональные состояния. Вложенные состояния используются для последовательного уточнения логики: внутрь более абстрактного, так называемого супер состояния могут быть вложены несколько более конкретных состояний. Ортогональные состояния служат для задания независимых логических «измерений». Если система находится в состоянии, разбитом на несколько ортогональных компонентов, это означает, что она находится во всех этих компонентах одновременно *1 На рис. 2.28 состояния «Бездействие» и «Работа» вложены в со*1 Поэтому в некоторых источниках такие состояния называют не ортогональными, а параллельными. стояние «Соединено». Наиболее абстрактное состояние «Включено» разделено пунктирной линией на два ортогональных компонента. В рамках нотации диаграмм переходов обе концепции: и последовательное уточнение логики, и задание независимых логических измерений — поддерживаются механизмом вложенных автоматов (хотя в графах переходов для компактного изображения однотипных переходов могут использоваться групповые состояния (см. рис. 2.24), которые в этом смысле эквивалентны супер состояниям). Семантически супер состояние с несколькими вложенными состояниями на диаграмме переходов эквивалентно состоянию с единственным вложенным в него автоматом, а супер состояние с несколькими ортогональными компонентами — состоянию с несколькими вложенными автоматами (или нескольким параллельно работающим автоматам на верхнем уровне иерархии).С точки зрения синтаксиса, решение, используемое в диаграммах переходов, имеет важное преимущество. В отличие от вложенных состояний, вложенные автоматы специфицируются отдельно от объемлющего автомата, и для каждого из них строится свой граф переходов. Это решение более масштабируемое (при росте размера системы диаграммы не становятся неограниченно большими) и лучше приспособлено для повторного использования (обращение к одному и тому же вложенному автомату в разных местах не требует повторения его спецификации). При этом отметим, что в языке UML поддерживаются вложенные диаграммы состояний, однако их поддержка появилась только в UML 2.0 В заключение отметим, что несмотря на разночтения в нотациях, подход Statemate и программирование с явным выделением состоянии концептуально очень близки. К сожалению, попав в объектно-ориентированный мир — в язык UML, диаграммы состояний не заняли подобающего им положения. Вместо формальной спецификации логики сложного поведения, достаточно выразительной для автоматической генерации по ней кода, диаграммы состояний превратились в еще один вид иллюстраций, которые иногда включают в техническую документацию системы. Причина этого, по мнению авторов, в недостаточно глубоком осмыслении роли автоматного описания поведения в объектно-ориентированном программировании. Попытка такого осмысления, результатом которой являются концепции объектно-ориентированного программирования с явным выделением состояний, сделана авторами в главе 3. При этом следует отметить, что возможность автоматической генерации кода с учетом диаграмм поведения появилась в рамках концепции исполняемый UML что потребовало значительной доработки языка UML