Modeling | Main
04.12.07
DSLs, XML, and Fluent Interfaces
Ayende writes about the right time for a DSL.
Concerning XML vs. DSL:
If you need to do things externally, a DSL is the place to look for. In fact, if you feel the urge to put XML into place, as anything except strict data storage mechanism, that is a place to go with a DSL.
DSL vs. Fluent Interface:
Fluent Interfaces relies heavily on intellisense in order to create that fluent feeling. If you need to work on it outside the IDE, that is probably going to be a factor.
Extensibility is also a concern; let us go back to the scheduling sample. We have the scheduling engine, and we have the tasks themselves. Consider that to write a task using a DSL I usually have to write a small text file, but to write a task using a Fluent Interface requires creating a project, compiling, etc.
I totally agree with Ayende. A DSL is the perfect means for supporting external aspects of a software development project, especially when non-programmers are involved.
Posted by Hartmut Wilms at 09:59
05.06.07
Interview: Jezz Santos about Software Factories
My interview with Jezz Santos, a trusted expert advisor for the Web Service Software Factory and the creator of one of the world’s first implementations of a software factory (the ‘EFx Factory’), which demonstrates some of the advanced features of a future generation of software factories to come from Microsoft, is published on InfoQ, at last.
Go read it here.
Posted by Hartmut Wilms at 19:25 | TrackBack
07.01.05
UML, OOAD and MDD
In addition to my previous entry, I’d like to comment on Jack Greenfield’s view of UML and it’s shortcomings in the field of Model-Driven-Development (MDD). Jack describes UML as a useful means of object oriented analysis and design here and here. He says that UML is not the appropriate tool for MDD and that it’s “focus is primarily on creating documentation that describes system structure or behavior.”.
My question is, what are analysis and design all about in Jack’s view? In my opinion software development is a series of model transformations. Parts of this transformation process can be automated and some parts have to be manually transformed. What are models anyway? Models are an individual’s view of real objects or processes. In order to cope with the complexity of reality models reduce the sum of aspects to those which are relevant for the context at hand.
The first model which comes to our mind is the natural language, at least I hope every developer’s brain works that way (funny, imagining Jack or Grady thinking in DSLs or UML diagrams ;-)). That’s what I would call analysis. Some parts of the design model may also be described in a natural language. Thus analysis and design are about creating models, aren’t they. Granted, these models are also suitable for documentation purposes.
The next step in the process is transforming your natural language model into a UML diagram (or a DSL). Why should I do this? Just write down your analysis requirements into plain code. We might argue about that, but I think that’s out of the scope of this blog entry … To answer the question: Model transformations are a way of reducing complexity and thereby formalizing models and at the same time loosing information. By formalizing we manage to remove ambiguities which is important for developing a consistent software. But we also lose information. This information might be added by for instance OCL constraints or other formalisms. I think that they are better gathered and manually added later on in the development/transformation process.
Additional transformation steps may be added before generating or manually implementing code. For instance an analysis model is transformed/formalized by a design model.
The last noteworthy step is to generate code from your (UML / DSL) models and fill in the missing information by manually implementing business rules which would have been much to difficult or even impossible to express in the UML notation, i.e. OCL. Your code is then transformed into byte code, and eventually into a sequence of 1000101001001 …
O.K. but UML still is not suitable for MDD, but DSLs are! First, I hope that I managed to explain why UML diagrams are models which may be transformed into code (-> MDD) and not a mere means of documentation. Simply put analysis and design contribute to implementing a software system as well as documenting the system! What is the difference between UML and DSLs? UML as pointed out in many other blog entries, e.g. by Stefan here, is a flexible instance of MOF which can be used in great variety of contexts. In addition UML can be customized by UML profiles (stereotypes). The advantage of customizing UML in contrast to specifying a new instance of MOF is that many aspects of UML can be reused and don’t need to be defined again and again. It might also be easier to get used to different UML profiles, all based on UML, than to familiarize with totally different DSLs. In the end it depends on the user. Some may prefer a more flexible meta model, which lacks some specific traits of the domain, others want to use a model which is as close to the domain as possible.
Posted by Hartmut Wilms at 18:15
05.01.05
UML vs. DSLs
Don Box is commenting on the ongoing debate between the MDA camp and the Software Factory/DSL camp.
I’m not baffled “why the UML camp puts so much emphasis on UML relative to MOF and XMI”. It’s in the name ;-). Alright, “MDA camp” might have been the better term. However, to my mind this is maybe the bottom line of Don’s critique. Why do the MDA people put so much stress on UML? The first thing I could think of is: because this is what every developer/architect will work with each day. UML is the “UI” of the MDA process, it is used for building models!
Is this a good thing? It depends … I fully agree with Don’s opinion about MOF and XMI. The reason why UML is so important is its support and its importance in nearly every tool set. I don’t know of any tool on a MOF basis save the EMF editors. In such modeling tools UML would just be one of the possible “visualizations”, syntax respectively, for models. In this regard MOF is the meta DSL and Microsoft’s DSL Tools are a tool set after my fancy. Well, at least they are a first approach. Even text based model languages would be possible and in some regard even preferable.
So, where is the difference? UML Stereotypes are very similar to DSLs and MOF might have been the basis for DSLs. The only notable difference might be that DSLs resemble the domain a bit more, i.e. it is easier to achieve a resemblance with DSLs and the right (meta) modeling tool.
The argument that MOF maybe too complicated for the typical developer is pointless. I think the typical developer would normally not define a DSL either. DSLs and stereotypes are defined by architects or domain experts with a profound knowledge of models. Such people will be able to cope with MOF as well. The Microsoft approach might look a bit easier, but this is merely achieved by tool support.
As .NET stimulated the sluggish Java and J2EE community DSLs might encourage the MDA camp to think about new ways of improving tools and processes. I’m curious. How about you?
Posted by Hartmut Wilms at 17:22 | Comments (6)