Подход к диаграммам UML и моделям ER, приемлемым для инженера-программиста

Это случайная часть режима, который я определил.

            } else if (state.name === "stereotype"){                
                if (stream.match(/\(/)) {
                    state.name = "stereotype style"
                    return null;
                }
                if (stream.match(/[A-Za-z][A-Za-z_0-9]*/)) {
                    return "variable";
                }
                if (stream.match(/>>/)) {
                    state.name = state.old_state;
                    return null;
                }
                if (stream.match(/,/)) { return null; }             
            } else if (state.name === "stereotype style"){
                if (stream.match(/\)/)) {
                    state.name = "stereotype"
                    return null;
                }
                if (stream.match(/[A-Z]/)) {
                    return "string";
                }   
                if (matchColors(stream, state)){
                    return "atom";
                }
                if (stream.match(/[,]+/)) {
                    return null;
                }      
            } else if (state.name === "class def"){
                if (stream.match(/[\t ]+/)) {
                    return null;
                }               
                if (stream.match(/\}/)) {
                    state.name = "base";
                    return "bracket";
                }
                if (stream.match(/\.\./)) { 
                    state.name = "class def section";
                    return "operator"; 
                }                                                                                    
                if (stream.match(/==/)) { 
                    state.name = "class def section";
                    return "operator"; 
                }      
                if (stream.match(/--/)) { 
                    state.name = "class def section";
                    return "operator"; 
                }
                if (stream.match(/__/)) { 
                    state.name = "class def section";
                    return "operator"; 
                }
                if (stream.match(/\+|-|#|~/)) {
                    if (isMethod(stream)) {                  
                       state.name = "class def method";
                    } else {
                        if (hasTypeAfter(stream)) {
                            state.name = "class def attribute (type after)";
                        } else {
                            state.name = "class def attribute";
                        }
                    }
                    return "attribute";
                }

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

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

MT("static class methods",
    "[keyword class] [def Car] [bracket {]",
    "  [operator ..][string Method Examples ][operator ..]",
    "  [attribute +][keyword {static}] [def Name][operator ():] [variable Type] [bracket {] [variable arg1], [variable arg2], [variable argn] [bracket }]"
  );     

  MT("abstract class methods",
    "[keyword class] [def Car] [bracket {]",
    "  [operator ..][string Method Examples ][operator ..]",
    "  [attribute +][keyword {abstract}] [def Name][operator ():] [variable Type] [bracket {] [variable arg1], [variable arg2], [variable argn] [bracket }]"
  );

  MT("interfaces examples",
    "[keyword class] [def Car]",
    "[variable ICar] [operator ()-] [variable Car]",
    "[variable ICar2] [operator ()--] [variable Car]",
    "[variable Car] [operator -()] [variable ICar3]"
  );

  MT("node package",
    "[keyword package] [def Node] <<[builtin Node]>> [bracket {]",
    "    [keyword class] [def Worker1]",
    "[bracket }]"
  );

Рассмотрим первый тест: он говорит, что первое слово ( класс ) должно распознаваться как ключевое слово, а второе ( автомобиль ) — как определение (или определение).

Единственная проблема при написании этого кода состоит в том, что грамматика plantuml… неоптимальна. Он используется для множества различных типов диаграмм, и он мне не так понятен. Я определенно не предложил бы это как пример хорошо разработанного DSL.

Что я хочу сделать в будущем

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

Следующим шагом является написание веб-приложения вокруг программы erd. Я начал создавать проект ( erd-web-server ), посмотрим, когда я найду время, чтобы немного поиграть с Haskell…

Как только я это сделаю, я начну работать над GitHub. Я хотел бы получить доступ к диаграммам в моих проектах и ​​генерировать изображения как часть веб-хука git.

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