What are "Out", "In" and "Very In" in UML

It's a crude way of classification and is just a way to have some prospect. Or you can think that I am doing this just for a fun.

What is "Out" in UML are those features which are almost never used in (real) practice, for some reason. Not that they are not useful but somehow they are not being used. Such as action semantics...

What is "In" is those features which everybody uses or everybody may be assumed to be using. This includes use case diagrams, sequence diagrams, activity diagrams, and all features which are Very In.

So what are "Very In"? Of course this includes UML class models offering specialisation hierarchy, attributes and signature of each method (operation). I also wish to include DBC features which associate OCL-based assertions with signatures in class models. So what are "Very In" are those features universally used and/or respected as foundations of MDA and business modelling.

What I wish to say by this classification is simple, and can be summarised as follows:

• Classified as "Very In" above concern the fundamental static structures of software, together with declarative assertions associated with them. In particular they are model elements which Frankel called Development Artifacts ---- formal artifacts which can be used for model transformation to develop programs from models, or at least check their correctness using a mechanical means.
  


• "In" on the other hand concerns dynamic structures of software which are useful to get general ideas but which do not have a formal basis ---- so these are, in the dichotomy by Frankel for model elements, Design Artifacts and not development artifacts. they can surely give a sketch of the general ideas of software and useful documentation but may not be material directly useful for MDA proper.


• "Out" again concerns dynamic structures --- and they are about detailed dynamic behaviour of software hence non-declarative, operational specifications on dynamics of programs. They are what would be very close to "implementations" from the viewpoint of software architects...

(As to the last item I am not against having dynamics in specifications --- this is a fascinating subject we may as well explore. Also a lot of UML features do not fall into these categories as clearly as can be.)

A plain fact about UML is, as far as what is being offered currently, the situation is that "Very In" is widely used or respected and moreover offer essential ingredients for MDA; "In" is again very popular and useful though they may not be part of MDA proper since their correspondence with realisd programs is hard to be made formal; And "Out" is the remaining bits in UML (which can of course later be classified otherwise).

So one question is in which of these categories we wish to introduce the modelling artifacts for distributed interaction, and what kinds would they be: we want some modelling elements useful for specifying financial protocols and more generally interactions among distributed participants. This is our question and we wish to answer this by asking the following question:

Why does Frankel say that interaction (i.e. how objects interact with each other, as given by activity diagram) is an implementation issue in UML?

Frankel does not explain too much in detail but given his other discussions in his book there must be a good reason for him to say this. In fact when we answer this question, we shall start to see the concrete shape of modelling artifacts we would be needing for our endeavour, tohether with their positioning in our trichotomy and in effect in the general modelling framework.

The rest for the next post (by the way I may update the "model hierarchy" post yesterday since I found it reads boring: while in fact this is a very exciting idea...).

PS: Gary, please do not despair by my long-winding introduction before we can go into real design (though for me the present discussions are also very real). I share your desire to go into the decisions on: what are the (top) units of descriptions; what are the type structure of the language; what are the fundamental control structures; and so on and so forth. And I admit that my discussions may not always look taking shortest possible paths (at least for readers!), and my English is getting worse and worse after starting this blog (I will correct at least glaring mistakes soon).

And yet, we certainly wish to be clear about what kind of language we are designing (e.g. for programming and/or modelling); and for that purpose, we also need be clear what does it mean to do programming, what does it mean to do modelling, in this new realm of software description we are working on. And to understand the landscape, it may be worth even going back to the modelling of non-distributed software through the representative design method such as UML, since in that way we may be able to obtain wisdom from our accumulated experience and well-understood foundations.

So I hope that you can bear a few more posts before we go into discussions on concrete design elements.