Article: Lightweight Domain Specific Modeling

Discussions

News: Article: Lightweight Domain Specific Modeling

  1. Article: Lightweight Domain Specific Modeling (22 messages)

    With lightweight domain specific modeling, developers can implement and use their own code generators to avoid repetitive manual coding and increase efficiency. In this article, software developer Patrik Nordwall shows how to make this approach easy, by being in control of the DSL and code generation tools.

    Read Improving Developer Productivity with Lightweight Domain Specific Modeling.

    Threaded Messages (22)

  2. Really fine[ Go to top ]

    In this way, that is, developing the model and generating (or provinding by reflection, or ATP, or ... ) all from it we can convert the MVC frameworks in simply Mc (Model and a little of controller).
    Obviously this produces more productivity, maybe as in Visual RAD but using OOP. :)

    Apart of UML as definition language (as in MDA) you can apply this idea using Plain Java classes (as in Nacked Object) or XML (as in OpenXava
  3. A solid Technique. :)[ Go to top ]

    I don't really post or read TSS that much anymore. I value quality technical information and i feel most times that TSS has too much pollution and a spam area for ordinary events.

    That aside, I like your idea and the foss tools you use to realise your process. It sounds really familiar to parts of Feature Driven Development (FDD), especially when it is combined with Borland Together; a tool which supports the FDD process but I feel this is a good thing.

    My input would be that it might be really cool for the agile community if there was a quality FOSS offering that could replicate Together's power and simplicity. If the JET templating could be hidden from the end user, I think that would be an improvement. :)
  4. Labeling the use of ArgoUML firstand EMF as described in this article with the term "DSM" or Domain Specific Language (DSL) may give some people a wrong impression about DSLs.

    The library model is hardly the definition of a DSL (i.e. a meta model), it rather is a UML-flavoured model of a library. Yes, you can take the perspective of calling the library model a meta model, but then the term "architecture-centric Model Driven Software Development" is more appropriate. In fact that's one of the patterns in the artile on MDD patterns that the author refers to.

    EMF can also be used to define a DSL, which describes the abstract syntax of a Domain Specific Language, and then to generate an editor for the DSL via JET and the default EMF templates. The editor generated by EMF subsequently is the tool with which models are expressed in the DSL. From there onwards, a template engine (JET, openArchitectureWare, or some other) and appropriate custom templates can be used to generate code - typically code that wires up the model to a domain specific framework.

    All of this may sound a bit complex, and the generated editors are pretty much bare bones, but that's how it works if you use EMF as a tool for DSM. However, the author is right, EMF is well suited for architecture centric MDSD.

    For further information on MDSD also see the articlesarticles at http://www.softmetaware.com.
  5. EMF can also be used to define a DSL, which describes the abstract syntax of a Domain Specific Language, and then to generate an editor for the DSL via JET and the default EMF templates. The editor generated by EMF subsequently is the tool with which models are expressed in the DSL.

    I think it is important to be able to easily change both the DSL model and the code generation templates and therefore I have choosen a unformal definition of the DSM model. Using EMF to define the DSL might be good for some scenarios, but it is probably more difficult to develop/change.

    UML is definitly not the one and only way to design a DSL. For many scenarios it is very bad, but for defining an application structure, which I do in the Library example, it is rather good.

    The point is, there is not one tool that fits all. Continue to post you experiences of other tools that can be used in this area.
  6. Yes agree, there is no tool that fits all purposes. Using DSLs is all about constantly thinking about the right balance of standardization and customization, i.e. use a general purpose language where it is does not cause pain and grief, and resort to DSLs wherever that is is the lesser effort.

    One way to look at a DSL is as the final step in building a domain specific framework. Frameworks are by definition closely interwoven with framework usage code. A DSM approach can serve to minimize the knowledge about framework internals that a user of the framework needs. The result is that frameworks are used correctly - as intended by the framework author - and encapsulation is improved. Again, it is about getting the right balancing. In this case between investing in framework development and investing in DSM driven code generation on top. One the one hand you don't want overly complex generator templates, and on the other hand you don't want to implement contorted framework code for situations where generation provides an easier solution.

    In most projects you end up with several technologies and several frameworks that need to be integrated. Small DSLs can be a great help in automating much of the integration.

    In terms of DSM tools, one interesting commercial example is the MetaEdit+ tool from http://www.metacase.com. Regarding Open Source tooling I strongly recommend looking into the OpenArchitectureWare (oAW) component on the Eclipse Generative Model Transformer project. oAW can now also be used with Ecore, the meta model used by EMF! On the GMT project you also find a range of other MDSD components, such as the ATL language for model to model transformations.
  7. New Tools[ Go to top ]

    Several tools have been released lately that makes Model Driven Software Development (Domain Specific Modeling) even more attractive. I have found openArchitectureWare to be a solid tool with nice DSLs for different tasks. Xpand is the template language, and compared to JET it is more efficient to work with. The expression and the Xtend language is powerful and removes a lot of code that otherwise must be written in helper Java classes. However, it is good that Java can be used as well for more extensive helper methods. I have ported the Library example from the article to oAW. You can download it. The major change apart from a different template language is that now I have defined a real meta model in Ecore. The generated EMF tree editor can be used to edit the application specific model. This editor is not very exciting to work with and a better DSL editor would be nice. Fortunately, two new tools for creating DSL editors have been released. oAW Xtext makes it really easy to create a textual DSL with editor that supports things like code completion and interactive constraints validation. Another exciting tool is GMF, which makes it possible to create a graphical DSL editor with reasonable effort. GMF looks very promising even though some more polish is needed until it becomes easy to use. I can also recommend reading From Front End to Code - MDSD in Practice and MDSD Book.
  8. Blech![ Go to top ]

    ArgoUML? JET? Lightweight? LoL!!!

    Seriously, since you can use something like Spring as the factory for most of the objects in your system, why would you spend any time creating factories? Furthermore, why automate the creation of factories? If you must automate creation of factories, look at something like Hibernate tools for Eclipse which will generate POJO's (your domain entities mapped to tables) and entity managers (finders).

    You wascal!
  9. Orphan Frameworks[ Go to top ]

    Yahoo! create a fragile framework that does something trivial, then move on when you are bored and there is a user community waiting for the next revision!
  10. Orphan Frameworks[ Go to top ]

    Yahoo! create a fragile framework that does something trivial, then move on when you are bored and there is a user community waiting for the next revision!

    Yeah, and TSS really need more constructive comments like this. Oh, now I get it. The comment was cranky and not constructive at all. That must mean that we don't need it and thus can put it aside... :-)
  11. You don't get it[ Go to top ]

    ArgoUML? JET? Lightweight? LoL!!!Seriously, since you can use something like Spring as the factory for most of the objects in your system, why would you spend any time creating factories? Furthermore, why automate the creation of factories?

    You don't get it.
    The objective is to define the domain and then generate other aspects of the application from the domain model, like the UI.
  12. You don't get it[ Go to top ]

    You don't get it.The objective is to define the domain and then generate other aspects of the application from the domain model, like the UI.

    I look at the 5 steps in the 'Overview' and don't get it, too. What's 'leightweight' in that approach??
  13. I look at the 5 steps in the 'Overview' and don't get it, too. What's 'leightweight' in that approach??

    It's lightweight compared to full-blown MDA methodologies and big expensive tools like Rational Rose. Also, you are not forced to use a tool that will lock you into doing everything its way. You could use these tools to develop just one aspect of your application.

    Hmm, maybe the word lightweight is too overloaded with expectations.
    I think the article should maybe instead emphasize that there are now tools for model-driven development that are available to a wider audience.
  14. what about AndroMDA?[ Go to top ]

    It's lightweight compared to full-blown MDA methodologies

    May be it's lighter than MDA approach. However, using framework like AndroMDA and their ready-made cartridges, make the Model-Driven Architecture very simple.
    In addition, by writing a so-called cartridge, you can customize AndroMDA to fit your needs; just like DSL is doing by helping you to implement your own code generators.
  15. You don't get it[ Go to top ]

    Exactly!

    It is not replacement for Spring. If you do some serious applications with Spring, which I do, you know that there is a lot of repititive coding with Spring also. For example, it would be easy to generate some of the Spring XML configuration from the same domain model.

    The example, with factories, is nothing else than just an example.
  16. I prefer RDF\OWL and Jena[ Go to top ]

    With lightweight domain specific modeling, developers can implement and use their own code generators to avoid repetitive manual coding and increase efficiency. In this article, software developer Patrik Nordwall shows how to make this approach easy, by being in control of the DSL and code generation tools.Read Improving Developer Productivity with Lightweight Domain Specific Modeling.

    I am currently working on my first model-driven application.
    I looked at EMF but I ended up using RDF\OWL to specify my model because I found RDF and OWL much easier to approach than ECore. I use the Jena API to process my model. Also, I can write RDF\OWL by hand in an editor. And the Jena API seems WAY easier to understand than the EMF API.
    I think this makes RDF\Jena a more lightweight approach than EMF. Any opinions?
  17. I have no problem with the principle of DSM. Having built & used code generators myself, they are IME at their most useful (& productive) when the generators are first-class objects in the project, and this is a basic requirement if you are developing specific to a domain. Developers can focus on developing templates, rather than individual classes.

    A minor gripe (and I know this isn't the thrust of the article) is the choice of tools. The chosen toolset should be as simple as possible and I think that dynamic languages lend themselves better than UML to defining DSLs and associated templates.

    My 2p
    Kit
  18. A minor gripe (and I know this isn't the thrust of the article) is the choice of tools. The chosen toolset should be as simple as possible and I think that dynamic languages lend themselves better than UML to defining DSLs and associated templates.My 2pKit

    Sure, there are a lot of alternatives when it comes to the choice of tools, and that choice should also be based on the problem domain. Use tools that fit your domain.
  19. Code generation[ Go to top ]

    Hi,
    this is my first post on TSS and I hope it will be coherent.

    I am a big fan of code generation and I want to share my experience.
    My way of using code generation is close to MDD but most MDD tools are trying to hide the templates from the developer. This aproach is used for many years and in my opinion always failed.
    Code generation tools must not tend to became Visual RAD tools. We are programmers, we write code, drag and drop programming over used never leaded to anything good.

    Code generation is based on the model ( database model or domain model or whatever model you want), the templates (any template engine will do as long it has a language different enough of the languages of the code you generate) and the framework (the architecture of your application).

    Trying to pass any of this responsabilities to an IDE tool gives you many restraints.

    For the model I use XML-files. Some of them are imported and adapted from database schema editors and some are hand written to define speciffic functionalities.

    I have an intermediate step to transform an XML from Azzuri Clay to a simpler xml for the database model (that is the MDA part of my system).

    I also have a different hand-written XML file (or more if necessary) where I define more complex and application related information.( this is the domain speciffic part ). Here I put anything from toString() definitions for objects, filters required from DAO layer to validation and layouts for user interfaces.

    As the template language I use FreeMarker. I think it is the best to generate any kind of code ( from XML, HTML to Java and config files).I use FMPP to setup my code generation so I don't have to write any programming code, only configuration files.

    The most important is how you design your application. It doesn't matter if you use JDBC/Hibernate/JDO, Factories/Spring/any container, as long as you can abstractize the layers of your application.

    For the example at DAO layer I generate most of required functionalities ( CRUD, pagination, history, filters) but sometimes I have to write an unique functionality so I have to extend the DAO classes. The business layer uses this functionality without knowing if it comes from a generated or hand-written source code.

    I generate any code from database to UI layer. Each time I have a new functionality I implement it by hand and if it is necesarry or usefull I transform the code to a freemarker template.

    Ofcourse this is not easy, and mostly it is one man show. The rest of the team uses the framework, but only one or few must change it because it requires deep understanding of the tehnologies used.

    Miron.
  20. ...not so many points for content.
  21. A real implementation[ Go to top ]

    This discussion is too abstract. Let me give you a real working Invention, to build Ajax GUI applications, for building online GUI Applications:
    (i): You build custom GUI Widgets (we will give you standard Widgets):
    http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm

    (ii): You build “Component Factories":
    http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm

    (iii): Then assemble supply chain of “Component Factories”:
    http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

    There you have it: You have your great looking Online GUI Application (which costs a fraction to build).

    If there is a real interest, I will write an article.

    Please also review:
    http://cbsdf.com/misc_docs/why-gui-api.htm
    http://cbsdf.com/misc_docs/gui-api-brief.htm

    Patrick, nice imagination! without having any solid platform to work from.

    Raju
  22. A real implementation[ Go to top ]

    This discussion is too abstract. Let me give you a real working Invention, to build Ajax GUI applications, for building online GUI Applications:(i): You build custom GUI Widgets (we will give you standard Widgets):http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm(ii): You build “Component Factories": http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm(iii): Then assemble supply chain of “Component Factories”:http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htmThere you have it: You have your great looking Online GUI Application (which costs a fraction to build).If there is a real interest, I will write an article.Please also review:http://cbsdf.com/misc_docs/why-gui-api.htmhttp://cbsdf.com/misc_docs/gui-api-brief.htm Patrick, nice imagination! without having any solid platform to work from.Raju
  23. A real implementation[ Go to top ]

    I just like to add one more comment: The combinations of JavaScript and XML Graphics languages (e.g. DHTML, SVG, X3D, Macromedias MXML or Microsoft’s XAML) are excellent domain specific languages for online GUI applications.

    P.S: Please forgive me if I provided too much data in the first web page. I appreciate your patience. I could not cut down any more, I hope you could understand why I have to start from clean slate and build the framework from ground up.
    http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm