Domain Specific Language related to methodology development

Domain Specific Language for the development of a methodology is my prime interest. The domain of application is related to Model Driven Engineering (MDE).

At this stage, using ANTLR, I developed a language called VROOM (Verifiable OO Methodology). For some of you, ROOM by ObjectTime (now by Rational), gave me the kind of inspiration to expand such a methodology in the area of project management and MDE. The methodology that I am pursuing includes a system engineering economic model as well as a project attribute monitoring and predicting capability.
The rationale for joining this community is to exchange with peers with similar interest and similar development approach. Five years ago, I experienced the potential integration of Decision Intelligence capabilities (Causal Decision Diagram based). I also experienced with numerous Graphical Notation-Based methodology like UML and others. From a validation and verification perspective, the only route I found beneficial for my work is the application of ANTLR in developing VROOM. The single issue at this stage is the integrate VROOM with a Virtual Machine specifically developed to match the V&V capabilities I am looking for.

I welcome any challenging views and observations. Should my work by of some value to this community, I welcome the feedback.


1 Like

Hello, welcome to the community!

Is there any information publicly available about your idea?

Good day Niko. Actually, not. A few years ago I had been exposed to Model Driven Architecture using a tool called IMES from Integranova. The value of that tool was to validate the generated model and then generate code in Java or C# associated with the model. The other interesting aspect is a function point measurement and detailed documentation of the code would be created. The primary issue I found was related to the user interface generated: a windows type screen. I was looking for the capability to generate graphs like Excel based on the formulas embedded. The second issue I found was the dynamic aspect of the model was not to my satisfaction. I wanted to embed a dynamic progress method into my model called IPALM (Intelligent Project Assistant in Lifecycle Modeling).

One last issue was the application IFPUG methodology to measure the size of the project. I found that methodology wanting when assessing complexity of the model being assessed and furthermore requiring qualification related to a manual type measurement (qualitative for the complexity assessment). I found a way to assess complexity quantitatively using a reference called Software Engineering with Formal Metrics by Dr. Le O. Ejiogu.

Estimating complexity with metrics is an interesting topic. When we have had chance to assist our customers with their domain-specific modeling languages we emphasize that metrics should be based on the domain too – and use the metamodel data. For example, a metric for software used to control production processes in a paper mill can calculate valves, motors, pumps, and their characteristics rather than produce general metamodel-independent traditional metrics on system complexity (e.g., cyclomatic complexity).