Posts

Showing posts from November, 2008

Worth a look - A process for MDD (Model Driven Development)

A post by lispy entitled "Why UML Fails to Add Value to the Design and Development Process" reminded me of an existing methodology put together by IBM. Lispy wrote (I cut a lot out) - "The modeling language must be a first-class citizen of the development process rather than just make-work for architects and project managers... There are two linguistic abstraction barriers that must be implemented in order to make this work: 1) the modeling language between the models and the generated code and 2) the framework between the generated code and the target libraries. You must build up from your core code components to the framework… and you must build down from the models to the generated code. If the code generation process is too complicated, you may need better abstractions at the framework level. If the code generation process is impossible, then the modeling language may not be providing a detailed enough description of the requirements. If there is too much repetition

UML vs Domain-Specific Languages

Great minds think and do not always think alike. In surfing the web this week around clojure , Stack Overflow , Architecture and DSL (Domain-Specific Language) sites there is just a broad misunderstanding of UML. Really smart people seem to miss that UML is more than a modeling language with everything and the kitchen sink that is to vague to use. Just keep reading...really. UML is meant for extension and restriction as it offers, via the UML Profiles, mechanism which I recently extolled in Profiles - The UML problem solver . I have found others that are in this camp, http://www.dsmforum.org/ . They even wrote a paper UML vs. Domain-Specific Languages, Methods and Tools which if you go by the title seems to pit UML against DSLs, however it is quite the opposite. They seem to understand that UML profiles can be used to create restricted models or DSMs (Domain Specific Modeling); and yes I am using DSM and DSL interchangeably. Call me crazy, but this is also what the OMG - Objec

Profiles - The UML problem solver

In reading several posts on stackoverflow.com (and posting ) and through personal interactions it has become clear that people hate UML because they think of UML as a drawing language and not a tool for modeling. Nothing new so far, however, I realized as people search to bring teams together or gain efficiencies in communication UML all together skip UML profiles. People would really benefit from the added rigour that UML profiles can be used to create. UML problem - How a UML profile helps: * UML is to big - Profiles reduce the scope and mature tools only display valid elements and relationships. Only allow drawing that which should be drawn (modeled). * UML is slow - Profiles reduce the problem space and force the modeler to solve only the important pieces for your particular problem space. * UML is complex - Yup it is, but profile can reduce the possibilities and focus on simpler problem spaces. Novel idea, you mean I don't have to diagram the bits and the components. The