29 August 2006 - 18:33Communication thru UML

I am reading Martin Fowler’s UML Distilled and I am going over his introduction to use cases. So far it looks like use cases are one point where domain experts and developers come together and is the main interaction between them. Basically, the domain experts communicate the behaviour of the system to the system architect which can extract from it an essence which can further be abstracted into collaboration diagrams, class diagrams, etc… A conceptual domain model is built and supposedly from this domain model you can start drawing collaboration diagrams and the rest.
This doesn’t get even close to the complexity of the business logic. It is just so simplistic. One other “great” way to “model” a business was to treat nouns as classes and verbs as methods. I don’t know why, but to me it sounds like medieval witch-craft. This packaging of information so that it fits inside a developer’s head is atrocious. It probably works with someone that has some knowledge of the business, but it doesn’t work with someone that is just entering the business. It is simplistic to assume that the ramp-up time for getting into a domain can be obviated by some collaboration diagrams. You have to know what you model, and you have to know it very well before starting to design.

Let’s take an architect that spent the last 10 years architecting video games. It probably has its head filled with design patterns, UML diagrams, tricks, frameworks, etc… that enable it to do his job very well. Suppose that the same person is given the task of designing an application in the insurance industry. After collecting a mountain of use cases will it be able to see points of change in the application he’s building, will it be able to abstract the business process that it is implementing so that the application changes easily as the business process changes itself? I’d be surprised. That architect will go thru its collection of use cases and come up with a platform independent model and from it design the whole application. And he will probably fail to capture quite a few assumptions that the domain expert takes for granted and create a system that deviates from the original intent. It would have to adapt itself to the domain and then start to make some assumption about it in order to model it better.

UML can be used as a tool for communication between the business analysts and developers, but we should not expect too much from this tool. I think that the potential for errors and the noise is pretty big for this communication channel. Once things start to get complex these diagrams will not be able to translate efficiently the process described by the domain owners to the system architect. Instead of relying on various meetings with the business analysts, the architect should be able to understand the process, should be able to ask question meaningful to the business owners about the process that it is implementing and then it should start modeling it. It would help a lot if the business analysts would have some sort of a manual that distils the business and that the system architect can read before engaging with them.
I, for one, treat use cases and collaboration diagrams mostly as documentation needed for bringing a developer on board, rather than a way to pull information out of a domain.

As a final note I would say that the ability to adapt to a new environment is becoming a requirement for a developer. In order to be able for a developer to function efficiently across a wide array of industries that developer should learn how to adapt to a new business environment, and pretty easily. A developer should scratch beyond the surface of a industry in order to make meaningful decisions.

P.S. I’ll give an example from my experience.
I was designing an e-commerce application that had to support multiple customers and had to be industry-agnostic. What was the functionality that was most prone to change from one customer to another and which had to be abstracted first? Navigation? Layout? No. It was/is the prices. Every customer has its internal pricing structure (tiered, contract-based, rebates, etc…) that has to be reflected in the application. I learned it the hard-way, and it is a valuable lesson. When I designed a B2B application the first interface that I wrote was the interface for handling prices because this was one piece of functionality that I knew the customer cared about and that was prone to change. Do you think that this need ever transpired from the various interactions I had with the customers and various use cases I walked thru? No. The prices were the functionality that were the most prone to change and there was nothing out there to tell me that, most customers would assume that their price schema is what everyone is using. It was the interaction with quite a few customers that showed me that what is really prone to change is the pricing module.
P.P.S. In the above application the next thing that had to be abstracted was the interaction with their back-office systems, but it is a lot more obvious that it has to be abstracted.