Modelling
I am organising a conference next week on Architectural Modelling (at Brocket Hall, a really spectacular location; although soup will not be on the menu!). This is an area which seems to hold a lot of promise in improving quality and productivity of complex projects and an approach I strongly believe in.
Researching this topic comes up with two different approaches; Model Driven Architecture (MDA) from OMG and Domain Specific Modelling (DSM) from Microsoft. There is a good discussion about the different models in the architecture section of DNJ online.
MDA is based around the concepts of sets of models at different levels of abstraction and the ability to transform from one level to another (and back again!) automatically. DSM is rather less ambitious and is based on the concept of a model for each domain and the validation of one domain model against another. Logically MDA points towards a CASE type methodology whilst DSM indicates a Product Line Factory or Software Factory approach. The thorny area of Round tripping is an immediate and obvious differentiator between these approaches.
The OMG are proposing the use of UML 2.0 as the modelling language of choice for MDA whilst Microsoft lean towards graphical Domain Specific Languages (of which of course UML 1.5 would be an example in the architectural space). There seems to be a lot of debate about the extensibility and appropriateness of UML 2.0.
I don’t have enough knowledge of UML 2.0 to comment on that language (although perhaps I should have) however I do feel very strongly that the concept of a general purpose transformation from one domain or level of abstraction to another will always yield a sub optimal solution unless there is a transform algorithm. I suspect this is why the CASE tools industry died and why O-R mapping technologies (and the upcoming O-XML mapping technologies) are also doomed to provide poor performance in the general case.
I do believe however that it is possible to build a mapping (or constrained transform) technology which is what the DSM approach proposes. Groping back to my undergraduate degree days the example that springs to mind is transformation from the amplitude to frequency domains which can be mapped approximately for specific bands or done in the general case using the Fast Fourier Transform (FFT). Alas I suspect it will be a long while before we have such a transform for architectural models.
Meanwhile I have to give a DSM demo (see TLS345) at the conference so will be busy trying to get it to work!
Comments
- Anonymous
February 10, 2004
Great to see the momentum in this area - in patterns & practices we got feedback from users of the Application Blocks for .NET where they perceive them as small frameworks focused on a particular domain, driven by a 'domain specific language' (the metadata they use, expressed in xml, in config) that models the behaviour of the block in more abstract, focused way. A good example of this is the User Interface Process block or the Configuration Management block. In these cases the DSL is interpreted (rather than transformed into implementation at design-time)
Any thoughts, comments or opinions on this are appreciated - - Anonymous
February 17, 2004
See http://blogs.msdn.com/keith_short/archive/2004/02/13/72796.aspx - Anonymous
February 20, 2004
Well, if you view UML 2.0 as a static language that can't be extended, then of course, one language can't fit all your needs.
But UML 2.0 is extensible. Much more than UML 1.x. And that's the point. It's a better (not perfect) platform for building models. It is a big mistake to think UML is nothing more than it's surface syntax.
Think of UML 2.0 as moving towards to as modeling CLI: A common infrastructure for all modeling languages, which includes a core set of models. You extend this infrastructure via libraries.
Also, UML as a programming language does indeed hold water. There is a lot of interest and even tools being shipped in the space. It is of great interest to embedded developers. I know of a major project at Boeing that is using the idea. Lockheed has a set of tools, and so on.
But, I think you are assuming that UML 2.0 major intent was to be executable. Believe me, that is not the case. One major goal was to make it a better platform for modeling languages of all types. Better extensiblity, better metamodeling concepts, and I think it has done a great job in that respect.
Also, take a look at tools like XSD designers. These are models that can generate a complete XSD just from the model. Is that a modeling tool as a sketchpad?
Is it the solution for other spaces? Maybe, maybe not. But, I'm all for the idea. Programming with a higher level of abstraction holds great appeal to me. - Anonymous
February 21, 2004
I remember a program that came out in the early 80's called "The Last One". I was meant to be the last program you would ever need and was extensible etc. Wonder what happened to that?
I'm all for progarmming with higher and higher levels of abstraction, I just dont think we know enough yet to be able to do it. That's the problem I have with Java, is it the last language we will ever need? Maybe but I remember someone telling me that about Cobol too.
I guess I am just too old and sceptical to believe we have the final definitive right answer. - Anonymous
February 25, 2004
I don't think we have the final and definitive answer, because there probably isn't any, and never will be.
But, I think we are at the point of having good ideas, and having enough drivers in place to make modeling an promising avenue for development, and experience with tools like Whitehorse will provide valuable input into where modeling needs to go.
We aren't at the last word yet. Heck, we all know that things don't get really interesting until version 3, after all. - Anonymous
March 02, 2004
The problem with UML is that it is very much a supply-side modelling technique. What is missing is a really business-orientated consumer-side model that integrates business process flow with web services within a contractual framework. The contract needs to specify the terms of use, change management approach, and operational management faciities for the service. I see this as a major inhibitor to business take up of the web service model. It would be great if Microsoft could lead on this on behalf of customers. - Anonymous
March 02, 2004
The comment has been removed - Anonymous
March 17, 2004
BPMN and BPEL4WS seem like a good place to start from. The analysis phase would proceed by associating a service and contract requirement with a Message Flow; this would then be expanded to a UDDI search; then a WSDL spec and ultimately a web service implementation. If the Visio add-ins for Biztalk 2004 (ODBA) could be expanded in this way it might provide the simple consumer-side tool we need. - Anonymous
March 17, 2004
Agree but I am concerned that BPMN does not have the richness in terms of levels of abstraction that we need. I think that IDEF was on the right track but again the levels they defined were not quite correct. We need a understanding of what BP levels there are in real organisations and what needs to be modelled at each level. - Anonymous
March 17, 2004
How does IDEF represent service invocation? - Anonymous
March 17, 2004
It dosnt, it works at the buisness modelling level - Anonymous
March 24, 2004
That seems to be the main problem - we lack a business modelling notation that includes service invocation. I believe, however, that it wouldn't be too difficult to associate contract and service specifications with a BPMN message flow as a first cut. - Anonymous
May 26, 2004
I am writing a paper on UML 2.0 - Anonymous
June 05, 2004
3dsky digital Inc has a computer rendering and animation division, we are experienced and provide quality computer graphics at the lowest possible prices. we bring your architectural paper designs to life, so it is easy for your clients to see how the building looks like when it is finish. architects, real estate developers, facility owners, city planners, interior designers, and landscape architects who require quality renderings benefit from our realistic presentation