Создавать для программы дополнительное визуальное и документальное сопровождение - процесс трудоемкий и утомительный: отнимает много времени и кажется совершенно излишним, если архитектура программного обеспечения проста или является эталонной. Однако на практике программисты далеко не всегда сталкиваются с такими задачами.
Мы уже рассказывали, как автоматное программирование помогает решать вопросы создания документации и разработки логики всей программы (на примерах от примитивных до сложных). Сегодня поговорим о том, какие еще концепции и инструменты можно использовать для этой цели - и какое место автоматное программирование занимает среди них.
Andrew Butitta / Flickr / CC
Почему не "взлетел" UML
В большинстве случаев при разработке программного обеспечения, если система требует правок, то программисты просто берут код и исправляют ошибки так, как им удобно, а затем демонстрируют результат заказчику.
"Сегодня программирование - это не инженерная наука, а прикладная математика. При этом программисты сразу учатся писать код", - уточняет заведующий кафедрой Технологии программирования Университета ИТМО Анатолий Шалыто.
Чаще всего архитектура решения объясняется на словах или с применением простейших блок-диаграмм. Универсальный язык моделирования (UML), основанный на базе нескольких предыдущих стандартов, таких как метод Гради Буча (Booch), метод Джима Румбаха (OMT) и метод Айвара Джекобсона (OOSE), должен был помочь в этом вопросе. И на него возлагали определенные надежды.
Люди пробовали работать с UML, надеясь, что тот станет своеобразной "серебряной пулей", однако он не приобрел широкой популярности. Исследователи выделяют три главных препятствия, которые помешали массовому распространению диаграмм состояний в качестве общепринятого средства описания алгоритмов и сложных поведений программ.
Во-первых, для описания поведения, кроме диаграмм состояний, предлагалось использовать и другие типы диаграмм, однако правила, определяющие их взаимодействие, не были регламентированы.
"Многие считают, что этот язык слишком объемный, - говорит исследователь и предприниматель Хорди Кабот (Jordi Cabot). - Это связано с большим количеством диаграмм, доступных в UML".
Во-вторых, не было предложено подходов для совместного использования диаграмм, описывающих структуру и поведение программ. В-третьих, диаграммы для описания поведения в основном использовались разработчиками для общения друг с другом, в то время как назначение UML - составление спецификации с последующим её воплощением в программном коде.
Подобная судьба ожидала и множество других решений, которые, однако, не являются полноценными альтернативами UML. Речь идет о системе условных обозначений для моделирования бизнес-процессов (BPMN), моделях сущность-связь (ERM), диаграммах потоков данных (DFD), диаграммах состояний и др. Как отмечает Крис Фурман (Cris Fuhrman), все это не более, чем инструменты общения.
Переход к автоматам
Однако спецификации проектов нужны, поскольку они фиксируют результат процесса проектирования, освобождая ум разработчика для решения других задач, а также используются в качестве входных данных на этапе реализации.
Этапы разработки программной системы со сложным поведением
Автоматное программирование является подходом, способным облегчить процесс формирования спецификации. Во время работы создаются графы, в которых под влиянием внешних или любых других входных воздействий осуществляются переходы между состояниями и формируются выходные "импульсы". Для этого сперва формируется текстовая версия технического задания, в котором заказчик прописывает подробную работу желаемого решения.
После этого объявляются условные обозначения входных и выходных воздействий, источников и приемников информации, а затем рисуется схема. Графы переходов позволяют заказчику лучше понять то, что будет делать программист.
Имея схему связей и диаграмму переходов, с помощью формального преобразования можно построить код, реализующий автомат на языке программирования. После этого спецификации становятся частью проектной документации системы. Проектная документация составляется на естественном языке и обычно содержит постановку задачи, описание структуры и поведения системы, примеры ее использования.
Автоматное описание в ООП
Принципы автоматного подхода находят применение и в объектно-ориентированном программировании. Это возможно благодаря концепции "автоматы и объекты управления как классы". Такая модель принята, например, в инструментальном средстве автоматного программирования UniMod. Архитектура системы со сложным поведением, построенная согласно этому принципу представлена на рисунке ниже.
Сопоставление отдельного класса каждому объекту управления приводит к тому, что усилия разработчиков по выделению этих объектов на стадии моделирования не пропадают на этапе реализации. При этом каждый запрос или команда имеет доступ только к строго определенной части вычислительного состояния.
В целом же процесс проектирования системы со сложным поведением можно описать следующим образом:
- Проведение объектной декомпозиции, когда система разбивается на множество самостоятельных взаимодействующих сущностей.
- Сопоставление сущностей с классами, определение интерфейсов классов и отношений.
- Выделение тех сущностей, которые обладают сложным поведением, - именно для их описания будет применяться автоматный подход.
- Задание набора управляющих состояний для каждой сущности. Запросы и команды сопоставляются с входными и выходными переменными управляющего автомата, а компоненты интерфейса - с его событиями. На их основе строится сам управляющий автомат.
- Реализация неавтоматизированных классов на выбранном объектно-ориентированном языке. Генерация кода может выполняться как автоматически, так и вручную.
Этот алгоритм не ограничивает программиста в выборе модели процесса разработки (водопадная, итеративная, кластерная и т. д.) и легко модифицируется в многоитерационный. При этом он также позволяет вносить изменения в уже существующую объектно-ориентированную систему и не требует проведения разработки "с чистого листа".