Comments on: Use Cases and Database Modeling — An interview with Michael Blaha. Trends and Information on Big Data, New Data Management Technologies, Data Science and Innovation. Mon, 03 Nov 2014 17:39:20 +0000 hourly 1 By: Babar Riaz Sat, 16 Feb 2013 10:05:39 +0000 which process model of Software engineering we should use to do a database related projects???
please help me

By: Reinhold Thurner Wed, 15 Feb 2012 16:47:50 +0000 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.

By: Michael Blaha Sat, 04 Feb 2012 22:54:13 +0000 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.

By: Thomas Behrens Wed, 01 Feb 2012 08:00:50 +0000 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.

By: Peretz Shoval Mon, 23 Jan 2012 10:02:35 +0000 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.

By: Michael Blaha Sat, 21 Jan 2012 23:36:30 +0000 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.

By: Reinhold Thurner Fri, 20 Jan 2012 22:26:02 +0000 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.

By: Michael Blaha Tue, 17 Jan 2012 14:36:23 +0000 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.

By: Milan Kratochvil (main author of UML Xtra Light - How to Spec your SW Requirements) Fri, 13 Jan 2012 15:34:38 +0000 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).

By: Jim Arlow Fri, 13 Jan 2012 10:32:09 +0000 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.