sql unit 20 object oriented modeling and design with uml michael blaha and james rumbaugh
Skip this Video
Download Presentation
SQL Unit 20: Object-Oriented Modeling and Design with UML Michael Blaha and James Rumbaugh

Loading in 2 Seconds...

play fullscreen
1 / 122

SQL Unit 20: Object-Oriented Modeling and Design with UML Michael Blaha and James Rumbaugh - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' SQL Unit 20: Object-Oriented Modeling and Design with UML Michael Blaha and James Rumbaugh' - anais

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sql unit 20 object oriented modeling and design with uml michael blaha and james rumbaugh

SQL Unit 20: Object-Oriented Modeling and Design with UMLMichael Blaha and James Rumbaugh

Summary of Selections from Chapter 12 prepared by Kirk Scott

chapter 12 domain analysis
Chapter 12, Domain Analysis
  • Chapter 12 is on the topic of domain analysis for object-oriented design
  • In brief, this means identifying classes, relationships between classes, and attributes of classes
  • The object-oriented approach given is very close to the modeling process for relational databases

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

  • Not surprisingly, the example pursued in chapter 19 is based on the example of chapter 12
12 1 overview of analysis
12.1 Overview of Analysis
  • Analysis starts with some sort of vague statement of the problem to be solved
  • It involves taking a look at existing systems and talking to users of an old system or people who are requesting a new system (possibly the same people)
  • The goal is to arrive at an unambiguous specification for the new system
  • The diagram on the following overhead is supposed to summarize these ideas
12 2 domain class model
12.2 Domain Class Model
  • The following list summarizes the contents of the chapter, outlining the sequence of steps in analysis
  • Find classes. [12.2.1-12.2.2]
  • Prepare a data dictionary. [12.2.3]
  • Find associations. [12.2.4-12.2.5]
  • Find attributes of objects and links. [12.2.6-12.2.7]

Organize and simplify classes using inheritance. [12.2.8]

  • Verify that access paths exist for likely queries. [12.2.9]
  • Iterate and refine the model. [12.2.10]
  • Reconsider the level of abstraction. [12.2.11]
  • Group classes into packages. [12.2.12]
12 2 1 finding classes
12.2.1 Finding Classes
  • Classes arise from the problem domain
  • Some may be concrete
  • Others may be abstract
  • Some may be stated explicitly by users/requestors/existing documents
  • Others may be implicit
  • The general rule for identifying classes is to look for nouns
  • See the following overhead

Don’t worry about superclass-subclass relationships at first

  • Just try to identify base classes that may be in horizontal relationships with each other
  • The book uses a banking example based on ATM transactions
  • The next overhead shows an initial list of explicit classes

The next overhead shows implicit classes

  • In other words, these are classes that you think need to exist based on knowledge of the problem domain
  • It is worth noting up front that before we’re finished, these two additional classes will be thrown out of the design.
  • The reason will be given below.
12 2 2 keeping the right classes
12.2.2 Keeping the Right Classes
  • The book has a list of the kinds of classes that can be eliminated from a design
  • The descriptive names alone may give an idea of why the classes are not suitable
  • In other cases further commentary is helpful
  • 1. Redundant classes
  • ATM example: Customer and User are redundant
  • Customer is kept because it’s more descriptive

2. Irrelevant classes

  • ATM example: Keeping track of Cost is beyond the scope of this application
  • 3. Vague classes
  • ATM example: RecordKeepingProvision is vague
  • It is most likely part of a Transaction

4. Attributes

  • These are things you identify as nouns, but which are attributes of classes, not classes themselves
  • ATM example: AccountData is likely an attribute of an Account
  • 5. Operations
  • Again, these are things that you identify as nouns, but which turn out to be things which would be implemented as methods within classes, not as classes

6. Roles

  • Think sub-type here.
  • A person may be an employee, a boss, a spouse, but a person is a person, not a role.
  • 7. Implementation constructs
  • This is a danger whenever letting computer people design applications for users…
  • ATM example: TransactionLog and CommunicationsLine are instances of this

8. Derived classes

  • The meaning here is not too clear.
  • This does not mean eliminate subclasses specifically.
  • It does mean eliminate identified classes which could just as well be a kind of some other class.

The following overhead shows the ATM example again

  • Good classes are identified
  • Classes to be eliminated are classified according to which of the bad categories they fell into
  • Not all of the bad categories are illustrated, just five of them
12 2 3 preparing a data dictionary
12.2.3 Preparing a Data Dictionary
  • This is a deceptively simple requirement
  • From the O-O perspective it means that it should be possible to write a concise description of a valid class
  • The book illustrates this with the figure shown on the next overhead
  • The relational requirement is more concrete
  • It should be possible to make a list of all tables and all fields of those tables, identifying the meanings of the fields and what domains they are on
12 2 4 finding associations
12.2.4 Finding Associations
  • Again, at this stage, the goal is not to find “is-a” inheritance relationships
  • It is to find “has-a” relationships
  • In O-O terms, most often this arises when one class has an instance variable that is a reference to an instance of another class
  • In a relational database, the relationship will eventually be captured by means of shared attributes (key pairs) but that lies in the future

Associations in a problem domain may be identified by verbal phrases

  • Typically, relationships are more specific than “has-a”
  • The book illustrates this in the following overhead
  • Notice the occurrence of phrases like “includes”, “shares”, “provides”, etc.
12 2 5 keeping the right associations
12.2.5 Keeping the Right Associations
  • Just like with classes, the first stab at a design might tentatively identify associations that do not belong in the final design
  • Again, the book gives a list of the kinds of associations which should be thrown out:
  • 1. Associations between eliminated classes
  • I guess it never hurts to state the obvious.
  • ATM example: There are many instances of this due to the number of eliminated classes

2. Irrelevant or implementation associations

  • Clearly, irrelevant associations don’t belong in a model
  • Likewise, when modeling, implementation concerns don’t belong
  • ATM example: System handles concurrent access
  • With multiple ATM’s, concurrency will occur
  • Reality is concurrent—but this is an implementation problem, not a design problem

3. Actions

  • Associations should embody structural relationships, not transient processing events
  • ATM example: ATM accepts cash card, ATM interacts with user, Central computer clears transaction with bank, and Central computer communicates with bank all describe transient actions, not structural relationships

4. Ternary associations

  • This terminology is linked to database concerns
  • It is possible to have a three-way relationship among three different tables
  • What they want to eliminate are cases where there are two base classes and the third item in the association description is just an attribute that is connected with the relationship
  • This idea will come up again when considering attributes

ATM example:

  • Bank computer processes transaction against account breaks down into Bank computer processes transaction and Transaction concerns account
  • Cashier enters transaction for account and ATMs communicate with central computer about transaction can also be broken into two binary associations

5. Derived associations

  • This is largely a warning against redundancy in the design.
  • If there is a relationship between classes and this ‘implies’ another relationship—possibly with a different name, but not differing in how things are related, then there is no need to capture the second relationship in the design.
  • The first relationship captures it all.

The book gives a concrete example of the derived associations problem that is also closely related to database concerns.

  • It illustrates this with the following diagram, where you might think that at least one of the relationships among the three classes could be derived from the other two

A company owns a set of computers

  • It also employs a set of employees
  • Employees are assigned to computers (or vice-versa)
  • The point is that AssignedTo is not a derived relationship
  • Which computer an employee is assigned to cannot be derived from the fact that an employee works for a given company

The book provides another list containing important semantic considerations when dealing with associations

  • In other words, this is a list of problems or pointers to keep in mind when trying to identify associations

1. Misnamed associations

  • You eliminate them if they are redundant.
  • You rename them if they’re valid and not redundant.
  • Names should state what a relationship is, not be based on how it came about or some other extraneous description.
  • ATM example: Bank computer maintains accounts describes an action
  • Rename this Bank holds accounts

2. Association end names

  • Like in an E-R model, remember to label any ambigous links

3. Qualified associations

  • This is a new aspect of UML notation
  • A qualifier distinguishes objects on the many side of an association
  • ATM example: The qualifier bankCode distinguishes the different banks in a consortium
  • This will be further explained just before the next UML diagram is shown

4. Multiplicity

  • When doing a first design, you can try to figure out the cardinalities of the ends of links, but you can always straighten out the details later.

5. Missing associations

  • Again, stating the obvious never hurts.
  • If you forgot something, add it to the design.
  • ATM example: The book suggests that all of these associations were forgotten in the foregoing list: Transaction entered on cashier station, Customers have accounts, Transaction authorized by cash card, and possibly Cashier authorized on cashier station

6. Aggregation

  • These authors take my point of view:
  • If you think you know the difference between aggregation and composition, fine.
  • Otherwise, don’t get bent out of shape about it.
  • ATM example: Let Bank be part of a Consortium and show the relationship with the aggregation symbol

A UML static structure diagram for the ATM example will be given shortly

  • It includes all of the classes that were dreamt up and not thrown out
  • It shows all of the associations that were dreamt up and not thrown out, plus those that were added afterwards
  • To the extent practical, the associations are labeled and given cardinalities

The UML diagram to be given includes notation that hasn’t been shown before

  • Not only are relationship arcs labeled
  • They can also extend from an additional, labeled box attached to the class, which gives a qualified association name
  • These qualified association names keep straight potential one-to-many relationships

For example, in the upper left hand corner of the model there is a class Consortium

  • Appended to it is the qualified name bankCode
  • From this the arc leads to the class Bank
  • bankCode is the attribute of the association

In a relational model, you would expect to see a pk embedded as a fk

  • In the O-O model, this signifies that the Consortium distinguishes which Bank it is associated with by means of such an attribute,
  • In the model, this is formally known as a qualified association
  • In the implementation it would require keeping track of real attributes in one or the other of the classes, but in the model the qualification is part of the association, not part of the base classes
12 2 6 finding attributes
12.2.6 Finding Attributes
  • The book suggests that attributes can be identified as nouns X, which appear in descriptions like these:
  • The X of Y
  • Y’s X
  • Just like with relational modeling, meaningful names are useful
  • Also, any attribute that can be calculated from other attributes is not a base attribute
12 2 7 keeping the right attributes
12.2.7 Keeping the Right Attributes
  • Just like with classes and associations, the first stab at a design might tentatively identify attributes that do not belong in the final design
  • Again, the book gives a list of the kinds of attributes which should be thrown out:
  • 1. Objects
  • If something is an object it’s not a simple attribute
  • However, note that instance variables can be object references

2. Qualifiers

  • This item illustrates an important difference between O-O modeling and relational modeling
  • What does the book mean by qualifier?
  • It gives an example:
  • Suppose you have a design with both Company and Person classes
  • Suppose you also identify an attribute with a qualified name like employeeNumber

In a relational model you would expect the pk of one table to be embedded as a fk in the other

  • The book points out that in an O-O model, this is a “has-a” type relationship that will be capture by a reference
  • In other words, there may be an attribute with a name like this in the model
  • However, when initially modeling a qualified attribute name like this suggests some sort of one-to-many relationship in the design, not a simple attribute

3. Name

  • This is also kind of obscure, but tied to relational modeling concerns
  • If a name attribute has to be unique, then the book suggests that in an O-O model it is likely not an attribute
  • It is serving the moral purpose of a pk and its implementation is likely to end up being as part of a reference

Therefore, when an attribute like this is initially discovered, think in terms of a relationship in the model, not a simple attribute

  • On the other hand, if a name is not or does not have to be unique, then it’s likely that it’s a garden variety attribute

4. Identifier

  • This is also at least in part related to relational design ideas
  • An identifier in an O-O setting might be a hash code for example
  • This is along the lines of a hidden record identifier in a table
  • This implementation level unique identifier does not belong to the set of domain level attributes of an object in an O-O design

5. Attributes on associations

  • This is another interesting point that will resonate with relational questions
  • The book gives an example:
  • membershipDate as an attribute on a many-to-many relationship

In the relational model it’s clear that this would be an attribute of a table in the middle

  • The O-O model doesn’t have such a table in the middle, but it is important not to attach such attributes to either table individually
  • They remain in the O-O model as an attribute of an association

6. Internal values

  • If the attribute is not visible outside of the class, then it’s not necessary to include it in the modeling.
  • It’s an implementation issue
  • 7. Fine detail
  • Fine detail can be ignored when modeling.
  • If necessary more detail can be included in a future iteration of the model

8. boolean attributes

  • The book suggests that quite often more than two values become evident and a boolean can be modeled as an enumeration (a set)
  • Note also that in the end this is really an implementation issue
  • You don’t initially concern yourself with the types of attributes

The UML diagram on the next overhead shows the ATM example with attributes included

  • It includes several examples of notation that appeared for the first time in the previous UML diagram
  • Not only are relationship arcs labeled
  • They can also extend from an additional, labeled box attached to the class, which gives a qualified association name

These qualified association names keep straight potential one-to-many relationships

  • Not only are there several already present, including Consortium/bankCode/Bank
  • The book emphasizes the inclusion of one that wasn’t present before: Bank/cardCode/CashCard
  • A Bank issues a CashCard, and the association between the two is qualified by a cardCode
  • In other words, eventually, in the implementation a cardCode attribute will be present in the base tables, but for now it qualifies the association
12 2 8 refining with inheritance
12.2.8 Refining with Inheritance
  • 1. Bottom-up generalization
  • Find classes with similar attributes, operations, and associations
  • Implement common features in a superclass

2. Top-down specialization

  • Look in the problem domain for phrases of the form adjective 1/noun, adjective 2/same noun, etc.
  • The book gives this example: fluorescent lamp, incandescent lamp, etc.
  • These names may indicate subclasses in the design

3. Generalization vs. enumeration

  • The book gives this example of enumeration: CheckingAccount, SavingsAccount, etc.
  • The point of this heading is that subcases do not necessarily mean subclasses
  • Just like in relational modeling, this may be most easily captured with a “type of account” attribute

4. Multiple inheritance

  • The books says that this may be used if necessary
  • As a Java programmer, you know that ultimately this will become an implementation issue since Java doesn’t support the concept directly

5. Similar associations

  • Sometimes the same association occurring between apparently different classes tells you something about the classes themselves
  • In the ATM example, Transaction is entered on CashierStation and Transaction is entered on ATM
  • EntryStation could be a superclass of both CashierStation and ATM

6. Adjusting the inheritance level

  • This is basically the rule of thumb about abstraction in class design:
  • Implement things as high as possible in the inheritance hierarchy
  • The UML diagram on the next overhead shows the ATM example with EntryStation and Transaction abstract superclasses added to the design
12 2 9 testing access paths
12.2.9 Testing Access Paths
  • What this basically means is follow the associations shown in the model and test them
  • If you believe that ultimately there is a relationship between class X and class Y, it should be possible to get from class X to class Y by following links in the diagram
  • This is related to relational design in the following sense:
  • The book expresses the idea as following associations in order to answer queries
  • In other words, the associations should exist so that you can find out what’s related to what

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

  • Once again, this question should ring a bell for someone interested in relational design

It is also important to consider any classes in the design that are floating in space without links

  • In relational design this is simply not possible in a single database
  • In an O-O design it may or may not be problematic
12 2 10 iterating a class model
12.2.10 Iterating a Class Model
  • You generally need to go over designs more than once.
  • There are four kinds of problems:
  • Forgetting classes in the design
  • Forgetting associations in the design
  • Including unnecessary things in the design
  • Needing to rearrange attributes and associations in the design

Following is given a list of signs that classes are missing, and pointers on how to correct the oversight:

  • 1. Asymmetries in associations and generalizations
  • Add new classes by analogy
  • 2. Disparate attributes and operations on a class
  • Split the class into two (or more) coherent classes

3. Difficulty in generalizing cleanly

  • One class may be playing >1 role
  • Split it up and one of the subparts may fit the generalization hierarchy
  • 4. Duplicate associations with the same name and purpose
  • Generalize to create the missing superclass that unites them

5. A role that substantially shapes the semantics of a class

  • Maybe the role should be a separate class
  • This may mean converting an association into a class
  • Example: Employment is an association between a Person and a Company
  • In a many-to-many employment situation, the role/association Employee may become a separate class
  • This may be analogous to a table in the middle in a relational design

You also need to look for missing associations

  • 1. Missing access paths for operations
  • In other words, it is not possible to follow a reference to the needed object in order to accomplish something
  • Needless to say, the solution is to add an association somewhere in the design

Following are two signs that there superfluous elements in the design, and pointers on how to correct this:

  • 1. Lack of attributes, operations, and associations on a class
  • If a class doesn’t “participate” in the model, it is superfluous
  • A classic example of this is subclasses that are simply enumerations
  • Eliminate the subclasses and just use the superclass with a single attribute telling what kind of thing an instance is

2. Redundant information

  • Associations that do not add new information are redundant
  • Eliminate them as direct parts of the design, and if desirable, mark them as derived
  • Recall that derived associations were ones that could be arrived at by following a different path through the model

Following are two signs that attributes or associations are misplaced in the design, and pointers on how to correct this:

  • 1. Association end names that are too broad or narrow for their classes
  • Move the association up or down in the class hierarchy

2. Need to access an object by one of its attribute values

  • Consider a qualified association
  • Recall that at this point we’re talking about modeling
  • In other words, the model may be improved if you use the qualified association concept
  • At implementation time, this may turn into a concept like a pk/fk pair in a relational design

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.

  • Rather than doing that, the UML for the revised design is simply given on the next overhead
  • This diagram reflects all of the changes so far
  • It is reasonably complete and correct, and by definition, it’s reached the point of complexity where a certain amount of effort would be required to trace through and understand every element of it
12 2 11 shifting the level of abstraction
12.2.11 Shifting the Level of Abstraction
  • The background to this section is the idea that every noun in the problem domain may lead to a class in the design
  • In an improved design, this may no longer be true
  • The book gives an example which is essentially the same as an example used to illustrate the concept in the database modeling notes given earlier

You may have employees and bosses

  • Ultimately, they are both types of person, or you might say, roles that people play
  • The book illustrates this with a three layer management hierarchy
  • This can be replaced with a class in a relationship with itself, as shown on the following overhead
12 2 12 grouping classes into packages
12.2.12 Grouping Classes into Packages
  • This is somewhat of a dark art, and even the ATM example is still too small to illustrate this realistically
  • The book gives two interesting ideas that are helpful in finally understanding how to go about this
  • 1. In a sense, the motivation stems from UML diagrams
  • The goal is to divide classes into packages in a way that allows for clean UML diagrams

2. The separation of classes into packages also has semantic meaning

  • In other words, classes that are put together in one package should be more closely related than classes in different packages
  • The UML motivation and the semantic motivation are connected
  • If classes are semantically grouped, then the UML diagrams for the packages should be self-contained and consistent

In pursuing this further, note that UML diagrams are not just collections of individual classes

  • They also show associations and inheritance
  • When separating classes into packages, you are also separating associations and inheritance into packages

The underlying idea that the book seems to be proposing is a simple idea about graph theory

  • Most classes will be connected to some other class in the model
  • When dividing classes into packages, you want to find classes that are cut points
  • These are the classes that connect two subparts of the model which do not have any other associations between them

Such a cut point class can be in both of the packages that it connects

  • Then when diagramming the model, subdivided into packages, there will be no lines between the packages
  • Their connection is embodied by the presence of the common class in each of them

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:

  • Each association is contained entirely in one package
  • An association doesn’t go from one package to another

It seems reasonable to make the same kind of statement about inheritance relationships

  • You would expect all of the classes of an inheritance hierarchy to be in the same package
  • You would not expect the “extends” or “implements” arrows to run from one package to another

Part of the reason this topic is somewhat vexed is that the Java API doesn’t seem to be organized following exactly these guidelines

  • It has to be accepted that the Java developers grouped classes together based on their understanding of how they might be used together in applications
  • However, the garden variety programmer would not be expected to have the knowledge to see why the API grouping made particular sense

As noted, the ATM model is still too small to be broken down into packages

  • However, the book suggests in outline form groupings that could become packages:
  • 1. A teller package, including: cashier, entry station, cashier station, ATM

2. An account package, including: account, cash card, card authorization, customer, transaction, update, cashier transaction, remote transaction

  • 3. A bank package, including: consortium, bank
12 3 domain state model
12.3 Domain State Model
  • Most objects in a model probably do not have states, or states worthy of modeling
  • Their use is concisely given by listing their attributes and operations
  • However, some objects may pass through different states which are significant to the modeling of the system
  • In these cases it’s useful to develop a domain state model and diagram it

These are the steps in constructing a domain state model:

  • 1. Identify domain classes with states [12.3.1]
  • 2. Find states [12.3.2]
  • 3. Find events [12.3.3]
  • 4. Build state diagrams [12.3.4]
  • 5. Evaluate state diagrams [12.3.5]
12 3 1 identifying classes with states
12.3.1 Identifying Classes with States
  • Search for classes where objects of that class have an identifiable life cycle or history
  • This can be truly cyclic, where an object returns to an initial state
  • It can also be progressive, running from one state to the next until the end
  • The ATM Account class is the only one with significant state
  • Its life cycle is a mixture of progressive and cyclic changes of state
12 3 2 finding states
12.3.2 Finding States
  • States, fundamentally, are captured by the values attributes have and the associations with particular other objects that a given object is in
  • The idea of a state might arise from the problem domain, but it will be reflected in values associated with an instance
  • You might find a particular configuration of values and also decide that this represents a significant state in the model

States should be given a descriptive name that describes what they are, not how they came about

  • Although states are based on values, differences between states should be describable as differences in quality, not just quantity of some attribute, for example
  • The behavior of an object should be related to the state that it’s in

Not all states may be apparent before a model is complete

  • However, the idea that something has state should be identifiable earlier on
  • In the ATM model, the Account class has state.
  • Here are examples of particular states: Normal, Closed, Overdrawn, Suspended
12 3 3 finding events
12.3.3 Finding Events
  • The events of interest are events that cause the states of objects to change
  • An easy analytical approach is to ask:
  • What causes a state to be initiated or entered?
  • What causes a state to end or be left?

Keep in mind that you’re modeling now, not coding

  • You are not interested in GUI events
  • You’re interested in domain events
  • Here are examples of events in the ATM model: Close account, withdraw excess funds, repeated incorrect PIN, suspected fraud, and administrative action
12 3 4 building state diagrams
12.3.4 Building State Diagrams
  • In the a diagram a state is an oval and an event/transition is an arrow
  • Analytically, for each state, you want to consider what events are possible
  • For each state/event pair, you need to determine what other state, if any, this leads to

Of particular interest are state/event pairs that seem to lead nowhere

  • This may mean that you’ve forgotten something in the diagram
  • It may also mean that the state/event pair leads to an error state which you need to include among the states
  • A state transition diagram for the ATM model is given on the following overhead
12 3 5 evaluating state diagrams
12.3.5 Evaluating State Diagrams
  • Having drawn a state diagram it is possible to go through it looking for possible oversights
  • Are all the states connected?
  • If there is a progression of states, is there a path through the model from the beginning to the ending state?
  • If state goes through a cycle, is there a cyclical path in the model?
  • Is there an exit path from the cycle?

The book points out that deep domain knowledge may be necessary to create a state transition diagram

  • The ATM example is simple, but it is as complete and correct as possible given the level of domain knowledge presented in the chapter
12 4 domain interaction model
12.4 Domain Interaction Model
  • This term refers to an analysis of user interactions with the system
  • It is not pursued here
12 5 iterating the analysis
12.5 Iterating the Analysis
  • This is just a statement of the obvious
  • You typically have to go through the analysis process more than once
  • The first pass will give a first approximation
  • Following passes will refine the model
  • This is not just the result of human failings
  • It stems from the fact that parts of the design depend on each other
  • You can’t understand one until you understand the other—and vice-versa
12 5 1 refining the analysis model
12.5.1 Refining the Analysis Model
  • A large model will consist of multiple parts
  • When refining, you can work from the top down, using the divide and conquer approach
  • This works all the way down to individual classes and attributes

Signs of problems include:

  • 1. Lots of classes that are similar, but not quite the same
  • This is a sign of not having generalized correctly
  • In particular, you may have tried to generalize, but you should have generalized on an alternative set of shared attributes

2. You have combined more than one concept into a class

  • This can happened because a physical entity has more than one logical aspect
  • You have tried to model the physical entity as one class
  • Instead, the different logical aspects should be modeled as separate classes

3. If your model seems to embody many exceptions or special cases, that may be a sign that something was missed in analysis

  • 4. If you expected certain things to appear symmetrically in the model, and they don’t, this may mean that you overlooked something (or had false expectations…)

5. A model may be inappropriate if it too rigidly captures details of current business practice

  • A good model will be abstract enough that will allow for changes in specific business practices in the future
  • It is difficult to quantify flexibility and how much flexibility is needed, but it is still an important analysis concept

6. As analysis continues, there will be a tendency to add more and more detail and distinctions

  • The point can be reached where this is counter-productive
  • In simple terms, if one class will do where you currently have two, there is definitely an argument in favor of the one class solution
  • The goal is a model that is both correct and as simple as possible

The grand conclusion is this:

  • As you iterate through the model you are looking for possible changes
  • If you find desirable ones, make them
  • It’s better to make changes, especially if they’re radical, at the analysis stage
  • Trying to make any changes, especially radical ones, becomes increasingly difficult the farther along in the development process you are
12 5 2 restating the requirements
12.5.2 Restating the Requirements
  • The model resulting from the analysis process may not agree exactly with the requirements that were given at the beginning of the process
  • Revised requirements should be explicitly written down, and they should be verified with the users who originally requested the system
12 5 3 analysis and design
12.5.3 Analysis and Design
  • Dividing analysis and design into two steps is a convenient application of divide and conquer
  • The idea is that analysis proceeds without any preconceived ideas about how the system might be implemented
  • The reality is that analysis is never done in a complete vacuum

The goal of all these rules of thumbs is not to achieve some kind of theoretical purity

  • The goal is to provide a working process for achieving a concrete result
  • Analyze and refine at will with the ultimate goal of arriving at a model that will serve as a basis for an implementation design
12 6 chapter summary
12.6 Chapter Summary
  • Blah blahblah
  • A list of key concepts is given on the following overhead