There are three levels of healthcare provided to rural populations: Sub Centers and Primary Health Centers provide primary care and Community Health Centers provide basic secondary care. The following model depicts the population guidelines that govern the formation of these rural health care centers. We have also included some statistical information in the model in the form of some Notes and the Village class.

Rural Healthcare System in India

A Sub Center is the most peripheral and first point of contact for the rural population with the public health system. The following models the staffing of a Sub Center:

Sub Center Staffing Model

A Primary Health Center provides an integrated curative and preventive healthcare to the rural population. The following models the staffing of a Primary Health Center:

Primary Health Center Staffing Model

A Community Health Center provides basic secondary care to the rural population including surgical intervention. The following models the staffing of a Community Health Center:

Community Health Center Staffing Model

As always, a picture is worth a thousand words!

First, the class model of the various field formations of the Indian Army:

Next a use case diagram (containing only actors) showing the various designations:

Finally, a structure diagram which emphasizes the hierarchical nature of the field formations and the reporting:

While the TEC web site uses a tree control to allow users to navigate through the capabilities of ERP software, my interest is in creating a UML representation of the same. Here is what I came up with:

I do not have the patience to create the 3000+ use cases that reside in these many packages, but if someone is looking for what is broadly in the scope of the term “enterprise resource planning”, this diagram is very illuminating.

As a result, while deployment diagrams are very expressive when it comes to portraying devices and nested execution environment and deployed artifacts, when it comes to showing connectivity between devices, they fall short.

After living with this problem for a long time (I pretty much stopped illustrating connectivity between devices), I hit upon the simple idea of modeling a “bus” / LAN / “high-speed backbone” as a node (not a device). This way, I am now able to connect multiple devices to this “bus” / LAN / “high-speed backbone”!

Here is an example of what I mean:

Alternately, imagine all the crisscrossing lines that will be needed to depict this same connectivity using communication paths and you will see why this model is a great improvement!

It is tempting to think of this node as a physical router / switch, but I refrain from doing that because a typical LAN is made up of more than one single router / switch. Hence this node is really modeling a collection of hardware and cables that go into a “bus” / LAN / “high-speed backbone” (this is why I did not model this as a device).

Strictly speaking, this node is not all right. You cannot deploy anything in it. Nothing executes on it. It is not a device; not an execution environment. It just carries signals back and forth which is not the semantics associated with a node in UML. But, until UML comes up with a better way to represent a “bus” / LAN / “high-speed backbone”, I am sticking with this, albeit inaccurate,  invention.

The following package diagram represents a typical model organization that I have found useful in the J2EE space:

All deployment diagrams are inside the Topology package with each of the sub-packages containing the deployment diagram for a particular environment.

Each of these deployment diagrams is built using instances of devices, execution environments and artifacts that are present in the Nodes and Artifacts packages. In other words, while the definitions of devices, execution environments and artifacts reside in the Nodes and Artifacts packages, instances of these will reside in the individual “environment” packages along with the deployment diagram for that environment.

The Nodes package is organized as Devices (the hardware) and Execution Environments (the infrastructure software). The one unlabeled device models a high-speed LAN (more on this in my next post).

The Artifacts package is organized as Framework Artifacts (which manifest popular pre-built components) and Application Artifacts (which manifest custom-built components).

The recommended order of creation of these packages is as follows:

• Define all your devices and execution environment first with appropriate tagged values to describe their various characteristics.
• Define all your artifacts next. These are the various code components that you have built (dll, jar files, cab files, XML files, whatever) as well as any pre-built frameworks that you have used in your custom-built code.
• Finally, proceed to define each of the environments. Drag and drop devices, execution environments and artifacts to create new instances of these in your deployment diagram. Change the tagged values appropriately to represent that particular environment accurately (for example, a production environment device is likely to have much more CPU and memory than a corresponding integration environment device).

In summary, deployment diagrams use instances of nodes and artifacts. Hence you need to define nodes and artifacts first, and then create instances of those. Also, typical software systems require multiple deployment diagrams – for instance, one for each environment. This leads to a proliferation of instances. Hence, it is advisable to keep the definitions separate from the instances. That is what this deployment model structure is attempting to do.

But this post is not about UML diagrams.

This connection between drivers and decisions is not unique to software development. Here is an interesting example from the the British Everest expedition of 1953 that put Edmund Hillary and Tenzing Norgay on top of Mount Everest:

Appendix A to Basis for Planning

EVEREST, 1953

THE ASCENT

1. From a study of the Shipton reconnaissance, the Swiss premonsoon attempt and from a general comparison of the latter with the British experience on the mountain between the wars, certain factors emerge which must influence our planning for 1953.

FACTORS

2. The absolute need for a sufficient period of comparative acclimatization before the assault
3. The psychological effects of remaining longer on the mountain than is really necessary to the achievement of success.
4. The physiological deterioration which appears to take effect high up on the mountain.
5. The limitations on the amount of stores and equipment which can justifiably be carried high on the mountain. These limitations are set by:

1. the objective dangers of the icefall;
2. the weight which can be carried by the porters and climbers at high altitudes;
3. the number of oxygen equipments available;
4. the time factor, as it affects paragraphs 3 and 5 (a) above.

6. The importance of a suitable and acceptable diet, together with that of ensuring the consumption of sufficient liquid during the crucial assault period.
7. The duration and period of favorable weather. This is likely to be very brief and to occur in the second half of May, or early in June.
8. The importance of exploiting this favorable period to the maximum extent. This means:

1. being positioned and ready in every sense to start the assault from the beginning of this period.
2. being so organized as to be able to continue the assault, if necessary, so long as the weather holds; in other words, to avoid the contingency of a premature retreat

CONCLUSIONS

9. From these factors it is possible to establish certain conclusions which will form the basis of the planning. (Scientific conclusions are not dealt with under this heading.)

1. There must be an acclimatization period, which should be spent in an area other than Everest.
2. Once the Base Camp has been established, the ascent of the mountain must be a continuous process, carefully planned so as to be completed in the minimum time consistent with success.
3. There must be provision in the plan for a number of assaults, each capable of being launched consecutively at intervals of one day, if the weather conditions allow. A maximum potential of three such assaults should be assumed.
4. Adequate logistic support must be provided in the highest camp(s) to enable the summit party(ies) to make the most of their opportunity.
5. The first assault party and, as far as possible, the follow-up parties, must be rested and in good condition when they start. They must, therefore, be spared the heavy work at an early stage in the build-up.

10. The Climbing Party.
The party must be large enough to make possible the series of assaults referred to above, and at the same time to allow for sickness and provide for supervision of the build-up behind the assault.
On the other hand, it must not be so large as to become unwieldy.
To achieve a potential of three assaults, a total of ten climbers has been decided. These may be considered for planning purposes in the ratio of 6 (assault) to 4 (support). To the latter should be added the physiologist and the photographer who may be expected to take their share in the build-up.
11. The Porter Requirement.
The porters may be considered in three categories:

1. Those taking part in the establishment of Advance Base (Head of S.W. Cwm).
2. Those taking part in the establishment of the Assault Camp (South Col).
3. Those taking part in the assault.

To some extent, these categories will overlap, e.g., all porters will be involved to a greater or lesser degree in establishing Advance Base; certain porters required to establish the Assault Camp may take part in the assault.
Taking into account a rough calculation of the load factors, the timetable at Appendix C and the intention to launch, if necessary, three assaults, it may be estimated that 25-30 Sherpas will be required. Of these, at least 16 must be capable and willing to take part in the assaults and the establishment of a camp on the South Col; they must, therefore, be equipped on this basis. 

– Appendix A to Basis for Planning, The Ascent of Everest, John Hunt

Another interesting point to note: these guys were not very Agile, were they? A document called Basis for Planning is bad enough; not to mention an appendix to it!

Do you thing these guys “welcomed change” like the Agilists do? I suspect not. They simply dealt with the inevitable change. This is where Agile methodologies go wrong. You do not welcome change. You have to deal with change the right way.

DLF Business Units

If you are proficient with modeling, you will immediately see this a nothing but a class model!

I continued reading through that report and finally derived the following model of their business:

DLF Business Units - Class Model

Quite a large business and I am not sure I got it entirely right. Further, each individual hotel / home / office construction is constituted as a separate company (DLF has 243 subsidiary companies)! I have not even attempted to model that – I have stopped with business units and joint ventures.

Why attempt such a model at all? You should ask that question to the guys from Ramco whose Ramco ERP is the ERP platform for DLF!

Conventional wisdom as articulated in various books [Use Cases: Patterns and Blueprints] and articles [Use and Abuse Cases] argues that functional decomposition of use cases to derive smaller, more fine grained use cases is bad, if taken too far. Most literature is concerned with preventing the “explosion” of use cases.

How far is too far? What is “explosion”? The answers to these questions are tied to another question – “what do you intend to do with your use cases?”

In my experience, I need my use cases to be detailed enough to support the following three goals:

• Need to help me in forming a reasonable estimate of the effort and time-line required to implement the functionality
• Need to help me in scheduling and tracking the progress of the implementation of the functionality
• Need to help me in various aspects of testing the functionality – writing test cases, as well as scheduling and tracking the testing processes

Consider the estimation part.

The Use Case Point methodology was proposed by Gustav Karner [download original paper] way back in 1993. It hinges on associating a complexity rating to each use case and then adjusting the total use case points to technology and environment variances. The complexity rating is a simple three point scale of simple, average and complex.

Now consider a coarse grained use case model. Even if you rate all use cases as complex, you will still likely under-estimate. On the other had, consider a very fine grained use case model. Even if you rate all use cases a simple, you will still likely over-estimate the effort.

The right balance will be to arrive at a set of use cases that capture every significant piece of functionality that is likely to keep designers, developers and tester busy.

The natural approach is to start with a few coarse grained use cases, and then start decomposing them functionally. Stop when you get to a stage where you feel you can confidently assign simple / average / complex to a use case and feel you are not under or over stating the complexity.

Modern modeling tools support the UCP Estimation methodology and can derive effort estimates from a use case model at the click of a button [screen shot from Enterprise Architect] but these tools can only be as good as the inputs they work on. And the key input is not just the complexity rating of each case, but also the granularity of the use cases themselves.

Let us now turn our attention to the scheduling and tracking part (of both programming and testing).

Given that we have created a laundry list of use cases, it is only natural that we schedule and track implementation progress using these use cases. This implies that every use case becomes a summary task in a project management tool with sub-tasks for detailed design, programming, unit test preparation, and unit testing. People will be assigned to each of these tasks and progress tracked periodically until percentage completion reaches 100%.

A coarse grained use case could well result in fifteen people being assigned to the programming sub-task for three months! This is clearly unsuitable for progress tracking and needs to be broken down into smaller use cases. A fine grained use case could result in one fourth of a person being assigned for two hours to each programming sub-task! This clearly makes the project schedule unmanageable.

From this perspective, if a use case maps to one or maximum two screens of the user interface, then the granularity will typically be OK. It is meaningful to assign that use case (and those screens) to a developer (and a testers) and track the progress.

What if there are no screens and we are dealing with a batch process? Well, in that case the use case methodology itself will not apply too well. A use case is always concerned with value delivered to end users and a  batch process does not service a end user!

When identifying use cases, is a system analyst in a position to envisage how many screens will be needed to realize that use case? Certainly yes. The analyst many not know exactly how many data fields and action buttons will be needed on each screen, but he/she will certainly know enough to judge how many screens will be needed.

Does this mean the use case now becomes a UI specification? No, while the system analyst envisages the number of screens required, he does not actually draw the screens at this time. That is a task for specialist UI designers to take up at a later point in time.

To make us for that lacuna, I model a current hot topic using UML object diagrams.

This month has been one of tremendous flux and turbulence in the global financial sector. Lehman Brothers has gone under and been subsequently dismembered and sold to Barclays and Nomura Holdings. Merrill Lynch was snapped up by Bank of America. In Europe, a series of consolidations have happened without much fanfare.

Is it possible to depict who-acquired-who using UML?

First, I modeled the financial institutions using the following simple model:

Financial Sector Model

With this model in place, I proceeded to model each financial institution and indicate who-acquired-who by means of composition relationships. I further filled-in values for the attributes (capital raised, writedown & loss) in billions of US Dollars (data sourced from Bloomberg). Finally, I linked (in UML a link is an instance of an association) the acquiring companies to their appropriate region of primary ownership.

Here is the final result:

Financial Sector Acquisitions

Of course I can nest the acquired company inside the acquiring company, but that would look very like a composite structure diagram, which I have already covered elsewhere.