Welcome to the Agile Architect Website!

Bringing Agility to Architecture, and Architecture to Agility

Modelling Techniques and DSLs

Microsoft have recently started talking about "Domain-Specific Languages", modelling techniques which are aimed at specific tasks. While some DSLs may derive from UML, others may be quite separate from it. This page outlines useful DSLs I have developed or discovered.

Modelling Enterprise Interfaces

In strict UML, components have a dependency on the interfaces of other components, as in the following example:

There are several problems with this notation:

  • It doesn’t really work where both systems expose their own interfaces, and we're trying to glue them together. This is very common in Enterprise Application Integration (EAI situations).
  • The notation implies a direct coupling between the components, which is definitely not true for EAI.
  • The arrow may be counter-intuitive in terms of data flow, sending the wrong messages to non-technical reviewers.

Therefore I've found it useful to extend the UML notation to provide a more complete and intuitive picture, with two main changes:

  • Draw interfaces on each component as required,
  • Draw the relationship directly between the interfaces as an "object flow", indicating the dominant data flow between them.

Remember that content is more important than representation. If you’re modelling to communicate, use models which avoid confusion.

Modelling Subsystem Dependencies

An interesting (ab)use of the UML Use Case diagram is as a DSL to model dependencies between things. Essentially you model each thing using a Use Case shape, and use dependency relationships. The things can be almost anything: modules in a system, systems in an enterprise, or activities in a project or programme. (Strictly speaking, of course, component dependencies should be modelled using a UML component diagram, but I've found it useful to use a "generic" dependency diagram in some cases.)


One Response to Domain-Specific Modelling Techniques

Manoj Bhardwaj on 27 February 2021 at 00:01

Hi Andrew,
Nice article, but you use invalid UML notation in section on Interfaces. In UML, both the calling and called interfaces and specified by different icons. The line joining the two is directed from Caller to Callee. To a person well versed in UML the notation is completely unambiguous.

Additionally, You rightly state that as an Agile Architect you would tailor your designs to your audience. Therefore, it implies that you would not present a UML diagram do business stakeholders. UML is for communication with developers & testers who are expected to be well versed in UML anyway.
So your Statement that some people would misinterpret the notation is wrong, as you would never be presenting UML to business stakeholders.

If you'd like to comment on this article, with ideas, examples, or just to praise it to the skies then I'd love to hear from you.

Comment on this article

Please share: All Addthis servicesTweet thisFacebook thisLink thisYam thisShare on Google