Mike Brough (email@example.com)
Mon, 24 Jan 2000 14:45:25 +0000
I agree with your philosophy, which is similar to the one we developed in Yourdon in the late 1980s (internal model, plus views paradigm). This avoids the (imho) slip into the P+P mindtrap, that I think is common to a lot of UML work. [I had already sent off an email reply to an earlier question, before I read your comment.] In the late 1980s, I pushed this idea in Yourdon. But it was informal then. I have since formalised this modelling approach somewhat. If you are interested, it proceeds as follows: Models, model types, MCs, MCtypes --------------------------------------- A model contains instances of model component types. Each model type can contain a number of MCtypes (a M:N relationship, of course). A MCtype can have any number of features; each of which is instantiated (possibly with state/value) for each instance. This is a fairly classic slot-filler approach. View types and views ---------------------- A system development method (SDM) can prescribe a number of view types (object sequence diagram, object collaboration diagram/DFD, ...), each of which can have instances (individual diagrams). [A view can be a diagram, but needn't be; see also the comments on modelling tools and presentations below.] A view type filters (selects) by type; that is, it selects only a certain number of MCtypes; and for those, only certain feature types are shown. An individual diagram also selects by extent - that is, it selects only some of the things of that type that it could show. Modelling tools and presentations ---------------------------------- A modelling tool is something that is capable of translating features seen in a particular view type into some 'human-readable form' (diagram, text, emulation, speech, film clip, ...). A given view type can have more than one appropriate modelling tool; each gives an alternative presentation of the same logical information. E.g. the states of an object & their changes is a view type; it could be translated by graphic tool (node-arc network of states & transitions), table, speech (we did this once, for blind users), ... .... You will note that this is a generic description of a modelling paradigm. It can be applied to O-O system development methods and technologies, just as much as it could be applied to a process+data approach. It can be complemneted/used in various ways, depending on the underlying philosophy of a system development method. For example, we can 'chunk' things up (as doomains, packages); we could define different types of model (conceptual/implementation), ... Many of these issues are not noticed by those who think UML is the sum of all we need to worry about. Actually, its really just a formalism for documenting O-O software or software-intensive systems. It has to be used in context. Mike Brough Stuart Kent wrote: > I think this ongoing discussion reveals the weakness in expressivity of > collaboration diagrams. I find them not very useful because it is very > hard to see how the state changes as messages are passed around. The > problem is that a visual depiction of time is lost. Collaboration > diagrams seem to work best when the configuration of objects remains > near-enough static throughout the series of interactions. On the other > hand, sequence diagrams don't show the connections between objects, > which can lead to confusion when trying to relate parameters of actions > to the objects whose lifelines are shown on the diagram. > > Rather than try and squeeze everything into one diagram, which seems to > be the case again and again in UML, I prefer to keep concepts simple in > one diagram and the use different diagrams to visualise what they're > good at visualising. In this spirit, a technique which I use (good on > paper, though painful to do in any CASE tool) is to draw a sequence > diagram then run a filmstrip (a sequence of object diagrams, as > described in Catalysis) down the side. The filmstrip shows the changes > in state and connections between objects at any particular time; the > sequence diagram shows which messages are being passed to whom. Of > course, constructing a case tool that could do this would not be that > difficult... > > We have also been working on 3D visual notations which combines the best > of sequence and collaboration diagrams. We also use constraint diagrams > as a generalisation of object diagrams. Constraint diagrams allow you to > express general conditions on the state (as one might express in a pre > or post condition) rather than protypical examples of state, which is > the best that can be achieved with object diagrams. Take a look at the > paper at http://www.cs.ukc.ac.uk/pubs/1998/790/index.html > > I'd be interested in any comments. > > Stuart Kent > > To remove yourself from this list please mail firstname.lastname@example.org > with a message containing the word "unsubscribe".