Genuine object model: Health care

Here is now my first business area abstract domain model. The target business area is generally health care. I have chosen the scope so that it will cover everything from doctor’s practice and from diagnosing through all kind of treatment, medication and other. It also includes all kind of laboratory tests and x-ray research (and similar). So to model covers the quite widely all kinds of deceases and injure treatment. This model is quite abstract (OOA) model and it will lack most of the attributes required for implementation and application around this core. On the other hand the semantics in defining and naming concepts (classes) is enough rich and if proceeded to application design and implementation the additional classes needed for the domain layer are few. The class model contains around 20 classes and almost 40 associations and one inheritance.  Here is he class diagram:

I am not completely satisfied with the current model but I would require a set of health case professional to finalize it. The things that are somewhat vague is the triangle of three events: Status, Disease and Treatment.  Another thing to keep in mind is that English is a foreign language for me and as I am not a health care professional so I don’t know how good my “translations” of concepts are.

The only collaboration that I include here is a story of two phase treatment of a sore throat.

This collaboration is lined up by three visits: 1. to doctor’s reception, 2. to laboratory 3. a phone call from the doctor to patient. The details of the story should be readable from above diagram (at latest from the animation).

Here is the StarUML-file

the same in MS-Word model for medical general practice.doc

and PowerPoint animation of collaboration diagram

All suggestion, questions and comment are appreciated.

An implementation of the domain layer is very straight forward from here.


OO domain models for several industries

I am about to start to publish OO domain models of some industries. The first model that publish is within healthcare and could be named as Heal Centre. The model will cover a group of doctors have reception. The model dynamic starts from a patient need for a doctor’s reception and it end at diagnosis, a treatment plan and possible recopies for medical treatment.

When I publish this kind of model, then it will contain the following parts:

  1. class diagram of the domain
  2. one to some collaboration diagrams describing the most essential business logic.
  3. PowerPoint animation presentation for each collaboration diagram to easy the reading of those.
  4. The abstraction level of this model is high and for instance the attributes in the classes is only a small portion of the required when implementing of any application that uses this domain.
  5. During a possible implementation the abstract analysis model should incrementally expanded to include all the necessary attributes. In most cases very few new classes are needed in this phase.

In this post I am not yet publishing the Heat Care (or any other real) model. Here I only give the form of the publication and the reasoning behind it.

I will publish here a very small toy (or tutorial) model called a BookShop to give you an example of everything that I described above.

The business that we look at here is a small bookshop in a centre of a city. The following is deliberately highly abstract model to emphasize the difference between the reality and the model. In the shop the books on the selves actually represent a publication than a copy. So our models don’t have these copies as objects in the model at all.

This way one can think that the copies represent a catalog. This way it is rather easy to sift from a real shop to internet shop. The model has first event called walk. This is the even where a person enters the shop and stars to walk around. During the walk the person pick up interesting book. This set of books are the candidates for purchase.

I use Peter Coad’s color coding. This will make it a lot easier to read. The colors are: Entity-classes green; Role-classes yellow; Description-classes blue and Event-classes pink.

Here is a collaboration diagram on what I described above.

If you have a need for a model on a specific domain then send me a proposal and let’s see can I do it for you.

Story about lost collaboration and its impact on tools

Short history of UML

When OOA & OOD had developed very rabidly from 1990 to 1994 it became evident that the overlapping OO diagram notations would severely harm the usage and the development of OO methods.  This started a process which result was to be UML. This was done mainly be three persons namely Grady Booch, Jim Rumbaugh and Ivar Jacobsson inside Rational company.

The work took more time than expected but the result was (is) good. In 1995 this team came out with UML 0.9 standard and it did indeed unify different notation dialect of OO diagrams. Important aspect to identify here is that the standard was purely Object-Oriented.

Pretty soon Rational’s Rose tool implemented this standard. The tool was (is?) very good but somewhat expensive, which is of course quite relative thing.

This was the time of OO boom and most important players like big DB- and development tool vendor  wanted to be part of this. The trouble with this was that many of these hade nothing OO to offer to this marketplace.

This mismatch was much more important than just diagram notations that UML was all about. Behind this was the whole OO to procedural antagonistic paradigms – world views.

So it meant really difficult problem for those big legacy company. On one hand they wanted to be part of the enthusiasm and the success story but on the other hand they did not fundamentally agree anything. At least the impression that I got was that at these early day OMG was supporting a clear genuine OO paradigm.

That tactic (perhaps even a planned strategy) of these legacy newcomers was “The old lesson learned”: “If you can beat them join them”. This was what happened. Immediately after this they started to demand that the methods and diagrams they had been selling have to be included in the standard too. I don’t actually know for sure but it seemed that no-one asked how these new features fitted the OO methodology. At least the fact remains that they did not at all! This way diagrams like ER-diagram, activity diagram etc. where included into ULM! This changed UML from  OO diagram notation standard to fuzzy collection of drawing standards that hade methodological common ground any more.

This crumbling of pure OO UML reached its peak at UML 2.0. The disintegration process seems to continue. This means that under the names of UML and Object Management Group for instance things like data mining and SOA has been associated to OO.  I will give you perhaps the saddest example of this:

How powerful collaboration changed to mere communication

The cornerstone of the whole OO paradigm – this also is the most important separator between OO and procedural- is the distribution of action between the participating objects! In OO we call this collaboration. (look Grady Booch: Object-Oriented Analysis and Design with Applications; Wirfs-Brook & McKean Object design; Evans: Domain Driven design etc.)

This term collaboration indicates a committed team with a common goal to achieve and distributed responsibilities. This is actually almost the only thing that makes a difference between OO and procedural.

This is why the object diagram with messages was called collaboration diagram. The naming indicated that even if the concrete elements to be seen in the diagram where messages the emphases was that these messages where not an meaningless chimps  of a small talk but a part of serious collaboration function. Now in UML 2 the name have been changed from collaboration diagram to communication diagram! I wonder if this is intentional act of crumbling of OO or an accidental result of lack of knowledge of OO. Sadly both option are fatal. When this is not understood or deliberately neglected it leads to secondary implication in the model. These changes concern the class diagram. Then the creation of business methods in the domain classes is in threat . If these are omitted then the class diagram (actually the class model) is atrophied into a disguised ER- or data model. Then there is not a single thing of the OO model left!

I am truly sad of this situation.

The usage of collaboration diagram

I am still using actively collaboration diagrams. To remind you collaboration diagram is a diagram of a scenario. Thus it consists of objects not classes. This is a fundamental difference that by the way is quite hard for part of people to distinguish. So we talk about a single case object diagram with indicated sequence of messages between objects. This describes exactly how the process goes in this single case. Here is an example of this:

Because of the nature of the collaboration diagram, it is not possible even dream of a exhausted set of a representative of all types of collaboration. This is why in practice only a few carefully selected collaboration diagrams are worthwhile drawing. These must be the deep most important business process describing the root behavior of the business. When I have very pedant people in the analyzing in many cases team these people have difficulties to accept this fact and along the way they tend to keep asking how I know that the right ones have been selected. The mental challenge is always in analyzing and developing complex system how to accept and live with some degree of uncertainty. The teaching for agile gurus however is that this reminds the only useful path and all other option –whatever they are- are far worse.

This is still one out of two diagrams that are able to describe the dynamics of OO model. The other one is sequence diagram. Technically both diagram types contains the same information so basically it is a question of taste which to choose. I like collaboration diagram, because in many cases one can have that same or similar positioning of objects that the corresponding classes have in the class diagram and secondly when one picks up a single message in the message flow one can immediately see the sender and the receiver of that message.

The impact on tools

There are two completely separate aspects about the tools. The first thing is the most agued development of software industry. Tool production has never been a gold mine but in the old days people were able to make a living on it, but for some completely incomprehensible reason the now companies are (or have to) distributing the result of work for free. My commonsense of economy cannot solve this equation, how on earth this real work effort is financed or are we drifting in the medieval patron type of financing of arts. This will finally move the control of the direction of development into the hands of money.

The second aspect is this OMG standards that will eventually push the tools into it. From my point of view there was actually a time when Rational Rose was good but expensive. IBM acquired Rational and OMG expanded the standard most of tools did not offer as good functionality when drawing collaboration digammas. Currently I am using both MagicDraw and StarUML. Neither of these serves me well, but I can live with them.

Ideal UML and tool

The things that are lacking in current collaboration diagrams are: convenient and systematic way to show attribute values at the time of receiving message. This becomes complex when an object receives more than one message during the message flow.

But I have an idea of ideal OO tool (ME -> modeling environment). I have written first short article on 3-dimensional class diagrams. I still consider than a fascinating option. When today with 2D class diagrams we are able to read up to 70 -100 classes in one diagram. These could “easily” double the max size of single diagram and at the same time add semantics.

Collaboration –as they are processes- they should be able to show the timeline rather than just to the end state. At some point of time Rose had and collaboration animation feature and this would be a must also today.