Skip to content

Use Cases and Database Modeling — An interview with Michael Blaha.

by Roberto V. Zicari on January 9, 2012

“ Use cases are rote work. The developer listens to business experts and slavishly write what they hear. There is little interpretation and no abstraction. There is little reconciliation of conflicting use cases. For a database project, the conceptual data model is a much more important software engineering contribution than use cases.“ — Dr. Michael Blaha.

First of all let me wish you a Happy, Healthy and Successful 2012!

I am coming back to discuss with our expert Dr. Michael Blaha, the topic of Database Modeling. In a previous interview we looked at the issue of “How good is UML for Database Design”?

Now, we look at Use Cases and discuss how good are they for Database Modeling. Hope you`ll find the interview interesting. I encourage the community to post comments.


Q1. How are requirements taken into accounts when performing data base modeling in the daily praxis? What are the common problems and pitfalls?

Michael Blaha: Software development approaches vary widely. I’ve seen organizations use the following techniques for capturing requirements (listed in random order).

— Preparation of use cases.
— Preparation of requirements documents.
— Representation and explanation via a conceptual data model.
— Representation and explanation via prototyping.
— Haphazard approach. Just start writing code.

General issues include
— the amount of time required to capture requirements,
— missing requirements (requirements that are never mentioned)
— forgotten requirements (requirements that are mentioned but then forgotten)
— bogus requirements (requirements that are not germane to the business needs or that needlessly reach into design)
— incomplete understanding (requirements that are contradictory or misunderstood)

Q2. What is a use case?

Michael Blaha: A use case is a piece of functionality that a system provides to its users. A use case describes how a system interacts with outside actors.

Q3. What are the advantages of use cases?

Michael Blaha:
— Use cases lead to written documentation of requirements.
— They are intuitive to business specialists.
— Use cases are easy for developers to understand.
— They enable aspects of system functionality to be enumerated and managed.
— They include error cases.
— They let consulting shops bill many hours for low-skilled personnel.
(This is a cynical view, but I believe this is a major reason for some of the current practice.)

Q4. What are the disadvantages of use cases?

Michael Blaha:
— They are very time consuming. It takes much time to write them down. It takes much time to interview business experts (time that is often unavailable).

— Use cases are just one aspect of requirements. Other aspects should also be considered, such as existing documentation and
artifacts from related software. Many developers obsess on use cases and forget to look for other requirement sources.

— Use cases are rote work. The developer listens to business experts and slavishly write what they hear. There is little interpretation and no abstraction. There is little reconciliation of conflicting use cases.

— I have yet to see benefit from use case diagramming. I have yet to see significant benefit from use case structuring.

— In my opinion, use cases have been overhyped by marketeers.

Q5. How are use cases typically used in practice for database projects?

Michael Blaha: To capture requirements. It is OK to capture detailed requirements with use cases, but they should be
subservient to the class model. The class model defines the domain of discourse that use cases can then reference.

For database applications it is much inferior to start with use cases and afterwards construct a class model. Database applications, in particular, need a data approach and not a process approach.

It is ironic that use cases have arisen from the object-oriented community. Note that OO programming languages define a class structure to which logic is attached. So it is odd that use cases put process first and defer attention to data structure.

Q6. A possible alternative approach to data modeling is to write use cases first, then identifying the subsystems and components, and finally identifying the database schema. Do you agree with this?

Michael Blaha: This is a popular approach. No I do not agree with it. I strongly disagree.
For a database project, the conceptual data model is a much more important software engineering contribution than use cases.

Only when the conceptual model is well understood can use cases be fully understood and reconciled. Only then can developers integrate use cases and abstract their content into a form suitable for building a quality software product.

Q7. Many requirements and the design to satisfy those requirements are normally done with programming, not just schema. Do you agree with this? How do you handle this with use cases?

Michael Blaha: Databases provide a powerful language, but most do not provide a complete language.

The SQL language of relational databases is far from complete and some other language must be used to express full functionality.

OO databases are better in this regard. Since OO databases integrate a programming language with a persistence mechanism they inherently offer a full language for expressing functionality.

Use cases target functionality and functionality alone. Use cases, by their nature, do not pay attention to data structure.

Q8. Do you need to use UML for use cases?

Michael Blaha: No. The idea of use cases are valuable if used properly (in conjunction with data and normally subservient to data).

In my opinion, UML use case diagrams are a waste of time. They don’t add clarity. They add bulk and consume time.

Q9. Are there any suitable tools around to help the process of creating use cases for database design? If yes, how good are they?

Michael Blaha: Well, it’s clear by now that I don’t think much of use case diagrams. I think a textual approach is OK and there are probably requirement tools to manage such text, but I am unfamiliar with the product space.

Q10. Use case methods of design are usually applied to object-oriented models. Do you use use cases when working with an object database?

Michael Blaha: I would argue not. Most object-oriented languages put data first. First develop the data structure and then attach methods to the structure. Use cases are the opposite of this. They put functionality first.

Q11. Can you use use cases as a design method for relational databases, NoSQL databases, graph databases as well? And if yes how?

Michael Blaha: Not reasonably. I guess developers can force fit any technique and try to claim success.

To be realistic, traditional database developers (relational databases) are already resistant (for cultural reasons) to object-oriented jargon/style and the UML. When I show them that the UML class model is really just an ER model and fits in nicely with database conceptualization, they acknowledge my point, but it is still a foreign culture.

I don’t see how use cases have much to offer for NoSQL and graph databases.

Q12. So if you don’t have use cases, how do you address functionality when building database applications?

Michael Blaha: I strongly favor the technique of interactive conceptual data modeling. I get the various business and
technical constituencies in the same room and construct a UML class model live in front of them as we explore their business needs and scope. Of course, the business people articulate their needs in terms of use cases. But theuse cases are grounded by the evolving UML class model defining the domain of discourse. Normally I have my hands full with managing the meeting and constructing a class model in front of them. I don’t have time to explicitly capture the use cases (though I am appreciative if someone else volunteers for that task).

However, I fully consider the use cases by playing them against the evolving model. Of course as I consider use cases relative to the class model, I am reconciling the use cases. I am also considering abstraction as I construct the class model and consequently causing the business experts to do more abstraction in formulating their use case business requirements.

I have built class models this way many times before and it works great. Some developers are shocked at how well it can work.

Michael Blaha is a partner at Modelsoft Consulting Corporation.
Dr. Blaha is recognized as one of the world’s leading authorities on databases and data modeling. He has more than 25 years of experience as a consultant and trainer in conceiving, architecting, modeling, designing, and tuning databases for dozens of major organizations around the world. He has authored six U.S. patents, six books, and many papers. Dr. Blaha received his doctorate from Washington University in St. Louis and is an alumnus of GE Global Research in Schenectady, New York.

Related Posts

– How good is UML for Database Design? Interview with Michael Blaha.

– Agile data modeling and databases.>

– Why Patterns of Data Modeling?

Related Resources Databases in General: Blog Posts | Free Software | Articles and Presentations| Lecture Notes | Journals |


From → Uncategorized

10 Comments Leave one →
  1. With regard to, “Use cases are rote work. The developer listens to business experts and slavishly write what they hear. There is little interpretation and no abstraction. There is little reconciliation of conflicting use cases.” If this is how Michael does use case modelling, then he is doing it wrong, he will get very poor results, and I can fully understand why he thinks so little of the approach.

  2. Having two different roles/persons make the structural model and the UC descriptions is an efficient practice. In many projects, their coupling is misunderstood and overemphasized. IMO, it’s interesting later, and evolves naturally, as we move on from structure to entity life cycles and to interactions of entities.
    Parallell progress on both clarifies vocabulary, context, ontology – which can be leveraged both in structure and in UC descriptions.

    Primarily, UCs are not about SW, OO, or DBs. They’re a black-box description of interactivity and HMI (no matter if the coming solution inside the black box employs HW, SW, or say, optics and mechanics). They’re powerful on external interactions, whereas inside the black box (system or subsystem), they make a very low-skill substitute for better suited modelling techniques; “Over-Use Cases”…

    A vital architectural tradeoff is having reusable, general Data and SW components cater for many specific UCs; functional configurators quickly find the optimal fit here (unfortunately, very rarely within the SW industry itself 🙂 and they embody the mapping of functional requirements onto a product architecture (also historically, in the AXE architecture at Ericsson decades ago, UCs complemented a consistent internal architecture – not replaced it).

  3. Michael Blaha permalink

    Regarding Jim Arlow’s comments… This is what I see others do. I’m a consultant and see lots of projects. There’s no way that a developer can do deep conceptual data modeling while in the world of use cases. OO languages are built about data structure. Procedural languages are built about process. Use cases emphasize process which is odd when the eventual target is OO.

    Regarding Milan Kratochvil’s comments… I agree with this. I have worked on projects where I did the data modeling and someone else did use cases and we worked together. This works well.

  4. In the beginning of a project developers and users speak two different and unaligned languages: Developers speak “conceptual data model” and users speak “use case”. When this work is done they don’t test their artefacts but rush off to create code (manually or mechanically).
    I remember that Michael said “For relational database projects, I first construct an object-oriented model, then re-enter the design into a relational database tool, and finally generate the database schema.”
    I would like to talk about use cases first – I mean uses cases user really use: These are descriptions (specimens) of the data they exchange with a system (reports, screens) or with another person. These descriptions contain sometimes explanations in form of sentences (object predicate subject and properties). (The customer delivers the order to the agent for immediate signature and acceptance). My argument: User use more or less arbitrary names for entities, relationships (predicates) and attributes. They do so because there is no agreed dictionary which contains the important “terms” and a description of the terms. Zachman has in his framework in the first line of the data column a “list of things important to the business”. In an older version he spoke even of a glossary.
    OK, if we provide the users with such a glossary and we teach and pester them to stick to this glossary we would certainly get leaner and more precise descriptions. If we provide the users with examples of the outputs with sample data (from their domain) they would look very carefully whether we really understood what they want.
    The glossary is a condensed form of the terms used in the data models. But where does the content of the data models (terms) come from? Is it imagination or is it the first drafts of the user requirements and use cases? There is obviously no first or last – it is a process which step by step creates the glossary, the data model and congruent “Use Cases”.
    There is still a problem which is completely unresolved – testing. The question is not “how do you test your data model?” – the question is “Can you afford to produce one of the most important artifacts of development without properly testing it?”
    Peter Chen and Jose Blakelet met for a video conference (a must see!) “”. Peter Chen said that the ER-Model is now established as the de facto standard for conceptual data models – and he continued that we need “an executable conceptual model” (his words!). With an executable conceptual model we would be in a position to test our data models against the gruesome reality of test data. A friend of mine used to say: Data modeling is like drawing a map from memory. At some point you must go out into the landscape: If you come to a river and the map says that there is a bridge, but reality says “no bridge” – trust reality and change the map.
    Ok it seems to be a good idea to get whatever we can from reality (testdata), test it against the data model (or vice versa). Then we could certainly find whether our model can store what the user wants to have stored and that we can produce Output-Specimens (with his data) to verify wether ge gets what he needs.
    In a nutshell – the only way to achieve the use of a strict congruent language for both sides the users and the developers is the daily fight against sloppy speak. The tool is called glossary, conceptual data model and test, test, test.
    If you are still reading and don’t disagree too much than we can tackle the problem of the tools to resolve the dilemma how to test a conceptual data model and to do it even BEFORE the implementation has started. The answer is – use an executable conceptual model, provide users with tools to load test data manually or from files or Excel sheets (!), to inspect the data and to create decent reports (BIRT is extremely helpful).
    Jose Blakely is completely right when he says (in the video) that the existing eco-System of relational databases is a huge asset and a first step like the entity framework is a step in the right direction. No objection. But the big fun with is that we can think and chat also about what could be and what would be fine and eventually will become reality – thanks to Roberto.

  5. Michael Blaha permalink

    I had private correspondence with Peretz Shoval. His papers “Class Diagrams and Use Cases – Experimental Examination of the Preferred Order of Modeling” and “Data Modeling or Functional Modeling – Which Comes First? An Experimental Comparison” are germane to this discussion. In these papers he poses hypotheses, collects experimental data, and seeks objective insight.

    When I build software I start by constructing the class model. Of course, users often talk in terms of use cases and I let them do so. I listen and during live interaction with an audience fold the effects of their comments into the class model. I can do much of the abstraction on the spot. I seldom explicitly document the use cases. (I have my hands full running the meeting and thinking intensely about the class model.) If there is another person available to record the use cases that are articulated that can be helpful, especially for a complex project.

    It’s also important that I explicitly announce my bias. I work with information systems, that is databased applications. I don’t have much experience with real-time software, AI software, etc. Maybe for these non-databased applications it might be better to start with use cases — I’m not sure and would prefer not to reach beyond my experience.

    Nevertheless information systems are clearly the predominant applications that occur in industry. I don’t have hard numbers, but I would guess that 80% of the applications that are constructed are information systems. So a bias towards databased applications is less of a problem that it might appear at first glance.

  6. Peretz Shoval permalink

    Michael mentioned in his last comment two of my papers that reported about experiments I’ve conducted (with colleagues) on the issue “Data modeling or functional modeling – which comes first?” In those studies we have examined the correctness of the functional and the data models created by analysts when working in the opposing orders. In one of the experiments we used class diagrams for data modeling and UML use cases for functional modeling; in the other we used class diagrams and OO-DFDs (a variant of traditional DFDs that include data classes rather than data-stores). The results of the two independent experiments where consistent: that the data model is of much better quality (more correct) when created before the functional model. But (surprisingly), there was no significant difference in the qualities of the functional models. (More details and findings can be read in those papers.)

    In my opinion, there is an advantage in creating the data model first, because this task is simpler compared to the task of functional modeling; it is better to solve the simpler problem first. Moreover, once you have the data model, it can ease overcoming the more complex task of creating the functional model, because in functional modeling you still need to deal with data aspects, i.e. which data/objects are needed by the various functions.

    Regarding use cases: they seem to be easy to create, but what does a use case diagram mean/include? merely a bubble with a name, and actors who are assumed to interact with the use case. But such a diagram says nothing about e.g. the data that need to be consumed/retrieved/created/updated by the use case; it say almost nothing about the input and output flows of data or information, and it certainly says nothing about the process logic of the use case. Therefore the use case diagram must be augmented with narrative or semi-structured descriptions. But why not include such essential components in the diagrammatic model? (As, for example, in “traditional” DFDs? Is it because DFDs are not so easy to construct? Are they less “object-oriented” that use cases?)

    Combining the two above issues above, my “prescription” for modeling an information system (as detailed in the FOOM methodology) is to work as follows:
    a) Create a conceptual data model – a class diagram.
    b) Create a functional model consisting of “transaction duagrams”: a transaction consists of one or more functions, and of data classes, external/user entities, and directed data flows which carry data elements among these components.
    c) Verify that the two models are consistent: data classes in the transactions are taken from the class diagram, and every class in the class diagram is “used” in at least one transaction, and vise versa. Moreover, every attribute of a class is updated by al least one transaction and retrieved by at least one transaction.
    d) In the next phase, the process logic of each transaction can be described using e.g. pseudo-code; eventually, every transaction is decomposed into respective class methods.

    These are in essence the main steps of the FOOM methodology. For more information I can provide references to papers and a textbook.

  7. Thomas Behrens permalink

    Michael, I think, your view about use cases is – probably provocatively – biassed. Use cases are not restricted to the most of obvious part of “a sequence of steps”. That view is too superficial.
    They are an interplay of documenting the functional requirements, data requirements, and behavioural requirements (if you follow the terminology of the IREB), using use case steps, data modelling and behavioural modelling elements. Note: we have illustrated our concepts here: “Elements of Effective Use Case Style

    I think the conclusion is not to ban them, but to apply them correctly.
    Use cases are an analysis and synthesis tool in the context of the requirements engineers tool box.

    Through use case models we often find with our clients that was deemed to be a pure CRUD (create/read/update/delete) application requires state management, seeding of data, and the like. If you want to build this on top of a compex data conceptual data model (take the financial derivatives domain) afterwards you are doomed.

  8. Michael Blaha permalink

    Responding to Thomas Behrens… Of course, I am biased. No argument about that. I get frustrated when I see projects with reams of use cases. They try to substitute rote work for software engineering thinking. Even I don’t “ban” use cases. Rather I subjugate them to the class model and incorporate them into it.

    Object-oriented software is supposed to be built about objects and that involves class models. In industry, too many practitioners are preparing use cases and avoiding class models.

  9. Responding to Thomas Behrens: I can only support your view. Requirements – not the big fat books – but structured requirements in Use-Cases supplemented by descriptions (Tom de Marco called them minispecs long before they came in fashion) and a conceptual data model (not class model) are the basis for the communication with the stakeholders – users and domain specialists. They are the customers, they know the requirements, pay the bill, accept (or reject) and finally use the system.
    UseCases and datamodels are required at the beginning of a project to state the business requirements. UseCases and conceptual data model are hopefully maintained and improved through the entire development phase. We need them for the functional acceptance tests and finally also for the functional documentation of the system. They make the big difference in maintenance when one can refer to this documentation instead of starting from scratch.
    The best recipee to crash (especially large) projects is to disregard users (stakeholders), avoid thorough work on the requirements, make quick drafts of a conceptual datamodels and discard them to rush to implement code and the tables of the databases.
    Use-cases and conceptual datamodels are important aritifacts (at least as important as code) and should be thoroughly tested before being cast in code.

  10. Babar Riaz permalink

    which process model of Software engineering we should use to do a database related projects???
    please help me

Leave a Reply

Note: HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS