Диссертация (Методы и средства разработки графических предметно-ориентированных языков), страница 4

Рассматриваются способы математической формализации визуальных языков.1.2. Визуальное моделированиеВ силу незримости программного обеспечения способ его визуализации —лишь договорённость между программистами. Такая договорённость называетсяметафорой визуализации [5, 115]. Например, при использовании языка UMLдля визуализации архитектуры системы мы договариваемся, что классы изображаются в виде прямоугольников, а случаи использования — в виде овалов.Поскольку язык UML является де-факто стандартом индустрии и очень широкораспространён, то нарисованная одним разработчиком схема будет скорее всегоправильно понята другими разработчиками.Поскольку программа не имеет какого-то внешнего вида и для её визуализациииспользуются метафоры, то часто оказывается невозможным нарисовать «программу целиком», каждая визуальная модель описывает какой-то свой аспект системы.

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

Такимобразом, каждая диаграмма рисуется с какой-то определённой целью для какойто определённой категории людей, при этом изображая какой-то определённыйаспект системы. Поэтому выделяют понятие «точка зрения моделирования» [115],в которое входят все перечисленные выше соображения о назначении диаграммы. Понятие точки зрения моделирования применимо не только к конкретнойдиаграмме, но и к языку моделирования в целом, поэтому весьма важно длядальнейшего изложения.

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

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

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

Такая ситуация19нежелательна, поскольку хотелось бы более продуктивно переиспользовать трудпроектировщиков. Поэтому семантический разрыв пытаются преодолеть.Существует класс инструментов, поддерживающих визуальное моделирование. Такие инструменты по традиции называют CASE-системами (или CASEпакетами), хотя этот термин весьма неточен. Исторически термин «CASE»(Computer-Aided Software Engineering) обозначал применение методов и технологических средств для разработки программного обеспечения с помощьюкомпьютера, то есть обычные текстовые среды разработки с точки зрения такогоопределения — тоже CASE-инструменты.

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

Средства из второй категории традиционно подразделяют на средства поддержки первых этапов водопадной моделижизненного цикла ПО (анализа и проектирования), называемые Upper CASE,и нижних этапов этой модели (реализации и тестирования), называемые LowerCASE. Исторически первые CASE-системы (например, PSL/PSA [77]) относилиськ категории Upper CASE, поскольку автоматизировали исключительно анализтребований, затем (в 80-х и начале 90-х годов 20-го века) широкое распространение получили I-CASE-средства. Связано это с тем, что в те времена основнойобъём разрабатываемых программных продуктов приходился на программноеобеспечение для мэйнфреймов, автоматизирующее бизнес-процессы крупныхкомпаний. Там CASE-средства играли роль интегрированных средств разработки,в которых писалось всё программное обеспечение целиком, и они интегрировались со всеми остальными необходимыми средствами разработки, доступнымидля нужной платформы.

Наиболее популярные современные CASE-средства, как1Программное обеспечение20правило, ориентированы на автоматизацию этапов анализа и проектирования,таким образом, относятся к Upper CASE по данной классификации.Современные CASE-системы, как правило, состоят из большого числа компонентов. Наиболее важный из них — репозиторий, база данных, хранящая всебе всю информацию о разрабатываемой системе, с репозиторием работаютвсе остальные компоненты. Вводится информация в репозиторий посредствомредакторов, которые могут быть визуальными редакторами диаграмм, текстовыми редакторами, редакторами таблиц и т.д. Впоследствии репозиторий могутиспользовать генераторы, которые по модели системы генерируют код на текстовых языках (как правило, фрагменты программы, например, объявления классовбез реализаций) или документацию, валидаторы, проверяющие корректность, целостность и полноту содержимого репозитория, интерпретаторы и отладчики, использующие хранящуюся в репозитории модель системы для непосредственногоисполнения.

Кроме того, в состав CASE-систем могут входить вспомогательныесредства, такие как текстовый редактор (для работы со сгенерированным кодомили документацией), редактор экранных форм, средства управления проектом,средства интеграции с системами контроля версий, средства импорта и экспортамоделей и т.д.1.3. Структура визуальных языковВизуальные языки могут применяться и без какой-либо инструментальнойподдержки, например, для рисования набросков архитектуры системы, моделейпредметной области, требований и т.д. Используемые при этом языки не нуждаются ни в какой формализации и никак не определяются, иногда диаграммы натаких языках могут сопровождаться легендой, поясняющей значение символов.Такие языки встречаются очень часто — считается, что наиболее полезнымидиаграммами оказываются нарисованные «на салфетке» наброски в ходе первогопродумывания структуры будущей системы.

Более того, они очень часто встречаются и в далёких от разработки программного обеспечения областях: например,схему метро можно рассматривать как диаграмму на некотором неформальномвизуальном языке, которая при этом снабжена легендой, поясняющей значениетипов символов на этой «диаграмме» (забегая несколько вперёд, можно сказать,21что эта легенда является аналогом метамодели визуального языка). Таким образом, от таких языков требуется только, чтобы диаграммы на них были понятнытем, для кого они предназначены.Необходимость в формальном описании визуального языка возникает, когдадля него требуется инструментальная поддержка.

Для того, чтобы создать редактор диаграмм, требуется знать допустимый набор символов языка и правила,по которым эти символы могут комбинироваться в диаграммы. То же касаетсягенераторов кода, валидаторов, интерпретаторов и всех остальных компонентовCASE-системы, которым важна семантика моделей, причём каждому инструменту может быть необходима своя часть формализации языка: генераторам кодаважны проекции из символов визуального языка в строки текста, валидаторамважны формальные ограничения на модели, интерпретаторам — семантикаязыка. В связи с тем, что инструментальные средства для визуальных языков разрабатываются и используются весьма активно, вопросы формализации описанияязыка довольно хорошо проработаны, далее приводятся основные понятия, приэтом используемые.1.3.1.

Синтаксис, семантика и прагматикаЛюбые языки, не только визуальные, но даже естественные языки, состоятиз трёх компонентов — синтаксиса, семантики и прагматики [115]. Синтаксисописывает правила построения текстов на языке из знаков языка, семантикаописывает значение текстов на языке (то есть его связь с предметной областью),прагматика описывает способы использования языка его пользователем.Синтаксис визуального языка описывает правила, по которым из элементовязыка составляются модели.

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

Как правило, абстрактный синтаксис содержит перечислениевсех элементов языка, их свойства, правила соединения элементов в диаграммы.Например, для языка UML абстрактный синтаксис определяет, что существуетэлемент «класс», у него есть свойства «имя», «абстрактность» и т.д., он имеетсписок операций, свойств, надклассов и т.д.Конкретный синтаксис, также называемый нотация, определяет правилаотображения элементов языка. Примером в случае языка UML может служитьконкретный синтаксис элемента «класс», который изображается прямоугольником с тремя секциями — название класса, поля и методы, при этом две последниене обязательны.

Один и тот же элемент абстрактного синтаксиса может иметьнесколько различных нотаций. Различия могут быть весьма существенными,например, в языке UML свойства класса могут быть изображены как текстовыеполя внутри фигуры класса (например, +name : String = “Temp”), либо какассоциации, связывающие класс с классами, которые являются типами полей.С точки зрения абстрактного синтаксиса два этих варианта неразличимы, нодиаграммы, нарисованные в двух этих вариантах, могут радикально отличатьсявизуально.Служебный синтаксис, или синтаксис сериализации, определяет способхранения диаграмм на диске.