Русский English
VI международная конференция
«РАЗВИТИЕ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ В РОССИИ, СТРАНАХ БЫВШЕГО СССР И СЭВ»
Россия, Нижний Новгород, НИУ ВШЭ, 25–27 сентября 2023 года
История развития графических методов проектирования ПО в СПбГУ

История развития графических методов проектирования ПО в СПбГУ

Системы реального времени

В начале 1980-х годов коллективу лаборатории системного программирования Ленинградского государственного университета пришлось заняться совершенно новой тематикой – программированием цифровых телефонных станций, которые являются классическим примером систем реального времени (СРВ).

Многие авторы признают программирование СРВ самой трудной задачей нашей специальности по следующим причинам:

  1. Необходимость укладываться в жёсткие временные ограничения, вне рамок которых важная информация просто пропадает;
  2. Обычно СРВ управляются не одной ЭВМ, а многими, соединёнными в сложноустроенные сети, поэтому в СРВ входит вся многообразная тематика сетей (протоколы, устойчивость к сбоям и отказам, реконфигурация, пропускная способность и т.д.);
  3. Любая цифровая телефонная станция включает в себя большие базы данных (абоненты, блоки аппаратуры, учёт трафика и т.д.), поэтому и проблематика БД, сама по себе весьма не простая, в полном объёме включается в СРВ;
  4. Часто (особенно для больших станций) станцией управляет один или несколько операторов, поэтому все проблемы человеко-машинных интерфейсов также приходится решать в процессе проектирования цифровых телефонных станций; 
  5. Самая большая трудность при отладке СРВ заключается в неповторяемости ситуаций. Станция может успешно работать 2 года, а потом вдруг «вылететь», причём понять причину отказа очень трудно. В СРВ обычно много критических интервалов, если программист при входе в такой интервал забудет опустить семафор, но при выходе его поднимет, то такая ошибка может долго не проявляться, то есть долго не возникает ситуация, когда 2 процесса попадают в критический интервал одновременно. Разумеется, есть способы борьбы с такими ошибками, например, использование мониторов Хоара вместо семафоров Дейкстры, постоянная трассировка процессов (правда, это значительно замедляет работу станций), отладка с механизмами поиска ситуаций гонок (к слову, 20 лет назад таких механизмов ещё не было) и так далее.

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

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

  1. Связисты, знающие протоколы, по которым станция общается с абонентами и другими станциями. Этих протоколов очень много, часть из них является международными стандартами, другие применяются только в нашей стране (например, ИКМ-15/16 – сельская связь), есть специальные протоколы, которые применяются в военной связи и т.д.
  2. Алгоритмисты, знающие стандарты Международного союза связи (раньше этот союз назывался ССITT, теперь – ITU-T) и на основе этих стандартов разрабатывают алгоритмы работы станции. Знание международных стандартов необходимо, иначе к станции нельзя будет подсоединить телефоны разных производителей, а саму станцию нельзя будет включить в существующую сеть связи, состоящую из станций разных производителей.
  3. Инженеры, проектирующие телефонное оборудование, которое должно соответствовать телефонным протоколам.
  4. Инженеры, проектирующие управляющие ЭВМ и протоколы, их связывающие. Отдельную трудность здесь составляет наличие интерфейсов с телефонным оборудованием (обычно эти интерфейсы отличаются от традиционных).
  5. Наконец, программисты, которые заставляют всё вышеперечисленное работать. Именно программисты ответственны за всю работу. Если, скажем, инженеры создали какой-либо интерфейс в 10 раз медленнее, чем записано в ТЗ, то заставлять укладываться в нужные рамки будут именно программистов, поскольку времени на перевыпуск оборудования уже не будет. Если алгоритмисты допустили ошибку, то эта ошибка выявится только на стадии комплексной отладки. И опять исправлять программистам.

То утверждение, что все эти специалисты говорят на разных языках, вовсе не является метафорой. У них разный профессиональный жаргон, многочисленные (причём, совершенно разные) сокращения, разные способы объяснения решения задач.

Нам понадобилось не менее двух лет, чтобы научиться понимать всю эту «братию». Особенно нас раздражала каста алгоритмистов с их объяснениями типа «Возьми это самое, там, на этом…»

Оказалось, что проблема взаимопонимания специалистов разных профилей носит международный характер. Над решением этой проблемы работали большие группы в CCITT (МККТТ – международный консультативный комитет по телеграфии и телефонии). Специалисты ЛНПО «Красная Заря», работающие в этих группах, в начале 1984 года привезли и показали нам рекомендацию Z.100 с описанием графического языка SDL (Specification and Description Language). Основная идея этой рекомендации состояла в том, что человек значительно легче воспринимает графические изображения (диаграммы), чем тексты.

Нам эта идея понравилась. Уже к концу того же 1984 года молодой кандидат физико-математических наук Фима Монарх реализовал первый в СССР графический редактор SDL. Однако графическим его можно было назвать с известной натяжкой. В те годы у нас ещё не было графических дисплеев и принтеров. Фима рисовал ромбики, прямоугольники, соединительные линии и другие объекты SDL крестиками, звёздочками и другими символами, которые можно напечатать на АЦПУ (алфавитно-цифровое печатающее устройство). Нас это не пугало, довольно быстро мы набрали на этом редакторе полный набор алгоритмов для одной из проектируемых нами станций. Получилась толстая (сантиметров 10–12) пачка больших листов бумаги.

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

Тогда Наталия Вояковская сделала интерпретатор SDL на ЕС ЭВМ. Тогда мы работали на дисплеях ЕС 7920, на которых рисовался телефон с опущенной трубкой. Нажимая на разные клавиши, можно было «поднять» трубку, набрать номер и потом пошагово проследить работу алгоритма, прыгая по элементам диаграмм на языке SDL. Особенно важно было увидеть, на какую диаграмму и с какими параметрами попадает посылаемый сигнал.

Но для полноценной отладки нужна была БД. Аспиранты Аня Бульонкова (из Академгородка Новосибирска) и Володя Парфёнов решили и эту задачу. Аня реализовала СУБД на базе стратегии тщательного замещения. Если в процессе исполнения транзакции происходил сбой, то после перезапуска мы мгновенно возвращались на состояние начала транзакции безо всякой журнализации, так как внутри транзакции все блоки писались на новое место (предыдущее содержимое блока не трогалось). В случае успешного завершения транзакции целый список старых блоков заменялся на новый список одной неделимой физической записью на диск.

Володя Парфёнов реализовал автоматическую генерацию данных по создаваемой человеком формальной схеме. Он придумал язык для этих целей и его реализацию. Только через 7-8 лет после него появился UML с очень похожими возможностями, но Володя успел получить свою долю славы. Я до сих пор рассказываю студентам, как мне звонил заместитель Министра промышленности средств связи генерал-лейтенант КГБ со скандалом, куда это я отпустил столь важного специалиста. Мне стоило большого труда объяснить, что это молодой специалист, выпускник мат-меха этого года, и уехал он командиром студенческого стройотряда.

К 1989 году все инструментальные средства были перенесены с ЕС ЭВМ на персоналки (тогда мы работали на болгарских персоналках Правец 16 – копиях IBM PC XT), графические технологии прочно завоевали своё место при проектировании телефонных станций и других СРВ [1,2]. В 1991 году А.Н.Терехов защитил докторскую диссертацию по этой тематике в Академгородке Новосибирска.

Языки для создания информационных систем

В конце 90-х годов нам поручили заниматься информационной системой нашего СПбГУ. После тщательного анализа предметной области оказалось, что надо сгенерировать более 100 таблиц в разных базах данных, сформировать порядка 200 форм ввода информации и запрограммировать более 1000 отчетов. Традиционной технологией в то время была MS Visual Basic, которая имела некоторый набор инструментов для этих задач, но, все равно, объем работы был слишком большой.

Ответственным исполнителем этой темы был Саша Иванов, который начал с ручного программирования отдельных задач, но при этом старался заметить и обобщить общие подходы, приемы и шаблоны программирования. Уже были известны инструменты, которые по диаграммам ERD (сущность-связь) генерировали базы данных, но уступали по эффективности ручному программированию, например, по построению системы индексов. Саше Иванову удалось расширить набор атрибутов элементов диаграмм, вместо ERD он начал применять диаграммы классов UML с их новыми возможностями наследования и агрегирования и добился сравнимого с ручным качества автоматически сгенерированного кода. Как всегда, все инструменты как графических редакторов, так и генераторов кода мы создавали сами. Наш многолетний опыт показывает, что использование своих, а не заимствованных средств программирования предпочтительнее - всегда можно что-то улучшить, добавить новые функции, да и обучение новых сотрудников проходит легче.

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

В результате Саше Иванову и возглавляемому им коллективу удалось реализовать более 15 подсистем информационной системы СПбГУ [3,4], не написав ни одной строчки на MS Visual Basic, которые проработали более 15 лет (система «Студент» работает до сих пор). Все проектирование выполнялось с помощью графических редакторов с автоматической генерацией кода на MS Visual Basic. Небольшая доводка все же требовалась, но это никак не было связано с логикой работы – подбор цветов, расположение окошек на диаграмме и другие “красивости”. Из-за этого возникла проблема round-robin - при внесении изменений в проект и перегенерации кода не должны пропадать ранее сделанные ручные правки, эта проблема также была решена.

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

DSL (Языки, ориентированные на отдельные предметные области)

Естественно, мы ожидали, что многие программисты будут применять столь удобные, на наш взгляд, технологии, но массового перехода на графические методы не произошло. Мы долго не могли понять, в чём дело. Сейчас мы думаем, что SDL и появившийся позже универсальный язык UML слишком мелкозернисты, слишком сильно похожи на текстовые алгоритмические языки – те же присваивания, циклы, условия и т.д.

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

В случае с визуальными языками общего назначения [1] полноценное создание системы с использованием только графических языков чрезвычайно сложно по ряду причин, основной из которых является семантический разрыв между моделями и кодом. Однако зачастую оказывается, что можно создать свой визуальный язык под конкретную предметную область или даже конкретную задачу. Более того, используя знания о предметной области при разработке инструментария для этого языка, можно добиться полной генерации работающего исходного кода системы по визуальным моделям. Сами модели при этом могут оставаться достаточно близкими к предметной области, чтобы их могли создавать и использовать даже непрограммисты. Такой подход называется предметно-ориентированным визуальным моделированием (Domain-Specific Modelling, DSM). Результаты ряда исследований [6-9] указывают на то, что он оказывается весьма эффективным, в том числе отмечается повышение производительности труда программиста от трёх до десяти раз.

Разумеется, создание визуального языка, графических редакторов, генераторов и других инструментальных средств для этого языка “с нуля” под каждую конкретную задачу было бы неоправданно трудоёмким. По этой причине были созданы инструментальные средства, позволяющие в большой степени автоматизировать этот процесс, такие инструменты называются DSM-платформами или metaCASE-системами. Такие системы позволяют создавать визуальную технологию (называемую DSM-решением) за время порядка дней, что делает это экономически оправданным даже для небольших проектов. В основе DSM-решений лежат языки DSL (Domain Specific Language), создаваемые специально для каждой узкой предметной области. Эти языки создаются экспертами, хорошо знающими свою предметную область. Каждая графическая иконка обозначает крупное действие, то есть заменяет десятки и сотни строк кода. Например, если на таком языке нарисовать сценарий поведения пользователя мобильного приложения (авторизация, выбор из меню, конкретные действия), то это и будет конечным алгоритмом, из которого можно полностью автоматически сгенерировать код.

На самом деле текстовые DSL мы создавали больше 40 лет назад на базе Алгола 68 (правда, тогда термина DSL не существовало). В этом языке впервые появились возможности описания новых типов данных и операций над значениями таких типов. Например, для создания языка планиметрии можно описать типы точка, прямая, окружность и т.д., а также операции построить с двумя операндами типа точка и результатом типа прямая, пересечь с двумя операндами типа прямая и результатом типа точка и т.п. При этом пользователь может годами писать программы на этом специализированном языке, не подозревая, что он пишет на Алголе 68 и использует стандартный транслятор, но, разумеется, наглядности графических образов такой подход лишен.

Одним из исследовательских проектов в области графического предметно-ориентированного моделирования стал проект QReal [10-12], выполненный на кафедре системного программирования Санкт-Петербургского государственного университета (кафедра образована на базе одноименной лаборатории в 1996 году). Проект ставил перед собой цель создания DSM-платформы (т.е. QReal является метатехнологией), достаточно простой в использовании, чтобы свой визуальный язык в течение нескольких часов мог создать даже человек, который использует её впервые. Платформа при этом достаточно функциональна, чтобы с её помощью можно было разрабатывать большие и сложные визуальные технологии [2].

Платформа QReal:Robots

С помощью метатехнологии QReal были созданы решения для систем реального времени, описания бизнес-процессов по стандарту BPMN, реализации мобильных приложений, проектирования кристаллов и др., но самым удачным, на наш взгляд, стало решение по программированию роботов QReal:Robots [13-14].

Концептуально программа на языке QReal:Robots представляется в виде набора элементарных команд роботу, связанных стрелками, означающими передачу управления между блоками. Пример программы представлен на рисунке 1.

Пример программы в QReal:Robots

Рис 1. Пример программы в QReal:Robots

Созданную на визуальном языке программу можно исполнить прямо на компьютере, посылая команды роботу через Bluetooth или USB. При этом текущий исполняемый блок будет подсвечиваться, будут выводиться показания сенсоров и значения переменных и будет возможность остановить или даже изменить программу в процессе выполнения. По диаграмме также можно сгенерировать код на языке C, оттранслировать и загрузить его на робот и исполнить на роботе. При этом отладочная информация выводиться не будет, но робот будет способен действовать автономно, без связи с компьютером. Кроме того, программу можно исполнить вообще без робота, на двухмерной модели, запущенной внутри среды QReal:Robots. Двухмерная модель реализует фиксированную конфигурацию робота (трёхколёсную тележку, типичную для задач, требующих перемещения робота в пространстве, например, при движении по линии или игре в робофутбол). Однако есть возможность задать конфигурацию и положение сенсоров, элементы внешнего мира, включая стены, цветные линии и области на полу.

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

Команды школьников, использовавшие QReal:Robots как основное средство программирования, выступали на многих соревнованиях по робототехнике и показали достойные результаты.

Заключение

Накопленная история использования графических методов проектирования ПО показывает, что при наличии мощной инструментальной поддержки использование предметно-ориентированных визуальных языков реализует принципиально новый подход к созданию сложных систем с довольно низким порогом вхождения для новичков и многократным увеличением производительности профессионалов. Для этого в распоряжении проектировщиков должен быть обширный набор программных средств, начиная от визуальных редакторов и репозитория и заканчивая средствами отладки, контроля версий и процессов рефакторинга создаваемых моделей. Платформы DSM помогают ускорить и автоматизировать процесс создания подобных инструментальных средств, позволяя применять данный подход к разработке программного обеспечения для различных предметных областей и наборов задач. При этом DSM-решение создаёт, как правило, один очень опытный разработчик (или небольшая команда опытных разработчиков), а пользуется этим решением большое количество людей, которые иногда даже могут не обладать навыками программирования.

Литература

Терехов А.Н., RTST — технология программирования встроенных систем реального времени. Записки семинара Кафедры системного программирования "Case-средства RTST++". 1998. С. 3.

Парфенов В.В., Терехов А.Н., RTST — технология программирования встроенных систем реального времени. Системная информатика. 1997. С. 228.

Terekhov A.N., Romanovskii K.Yu., Koznov D.V., Dolgov P.S., Ivanov A.N. RTST++: Methodology and CASE tool for the development of information systems and software for real-time systems. Programming and Computer Software. Vol. 25. № 5. 1999.С. 276–281.

Терехов А.Н., Кияев В.И., Комаров С.Н., Принципы информатизации системы управления в Санкт-Петербургском Государственном Университете. Вестник Санкт-Петербургского университета, Серия 8: Менеджмент. № 2. 2004. С. 151–200.

Кознов Д.В., Основы визуального моделирования, БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2008.

Weiss, D., Lai, C. T. R. Software Product-line Engineering, Addison Wesley Longman, 1999.

Kelly, S., Tolvanen, J.-P. Visual domain-specific modeling: benefits and experiences of using metaCASE tools, in: Bezivin, J., Ernst, J. (Eds.), Proceedings of International workshop on Model Engineering, ECOOP 2000.

Kelly, S., Tolvanen, J. Domain-Specific Modeling: Enabling Full Code Generation // Wiley-IEEE Computer Society Press. 2008. 448 p.

Kieburtz, R., et al. A software engineering experiment in software component generation, Proceedings of 18th International Conference on Software Engineering, Berlin, IEEE Computer Society Press, March, 1996.

Терехов А.Н., Брыксин Т.А Литвинов Ю.В., Смирнов К.К., Никандров Г.А., Иванов В.Ю., Такун Е.И., Архитектура среды визуального моделирования QReal. Системное программирование. Т. 4. СПб.: Изд-во СПбГУ. 2000. С. 171–196

Кузенкова А.С., Дерипаска А.О., Таран К.С., Подкопаев А.В., Литвинов Ю.В., Брыксин Т.А., Средства быстрой разработки предметно-ориентированных решений в metaCASE-средстве QReal // Научно-технические ведомости СПбГПУ, Информатика, телекоммуникации, управление. Вып. 4 (128). СПб.: Изд-во Политехнического Университета. 2011. С. 142–145.

А. Н. Терехов, Т. А. Брыксин, Ю. В. Литвинов. QReal: платформа визуального предметно-ориентированного моделирования // Программная инженерия. – № 6. – 2013. – С. 11–19.

Andrey Terekhov, Yurii Litvinov, Timofey Bryksin, QReal:Robots an environment for teaching computer science and robotics in schools, Proceedings of the 9th Central & Eastern European Software Engineering Conference in Russia, ACM New York, NY, USA ©2013

А. Н. Терехов, Т. А. Брыксин, Ю. В. Литвинов, Среда визуального программирования роботов, QReal:Robots, Сборник тезисов III Всероссийская конференция «Современное технологическое обучение: от компьютера к роботу», 2013

Примечания.

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

2. Домашняя страница проекта QReal на GitHub, URL: https://github.com/qreal/qreal

Об авторе: д.ф.-м.н.
к.т.н.
к.т.н.
Кафедра системного программирования СПбГУ
Материалы международной конференции Sorucom 2017
авторов 17.01.2019