Following this theme, I draw a ‘Domain Diagram’ as a ‘logical class diagram; in the entity modelling sense. The domain diagram only contains .’Business Objects’. which are classes that the CEO or lead business people will understand. Again, within a class, I may simplify the details, again to make it readable by the business; not just by Business Analysts, but by non technical managers and artisans. The Domain Diagram is drawn with one objective, and that is to encapsulate the Business Rules. There are 5 types of Business Rule:
1. Constraints on Classes
2. Constraints on Attributes
3. Pre-conditions on operations
4. Post-conditions on operations.
5. Constraints on the links between business objects.

I also draw use cases, but these more or less avoid the Business Rules. These describe what the user wants of the system, They are also restricted to simple concepts:
1. User (Actor)
2. Goal
3. Precondition
4. Trigger
5. Post Condition
6. Scenario (User-System interface – almost as a protocol – user does, system does.

Business Rules have a many to many association with most use cases, so sepparating them reduces many redundant use case steps. It also allows auto-matic testing, at two levels, so that when the use case is tested, it is known that the Business Rules already working.

Then analysis of the system falls down to two stages:
1. Have we covered everything that the user wnats to do (needs)
2. Have we covered all the business object contraints and rules the the Business requires, on top of the use cases.

For more detail, see my blog on the Wesite (blog) address attached. This shows how to use this approach in agile projects.

Gil

PS On the previous reply, I didn’t tick the box that notifies me of followup comments by email. Can you help here please?

I have one reservation. The title is ‘Uncovering Requirements with UML class diagrams’.

The articles give a very clear of what Classes are and how to draw and interpret them. However, this is all syntax of classes. It would have better been called ‘How to work with UML class diagrams when you begin Uncovering Requirements’.

There are a number of key semantic concepts that you clearly missed.

– A computer system should model the business that it lives in as closely as possible. Then it is more maintainable. If the users think about changes, they will often reject the big ones before asking, because they sound too complicated. If the match between business and system is bad, they may have thrown out an very simple change, without even bothering to ask. At the other end of the scale, they will fight furiously to get what is a very simple business change, even when it has been explained that the system can NOT ever support that feature without a complete rewrite.

– The class model is always morer static than the dynamic use case model. Hence, there is a stable base to use when discussing future changes to the system. It usually restricts most of the changes to just a rewrite of a use case or two and possibly an extra feature on a couple of classes. This is why, it is even more important for the classes to be a close map to the business; yet BPMN deals with only the identification and understanding of what are essentially use cases.

I like to start my business model of a system, with a class or object model of the ‘Mission Statement’ for the proposed project. It is usually stated in terms of 4 or 5 classes and some activity that they want to involve them in. This activity is then either embyonic use cases or procedures on these classes. Use cases when defined, will be implemented as application controllers, which if you think of sequence diagrams, call procedures on the classes.

So the whole mission statement can be mapped with surprising detail, for a first step, as a class diagram, with links (associations) laying out the roads that they use cases must follow. With NO controllers (use cases) identified at this stage, the busness classes will appear to link to objects that are real people; these are embryonic actors. Again, it does NOT matter whether we have just classes, or distinguish instances of classes, like identifiable people in class staff; this will sort itself very rapidly as the classes get more clearly defined.

However, the first diagram we draw can actually capture a simple view of the whole of the project to a level that the business should have really clear.

If we start with process diagrams or use cases, you may already be ahead of the business’ thinking. Even if they have thought this through a bit, I will bet that ir is more liekly to change that the simple class diagram.

Now we are beginning to ‘Uncover Requirements’. Dont forget that a few requirements lie in the goals and branch points to alternative paths in use cases. However, the classes should hold a lot more:
– invariants on the class
– constraints on the attributes
– pre-conditions on the procedures
– post conditions on the procedures, if the algorithm to be used is dictated by the business
– constraints on the associations; multiplicity, optionality, qualifiers and other constraints.

Having both use cases and classes shows where the rules fit in and gives their context. The diagrams can provide a good ‘Requirements List’ in pictorial form (worth a thousand words and al’ that!)

Gil

Just think, how long would it take you to teach this to 1000 business users?

My guess is that you would not only fail to get the concept accross, but that you would spend your life supporting the user population and never achieve a best practice library for the business.

Have a look at the video on my web site – http://www.processmaster.com

It puts everything you are doing above into a simple tool, which can be learned in a short video – and uses BPMN, which is the most suitable stencil for normal people.

And the model can be converted over to UML (or any other model) with an adaptor if needed.

You are an expert, and you do know your stuff, but educating people in this way only works for people with basic expertise – you have to go for a media solution if this is to be taken to the masses…………..even a bad video is better than a good document.

In my particular example, they have a “bad ER model” in my opinion as a technologist, because they developed a schema that does not “closely enough” (my opinion) reflect the concepts in play. I would have designed it differently. I can also see, in conversations with them about future unanticipated (but predictable) uses, that they will have to do more work to support those needs.

Reviewing a logical model of how they represent data did not provide me with insights into the uses or interpretation of the data. It provided me with insight into how their implementation was done.

I don’t necessarily disagree with you about models created for the purpose of design and implementation. I subscribe to the “many models” school, and will happily draw whatever makes the most sense in a specific situation.

I’ve been having success over the last year in using fact models to drive teams to common use of terms and language. And I’ve had success for several years in using class diagrams to validate an understanding of the domain with subject matter experts.

I’ve also seen the same thing you have, with people running screaming. :)

I do not believe that a class diagram “stands alone” but I have found it to be consistently effective when collaborating and “talking to” a diagram with SMEs.

There is one exception to that. I have included snippets of class diagrams within requirements documents to illustrate points. For example, I might show a small diagram that highlights the relationships between a sales order, an order item, and a product. This makes it much easier to express, for example, a requirement for distributing (or allocating) a discount to an order across the order items (for revenue recognition purposes).

You can certainly produce a bad ER model; or is it a generalized meta-model the vendor uses? That is handy when you can support different clients’ business without having to change the model.

…but I will take this as an answer I could expect; if class diagrams work better with the involved business people, then that is the best reason to use them. I know other people who run screaming from either type of model, but love Process Models, so you have to use what works best.

I am just saying ER diagrams are good for data, and UML is good for the software that uses the data, and people should know that. In that case, I still want to hear a good reason to use UML for data requirements over ER diagrams, other than that you can…

Dave – in addition to Roger’s citation of Wikipedia, here’s how Scott Ambler teases the two notions apart:

From the point of view of an object-oriented developer data modeling is conceptually similar to class modeling. With data modeling you identify entity types whereas with class modeling you identify classes. Data attributes are assigned to entity types just as you would assign attributes and operations to classes. There are associations between entities, similar to the associations between classes – relationships, inheritance, composition, and aggregation are all applicable concepts in data modeling.

Traditional data modeling is different from class modeling because it focuses solely on data – class models allow you to explore both the behavior and data aspects of your domain, with a data model you can only explore data issues.
Data Modeling 101, Scott Ambler

Personally, I feel that there is an important distinction between “What I’m trying to represent” and “how I’m going to represent it.” As an OO programmer, I expect significant overlap between the two, but not perfect alignment in all cases. Even though you are making a distinction between the logical and the physical data models, they are still both representations of “what” and not representations of “why.”

When using a class diagram (or, as Roger points out – a static structure diagram) for analysis, you are building a conceptual model. As Ambler also points out in his article, these can be created either before or instead of a logical data model.

I’m working with a COTS (customized off-the-shelf) software vendor right now who’s LDM does not at all represent the conceptual view of the business. This will end up being a source of additional expense for the vendor (and their clients) over time. Regardless, my current role is to validate an understanding of what the business needs – and I’m using class diagrams. The vendor is capable of translating the business view into his implementation view. The business should not be expected to translate in the opposite direction. Both the business and the vendor can utilize this class diagram to do that. Only the vendor would be able to use their logical data model.

That’s a long winded way of saying I prefer the class diagram to an ER diagram because I want to explicitly separate “This is what we need” from “Here’s how we provide it.”

Wikipedia states:

“An Entity-relationship model is used in modern database software engineering to illustrate the logical structure of a database.”

Yet, as you wrote, you can model concepts, not just database entities, in an ERD.

Similarly, though developers use class diagrams to model software classes, you can model concepts in a class diagram.

By the way, UML has shifted from calling them “class diagrams” to calling them “static structure diagrams”, precisely because they are useful for modeling more than just classes. Concepts and associations are certainly a form of static structure.

UML is great for for modeling component/OO software. Software does stuff, so a Class without operations is just simply incomplete. If you want to model data at rest, use a data model, and augment it with business rules.

(I know, I know, some people will say they prefer Class diagrams over ER diagrams when modeling data, but I have never heard a good reason why…any one got one?)

“If in doubt, make it a separate concept.” – In other words, prefer concepts over attributes.

“It is better to overspecify a conceptual model with lots of fine-grained concepts than to underspecify it.” – When there are “implied” concepts, explicitly model them.

Another important thing to recognize is that conceptual models are an explication tool.

In relation to the beginning of the post, I recall the idea of literal modelling and the book “Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML” by Jim Arlow and Ila Neustadt. They convey the idea of literal modelling and use it throughout the book to describe the business archetypes.

They also note that even a person who does not know the formality of UML will understand most of the diagrams if these have descriptive text. It sure is a powerful form of communication.