{"id":1307,"date":"2012-01-09T08:58:13","date_gmt":"2012-01-09T08:58:13","guid":{"rendered":"http:\/\/www.odbms.org\/blog\/?p=1307"},"modified":"2012-01-09T08:58:13","modified_gmt":"2012-01-09T08:58:13","slug":"use-cases-and-database-modeling-an-interview-with-michael-blaha","status":"publish","type":"post","link":"https:\/\/www.odbms.org\/blog\/2012\/01\/use-cases-and-database-modeling-an-interview-with-michael-blaha\/","title":{"rendered":"Use Cases and Database Modeling — An interview with Michael Blaha."},"content":{"rendered":"

\u201c 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.\u201c<\/strong><\/em> — Dr. Michael Blaha.<\/strong><\/p>\n

First of all let me wish you a Happy, Healthy and Successful 2012!<\/strong><\/p>\n

I am coming back to discuss with our expert Dr. Michael Blaha<\/a>, the topic of Database Modeling. In a previous interview we looked at the issue of \u201cHow good is UML for Database Design\u201d<\/a>?<\/p>\n

Now, we look at Use Cases<\/strong><\/em> and discuss how good are they for Database Modeling. Hope you`ll find the interview interesting. I encourage the community to post comments.<\/p>\n

RVZ<\/p>\n

Q1. How are requirements taken into accounts when performing data base modeling in the daily praxis? What are the common problems and pitfalls<\/strong>?<\/p>\n

Michael Blaha<\/strong>: Software development approaches vary widely. I’ve seen organizations use the following techniques for capturing requirements (listed in random order).<\/p>\n

— Preparation of use cases.
\n— Preparation of requirements documents.
\n— Representation and explanation via a conceptual data model.
\n— Representation and explanation via prototyping.
\n— Haphazard approach. Just start writing code.<\/p>\n

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

Q2. What is a use case?<\/strong><\/p>\n

Michael Blaha<\/strong>: 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.<\/p>\n

Q3. What are the advantages of use cases?<\/strong><\/p>\n

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

Q4. What are the disadvantages of use cases?<\/strong><\/p>\n

Michael Blaha<\/strong>:
\n— 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).<\/p>\n

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

— 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.<\/p>\n

— I have yet to see benefit from use case diagramming. I have yet to see significant benefit from use case structuring.<\/p>\n

— In my opinion, use cases have been overhyped by marketeers.<\/p>\n

Q5. How are use cases typically used in practice for database projects?<\/strong><\/p>\n

Michael Blaha<\/strong>: To capture requirements. It is OK to capture detailed requirements with use cases, but they should be
\nsubservient to the class model. The class model defines the domain of discourse that use cases can then reference.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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?<\/strong> <\/p>\n

Michael Blaha<\/strong>: This is a popular approach. No I do not agree with it. I strongly disagree.
\nFor a database project, the conceptual data model is a much more important software engineering contribution than use cases.<\/p>\n

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.<\/p>\n

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?<\/strong><\/p>\n

Michael Blaha<\/strong>: Databases provide a powerful language, but most do not provide a complete language.<\/p>\n

The SQL language of relational databases is far from complete and some other language must be used to express full functionality.<\/p>\n

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.<\/p>\n

Use cases target functionality and functionality alone. Use cases, by their nature, do not pay attention to data structure.<\/p>\n

Q8. Do you need to use UML for use case<\/strong>s?<\/p>\n

Michael Blaha<\/strong>: No. The idea of use cases are valuable if used properly (in conjunction with data and normally subservient to data).<\/p>\n

In my opinion, UML use case diagrams are a waste of time. They don’t add clarity. They add bulk and consume time.<\/p>\n

Q9. Are there any suitable tools around to help the process of creating use cases for database design? If yes, how good are they?<\/strong><\/p>\n

Michael Blaha<\/strong>: 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.<\/p>\n

Q10. Use case methods of design are usually applied to object-oriented models. Do you use use cases when working with an object database?<\/strong> <\/p>\n

Michael Blaha<\/strong>: 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.<\/p>\n

Q11. Can you use use cases as a design method for relational databases, NoSQL databases, graph databases as well? And if yes how?<\/strong><\/p>\n

Michael Blaha<\/strong>: Not reasonably. I guess developers can force fit any technique and try to claim success.<\/p>\n

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.<\/p>\n

I don’t see how use cases have much to offer for NoSQL and graph databases.<\/p>\n

Q12. So if you don’t have use cases, how do you address functionality when building database applications?<\/strong><\/p>\n

Michael Blaha<\/strong>: I strongly favor the technique of interactive conceptual data modeling. I get the various business and
\ntechnical 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).<\/p>\n

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.<\/p>\n

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

\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2013
\nMichael Blaha<\/strong> is a partner at Modelsoft Consulting Corporation.<\/a>
\nDr. Blaha is recognized as one of the world\u2019s 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.<\/p>\n

Related Posts<\/strong><\/p>\n

– How good is UML for Database Design? Interview with Michael Blaha.<\/strong><\/a><\/p>\n

– Agile data modeling and databases.<\/strong>><\/p>\n

<\/a>– Why Patterns of Data Modeling?<\/strong><\/a><\/p>\n

Related Resources<\/strong><\/p>\n

-ODBMS.org:<\/strong> Databases in General: Blog Posts | Free Software | Articles and Presentations| Lecture Notes | Journals |<\/a><\/p>\n

##<\/p>\n","protected":false},"excerpt":{"rendered":"

\u201c 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.\u201c — Dr. Michael […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[112,138,376,413,416,427,499,591,596],"_links":{"self":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/1307"}],"collection":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/comments?post=1307"}],"version-history":[{"count":0,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/1307\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/media?parent=1307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/categories?post=1307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/tags?post=1307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}