110
модель системы и интегрировать с другими диаграммами. По мнению авторов, это и
явилось основной причиной, по которой диаграммы состояний долгое время
использовались в объектной технологии только в качестве документации, а не как
полноценные формальные спецификации. При этом в результате опроса,
проведенного С. Орликом (Borland), было установлено, что даже в тех случаях, когда
архитекторы программной системы создают диаграммы состояний, при переходе к
реализации разработчики их обычно не используют.
Если следовать приведенной выше рекомендации, исчезает разница между графами
переходов, диаграммами состояний и другими нотациями, поддерживающими
различные расширения базовой модели конечного автомата. Поскольку объектная
декомпозиция заменила автоматную, больше нет необходимости ни во вложенных и
вызываемых автоматах, ни в ортогональных и суперсостояниях (хотя группировку
состояний, безусловно, можно использовать как косметическое средство для
улучшения внешнего вида диаграмм). Все, что требуется от графической нотации –
это состояния и переходы между ними с условиями (в виде булевых формул от
событий и входных переменных) и действиями (в виде одиночных выходных
переменных или их последовательностей).
Поговорим немного о декларативном описании сложного поведения. Этот вопрос в
настоящее время изучен гораздо меньше. Причина этого, по мнению авторов этой
книги, в том что, круг исследователей, которые интересуются формальными
спецификациями и контрактами, практически не пересекается с кругом тех, кто
озабочен проблемами сложного поведения.
Контракт является частью интерфейса класса и, в основном, предназначен для его
клиентов. Если обыкновенные классы в системе снабжены контрактами, то и
автоматизированные классы должны иметь контракты точно такого же вида. Однако
составление содержательного контракта для сущности со сложным поведением
может быть непростой задачей. Спецификации компонентов этой сущности должны
отражать ее реакцию во всех возможных управляющих состояниях.
Например, если вспомнить уже знакомые читателю часы с будильником, каким
должно быть постусловие компонента h? Оно может быть, например, следующим:
«Если часы в первом или в третьем состоянии, то увеличилось число часов текущего
времени, а если во втором – то увеличилось число часов срабатывания будильника».
Такой контракт очень содержателен, однако он раскрывает внутреннюю
информацию об управляющих состояниях. Для клиентов класса такой контракт,
скорее всего, будет являться чрезмерной спецификацией. Можно предложить другой
вариант: «Увеличилось либо число часов текущего времени, либо число часов
срабатывания будильника», или: «Число минут не изменилось, а число часов
текущего времени и число часов срабатывания будильника не могли оба
увеличиться». Будет ли такая спецификация достаточной? Что именно необходимо
знать клиенту о работе компонента h? Стандартных рекомендаций по этому поводу
не существует, по крайней мере, на данный момент.
Каким бы ни был контракт автоматизированного класса, его поведение в каждом из
управляющих состояний в отдельности является частным случаем общего, сложного
поведения. Поэтому если составить контракт на поведение сущности в одном
конкретном состоянии, то он должен быть сильнее, чем общий контракт на сложное
поведение. Это условие аналогично принципу подстановочности, который