1. Меню нетерминала тождественно меню первой конструкции в списке правила, определяющего данный нетерминал.

2. Меню предопределенного нетерминала строится аналогично пункту 1 текущего списка. Меню предопределенного нетерминала «Пусто» состоит из символов меню следующей за ним конструкции.

3. Метасимволы конца групп и альтернативы не имеют собственного меню.

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



Глава 3. Проектирование архитектуры языкового инструментария

Для построения текстовых предметно-ориентированных языков, необходимо создать удобную среду разработки, включающую в себя текстовый редактор с подсветкой синтаксиса, с помощью которого пользователь сможет корректно вводить правила описания метаязыка, метамодели, трансформации моделей, с последующим сохранением этих правил в репозитории, строить модель предметной области на основе описанных метамоделей [4]. Для хранения данных можно воспользоваться базой данных, имеющей строгую структуру, однако возникает проблема со сложностью переносимости системы, что является существенным недостатком такого вида репозитория, данную проблему решает расположение хранилища данных на жестком диске в XML_формате.

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

1. Текстовый редактор кода с подсветкой синтаксиса.

2. Репозиторий.

3. Браузер проектов.

4. Валидатор.

5. Трансформатор.

3.1 Проектирование языкового инструментария

Языковой инструментарий для создания текстовых DSL имеет следующую архитектуру (см. рис. 3.1).

В соответствии с данной архитектурой платформа включает в себя репозиторий, который хранит как отдельные метамодели (предметно-ориентированные языки), так и готовые решения (DSL и созданные на его основе программы). Браузер проектов из хранилища данных загружает в систему имеющиеся решения, позволяет пользователю управлять репозиторием, а именно добавлять, удалять, редактировать метамодели, созданные на их основе модели. Редактирование какого-либо уровня моделирования осуществляется посредством редактора кода, который выполняет динамическую подсветку синтаксиса в соответствии с заданными правилами, а для метамодели еще и проверку корректности языка.

Размещено на http://www.allbest.ru/

Рисунок 3.1. Архитектура языковой инструментарий

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

Преобразование созданной модели предметной области в код на целевом языке программирования или в модель, базирующейся на другом DSL, осуществляется трансформатором, который на основе заданных в браузере проектов правил трансформации и исходной модели выполняет соответствующие модификации [4].

3.2 Проектирование компонента проверки синтаксиса

В рамках данной работы рассматривается реализация только компонента проверки синтаксиса, поэтому архитектура разрабатываемой части системы, в соответствии с предъявляемыми требованиями, представлены в виде технического задания (см. прил. Ж), включает в себя браузер проектов, репозиторий и непосредственно сам валидатор (см. рис. 3.2).

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 3.2. Архитектура компонента проверки синтаксиса

3.3 Проектирование пользовательского интерфейса

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

Главное окно системы (рис. 3.3) содержит редактор синтаксиса и область со списком найденных ошибок, включающую индикаторы корректности: первый определяет наличие или отсутствие ошибок в метамодели, загораясь при этом красным или зеленым цветом соответственно, а второй - корректность модели. Если метамодель создана с ошибками, при сохранении или создании на ее основе моделей система еще раз явно уведомит об этом пользователя, аналогичное сообщение появится и при сохранении модели, если она не является корректной, однако данные функции при этом не будут заблокированы.

Рисунок 3.3. Интерфейс системы - редактирование программы

В рамках метамодели терминалы выделаются черным цветом, кроме экранируемых обратным слешем, они имеют синий цвет, метасимволы - зеленым, а нетерминалы - серым. В модели выделяются только терминальные символы, составляющие описание для не предопределенных нетерминалов (см. рис. 3.4).

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

Рисунок 3.4. Интерфейс системы

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



Глава 4. Программная реализация компонента проверки синтаксиса

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

4.1 Построение дерева разбора

Важным этапом, реализующим возможность выполнения проверки синтаксиса модели, является построение дерева. Анализ метамодели осуществляет конструктор CSentence(string s), который получает входной параметр от компонента описания синтаксиса в виде текущей рассматриваемой лексемы и реализует следующие важные поля класса CSentence:

1. Nonterminals - список нетерминалов как предопределённых, так и не предопределённых, определяющий правила языка.

2. StartSymbol - стартовый нетерминал, от которого строится дерево.

3. SemanticErrors - список семантических ошибок в текстовом виде для вывода на экран.

4. LanguageFault - признак наличия синтаксических или семантических ошибок в языке.

Основой построения дерева является заполнение списка Nonterminals. Изначально в него вносятся предопределённые нетерминалы, которые могут быть впоследствии заменены на не предопределённые. Затем компонент описания синтаксиса, а именно лексический анализатор последовательно передает рассматриваемые нетерминалы и выполняет разбор текста языка. Каждое корректное правило разбивается на список лексем Sequence, после чего устанавливается связь с описываемым нетерминалом. Порядок расположения символов в списке соответствует порядку их расположения в тексте правила: слева направо. Каждый символ является наследником абстрактного класса CSymbol:

1. CTerminal - терминал.

2. CPredefined - предопределённый нетерминал.

3. CDefined - нетерминал, определённый пользователем.

4. CMetaSymbol - метасимвол.

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

По завершении анализа дерево почти построено. В Sequence содержатся все ветви узла в виде символов типа CDefined. Завершающим этапом является поиск корня, то есть стартового символа. Для этой цели служит поле NonStart класса CDefined. При создании объекта данное поле равно false. По окончании синтаксического анализа текста для всех не предопределённых нетерминалов проводится следующая операция: поле NonStart для всех нетерминалов, содержащихся в Sequence, устанавливается в true, поскольку они не могут быть стартовыми символами, оставшийся нетерминал с неизменённым полем NonStart и есть стартовый символ.

4.2 Анализ модели

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

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

В процессе анализа программы методом List<string> Compile(string s, int iCaret) компонент описания синтаксиса каждой конструкции ставит в соответствие определенный стиль для дальнейшего выделения цветом, после чего компонент проверки синтаксиса составляет разметку текста программы и заносит ее в поле CompiledText. Если вариант разбора признан некорректным (в частности невозможен дальнейший анализ текста программы), то при выборе нового варианта список CompiledText возвращается к разметке до текста, с которого будет происходить дальнейший разбор по алгоритму, описанному в разделе 2.5. Поле CompileError определяет наличие ошибок в последнем разобранном тексте программы и обуславливает цвет индикатора корректности модели в редакторе. Результатом работы метода является список элементов контекстного меню для заданного параметрами положения курсора. Если анализ программы невозможен из-за ошибок в языке, метод возвращает null.

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

Символы, которые могут служить возможным продолжением текста программы, отображаются при равенстве индекса конструкции текста модели, задаваемого курсором, и текущим анализируемым символом. Таким образом, меню редактора программы формируется на основе меню рассматриваемой конструкции, созданного в момент разбора метамодели (рис. 4.1).

Рисунок 4.1. Пример меню со списком терминальных символов

4.3 Разработка репозитория

Основные функции по созданию, удалению окон редактора, управлению браузером проектов осуществляет класс CLanguageEditor. В правом окне формы редактора располагается элемент управления репозиторием типа TreeView, представленный классом CRepository, который содержит 3 уровня коллекции объектов: решения, языки и программы. Наполнение браузера проектов актуальными данными происходит при загрузке системы, в дальнейшем все изменения структуры объектов отражаются в данном элементе управления, а при сохранении изменений и в репозитории, расположенном на жестком диске (рис. 4.2).

Создание нового узла класса TreeNode дерева репозитория генерирует добавление нового контекстного меню к данному элементу в зависимости от его типа:

1. Решения (menuRepository) - генерируется для окна браузера проектов, а также для узлов, не имеющих собственного элемента управления.

2. Языки (menuLanguage) - добавляется к узлам, типа решение или язык.

3. Программы (menuProgram) - добавляется к узлам типа программа.

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

Рисунок 4.2. Браузер проектов с контекстным меню для модели

Описание всех методов и свойств классов, разработанных в ходе программной реализации системы представлено в таблице (см. табл. 4.1). Подробное описание интерфейса системы и ее функциональных возможностей приведено в руководстве пользователя (см. прил. И). Особенности работы с компонентом для системного программиста представлены в руководстве администратора (см. прил. К).

Таблица 4.1. Описание свойств и методов реализованных классов

Наименование класса	Поля и свойства	Методы
CSymbol - абстрактный класс для представления терминальных и нетерминальных символов языка
CTerminal - класс для представления терминала	string Symbol -терминал	CTerminal(string Symbol) - создание заданного терминала
CNonterminal - класс для представления нетерминала
CMetaSymbol - класс для представления метасимвола	int iGoto - индекс символа, на который выполняется переход при выполнении заданного условия во время разбора языка; EMetaType type - тип метасимвола	CMetaSymbol(EMetaType type) - создание заданного метасимвола
CPredefined - класс для представления предопределенного нетерминала	bool CanEmpty - признак наличия описания предопределенного нетерминала; EPredefined type - тип предопределенного нетерминала	CPredefined(EPredefined type, bool CanEmpty) - создание предопределенного нетерминала заданного типа
CDefined - класс для представления определяемого пользователем нетерминала	int Ier - индекс элемента следующего за правилом, определяющим данный нетерминал; int It - индекс нетерминала в правиле; List<CDefined> Links - список связей для контроля цикличных описаний; List<string>[] Menus - меню для конструкций из последовательности данного нетерминала; bool NonStart - признак, определяющий стартовый символ; List<CSymbol> Sequence - последовательность, описывающая нетерминал	Add2Menu(List<string> menu, string item) - добавление пункта в меню для заданного нетерминала; Add2Menu(List<string> menu, List<string> items) - объединение двух меню для заданного нетерминала; AddLink(CDefined d) - добавление в список связи нетерминала; CDefined(int it) - создание нетерминала; MakeMenu() - создание меню для заданного нетерминала; RemoveLinks() - удаление из списка связей нетерминалов с пустыми списками связей
CSentence - класс для представления последовательности символов	List<CTextStructure> CompiledText - разметка текста; bool CompileError - признак наличия ошибок в последнем анализируемом объекте; char[] cServiceSymbols - список метасимволов; bool error - признак наличия ошибки для текущего правила; int iSW - индекс последнего корректно разобранного объекта; int iTS - индекс начала правила; bool LanguageFault - признак наличия ошибок в языке; Dictionary<string, CNonterminal> Nonterminals - упорядоченный список нетерминалов; List<string> SemanticErrors - список семантических ошибок; string StartSymbol - стартовый символ; List<CTextStructure> TextStructure - структура текста языка; List<CTextStructure>WText - последняя корректная разметка текста	AddError() - добавление ошибки; AddMarker() - добавление маркера в разметку; Compile(string s, int iCaret) - анализ текста программы; CSentence(string s) - анализ правила; GetText(int i, int k, string s, ETextPiece type) - обработка полученной лексемы; MakeMenu() - создание меню для нетерминала; MarkIncorrect(int iS, int iF) - признак некорректного правила; SearchBound(int i, string s, char c) - поиск начала и конца метасимвола; SetProgrammError(string s, int iS) - обозначение строки с ошибкой; WhenNotItem(List<CCompileState> states, ref CDefined Defined, ref List<CSymbol> Sequence, ref CCompileState CurrentState, ref int iS) - поиск корректной разметки
CLanguageEditor - класс для представления редактора	char[] BackSlash - символ разделения катологов; CRepository Repository - репозиторий языков и программ.	contexCreate(object sender, ToolStripItemClickedEventArgs e) - отображение репозитория; contexNode(object sender, ToolStripItemClickedEventArgs e) - реализация пункта меню для узла; GetName(string ObjectType) - получение имени объекта; GetNewSolusion() - получение имени решения; IsModelOpened(string solution, string language, string program) - определение открытой модели в редакторе; IsSelected(TreeNode node, int Y) - определение выделенного узла.
CLanguageRepository - класс для представления репозитория для языка	CText Language - язык; List<CText> programs - список программ	CLanguageRepository(CText langauge) - создание репозитория для языка; CLangaugeRepository(XmlElement el) - получение репозитория для языка из XML-элемента; XML(XmlDocument doc) - создание XML-элемента для репозитория языка
CTextStructure - класс для представления разметки языка	Int Ind - индекс символа в строке; ETextPiece Type - тип разметки	CTextStructure(int ind, ETextPiece type) - создание разметки
CText - класс для представления анализируемого текста	String Content - содержимое лексемы; String Name - название лексемы	CText(string name, string content) - создание объекта с заданным именем и содержанием; CText(XmlElement el) - считывание объекта из XML документа; GetModelName(string path) - получение имени модели из пути; ReadFile(string FileName) - считывание текста из файла; XML(XmlDocument doc, string type) - создание объекта из XML документа
CSolution - класс для представления решения	List<CLangaugeRepository>List - список языков репозитория; String Name - имя решения	CSolution(XmlElement el) - считывание решения для языка из XML документа; XML(XmlDocument doc) - создание XML документа для объекта репозитория
CRepositiry - класс для представления репозитория	List<CSolution>Repository - список решений в репозитории	CRepository(XmlDocument doc) - считывание репозитория из XML документа; IndexesOf(string SolutionName) - поиск решения в репозитории; IndexesOf(string SolutionName, string LanguageName, out int i0, out int i1) - поиск программы в репозитории; IndexOf(string SolutionName, string LanguageName, string ProgramName, out int i0, out int i1, out int i2) - поиск языка в репозитории
CTab - класс для представления языка и программы	RichTextBox Editor - редактор метамодели; Int Level - уровень модели; ContextMenuStrip menuEditor - контекстное меню для модели; List<CTextStructure> OldStructure - разметка текста; String OldText - предыдущий рассматриваемый текст модели; String ProgramName - имя программы; CRepository Repository - репозиторий; TextBox Semantics - список ошибок; CSentence Sentence - лексема; Label Shape1 - индикатор ошибок в метамодели; Label Shape2 - индикатор ошибок в модели; String SolutionName - имя решения	CompileText() - анализ текста модели заданного уровня; CTab(CRepository rep, int i0, int i1, int i2, TabControl container) - создание страницы модели в репозитории; CTab_Enter(object sender, EventArgs e) - переход к странице репозитория; CTab_Leave(object sender, EventArgs e) - переход к другой страницы репозитория; Exit(object sender, EventArgs e) - выход без сохранения; Menu_ItemClick(object sender, ToolStripItemClickedEventArgs e) - выбор пункта меню; RenameLanguage(string solution, string OldName, string NewName) - переименование языка; RenameProgram(string solution, string language, string OldName, string NewName) - переименование программы; RenameSolution(string OldName, string NewName) - переименование решения; Save(object sender, EventArgs e) - сохранение модели в репозитории; SaveAndClose(object sender, EventArgs e) - сохранение модели в репозитории и выход из приложения; SetSemanticErrors() - вывод ошибок; SetTitle() - вывод имени в заголовок формы; ShowText(List<CTextStructure> structure, List<string> MenuItems) - вывод текста в редактор

4.4 Тестирование компонента проверки синтаксиса

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

В качестве одного из кейсов исследовательского тестирования можно рассмотреть создание матамодели, а затем и модели для описания нескольких бизнес-процессов библиотеки: выдача, возврат книг, прием новых изданий и запись читателя в библиотеку. Каждый из рассматриваемых бизнес-процессов определяется набором атрибутов (см. табл. 4.2).

Таблица 4.2. Описание атрибутного состава бизнес-процессов библиотеки

Бизнес-процесс	Атрибутный состав
Выдача книг читателю	Читатель (ФИО, номер читательского билета); издание (название книги, автор); дата выдачи
Прием новых книг	Издания для включения в фонд (издение, количество); дата приема книг
Возврат книг читателем	Читатель; издание; количество; дата возврата
Запись в библиотеку	Человек (ФИО); присваиваемый номер читательского билета; дата записи

Таким образом, метамодель можно сформировать посредством правил (рис. 4.3), включающих как описание самих бизнес-процессов, так и определяющих их сущностей: человек, читатель, автор, издание, набор изданий.

Рисунок 4.3. Тестирование: метамодель для описания бизнес-процессов библиотеки

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

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

Рисунок 4.4. Тестирование: процесс построения модели по заданному языку

Одним из вариантов полностью корректно созданной программы по заданному языку может служить следующая реализация (рис. 4.5):

Рисунок 4.5. Тестирование: корректная модель

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

Заключение

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

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

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

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



Библиографический список

1. Зарплата.ру [сайт]. URL: https://perm.zarplata.ru/ (дата обращения: 29.04.2017).

2. Методика оценки трудоемкости и стоимости разработки и сопровождения прикладного программного обеспечения при создании информационных систем (Методика CETIN) [Электронный ресурс]: Астана, 2011. URL: … (дата обращения: 29.04.2017)

3. АО «Национальный инфокоммуникационный холдинг «Зерде». Нормативы на создание, развитие и сопровождение информационных систем [Электронный ресурс]: приложение к методике CETIN. Астана. 2011. URL: (дата обращения: 29.04.2017)

4. Сухов А.О. Разработка инструментальных средств создания визуальных предметно-ориентированных языков: диссертация на соискание ученой степени кандидата физико-математических наук: 05.13.11: защищена 05.12.13 // Сухов Александр Олегович. - Пермь. - 2013. - ПГНИУ. - 256 с.

5. Сухов А.О., Лядова Л.Н. О подходе к разработке профессионально-ориентированных систем на основе DSM-платформ // Информатизация и связь. - 2013. - № 5. - С. 15-18.

6. Charles Ph., Fuhrer R.M., Sutton S.M. IMP: a Meta-Tooling Platform for Creating Language-Specific IDEs in Eclipse Proceedings of the Twenty-Second IEEE/ACM International Conference on Automated Software Engineering. - NY. - 2007. - P. 485 - 488.

7. Cuadrado J.S., Canovas J., Molina G.J. Comparison between internal and external DSLs via RubyTL and Gra2MoL [Электронный ресурс]: HAL archives-ouvertes. 2012. URL: https://hal.inria.fr/hal-00752687/document (дата обращения: 29.04.2017).

8. Drobintsev P.D., Kotlyarov V.P., Voinov N.V., Nikiforov I.V. Model Oriented Approach for Industrial Software Development // Modeling and Analysis of Information Systems. - 2015. - No 6. - Vol. 22. - P. 750-762.

9. Fowler M. Domain Specific Language [Электронный ресурс]: URL:https://martinfowler.com/bliki/DomainSpecificLanguage.html (дата обращения: 29.04.2017).

10. Haase A., Voelter M., Efftinge S., Kolb B. Introduction to OpenArchitectureWare 4.1.2. Model-Driven Development Tool Implementers Forum (MDD-TIF 2007). - 2007.

11. HeadHunter [сайт] URL: https://perm.hh.ru/ (дата обращения: 29.04.2017).

12. Kats L.C.L., Visser E. The Spoofax Language Workbench: Rules for Declarative Specification of Languages and IDEs, Proc. Conf. Object-Oriented Programming, Systems, Languages and Applications (OOPSLA 10). - 2010. - P. 444-463.

13. Krahn, H., Rumpe, B., Vцlkel, S. Monticore: modular development of textual domain specific languages // Proceedings of Tools Europe. - 2008.

14. Pech V., Shatalin A., Voelter M. JetBrains MPS as a Tool for Extending Java. Proceedings of the 2013 International Conference on Principles and Practices of Programming on the Java Platform: Virtual Machines, Languages, and Tools. - NY. - 2013. - P. 165-168.

15. SuperJob [сайт] URL: https://perm.superjob.ru/ (дата обращения: 29.04.2017).

16. Wachsmuth G.H., Konat G.D., Visser E. Language Design with the Spoofax Language Workbench // IEEE. - 2014. - Vol. 31. - P. 35-43.



Приложение А. Диаграмма прецедентов

Рисунок А.1. Диаграмма прецедентов



Приложение Б. Диаграммы последовательностей

Рисунок Б.1. Диаграмма последовательностей «Создание решения, языка, программы»

Рисунок Б.2. Диаграмма последовательностей «Открытие решения, языка, программы»

Рисунок Б.3. Диаграмма последовательностей «Сохранение решения, языка, программы»

Рисунок Б.4. Диаграмма последовательностей «Переименование решения, языка, модели»

Рисунок Б.5. Диаграмма последовательностей «Редактирование языка»

Рисунок Б.6. Диаграмма последовательностей «Редактирование программы»

Рисунок Б.7. Диаграмма последовательностей «Удаление решения, языка, программы»



Приложение В. Диаграмма классов

Рисунок В.1. Диаграмма классов



Приложение Г. Таблица взаимодействия классов

Таблица Г.1. Взаимодействие классов

Название класса	CSymbol	CTerminal	CNonterminal	CMetaSymbol	CPredefined	CDefined	CSentence	AskName	CLanguageEditor	CLanguageRepository	CTextStructure	CText	CSolution	CRepositiry	CTab
CSymbol	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
CTerminal	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0
CNonterminal	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0
CMetaSymbol	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0
CPredefined	0	0	1	0	0	0	0	0	0	0	0	0	0	0	0
CDefined	1	1	1	1	1	0	0	0	0	0	0	0	0	0	0
CSentence	1	1	1	1	1	1	0	0	0	0	1	0	0	0	0
AskName	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
CLanguageEditor	0	0	0	0	0	0	1	0	0	0	1	1	1	1	1
CLanguageRepository	0	0	0	0	0	0	0	0	0	0	0	1	0	0	0
CTextStructure	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
CText	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
CSolution	0	0	0	0	0	0	0	0	1	0	0	0	0	0	0
CRepositiry	0	0	0	0	0	0	0	0	0	1	0	1	1	0	0
CTab	0	0	0	0	0	0	1	0	0	1	1	1	1	1	0



Приложение Д. Нормативные коэффициенты трудоемкости

Рисунок Д.1. Нормативные коэффициенты трудоемкости



Приложение Е. Поправочные коэффициенты

Таблица Е.1. Поправочные коэффициенты

Номер коэффициента	Фактор частного поправочного коэффициента	Описание фактора частного поправочного коэффициента	Значение
К1	Режим эксплуатации ИС	Параллельная обработка данных	1,01
К2	Масштаб ИС	Малые ИС (до 10 пользователей с непродолжительным ЖЦ)	0,90
К3	Стабильность ИС	Маловероятное внесение изменений	0,95
К4	Защита от несанкционированного доступа	Слабая	0,96
К5	Защита программ и данных (на уровне операционной системы, на уровне сетевого программного обеспечения, на уровне СУБД)	Слабая	0,97
К6	Контрольный след операций	Не имеется	0,97
К7	Отказоустойчивость	Низкая	1,00
К8	Восстанавливаемость	Низкая	0,92
К9	Длительность обработки	Умеренная	1,02
К10	Исходный язык разработки ИС	Объектно-ориентированный (Си++ или эквивалентный)	0,99
К11	Класс пользователя	Случайный	1,08
К12	Требования к центральному обрабатывающему устройству	Средняя	0,97
К13	Требования к оперативной (основной) памяти	Малая	0,97
К14	Требования к внешней памяти	Малая	0,97
К15	Требования к локальной вычислительной сети	Средняя	0,97
К16	Критичность ИС	Организационная безопасность	0,97
К17	Готовность	Общедоступная (известная методика)	0,97
К18	Представление данных	Форматированный файл	0,91



Приложение Ж. Техническое задание

Компонент проверки синтаксиса языкового инструментария

Компонент проверки синтаксиса

Техническое задание

Действует с_______

Пермь 2017

Ж.1. Общие сведения

Наименование системы

Полное наименование: Компонент проверки синтаксиса языкового инструментария.

Краткое наименование: Компонент проверки синтаксиса

Наименование организации - Заказчика и Разработчика

Заказчик: Кафедра ИТБ НИУ ВШЭ-Пермь.

Разработчики: студентка группы ПИ-13-1 Е.Ю. Медведева.

Плановые сроки начала и окончания работы

Плановые сроки начала: 09.01.2017.

Плановые сроки окончания: 20.04.2017.

Источники и порядок финансирования

Финансирование отсутствует.

Порядок оформления и предъявления заказчику результатов работы

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

Ж.2. Назначение и цели создания системы

Назначение системы

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

Общую схему работы пользователя по созданию программы в разрабатываемом инструментарии можно представить в виде последовательности действий:

1. Создание языка (метамодели).

2. Создание программы (модели).

Цели создания системы

Компонент проверки синтаксиса языкового инструментария создается для достижения следующих целей:

1. Оптимизация процесса проверки корректности программы относительно созданного языка.

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

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

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

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

2. Точность и достоверность информации, полученной в результате соотнесения требований языка и спроектированной программы.

Ж.3. Характеристика объектов автоматизации

Связь разрабатываемого компонента проверки синтаксиса и редактора кода можно представить в виде диаграмм последовательностей, отражающих бизнес-процессы редактирования моделей разного уровня (рис. Ж.1, см. рис. Ж.2).

Рисунок Ж.1. Диаграмма последовательностей «Редактирование языка»

Рисунок Ж.2. Диаграмма последовательностей «Редактирование программы»

Ж.4.Требования к системе

Требования к структуре и функционированию системы

Требования к функциональным характеристикам

Разрабатываемая система помимо компонента проверки синтаксиса должна иметь репозиторий для возможности хранения данных о созданных в системе решениях, программах и языках. Данный репозиторий должен представлять из себя коллекцию XML файлов с определенным расширением, зависящим от уровня сохраняемых данных (программа, язык, решение), расположенной на жестком диске.

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

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

Архитектуру системы можно представить следующим образом (см. рис. Ж.3):

Размещено на http://www.allbest.ru/

Рисунок Ж.3. Архитектура системы

Требования к составу выполняемых функций

Для эффективного функционирования компонента проверки синтаксиса необходимо разбить его на следующие подкомпоненты:

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

2. Синтаксический анализатор - выполняет соотнесение лексемы модели с ожидаемым символом, полученным в результате спуска по построенному дереву разбора, формируя список синтаксических ошибок.

Требования к организации входных данных

В данном компоненте источником входных данных является строковая лексема и ее индекс в тексте языка, передаваемой компонентом описания синтаксиса.

Требования к организации выходных данных

В качестве выходных данных принимается список найденных в ходе анализа модели ошибок, а также последняя корректно спроектированная разметка текста модели для выполнения подсветки ее синтаксиса.

Требования к надёжности

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

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

1. Сбой электропитания технических средств.

2. Сбои программного обеспечения.

3. Сбой в работе операционной системы.

4. Отказы в системе, не найденные во время отладки.

Время восстановления после отказа

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

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

Отказы из-за некорректных действий оператора

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

Условия эксплуатации

Система должна использоваться на ПК в Операционных системах Windows XP, Windows 7, Windows 8, Windows 10.

Климатические условия эксплуатации

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

Требования к численности и квалификации персонала

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

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

Режимы работы конечного пользователя обуславливается его рабочим графиком.

Требования к составу и параметрам технических средств

В состав технических средств должен входить

1. IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

1.1. Процессор Pentium - 4 с тактовой частотой 1.2 ГГц, не менее.

1.2. Оперативную память объемом, 512 Mб, не менее.

1.3. Жесткий диск объемом 40 Гб, и выше.

1.4. Оптический манипулятор типа «мышь».

2. Локальная сеть. Пропускная способность ЛС до 1Гб/сек.

Требование к информационной и программной совместимости

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

1. Среда разработки MS Visual Studio, так как она предназначена для разработки и исполнения приложений различных типов, в том числе приложение Windows Forms.

2. Операционные системы, которые поддерживают среду разработки:

2.1. WindowsXP.

2.2. Windows 7.

2.3. Windows 8.

2.4. Windows 10.

Требования к информационным структурам и методам решения

Файлы составляющие репозиторий должны быть XML формата с расширением заданным уровнем сохраняемого объекта.

Требования к исходным кодам и языкам программирования

Компонент должен быть реализовать на языке программирования C#.

Требования к программным средствам, используемым программой

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

Требования к защите информации и программ

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

Специальные требования

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

Ж.5.Требования к программной документации

Предварительный состав программной документации

Состав программной документации должен включать в себя:

1. Техническое задание.

2. Отчет о проделанной работе.

3. Руководство пользователя.

4. Руководство программиста.

Специальные требования к программной документации

Специальные требования к программной документации не предъявляются.

Технико-экономические показатели

Ориентировочная экономическая эффективность

Расчет экономической эффективности не выполняется.

Предполагаемая годовая потребность

Предполагаемое число использования программы в год - круглосуточная работа программы на одном рабочем месте.

Ж.5. Стадии и этапы разработки

Стадии разработки

Разработка должна быть проведена в три стадии:

1. Составление ТЗ.

2. Анализ предметной области и выбор средств реализации.

3. Проектирование алгоритмов реализации компонента:

3.1. Создание алгоритмов построения дерева разбора.

3.2. Создание алгоритмов проверки синтаксиса модели.

3.3. Создание алгоритмов формирования списков ожидаемых символов.

4. Про...