Loading in 2 Seconds...
Loading in 2 Seconds...
SQL Unit 20: Object-Oriented Modeling and Design with UML Michael Blaha and James Rumbaugh. Summary of Selections from Chapter 12 prepared by Kirk Scott. Chapter 12, Domain Analysis. Chapter 12 is on the topic of domain analysis for object-oriented design
Summary of Selections from Chapter 12 prepared by Kirk Scott
The reason for covering this is that chapter 19 in the book is specifically on the topic of developing a database to match an object-oriented design
The book gives a concrete example of the derived associations problem that is also closely related to database concerns.
The book provides another list containing important semantic considerations when dealing with associations
The UML diagram to be given includes notation that hasn’t been shown before
For example, in the upper left hand corner of the model there is a class Consortium
In a relational model you would expect the pk of one table to be embedded as a fk in the other
Therefore, when an attribute like this is initially discovered, think in terms of a relationship in the model, not a simple attribute
In the relational model it’s clear that this would be an attribute of a table in the middle
The UML diagram on the next overhead shows the ATM example with attributes included
These qualified association names keep straight potential one-to-many relationships
As you follow the links, it may be important to pay attention to their cardinalities and ask in particular whether it will be possible to uniquely identify which one of many is under consideration when following a particular path
It is also important to consider any classes in the design that are floating in space without links
Following is given a list of signs that classes are missing, and pointers on how to correct the oversight:
Following are two signs that there superfluous elements in the design, and pointers on how to correct this:
Following are two signs that attributes or associations are misplaced in the design, and pointers on how to correct this:
It’s reached the point where tracing through all of the changes to the example design based on the observations in the text is somewhat tedious.
2. The separation of classes into packages also has semantic meaning
In pursuing this further, note that UML diagrams are not just collections of individual classes
The underlying idea that the book seems to be proposing is a simple idea about graph theory
Viewed from the point of view of associations rather than classes, the goal of separating classes, associations, and inheritance into packages can be stated as follows:
It seems reasonable to make the same kind of statement about inheritance relationships
Part of the reason this topic is somewhat vexed is that the Java API doesn’t seem to be organized following exactly these guidelines
2. An account package, including: account, cash card, card authorization, customer, transaction, update, cashier transaction, remote transaction
States should be given a descriptive name that describes what they are, not how they came about
The book points out that deep domain knowledge may be necessary to create a state transition diagram
3. If your model seems to embody many exceptions or special cases, that may be a sign that something was missed in analysis
5. A model may be inappropriate if it too rigidly captures details of current business practice
6. As analysis continues, there will be a tendency to add more and more detail and distinctions
The goal of all these rules of thumbs is not to achieve some kind of theoretical purity