Introducing DRYML
“If you can’t describe what you are doing as a process, you don’t know what you’re doing.” — Edwards Deming
DRYML (an acronym for “DRY Modeling Language”) is both a human- and machine-readable software modeling language.
DRY (an acronym for “Don’t repeat yourself”) is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy. [Wikipedia]
[https://gist.github.com/vgrigoryevskiy/cb4cef2fe61f735ced78ca88e84d80bf]
The Problem
Simple Models are overly simplified.
Complex Models are overly complicated.
In Software Engineering, there’s a task to model systems and processes for the purpose of their development and automation.
There’s plenty of software modeling tools to do this, of two main types.
Simple Tools
Pros:
- Free, easy-to-use, no IT qualification required, sometimes natural language-based
- Models are described with different types of diagrams (Use Case, Class, Activity, etc.)
Cons:
- If a Model is complex, more than one diagram needs to be created
- Data from different diagrams is not linked
- If a model needs to be updated, all the created diagrams shall be updated separately
Complex Tools
Pros:
- Data Integrity
- Good basis for gap and impact analysis
Cons:
- Expensive, complicated, require special qualification
- Hard to support models up-to-date in a long-term as it rapidly grows
The Solution
To combine all the benefits of the “complex” solutions preserving the advantages of “simple” tools. [Seems obvious, yeah?]
DRYML implements the development principle “DRY” (don’t repeat yourself), providing the capability to describe a model just once and then work with it as with a master-data. The benefits are:
- Free
- Natural language-based (English)
- Universal — any processes can be modeled on the “Business” Level without specifying implementation details which usually reside in source code
- Generate UML diagrams (Use Case, Class, Object, Activity, Sequence, State)
- Early validation of mistakes and mismatches in a model
- Alerts on non-active Actors and non-used resources
- Unlike it’s done in source code, DRYML is not so strict — it helps you model what you want exactly at that level of details you need it, forgiving you missed statements instead of throwing compilation errors at you
- Bonus: Provides a capability to design Business-Layer Models (Domain Models and Business Rules) and easily interchange them between systems, teams, and projects.
For more information on separation Domain Layer from other parts of Software — read the Article What is the Level of your Tech Start-up? Part 1/3. Software Technical Architecture.
For more information on data exchange format — see the Section “Information Model” below.
DRYML Main Principles
- There are three core entities: Actor, Resource, and Activity
- A process has at least one Activity
- Actor executes some Activities
- Actors may interact during Activities execution
- Activity may need specific Resources as an Input to process successfully
- Activity may produce specific Resources as a result of its execution
- At a specific moment of time, a Resource [Object]can be in one and just one particular State (even if it’s in two or more States simultaneously, it’s a new separate State)
- At a specific moment of time, a Resource [Object] may have some Parameters with specific Parameters Values
- [Not added in the current version yet] Activity may have dependencies on one or more other Activities
- [Not added in the current version yet] Activity may have Loop indication provided
- [Not added in current version yet] Activity may have additional constraints on the quantity of Input and Output Resources [Objects]
Information Model
DRYML supports the AIFORSE Framework’s mission — to define a set of standards that support the integration and interoperability between software engineering tools.
More specifically, DRYML implements the AIFORSE Integration Framework Domain Data Model, defined for the entity “Process”. See the reference to the Schema below.
As it’s already mentioned above, managing Processes Data in the provided way allows capturing, storing and exchanging data about the processes between teams, projects, and systems.
Diagram
Schema
You can review and download the JSON Schema following the link:
aiforse-integration-framework---process-json-schema.json
Feel free to contribute to the Schema in particular or to the Framework in general.
Examples
Here comes the most interesting part.
In order to make it both fun and practical, let’s review the step-by-step description of the cooking process to prepare the “Momofuku’s Soy Sauce Eggs”.
[The original recipe was taken from https://food52.com/recipes/35930-momofuku-s-soy-sauce-eggs]
Step 1. Whisk together water and sugar
Step 2. Add the sherry vinegar and soy sauce
…
See the Complete Process here:
Conclusion
Each time when you model any software solution, just ask yourself the following questions:
- What is the Process Flow I’m implementing?
- How will I ensure data integrity both within the Model and between several Models?
- How can I verify that the Model is testable?
- How will I share the Model within the team, with other teams, including customers’, partners’, and subcontractors’ ones? How will I make sure the Model is understood in the same way by all the involved stakeholders?
- How will I keep the Model up-to-date during all the lifeline of the software solution?
- How can I make information about the Model to be quickly found by new team members, as well as to make it easy to navigate within the Model?
- How can I reuse the Model as much as possible in new projects, or when delivering updates for the current project some time later?
