I also share you view on using the capabilities of a host language to create abstractions that map closer to the actual problem domain. Lisp seems a good choice for you. In teams and bigger organizations the usual challenge with embedded/internal DSLs is how to make sure that other developers also use the higher level expressions and do not “drop” to the host language. External DSLs solve this issue. See examples of various domain-specific graphical languages at http://www.dsmforum.org/cases.html

Unfortunately in practice that doesn’t work, and the reason is that it is not Lisp! It doesn’t work because it is much more harder to implement any software transformation in a system that is not homoiconic, where you need special (commercial) tools to have access to all the features, and where you need a full feature programming language to develop sophisticated algorithms and heuristics to transform your systems and designs, or just to generate code. The way it is implemented in Objecteering with J is just too hard and idiosyncratic to be worth in practice to do something that lisp programmers do everyday: writting macros transforming high level expressions into lowlevel code.

And there’s no need for a graphical representation such as UML to do that, lisp symbol expressions are all you need to climb the abstraction ladder.

I would like to emphasize the domain-specific parts of a language. This is essential here as it is needed to raise the level of abstraction as well as to make the code generation possible. UML simply can’t do that since it does not “know” about any particular domain, such as automotive, telecom, bank, insurance etc. For those who want to see a comparison via an example, please take a look of the Chapter 1, Section 1.3. at Wiley site. (http://media.wiley.com/product_data/excerpt/64/04700366/0470036664.pdf)

In the example the DSM solution is created for a narrow area of interest (Symbian applications), raise the level of abstraction and provide full code generation from the models. I would be interested to see a similar kind of working example made with a general purpose modeling language, like UML, SySML, SSADM, EXPRESS-G, MERISE or IDEF. I would be even more interested to see the profile definition for this domain with UML. Implementing the profile would be enormous tasks since most domains are really different to that UML provides.

In my opinion, SysML is not a domain-specific modeling language. I share the view of OMG (http://www.omgsysml.org/#What-Is_SysML) as I can’t see from SysML any specific kind of systems it addresses. A more domain-specific language addressing system modeling would be for instance AUTOSAR, EAST-ADL or AADL – all targeting automotive domain.

It is true that with executable UML we can also generate code but the models are at low level of abstraction. And it is the raise in the level of abstraction that improved productivity in the past and will do so in future too. Moreover, (executable)UML does not guide developers making correct designs or prevent creating models that don’t execute or execute with a poor performance. This simply because a general purpose language don’t know about the domain we are working in. In my opinion the whole term executable UML is a bit misleading since most of the executable work (by Kennedy Carter, Olivanova/Oasis, Schaler&Mellor) existed already before UML and they already know then the “right” parts of the UML specification

But in domain specific cases, UML can be not enought. System conception is not only software design, and, if we add business rules and domain constraints, the best notation won’t be UML.

But UML introduced the notion of profile, which is way to extend UML, adding new concepts or refining existing concept. Profiles can be used to add lower concepts (Platform specific extension, ie “this class is a C++ class or a C structure”), but also high level concepts (This is the concept of requirement, which will be declared as implemented in this use case, and its technical realization will be this software component).

With this extensions, we can adapts UML to domain specific needs. The most advanced is sysML, which is an OMG profile for system modeling, but the user can create its own profile to its domain. I’m currently working on a profile for system modeling using a enterprise-specific method.

With such a tool, UML can be adapted to the user domain, and tooling can be created among this model to help user manipulating it.

But why use a profile instead of creating a specific metamodel and its manipulation from scratch ? Many UML tools supports profil, and, if the user profile reuse some UML diagrams (sequence diagram are horrible to rewrite and are very common in many methods), thoses diagrams come freely with the tool.

Note that if your business specific modeling is very far of UML modelling, the complexity of profil and UML mapping can be a very bad idea. You have to be very pragmatic, as usual.

Huh? Have you ever heard of Executable UML? Leon Starr’s classic UML book on class modeling discusses domain-specific modeling (I wouldn’t necessarily recommend the book, though). Code architectures are supposed to be limited to the deployment diagram.

@As Steven Kelly said in a 2006 article, “To make model-driven development work this way, you cannot use a general-purpose design language like UML and a modeling tool’s built-in code generator. The people that created UML did not design it for describing applications in your domain, or for generating code other than skeletons.[...]”

This is the same thesis presented OVER 20 YEARS AGO by the ROOM folks. The problem was that ROOM was “ahead of its time”: it was a domain-specific pictorial modeling language for distributed, real-time systems. It also basically failed in the marketplace, in part because it was proprietary and in part because it served such a narrow niche that it didn’t attract the attention of mainstream journalists who could write silly but useful promotional articles, with headers that say, “PROGRAMMING HAS NEVER BEEN EASIER.”