Диссертация (1148272), страница 34
Текст из файла (страница 34)
Должен быть провязан с диаграммой активностей,реализующей этот метод.1792. Диаграмма структур данных (Ubiq Data Structures), на ней описываетсякласс Message, предназначенный для обмена сообщениями между клиентоми сервером или сервером и другими процессами, а также другие классы,служащие данными.
Такая диаграмма должна быть одна в проекте. Узлы наэтой диаграмме таковы.(a) Comment — комментарий.(b) Custom Class — произвольный класс, содержащий данные. Имеетсвойство «имя» (которое генерируется в имя класса), содержит в себеполя (элементы типа Field).(c) Data Structures Diagram — сама диаграмма, корневой элемент.(d) Enum Element — элемент перечисления. Имеет имя и значение. Можетнаходиться в узлах Message Codes и Error Codes, будет сгенерированакак константа внутри класса Message.(e) Error Codes — описание кодов ошибок, используемых в классеMessage.
Должен быть один на диаграмме. Содержит в себе элементыEnum Element.(f) Field — произвольное поле класса Message или произвольного класса(может лежать в Message Class или Custom Class), генерируется в свойство соответствующего класса. Имеет имя (имя свойства), значение поумолчанию, тип, может быть сериализуемым или несериализуемым.(g) Message Class — описание класса Message, должен быть один надиаграмме. Содержит в себе только поля (элементы Field).(h) Message Codes — описание кодов сообщения, используемых в классеMessage.
Должен быть один на диаграмме. Содержит в себе элементыEnum Element.3. Диаграмма активностей (Ubiq Activity Diagram). На таких диаграммахзадаётся поведение обработчика сообщений, метода, препроцессора и т.д.В модели их может быть несколько (по числу обработчиков). Содержание несколько разнится в зависимости от вида диаграммы — диаграммаактивностей для обработчика, диаграмма активностей для препроцессора,180вспомогательной функции. Диаграмма для обработчика обычно состоитиз нескольких цепочек операторов, начинающихся с узла HandlerStart,препроцессор начинается с Initial Node, функция — с Function Signature.Узлы, используемые на всех видах диаграммы активностей, таковы.(a) Action — действие, имеет свойство «имя», которое должно содержатькод на C#. Он будет без изменений скопирован в результат генерации.(b) Activity Diagram — сама диаграмма.(c) Activity Final Node — завершающий узел, означает конец цепочкиоператоров.
Полезен, например, для рисования пустой ветки else, востальных случаях необязателен.(d) Actual Parameter — фактический параметр, передаваемый в функциюпри вызове. Имеет имя, которое должно быть C#-кодом, подставляемым вместо параметра при вызове функции, может содержаться тольков узле Function Call.(e) Comment — комментарий.(f) Control Flow — направленная связь, означающая передачу управленияот оператора к оператору. Имеет свойство guard, используемое пригенерации узлов Decision Node.(g) Decision Node — оператор ”if”. Должен иметь ровно две исходящиесвязи, ровно у одной из которых свойство guard не пусто. Обе веткидолжны сходиться либо на одном Merge Node, либо на одном ActivityFinal Node.
Свойство guard становится условием оператора if в сгенерированном коде.(h) Formal Parameter — формальный параметр, описываемый в заголовкевспомогательной функции. Может содержаться только в узле FunctionSignature. Имеет имя и тип.(i) Function Call — вызов функции. Имеет имя, которое должно совпадать с именем диаграммы активностей, реализующей вызываемуюфункцию. Содержит набор параметров (узлов Actual Parameter), имаксимум один узел Return Value, показывающий, куда положитьрезультат вызова функции.181(j) Function Signature — описание вспомогательной функции, с негоначинается цепочка операторов диаграммы активностей для вспомогательной функции.
Имеет имя (должно совпадать с именем диаграммы)и тип возвращаемого значения. Может содержать в себе формальныепараметры (типа Formal Parameter).(k) Handler Start — начало обработчика сообщения. С него начинается цепочка операторов на диаграмме активностей обработчика. Имеет имя,которое должно совпадать с именем константы — типа сообщения,описанного на диаграмме структур данных.(l) Initial Node — начальный узел, с него начинается цепочка операторовдиаграммы активностей препроцессора.(m) Merge Node — точка слияния двух веток выполнения оператора if.(n) Package — вспомогательный узел, предназначенный для организациидиаграмм активностей в связанные блоки в логической модели. Семантической нагрузки не несёт.(o) Return — возврат значения из вспомогательной функции, генерируетсяв оператор return C#. Равносилен узлу Action с оператором return<возвращаемое значение>;(p) Return Value — указывает, куда положить возвращаемое функциейзначение.
Может содержаться только в узле Function Call. Имеетимя (код на C#, обычно имя переменной) и тип. Если тип не пуст,генерируется объявление переменной для хранения результата, еслипуст, считается, что переменная уже объявлена.Как видно из описания, язык имеет гибридную структуру, то есть для заданияпрограммы активно используются и визуальные, и текстовые символы.
Приэтом визуальная и текстовая части языка частично взаимозаменяемы — языкпозволяет не рисовать диаграмму обработчика сообщения, а написать весь кодвручную в единственном блоке. В качестве текстовой части используется языкC#, код на котором непосредственно генерируется в выходные файлы. Технологияне имеет синтаксического анализатора языка C#, поэтому не может выполнятьникаких действий над содержимым блоков, даже синтаксические ошибки в коде182будут обнаружены только после генерации. Язык задания логики обработчиков(диаграмма активностей) по сути представляет собой диаграмму активностейUML, модифицированную для того, чтобы отразить особенности Ubiq Mobile.A.2.4.
ОбсуждениеГлавный недостаток получившегося набора языков вытекает из выбранногоспособа анализа предметной области: визуальный язык слишком привязан к целевому коду, так что без достаточно хорошего владения технологией Ubiq Mobileили специальной подготовки создавать программы оказывается довольно сложно.Фактически, надо представлять, в какую часть программы будет сгенерирован тотили иной код, который пишется в узлах Action и различных других узлах, гдедопускается ввод кода на C# вручную. Смысл некоторых свойств практическиневозможно объяснить человеку, не знакомому детально с Ubiq Mobile (поэтомутакие свойства опускались при описании языка). Кроме того, наличие в C#переменных и полей классов делает возможным модификацию локального илидаже глобального состояния из кода в узле Action обработчика, что приводит кнеявным и никак не визуализируемым зависимостям по данным, на диаграммахвизуализируется только поток исполнения.
Фактически оказалось, что оченьсложно писать код на C# в элементах визуального языка, не смотря при этом всгенерированный код. Кроме того, диаграммы активностей более громоздкие, чемкод, который они призваны визуализировать, поэтому в них оказывается сложнееразобраться. Субъективный вывод, сделанный автором данной работы в ходеразработки модельного примера — диаграммы активностей не оправдывают себя,проще и продуктивнее писать код обработчиков вручную.Перечисленные недостатки являются проблемой для всех гибридных (текстографических) языков, в которых текстовая часть является кодом на целевом языкеи не анализируется синтаксически самим DSM-решением. В любом случае, пользователи DSM-решения могут эксплуатировать знания о результатах генерациидля создания эффективных по их мнению, но сложных в сопровождении программ, пример такого: объявление переменной в одном блоке и использование еёв другом.
При изменении потока управления результат генерации может оказатьсянекорректным. Эти проблемы частично можно решить синтаксическим анализомкода внутри элементов, но это может быть технически сложно в реализации.183Кроме того, подобный подход требует наличия качественного интегрированноготекстового редактора внутри DSM-решения, с подсветкой синтаксиса, автодополнением и прочей функциональностью, свойственной современным средамразработки.Основное достоинство получившегося решения состоит в том, что от пользователя скрыта вся объектно-ориентированная составляющая программированияпод Ubiq Mobile, все объявления классов генерируются автоматически, генерируются необходимые отношения наследования, поля и заголовки методов. Фактически всё, что пользователь рисует на диаграммах, укладывается в парадигмуструктурного программирования и в знания, входящие в программу среднейшколы. Как кажется, это весьма важный результат, потому как технология ужесущественно снизила порог вхождения, и дальнейшее развитие в этом направлении могло бы путём последовательного исключения необходимых знаний сделатьпрограммирование под Ubiq Mobile доступным существенно более широкомукругу людей, чем ранее.
А именно это и является одной из основных целейсоздания предметно-ориентированного решения в DSM-подходе.A.2.5. Дальнейшее развитие QReal:UbiqРаботы по второму этапу создания технологии программирования под платформу Ubiq Mobile велись в направлении создания полноценной самодостаточной технологии, включающей в себя в том числе возможность задания пользовательского интерфейса мобильного приложения, и исправления недостатковпервой версии языка, описанных выше.Большинство существующих решений для создания мобильных приложенийлибо не позволяет задавать сложную логику вообще, ограничиваясь правиламиперехода между экранами, либо позволяет задавать её в текстовом виде.
Интересной альтернативой является язык Scratch и ряд специализированных технологийна его основе: программа имеет текстовый вид, но собирается из набора визуальных блоков, каждый из которых соответствует текстовому оператору. Структурапрограммы полностью соответствует программе на текстовом языке, поэтомувыразительная сила такого подхода всё же ниже, чем при использовании «настоящих» визуальных языков, зато требуется меньше знаний (мы не вспоминаем184синтаксис языка, а выбираем готовые блоки из палитры) и меньше вероятностьошибиться (блоки неправильных типов невозможно соединить друг с другом).В результате анализа существующих решений и опыта использования прототипа языка было принято решение полностью отказаться от текстового программирования на диаграммах и реализовать две схемы.1.
Язык с настраиваемыми элементами, реализующими крупный блок функциональности, например, расстановка кораблей на поле в игре «Морской бой».Семантика таких элементов реализуется для каждой конкретной задачи наязыке C#.2. Вынести все элементарные конструкции на уровень визуального языка,существенно сузив при этом класс решаемых задач (иначе в таком случаеполучился бы визуальный язык общего назначения, что не соответствовалонашим целям).Первая схема была реализована только в виде прототипа, поскольку, несмотряна то, что она существенно более гибкая, требует возможностей, которыми QRealтот момент не обладал — чтобы описывать семантику настраиваемого элемента,надо уметь изменять генератор кода прямо во время создания модели, иначеобеспечить интеграцию сгенерированного и рукописного кода очень сложно.Полноценно была реализована вторая схема, в качестве предметной областибыли выбраны игры с доской, такие как «Крестики-нолики», «Морской бой»,«Шашки» и т.д.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
