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.

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.

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.)

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.