Как проектируют программы: от UML до автоматного подхода

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

    Мы уже рассказывали, как автоматное программирование помогает решать вопросы создания документации и разработки логики всей программы (на примерах от примитивных до сложных). Сегодня поговорим о том, какие еще концепции и инструменты можно использовать для этой цели – и какое место автоматное программирование занимает среди них.

    Andrew Butitta / Flickr / CC

    Почему не «взлетел» UML


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

    «Сегодня программирование — это не инженерная наука, а прикладная математика. При этом программисты сразу учатся писать код», — уточняет заведующий кафедрой Технологии программирования Университета ИТМО Анатолий Шалыто.

    Чаще всего архитектура решения объясняется на словах или с применением простейших блок-диаграмм. Универсальный язык моделирования (UML), основанный на базе нескольких предыдущих стандартов, таких как метод Гради Буча (Booch), метод Джима Румбаха (OMT) и метод Айвара Джекобсона (OOSE), должен был помочь в этом вопросе. И на него возлагали определенные надежды.

    Люди пробовали работать с UML, надеясь, что тот станет своеобразной «серебряной пулей», однако он не приобрел широкой популярности. Исследователи выделяют три главных препятствия, которые помешали массовому распространению диаграмм состояний в качестве общепринятого средства описания алгоритмов и сложных поведений программ.

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

    «Многие считают, что этот язык слишком объемный, — говорит исследователь и предприниматель Хорди Кабот (Jordi Cabot). — Это связано с большим количеством диаграмм, доступных в UML».

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

    Подобная судьба ожидала и множество других решений, которые, однако, не являются полноценными альтернативами UML. Речь идет о системе условных обозначений для моделирования бизнес-процессов (BPMN), моделях сущность-связь (ERM), диаграммах потоков данных (DFD), диаграммах состояний и др. Как отмечает Крис Фурман (Cris Fuhrman), все это не более, чем инструменты общения.

    Переход к автоматам


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


    Этапы разработки программной системы со сложным поведением

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

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

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

    Автоматное описание в ООП


    Принципы автоматного подхода находят применение и в объектно-ориентированном программировании. Это возможно благодаря концепции «автоматы и объекты управления как классы». Такая модель принята, например, в инструментальном средстве автоматного программирования UniMod. Архитектура системы со сложным поведением, построенная согласно этому принципу представлена на рисунке ниже.



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

    В целом же процесс проектирования системы со сложным поведением можно описать следующим образом:

    1. Проведение объектной декомпозиции, когда система разбивается на множество самостоятельных взаимодействующих сущностей.
    2. Сопоставление сущностей с классами, определение интерфейсов классов и отношений.
    3. Выделение тех сущностей, которые обладают сложным поведением, — именно для их описания будет применяться автоматный подход.
    4. Задание набора управляющих состояний для каждой сущности. Запросы и команды сопоставляются с входными и выходными переменными управляющего автомата, а компоненты интерфейса — с его событиями. На их основе строится сам управляющий автомат.
    5. Реализация неавтоматизированных классов на выбранном объектно-ориентированном языке. Генерация кода может выполняться как автоматически, так и вручную.

    Этот алгоритм не ограничивает программиста в выборе модели процесса разработки (водопадная, итеративная, кластерная и т. д.) и легко модифицируется в многоитерационный. При этом он также позволяет вносить изменения в уже существующую объектно-ориентированную систему и не требует проведения разработки «с чистого листа».
    • +22
    • 27.6k
    • 9
    Университет ИТМО
    85.54
    IT's MOre than a University
    Share post

    Comments 9

      +2

      Почему автоматное описание противопоставляется UML? Есть же UML state machine / UML statechart...

        +4

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


        Не верите? Проверьте по гуглу: aggregation vs composition — десятки, сотни разных трактовок.


        Лично моё отношение к UML: отличная идея с ужаснейшей реализацией.

          0
          «Документация на программу» — это понятие надо уточнить. Ведь если программа — это уже описание некоторых действий на некотором языке программирования, то нужно ли делать описание описания? (на языке УМЛ или тп).
          Может, тогда есть смысл в сами языки программирования добавлять обязательные требования «прозрачности» кода? Да, это увеличит трудоемкость собственно разработки, но решит массу проблем.
            0

            Документация абстрактна и не привязана к языку, а потому может быть реализована в виде программы на любом из множества языков.

              0
              Вопрос в том, стоит ли два раза писать одну программу? Причем независимо — то есть нет гарантии, что описания совпадут.
              Может быть, лучше поставить требования прозрачности (или инструменты визуализации) к первому языку?
            +5
            Кто-нибудь имеет представление как в Амазоне/Фейсбуке/etc осуществляется Business Process Management (BPM)?

            A то сейчас приходится знакомиться с JBoss BPM Suite (жаба монстр от редхата) — я эти песни про автоматическое транслирование диаграмм бизнес-процессов в работающие бизнес-процессы уже лет 20 слышу.

            Tакая шняга вообще взлетает? — программирование на уровне UML диаграм нифига не взлетело.

            В одной из компаний использовали JBPM и Drools для кастомизации процессов (финансовый аудит), все равно дофига времени уходило на написание кода.

            Mоя команда — в 1997 году пытались построить весь девелопмент начиная с рисования uml диаграмм и затем
            генерации джава кода из них. Но Rational Rose еще не был ИБМ-овским.

            Не-взле-те-ло!

            Настолько геморройное оказалось занятие, с таким ОГРОМНЫМ количеством ручного «допиливания» кода, что мы выдержали примерно год, и забили на это дело.
              +1

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


              "Программирование на диаграммах UML" в этом плане является просто разновидностью визуального программирования и может использоваться как точка композиции для написанного кода.


              То есть процесс тут должен быть обратным: сначала пишется код, потом он включается в диаграмму.

              0
              >>текстовая версия технического задания, в котором заказчик прописывает подробную работу желаемого решения

              Звучит весьма утопично. Будто постановка уже содержит большую часть реализации. Имхо, чаще в реальности эта часть работы выполняется командой разработки, в лучшем случае при участии заказчика.
                +1
                Сам сталкиваюсь с тем, что UML очень мощный инструмент проектирования, но при этом он не «стого формализован», как уже писали выше
                aggregation vs composition — десятки, сотни разных трактовок
                И порой приходится вводить свои правила, чтобы понимать как-то или иное решение в диаграмме будет отражено в реальном коде, на конкретном языке. Судя по всему это всё следствие буквы «U» из названия и широких возможностей языка.
                Бесспорно, UML идеально подходит для общения, хотя надо признать, что при этом в ход идут и многие другие диаграммы: DFD, ER, и т.д.

                Only users with full accounts can post comments. Log in, please.