A couple of things, separate but related. Firstly I want to announce that we have made available a paper describing our UML Profile for Software Services. This profile was developed according to the principles I outlined in my previous entry; i.e. we spent a long time looking at examples and asking ourselves if these models actually provided us the ability to reason about and communicate the architecture of a system. We believe we have struck a reasonable balance, we are able to leverage the flexibility provided by basing this model on UML itself (so all of UML is still there to use) while specifying a subset which is useful in identifying, designing and refining a service-oriented solution. Note that we have also developed a profile, a model template, and also some examples that we are preparing to make available, also on developerWorks, in the next week so you can tell us if we have achieved our aims.
Now, my second comment. In a recent conversation with a colleague started with his asking for a reference he could cite on the OMG architecture for modeling, the M0..M3 layers of modmodeling and so on. He is also working on a model, in this case a model that represents certain managed assets for one of our runtime platforms and the model will be used to describe these assets at runtime and also in the tools his group are building. So, my question to him was why he needed the reference; well it turns out his team couldn't decide if the model they were developing was a model or meta-model or something else. Well, you know this is the kind of time-wasting discussion that we as tool vendors (and model geeks) love to engage in - but why does it matter? does it make the tool better to know this? does it help the customer if you can sit back and be satisfied that you have a valid M0 meta-model? I come back to my last entry, let's not confuse the technical nonsense we like for value for our customers... customers care about what they can do with the tool you develop, not what model or meta-model is used.[Read More]
Tooling platforms and RESTful ramblings
skjohnston 120000GMPN 653 Visits
I was recently looking for a piece of information and was looking through Software Blueprints by David Robertson and Jaume Agusti (a good but heavy read). Interestingly I found a section on conceptual modeling that I think applies to all forms of modeling and which I would like to share here. In a section entitled "What we require of conceptual models" the authors provide a list of attributes of models, listed below. The reason I found this advise particularly timely is that we here at Rational are currently in the process of developing specific content for Service-Oriented Development of Applications within the RUP supported by specific service design models in the IBM Rational Software Modeler.
Now, personally I have used a simple rule of thumb when looking at models and the use of models to support a given technical or business domain - does it make me go faster? (thanks to Kevin Kelly). More recently I have used an additional metric does the model of this thing tell me something about the thing that I could not tell from staring at the thing itself?. Now it would seem that these simple rules are related to the more precise list of attributes above, a list I must admit I find more useful with each read. An idealized, germane model concentrates on what is important and presents that at the right level of abstraction and detail pertinent to the user and the task at hand - it makes me go faster. Also an arguable, communicable model is one that shows me aspects of a system that I might not otherwise have been able to see. However, this leaves us with traceable and methodical, well one aspect of a lot of the models that we have described in the RUP is that they are based upon the UML and so connections and relationships between elements can easily be made to support traceability. In fact this traceability is a key aspect of both the RUP guidance on separation of models and the OMG MDA initiative. In a similar way the RUP takes an iterative approach to development that drives right down into guidance on the development of models, start by identifying the significant (relevant concepts) model elements and build out the detail in subsequent iterations providing a methodical approach.
So, going back to the opening comments, we are looking at a model for the representation of services from an architectural and design perspective (specifically as black boxes not white boxes); we idealize them by creating relationship between elements that are certainly not available in some of the standards in use today such as WSDL. We have certainly represented the concepts we believe to be germane given both the target model author as well as those to which the model will be communicated. We certainly feel that, given the examples we have modeled so far, that the model provides value to its reviewers in providing certain views that are not possible by directly reflecting the physical artifacts, and also that the model can be built iteratively. We have also connected the model with guidance in RUP such that we can describe how the model traces back to earlier models such as business process and use case models and how it can flow down into implementation models and implementation artifacts.
Incidentally one of the areas where such model representations, based upon a common underlying semantic base, have advantages over custom (dare I say domain specific) languages is that they do support the traceable attribute above. It is relatively easy to use predefined relationships in the UML (trace, refine, realize, reify, implements, use) to describe the relationship between elements in different models, across domains and across abstraction boundaries. One down-side that I would have to admit to is that precision can be a lost factor, today with the mechanisms available at our disposal in the UML to extend the language we cannot easily redefine the semantics of what is already there (and as some have pointed out, even that is not formally defined). In some cases this is a problem where the semantics of the domain being modeled are significantly different from the semantics already described in the UML. Luckily in describing a model for services and SOA the mismatch is insignificant, and when we apply the Germane factor we find that those concerns that we decide to elide are generally those with obscure or undefined semantics. In terms of custom languages then, it is often possible to define the semantics formally and/or precisely, however the tendency is to pay far too much attention to this factor than to the Idealized and Germane concerns, i.e. there is a need to reflect everything that is in the domain of concern without applying the relevance filter, and what we end up with is a model that may directly represent some artifact, but is no easier to model than it is to code and contains so much detail that we lose the ability to communicate it and argue over it.
Finally, let me be clear, this is not an argument that UML is good and DSL or custom languages are bad - I have seen good and bad UML models as well as good and bad DSLs (and that covers both textual and graphical DSLs). All I hope is that language designers and modelers take into accound these 7 principles when they start their work - and that users will always hold them to account.[Read More]