Data Modelling & Object Oriented Development

Hi:

One of the overwhelming temptations that BA's face is a strong desire to short-cut requirements analysis and get on with design. Result: Incomplete requirements.

The fact that Business Analysis is about analyzing businesses - and not about application design - often gets lost.

Why should a BA choose to use an OOD (D for development) technique in performing the analysis of a businesses data?

Tony

Hi Tony,

You're quite right - analysis should be divorced from design - in an ideal world. However sometimes you need to bend with the wind and if it's an OO project then the analyst needs to show developers how logical data models apply to their world. I think the skill of a good analyst is to have a variety of tools they can call on and use the one most applicable to their audience.

Regards....Jan@IRM

Hi -

This article addresses a critical topic, and it - and the above comment / response - raise important questions.

First, a couple of complaints about the article.

- One of my bugbears in writing about this kind of stuff is poor examples that obfuscate rather than clarifying. The "Vehicle" example I think falls into this category. (I can elaborate if you want, but I hope I don't have to.) Doesn't help!

- Are the differences between the cardinalities / multiplicities in the diagram in Sect 3 intentional? (at the Customer end, 1..1 in the Class Diagram, 1:M in the Data Model). Needs to be consistent or the inconsistency explained. Again, doesn't help.

- In Sect 5, the Data Model could (should?) show the same attributes as the Class diagram - why don't they? Is there an implication that they shouldn't be shown on the Data Model? (And can we please use the correct terminology for the parts of the Class "box" - ie. compartments - not "layers", which frequently has a very different meaning in systems development?)

- In Sect 6, you say "The data in a class diagram is organised according to the needs of the class’s operations or processes, not by the natural structure of the data." I'd say that these are one and the same thing - a good Class model will be normalised just like a good Data Model.

- Again in Sect 6, you imply that resolving a M:M relationship of itself somehow creates extra work by requiring additional coding. But if there's a M:M relationship, the complexity will have to be handled either by one or (even worse) both of the related classes, or we'll introduce an Association Class, which amounts to the same thing.

And a couple of thoughts on Tony's previous comment, and Jan@IRM's response:

- Business Analysis is certainly about analysing businesses, but that's not all. If the BAs on my team said: "There, I've analysed the business - now get on with the design" - in essence, chucking the "analysis" over the wall to the "designer" - I'd be very upset. They absolutely need to get involved in the transition to design (and development, and testing, and support ...).

- The techniques described in the article are certainly not just applicable to development. OK, they may have originated with software design and development, but they are most certainly applicable to getting and sharing a full understanding and description of the business. An analyst who doesn't understand the core concepts in the business domain, and their structure - which is in essence what both these techniques express - is missing at least half the story. I'd agree that by the time we're adding operations to a Class diagram, we're moving pretty well into the area of software design, but having a BA who can work with the models throughout that transition in invaluable.

- And to continue on that theme - Jan@IRM suggests that this is "bending with the wind" and applicable only to OO projects. Analysts need to work with developers to ensure that both have the same understanding of the business concepts whatever the technical development environment.

And a merry Christmas to you all!

The criticism is interesting but misses the concepts the article is designed to explain. Let's take them one at a time:

There is a have a bugbear about the Vehicle example. Maybe we should use the one used by Grady Booch et al in the UML User Guide v2.0 which uses a "Motor" which is a class with two sub-classes called "SteeringMotor" and "MainMotor". Is there some difference here?

In section 3 we have to concede a typo in that one of the cardinalities does not match the equivalent multiplicity, for which we apologise.

In section 5 the reason the attributes are not shown at all in the ERD is due to a difference in the standards between ERDs and class diagrams. The data modelling standard is to show either all or no attributes because the entities are structural not just abstractions of the data. Class Diagrams can show none, all or some of the attributes depending upon which ones are relevant to the specific view. Class Diagrams show only a specific view and only a collection generally shows the complete view. This is not true of ERDs.

The comments in section 6 are just plain wrong. The whole point of data modelling is to analyse the structure of the data without any reference to the operations or processes. ERDs were invented partly to achieve that separation. ERDs and class diagrams are not the same thing.

Structured analysis and relational database design which did not come from OOD are predicated upon the separation of data and processes in the early stages of analysis and early stages of physical database design. Normalisation is a mathematically proven technique for designing databases where the data not the processes is involved. It cannot be done in a class diagram. Rules of relational algebra must apply.

In the UML User Guide Grady Booch et al state that logical database schemas can be represented in class diagrams under certain conditions, and these are their words:
"define stereotypes and tagged values to address database specific details"
"specify details of attributes and focusing on the associations and their multiplicities".
"expanding operations that are important for data access and data integrity"
My favourite is "business rules concerned with the manipulation of sets of these objects should be encapsulated in a layer above these persistent classes". In other words Booch et al themselves agree that we must separate the processing from the data first.

The scope of UML is stated as follows in the user guide:
"Logical Database Design is beyond the scope of this book. The focus here is simply to show how you can model schemas using the UML". OK so we MUST use structured analysis and design and relational database design to design databases NOT UML. Booch et al specifically put UML out of this area. The point of the article is to clarify this.

The article is about data modelling not OOD. It therefore avoids the class diagram terminology except when parts are being compared such as cardinality v multiplicity. Well OK lets translate.
Let's take the word box and translate it into UML using a quote from the user guide:
"Graphically, a class is rendered as a rectangle".

The word layer in the ERD and Class Diagram context has no meaning. It is used here as a non-technical English word. I believe there are some OOD authors that have used the same word in the initial introduction describing classes although I would have to confirm that.

Whether the introduction of a new association class causes more work or not depends upon the individual application, the company, team and individuals involved. We can only talk here about what should be expected. As a rule of thumb the number of programs is often taken by project managers as a rough guide in estimating the effort for a project and usually, more programs is taken to means more work.

The article does not recommend that there be a wall between analysis and design - BAs should be involved in supporting the design. However, there is often a separation in place in some large organisations. This can occur when design is outsourced, possibly overseas, and the internal analysis is provided to the vendor. We are simply saying that if class diagrams are used to model data for use in a future database, their use can only be taken so far. It should stop where Booch et al and UML says they should stop. It should stop where structured analysis and design and relational modelling says they should stop. I infer from Booch et al that class diagrams should not be used to normalise data structures.

In the user guide Booch et al state that "class diagrams have a clear mapping to all industry strength object-oriented languages...and a variety of commercial object-based languages, such as Visual Basic". There is no mention of SQL in the list. My final question is why would BAs or designers not use ERDs or data structure diagrams for relational database design which do have a clear mapping to SQL? Their automated tools also often support SQL for automatic generation of the DDL. They also support the separation of business rules into another layer.

Happy New Year - I'm pleased the article has generated some debate and offers food for further thought.

(Posted by Jan@IRM on behalf of the article author who is on an extended fishing holiday !!).