- PVSM.RU - https://www.pvsm.ru -
Создавать для программы дополнительное визуальное и документальное сопровождение – процесс трудоемкий и утомительный: отнимает много времени и кажется совершенно излишним, если архитектура программного обеспечения проста или является эталонной. Однако на практике программисты далеко не всегда сталкиваются с такими задачами.
Мы уже рассказывали [1], как автоматное программирование помогает решать вопросы создания документации и разработки логики всей программы (на примерах от примитивных до сложных [2]). Сегодня поговорим о том, какие еще концепции и инструменты можно использовать для этой цели – и какое место автоматное программирование занимает среди них.
[3]Andrew Butitta [4] / Flickr / CC [5]
В большинстве случаев при разработке программного обеспечения, если система требует правок, то программисты просто берут код и исправляют ошибки так, как им удобно, а затем демонстрируют результат заказчику.
«Сегодня программирование — это не инженерная наука, а прикладная математика. При этом программисты сразу учатся писать код», — уточняет заведующий кафедрой Технологии программирования Университета ИТМО Анатолий Шалыто.
Чаще всего архитектура решения объясняется на словах или с применением простейших блок-диаграмм. Универсальный язык моделирования (UML), основанный на базе нескольких предыдущих стандартов, таких как метод Гради Буча (Booch), метод Джима Румбаха (OMT) и метод Айвара Джекобсона (OOSE), должен был помочь в этом вопросе. И на него возлагали определенные надежды.
Люди пробовали работать с UML, надеясь, что тот станет своеобразной «серебряной пулей», однако он не приобрел широкой популярности. Исследователи выделяют три главных препятствия, которые помешали массовому распространению диаграмм состояний в качестве общепринятого средства описания алгоритмов и сложных поведений программ.
Во-первых, для описания поведения, кроме диаграмм состояний, предлагалось использовать и другие типы диаграмм, однако правила, определяющие их взаимодействие, не были регламентированы.
«Многие считают, что этот язык слишком объемный, — говорит [6] исследователь и предприниматель Хорди Кабот (Jordi Cabot). — Это связано с большим количеством диаграмм, доступных в UML».
Во-вторых, не было предложено подходов для совместного использования диаграмм, описывающих структуру и поведение программ. В-третьих, диаграммы для описания поведения в основном использовались разработчиками для общения друг с другом, в то время как назначение UML — составление спецификации с последующим её воплощением в программном коде.
Подобная судьба ожидала и множество других решений, которые, однако, не являются полноценными альтернативами [7] UML. Речь идет о системе условных обозначений для моделирования бизнес-процессов (BPMN [8]), моделях сущность-связь (ERM [9]), диаграммах потоков данных (DFD [10]), диаграммах состояний и др. Как отмечает [11] Крис Фурман (Cris Fuhrman), все это не более, чем инструменты общения.
Однако спецификации проектов нужны, поскольку они фиксируют [12] результат процесса проектирования, освобождая ум разработчика для решения других задач, а также используются в качестве входных данных на этапе реализации.
Этапы разработки программной системы со сложным поведением
Автоматное программирование является подходом, способным облегчить процесс формирования спецификации. Во время работы создаются графы, в которых под влиянием внешних или любых других входных воздействий осуществляются переходы между состояниями и формируются выходные «импульсы». Для этого сперва формируется текстовая версия технического задания, в котором заказчик прописывает подробную работу желаемого решения.
После этого объявляются условные обозначения входных и выходных воздействий, источников и приемников информации, а затем рисуется схема. Графы переходов позволяют заказчику лучше понять то, что будет делать программист.
Имея схему связей и диаграмму переходов, с помощью формального преобразования можно построить код, реализующий автомат на языке программирования. После этого спецификации становятся частью проектной документации системы. Проектная документация составляется на естественном языке и обычно содержит постановку задачи, описание структуры и поведения системы, примеры ее использования.
Принципы автоматного подхода находят применение и в объектно-ориентированном программировании. Это возможно благодаря концепции «автоматы и объекты управления как классы». Такая модель принята, например, в инструментальном средстве автоматного программирования UniMod. Архитектура системы со сложным поведением, построенная согласно этому принципу представлена на рисунке ниже.
Сопоставление отдельного класса каждому объекту управления приводит к тому, что усилия разработчиков по выделению этих объектов на стадии моделирования не пропадают на этапе реализации. При этом каждый запрос или команда имеет доступ только к строго определенной части вычислительного состояния.
В целом же процесс проектирования системы со сложным поведением можно описать [12] следующим образом:
Этот алгоритм не ограничивает программиста в выборе модели процесса разработки (водопадная, итеративная, кластерная и т. д.) и легко модифицируется в многоитерационный. При этом он также позволяет вносить изменения в уже существующую объектно-ориентированную систему и не требует проведения разработки «с чистого листа».
Автор: Университет ИТМО
Источник [13]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/analiz-i-proektirovanie-sistem/249213
Ссылки в тексте:
[1] рассказывали: https://habrahabr.ru/company/spbifmo/blog/323122/
[2] сложных: http://is.ifmo.ru/automata/_s7300.pdf
[3] Image: https://habrahabr.ru/company/spbifmo/blog/323780/
[4] Andrew Butitta: https://www.flickr.com/photos/aperture_lag/
[5] CC: https://creativecommons.org/licenses/by-sa/2.0/
[6] говорит: https://www.quora.com/profile/Jordi-Cabot
[7] альтернативами: https://www.quora.com/Which-are-the-alternatives-to-UML
[8] BPMN: https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation
[9] ERM: https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
[10] DFD: https://en.wikipedia.org/wiki/Data_flow_diagram
[11] отмечает: https://www.quora.com/Do-prestigious-software-companies-regularly-use-UML
[12] фиксируют: http://is.ifmo.ru/books/_book.pdf
[13] Источник: https://habrahabr.ru/post/323780/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.