1

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

2

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

3

• 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

4

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

5

6

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]

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]

8

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

9

10

• 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

11

12

• 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.

13

14

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

15

• 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

16

• 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

17

• 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

18

• 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.

19

• 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

20

21

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

22

23

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

24

• 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.

25

26

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

27

• 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

28

• 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

29

• 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

30

• 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

31

• 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.

32

• 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

33

34

• 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

35

• 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

36

• 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

37

• 2. Association end names • Like in an E-R model, remember to label any

ambiguous links

38

• 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

39

• 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.

40

• 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

41

• 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

42

• 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

43

• 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

44

• 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

45

• 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 of several instances of Bank it is associated with by means of such an attribute,

46

• 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

• In the model the qualification is part of the association, not part of the base classes

47

• There is something important to note about the cardinalities on a qualified association

• The Consortium may have many banks• However, each bankCode represents at most

one bank• In the diagram, the cardinalities at the ends of

the qualified association are 1 to 0..1• Still, implicitly, this notation is capturing a 1-m

relationship

48

49

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

50

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

51

• 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

52

• 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

53

• 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

54

• 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

55

• 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

56

• 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

57

• 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

58

• 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

59

• 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

60

• 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

61

• 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

62

63

12.2.8 Refining with Inheritance

• 1. Bottom-up generalization• Find classes with similar attributes,

operations, and associations• Implement common features in a superclass

64

• 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

65

• 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

66

• 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

67

• 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

68

• 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

69

70

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

71

• 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

72

• 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

73

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

74

• 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

75

• 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

76

• 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

77

• 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

78

• 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

79

• 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

80

• 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

81

• 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

82

• 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

83

84

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

85

• 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

86

87

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

88

• 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

89

• 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

90

• 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

91

• 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

92

• 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

93

• 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

94

• 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

95

• 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

96

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

• 3. A bank package, including: consortium, bank

97

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

98

• 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]

99

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

100

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

101

• 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

102

• 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

103

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?

104

• 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

105

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

106

• 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

107

108

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?

109

• 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

110

12.4 Domain Interaction Model

• This term refers to an analysis of user interactions with the system

• It is not pursued here

111

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

112

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

113

• 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

114

• 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

115

• 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…)

116

• 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

117

• 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

118

• 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

119

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

120

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

121

• 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

122

12.6 Chapter Summary

• Blah blah blah• A list of key concepts is given on the following

overhead

123

124

The End