Uml

UML and Object Oriented
Modeling
JiHsian Lee
Web:http://202.201.18.40:8080/mas5/labs/home.jsp?id=7
The School of Mathematics, Physics and Software Engineering
Lanzhou Jiaotong University
July 19, 2006

2
Contents
1 Fundamentals of OOM 7
1.1 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Model Organization . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Structured Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Object Orientation . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Encapsulation of Hardware . . . . . . . . . . . . . . . . . . . . 12
1.7 Encapsulation of Software . . . . . . . . . . . . . . . . . . . . 12
1.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.9 Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 UML - Part 1 19
2.1 UML - What It Is . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Why Use UML? . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 How UML Started . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 UML Diagram Types . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Business Modelling, Web Applications, and extending UML . 26
2.6 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.7.1 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3
4 CONTENTS
2.7.2 Relationships . . . . . . . . . . . . . . . . . . . . . . . 36
2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.9 Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 UML - Part 2 45
3.1 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Collaboration Diagram . . . . . . . . . . . . . . . . . . . . . . 47
3.3 Statechart Diagram . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . 53
3.6 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . 53
3.7 Modelling Architecture . . . . . . . . . . . . . . . . . . . . . . 56
3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.9 Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 The Software Development Process 61

4.1 Business Process Modelling . . . . . . . . . . . . . . . . . . . 61
4.2 System Requirements Definition . . . . . . . . . . . . . . . . . 62
4.3 The System Analysis Model . . . . . . . . . . . . . . . . . . . 63
4.4 System Model Information Flow . . . . . . . . . . . . . . . . . 63
4.5 The System Design Model . . . . . . . . . . . . . . . . . . . . 64
4.6 Overall Process Flow . . . . . . . . . . . . . . . . . . . . . . . 65
4.7 Incremental Development . . . . . . . . . . . . . . . . . . . . 66
4.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.9 Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A Answers 71
CONTENTS 5
B CRC 73
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.3 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.4 CRC Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B.5 Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6 CONTENTS
Chapter 1
Fundamentals of OOM
This chapter explains the principles behind modeling and abstraction and
shows how they can be applied to object oriented models and systems.
1.1 Abstraction
Abstraction is a fundamental principle of modeling. A system model is cre-

ated at different levels, starting at the higher levels and adding more levels
with more detail as more is understood about the system. When complete,
the model can be viewed at several levels. So abstraction is about:
• Looking only at the information that is relevant at the time
• Hiding details so as not to confuse the bigger picture
1.2 Modeling
When we model, we create a number of views of the system being described,

usually 2 or 3. For a complete description 3 are normally needed. Each
7
8 CHAPTER 1. FUNDAMENTALS OF OOM
Figure 1.1: Orthogonal View of a Plane
view is an “orthogonal” view, see Figure. 1.1. Each view is needed for a full
understanding of the system. Views are orthogonal when:
• Each view has information that is unique to that view
• Each view has information that appears in other views
• The information that is common between views is consistent(一致的,

相容的)
1.3 Model Organization
All model syntaxes(语法, 句法) provide a number of model elements which

can appear on one or more diagram types. The model elements are contained
within a central model, together with all their properties and connections to
other model elements. The diagrams are independent views of the model just
as a number of computer screens looking into different records or parts of a
database shows different views. See Figure. 1.2.
1.4. STRUCTURED ANALYSIS 9
Figure 1.2: Model Diagram
1.4 Structured Analysis

In structured analysis there are three orthogonal views, Figure. 1.3:
• The functional view, made up of data flow diagrams(DFD), is the pri-

mary view of the system. It defines what is done, the flow of data
between things that are done and provides the primary structure of
the solution. Changes in functionality result in changes in the software
structure.
• The data view, made up of entity relationship diagrams(ERD), is a

record of what is in the system, or what is outside the system that is
being monitored. It is the static structural view.
• The dynamic view, made up of state transition diagrams(STD), defines

when things happen and the conditions under which they happen.
Traditional Structured Analysis and Design methods tend to fall short

of(缺乏, 达不到) the goal of producing software that is easy to maintain
and extend over a long period. They are able to produce a hierarchically
Figure 1.3: Orthogonal Views in Structured Analysis
structured model that satisfies a static requirement. The model is, to a

trained analyst, clear and easy to understand and, to a large degree, reason-
able traceable. What structured analysis is not good at is adapting models to
the continuously changing requirements that are the characteristic of modern
businesses.
1.5 Object Orientation
Object Oriented software is based on the static, or object model — the

things in the system, or, the things outside the system about which we need
to record information, and their relationships. This is the most stable view in
the system. It is why an object oriented model produces more stable software
over a long period. See Figure. 1.4
• Functionality from the interaction model is mapped onto the object

model.
1.5. OBJECT ORIENTATION 11
Figure 1.4: Orthogonal Views in Object-Oriented Analysis
• The interaction model is, in turn, derived from the Use Case model
which defines the functionality of the system from a user’s perspective.
• The dynamic model defines the order and conditions under which things
are done and is also mapped onto the object model.
The object model is usually less affected by the changes to functional

requirements that characterize most of the evolutionary process of the soft-
ware. The things that are part of the problem and the way in which they
are related tend to remain the same. It is what we want to do with them
— the functional model — that changes the most. If, therefore, we model
the structure of the problem and the structure of the resulting software solu-
tion around the object model instead of around the functional model, then
we will produce systems that are more resilient to change over a period of
time. This is what object orientation does and is the primary reason why
object oriented software is more maintainable, re-useable and extensible than
traditional structured software, especially over a long period.
In addition, the flexibility and resultant portability of an object-oriented
solution, tends to result in software that is inherently scalable. The encap-
sulation of objects lends itself to redistribution across distributed platforms

once the functionality of the application has been proved as a single machine
solution.
1.6 Encapsulation of Hardware

The concept of encapsulation of data and functionality that belongs together
is something which the hardware industry has been doing for a long time.
Hardware engineers have been creating re-useable, re-configurable hardware
at each level of abstraction since the early sixties in the last century. El-
ementary boolean functions are encapsulated together with bits and bytes
of data in registers on chips. Chips are encapsulated together on circuit
boards. Circuit boards are made to work together in various system boxes
that make up the computer, as shown in Figure. 1.5. Computer are made to
work together across networks. Hardware design, therefore is totally object
oriented at every level and is, as a result, maximally re-useable, extensible
and maintainable. In a single word: flexible. Applying object-orientation to
software, therefore, could be seen as putting the engineering into software
design that has existed in hardware design for many years.
• Hardware encapsulates data and function at every level of abstraction
• Maximizes maintainability, reuse and extension
1.7 Encapsulation of Software

In well developed object oriented software, functionality and data is encap-
sulated in objects. Objects are encapsulated in components. Components
1.7. ENCAPSULATION OF SOFTWARE 13
Figure 1.5: Encapsulation of Hardware
Figure 1.6: Encapsulation of Software
are encapsulated into systems. See Figure. 1.6. If this is done well the result
is:
• Maximal coherence(一致)
• Minimal interconnection
• Solid interface definitions Maximum maintainability, reuse and exten-

sibility
Encapsulation of primitive functions, together with the data upon which

they act and to which they belong, is fundamental to object orientation.
The trick is to get the right functionality encapsulated with the right data.
If this is achieved, then, the network of objects, which collaborate to provide

the required functionality of the software, will have the minimum possible
essential connections between objects and maximum functional cohesion of
the objects. From this maximal functional cohesion(结合, 凝聚, 内聚力) can
be derived maximal maintainability, reuse and extension. To achieve this we
need two things. Firstly, the right objects. Secondly, to set the interface to
the objects in concrete. If a change to an object requires a change to the
interface to the object, then the effect of that change will escape beyond
the boundaries of the object and propagate around the network. This is to
allow the whole reason for encapsulation to be negated(否定, 打消) in one
go. Proper Analysis and Design defines the right objects for the system and
their interfaces to the point where each object can be given to a programmer
and coded independently of any other object in the system. If this is done
well then the resulting objects will still be around in future versions of the
software, and, furthermore, their interfaces will not have changed except for
additions. We aim for maximum maintainability, re-use and extension.
1.8 Summary
• Abstraction is about looking only at the information that is relevant
at the time.
• When modelling 2 or 3 orthogonal views of the system are created.
• Diagrams are independent views of the model and may be of different

types.
• In structured analysis the functional view is the primary view of the

system.
1.9. QUIZ 15
• In object oriented analysis, the object model, or data view, is the pri-
mary, and most stable view of the system.
• Hardware engineering produces well encapsulated hardware designs
• Applying encapsulation techniques to software encourages maintain-

able, re-useable and extensible code.
1.9 Quiz
1. Abstraction is about
(a) Looking at things in detail
(b) Looking at relevant information only
(c) Focusing on one detailed point
2. Hiding details is a good idea because
(a) There is no need to worry about them as they are unnecessary
(b) Details are not important
(c) It stops you worrying about them when they are not important
3. In a model made up of multiple views
(a) Each view is a transformation of another view
(b) Views contain unique information
(c) Common information must be consistent
(d) 3b and 3c are true
(e) None of the above

4. Model elements
(a) appear on one diagram only
(b) are distributed amongst the diagrams of the model
(c) can appear on multiple diagrams of the same or different types
(d) can appear on multiple diagrams of different types only
(e) 4a and 4b are true
5. In structured analysis
(a) The functional view is the primary view
(b) The data view records what is in the system
(c) The dynamic view describes the flow of data
(d) 5a and 5b are true
(e) 5a, 5b and 5c are true
6. In object orientation
(a) The functionality of the object model is derived directly from the
use case model
(b) The interaction model is mapped onto the dynamic model
(c) The object model is the most stable view of the system
(d) 6a and 6c are true
(e) None is true
7. Encapsulation of hardware
(a) Is little used in modern electronics

1.9. QUIZ 17
(b) Makes software development easier
(c) Is inherent in the way most hardware engineers work
8. Object orientation
(a) Encapsulates software at object, component, and system level
(b) Maximizes maintainability, reuse and extension
(c) Helps give applications a longer life
(d) All of the above

Chapter 2
UML - Part 1
This chapter explains the origins of UML and some of the different kinds of
diagrams available within it.
2.1 UML - What It Is
The Unified Modeling Language was originally developed at Rational Soft-

ware but is now administered by the Object Management Group. It is a
modelling syntax aimed primarily at creating models of software-based sys-
tems, but can be used in a number of areas. It is:
• Syntax only — UML is just a language, it tells you what model

elements and diagrams are available and the rules associated with them.
It doesn’t tell you what diagrams to create.
• Process independent — the process by which the models are created

is separate from the definition of the language. You will need a process
in addition to the use of UML itself.
19
20 CHAPTER 2. UML - PART 1
• Tool independent — UML leaves plenty of space for tool vendors

to be creative and add value to visual modelling with UML. However,
some tools will be better than others for particular applications.
• Well documented — the UML notation guide is available as a refer-

ence to all the syntax available in the language.
• Its application is not well understood — the UML notation guide

is not sufficient to teach you how to use the language. It is a generic
modelling language and needs to be adapted by the user to particular
applications.
• Originally just for system modelling — some user defined exten-

sions are becoming more widely used now, for example for business
modelling and modelling the design of web-based applications.
2.2 Why Use UML?

• Software Construction Needs a Plan.
There is a common perception(理解) among general management that

software is both cheap to produce and easy to change. “Its only a bit
of software - it won’t take you long.” Developers know that this is not
true. Software is extremely complex and, once a particular structure
is in place, often long-winded(气长的, 罗嗦的, 冗长的) and difficult
to change. An architect(建筑师) knows this and creates a drawing of
the building from more than one direction, ensuring that the structure
is appropriate for the purpose of the building and that the dimensions
are all consistent. Only when this visual model of the proposed work
has been approved is the job of laying bricks begun.
2.2. WHY USE UML? 21
• Visualize In Multiple Dimensions and Levels of Detail.
Software is very abstract and hard to visualize. A visual modelling

language, such as UML, allows software to be visualized in multiple
dimension, so that a computer system can be completely understood
before construction begins. Furthermore, UML can be used to produce
several models at increasing levels of detail. The overall scope of the
software can quickly and easily be defined at the start of the project
with a high level model allowing for accurate estimation. Increasing
levels of detail can then be added to each part of the software as it is
constructed, until finally the software appears as code. The code can
then be tested against a test model that is derived from the original
model of requirements.
遗赠物,遗
• Appropriate For Both New and Legacy(遗遗产) Systems.
UML is appropriate for both new system developments and improve-

ments to existing systems. It is a fallacy(谬误, 谬论) that in order to
use a new modelling technique on an old system, the old system will
have to be completely “re-documented” in the new style in order for
any change to take place. The truth is that only those parts that are
affected by the change will need to be modelled. If they were badly
documented or not documented at all, then a lot of work would need
to be done to understand them anyway in order to make the change.
• Documents Software Assets.
Undocumented or badly documented software has a reduced value as

a company asset. With so much of the company’s business process
embedded in obtuse(愚蠢的, 迟钝的) software code, a company is vul-
nerable to losing an understanding of and control over the business
rules by which it operates. Gradual re-engineering of the company’s

computer software in a way that makes the functionality of the soft-
ware transparent, brings those important assets back under control.
It removes the company from dependence on key personnel who may
leave at any time and improves understanding of the company’s critical
business processes. It even improves the quality of software engineering
staff because those who want to do a proper job will look for companies
that model with UML.
• Unified and Universal.
The Unified Modelling Language was created by Rational Software in

order to provide a standard for software modelling languages. It is now
owned and controlled by the Object Modelling Group, an independent
organization. UML has quickly become the de facto(事实上的, 实
际的) standard modelling language in the software industry. UML
is a universal language because it can be applied in many areas of
software development. It includes user-definable extension mechanisms
so that it can be adapted for specific environments. Industry standard
extensions now exist for business modelling and web-based applications
development.
可描绘, 可描写,可
• Inherent Traceability(可可追溯).
The Use Case Driven nature of modelling with UML ensures that all
levels of model trace back to elements of the original functional re-
quirements. This traceability between models comes without the extra
effort creating and maintaining a “traceability matrix” which can be a
complex and time consuming job. The result is that the impact of a
requested change can quickly be estimated. A change in requirements
2.2. WHY USE UML? 23
can be traced though analysis and design models into those components
affected and even lines of code. The code affected can then be traced
back to the requirements and total regression testing(回归测试) effort
calculated.
适应, 容纳) Incremental Development and Re-

• Accommodates(适
Development.
UML models respond well to an incremental development environment.

It is possible not only to develop only those parts of the model that are
required to satisfy the new requirements, but also to demonstrate that
all the code needed to fulfil those requirements is in place and that only
the code needed to fulfil those requirements is in place. This approach
ensures that only the work needed to fulfil the current requirement
is done, while still developing in such a way that maximizes re-use,
maintainability and extensibility.
• Accommodates Parallel Development of Large Systems.
Large complex UML models can be decomposed in a totally user-

definable way so that different parts of the model can be developed
independently by different people or groups. Furthermore, given the
right tool and change management infrastructure(基础设施), each part
of each model can be independently change managed. This facility en-
ables independent, yet controlled and coordinated, working on different
parts of a project by different groups. Each group, however, still has
full visibility of the activity of other groups and is kept fully aware of
all changes that affect its own work. Automatic metric extraction can
contribute further to improving estimation.
Figure 2.1: How UML Started
2.3 How UML Started

UML came about when James Rumbaugh joined Grady Booch at Rational
Software. They both had object oriented syntaxes and needed to combine
them. Semantically(语义上) they were very similar, it was mainly the sym-
bols that needed to be unified. The result was UML 1.0
Then Ivar Jaconson joined them. He brought with him the syntax for
use cases which was added in UML 1.1. The Object Management Group
adopted the UML1.1 specification in November 1997 making it an indepen-
dent industry standard. Some small changes were made in versions 1.3 and
1.4. Version 2.0 is currently being researched. See Figure. 2.1.
2.4 UML Diagram Types

UML provides a number of diagram types as a mechanism for entering model
elements into the model and showing overlapping sets of models elements and
2.4. UML DIAGRAM TYPES 25
their relationships. UML does not specify what diagrams should be created
or what they should contain, only what they can contain and the rules for
connecting the elements. the diagram types include:
• Use Case Diagrams — shows an outside-in(里面翻到外面的, 彻底

的) view of the procedures available in the use of the system. These
are summary diagrams and between them should contain all use cases
available in the system and so all the available functionality of the
system, represented at a high level.
• Static Structure Diagram — includes object and class diagrams. Most

methods use class diagrams to describe the properties of the objects in
the system and their relationships. Object diagrams are rarely used,
except for examples of the way in which object interact, and these are
normally shown on sequence or collaboration diagrams
• Interaction Diagrams — these include collaboration and sequence dia-

grams, both of which show the way in which objects interact in order
to fulfil the functionality of the use case
Further diagram types include:
• Activity Diagrams — a generic flow chart used much in business mod-

elling and sometimes in use case modelling to indicate the overall flow
of the uses case. This diagram type replaces the need for dataflow dia-
grams but is not a main diagram type for the purposes of analysis and
design.
• Component Diagrams — shows the types of components, their inter-

faces and dependencies in the software architecture that is the solution
to the application being developed.
• Deployment Diagrams — shows actual computing nodes, their com-

munication relationships and the processes or components that run on
them.
2.5 Business Modelling, Web Applications,

and extending UML
UML can be used to model a business, prior to automating it with computers.
The same basic UML syntax is used, however, a number of new symbols are
added, in order to make the diagrams more relevant to the business process
world. A commonly used set of these symbols is available in current versions
of Rational Rose.1
The most commonly used UML extensions for web applications were de-
veloped by Jim Conallen2 . You can access his own website to learn more
1
IBM Rational Rose 是一个完整的可视建模方案，开发人员、项目经理、工程师和分
析人员可以在提交编码之前对需求和构架进行可视化、理解和改进。
• 支持UML 1.4 的模型驱动开发灵活的实施支持
• 从单独的建模，到设计级代码生成，再到可全面执行的应用程序生成
• Java、C、C++、Visual Basic、Ada、XML、CORBA/IDL、MIDL 的双向工程
• 自动或按需而定的Java 同步
• 与领先的IDE 集成
• 基于UML 的数据建模
• 用领先的数据库管理系统进行数据模型同步
• 对Java 和Visual C++ 提供Gang of Four (GoF) 设计模式的支持
• 多用户支持Web 发布和生成报告
2
Jim Conallen is a software engineer in IBM Rational’s Model Driven Development
2.6. USE CASE DIAGRAM 27
about them by following the link. These symbols are also available in cur-
rent versions of Rational Rose.
UML is designed to be extended in this way. Extensions to the syntax are
created by adding “stereotypes(固定形式)” to a model element. The stereo-
type creates a new model element from an existing one with an extended,
user-defined, meaning. User defined symbols, which replace the original UML
symbol for the model element, can then be assigned to the stereotype. UML
itself uses this mechanism, so it is important to know what stereotypes are
predefined in UML in order not to clash with them when creating new one.
Stereotypes allow the UML syntax to be used to model anything.
2.6 Use Case Diagram

The use case diagram show the functionality of the system from an outside-in
viewpoint. See an example of use case diagram in Figure. 2.2.
• Actors (stick men) are anything outside the system that interacts with
the system.
• Use Cases (ovals) are the procedures by which the actors interact with
the system
• Solid lines indicate which actors interact with the system as part of
which procedures
• Dotted lines show dependencies between use cases, where one use case
is “included” in or “extends” another.
Strategy team, where he is actively involved in applying the Object Management Group’s
(OMG) Model Driven Architecture (MDA) initiative to IBM Rational’s model tooling.
Figure 2.2: Use Case Diagram
A use case can be related to another use case by either an “include” or

an “extend” relationship.
An “include” relationship indicates that the procedure of the used use

case is part of the procedure of the using use case. The arrow is, in effect, an
unconditional call to the procedure in the used use case. An example of the
include relationship is illustrated in Figure. 2.3 in which use case 1 includes
use case 2.
If the procedure of the use case is an alternative or partial alternative

course to a procedure defined in another use case, then an “extends” rela-
tionship is used from the “extending” use case to the “extended” use case.
The procedure in the “extending” used case then replaces all or part of the
procedure in the “extended” use case under conditions specified in the “ex-
tending” use case. This is illustrated in Figure. 2.3 in which use case 3
extends use case 1.
2.7. CLASS DIAGRAMS 29
Figure 2.3: The Extend and Include Relationships Among Use Cases
Include and extend relationships allow all possible procedures to be spec-

ified without duplication.
The boundaries of the system are illustrated in a use-case diagram as a
boundary rectangle including the use cases with the actors outside of it. The
name of the system appears at the top of the rectangle. A typical use-case
diagram incorporating the boundary rectangle appears in Figure. 2.4.
Associated with a use-case diagram is usually the corresponding use-case
detail. The details may be captured as either a sequence diagram or in a
textual description.
2.7 Class Diagrams

Class diagrams show the static structure of the systems. In other words, it
describes how the system is structured instead of how it behaves. It describes
“what things are” and their relationships with other things. To describe all
the objects in a system would be rather tedious as many of them have similar
characteristics, and, in any case, some of them are created and destroyed as
Figure 2.4: Use-Case Diagram for a Registration System.

Figure 2.5: Class Diagram
a program proceeds. Class diagrams are, therefore, used more often than
object diagrams to show this view3 .
Classes define the properties of the objects which belong to them. See
Figure. 2.5. These include:
• Attributes - (second container) the data properties of the classes in-

cluding type, default value and constraints
• Operations - (third container) the signature of the functionality that

can be applied to the objects of the classes including parameters, pa-
rameter types, parameter constraints, return types and the semantics.
• Associations - (solid lines between classes) the references contained

3
Actual objects become important when they interact with other objects, so it is more
useful to view then in interaction diagrams.
Figure 2.6: UML Notation for Objects
within the objects of the classes to other objects enabling interaction

with those objects.
2.7.1 Class
A class represents entities with common characteristics and behaviors(i.e.,

attribute, services, rules, and relationships). The following paragraphs de-
scribe how objects, class, and parameterized classes are documented in UML.
Figure. 2.6 illustrates how objects are represented in UML. An object is
illustrated as a rectangle with the name underlined. The full name of an
object is the object name and the class name separated by a colon. In some
cases, either the object name or the class name is not present. In all cases
(and diagrams illustrating objects), the name of the object is underlined to
distinguish it from a class.
In UML a class may appear in multiple diagrams. One result of this pos-
sibility is that different diagrams may suppress(抑制, 忍住; 隐瞒) all or some
attributes or operations. If a single attribute or operation is given, the rect-
angle for the class is partitioned into three sections. An empty section does
not mean that there is no attributes or operations associated with the class,
only that they have not been shown in that diagram. Figure. 2.7 illustrates
two ways in which classes are represented in UML diagrams. The first exam-
ple illustrates how a class is represented when the attributes and operations
Figure 2.7: UML Representations for Classes
associated with the class are suppressed. The second example illustrates a
class with the attributes and operations represented. In the second example,
the name of the class appears in the top section, the attributes in the middle
section, and the operation in the bottom section.
Attributes are specified according to the following notation:
Visibility name: type = default-value
where,
• visibility is public (+), protected (#), or private(-)4
• name is a string by which the attribute is identified
• type is the attribute type
• default-value is a value assigned to the attribute unless specified oth-

erwise.
4
The visibility parameter does not have rigorous semantics in UML. In fact, the inter-
pretation of this parameter is usually locally defined base on the semantics of visibility
employed by the programming language used in implementation. Hence, a C++ oriented
development organization and a Smalltalk-oriented development organization may use the
same visibility for an attribute, but mean different things by it.
At a minimum, the name os the attribute must be specified. The other

fields are optional5 . A derived attribute, one that is computed rather than
stored, is indicated by a “/” before the attribute declaration.
Operations are specified according to the following notation:
visibility name (parameter-list) : return-type [property-string]
where,
• visibility is public (+), protected (#), or private (-)
• name is a string by which the operation is identified
• parameter-list contains comma-separated parameters whose syntax

is given by
direction name: type = default-value
– direction indicates if the parameter is for input (in), output(out),

or both(in out)
– name is the name of the parameter
– type is the type of the parameter
– default-value identifies the default value of the parameter
• return-type is a comma-separated list of return types
• property-list indicates property values that apply to the operation.

5
We should not be concerned with identifying the type associated with an attribute
with an attribute during analysis as that is a design decision. Because class diagrams
are used during analysis and design, UML must support documenting our model with the
appropriate levels of detail.
Figure 2.8: Attaching a Constraint on the class
Figure 2.9: Package Diagram.
As was the case with attributes, only the name of the operation must be
specified; the other fields are optional.
Figure. 2.8 illustrates how a constraint can be attached to a class. Any-
thing may appear within the brace identifying the constraint. Most practi-
tioners use a textual description of the constraint.
Figure. 2.9 shows a package diagram. According to the UML specification,
a package is illustrated using a folder-style icon. When the classes contained
within the package are suppressed, the name of the package goes in the center
of the folder. When the classes are present, the name of the package goes in
the tab portion of the folder. Dependencies between packages are illustrated
Figure 2.10: Associations in UML.
as a dashed arrow pointing in the direction of the dependency.
2.7.2 Relationships
Relationships can exist between instances of classes or between classes. As-

sociations(联系) and aggregations(聚合) are relationships that relate two
or more other instances of classes(association and aggregation). Generaliza-
tion(一般化, 普遍化, 概括) and specialization are relationships(特殊化, 专
门化) between two classes.
Figure. 2.10 illustrates the basic representation of an association in UML.
An association is drawn as a line connecting two classes. The line is labelled
with the name of the association, the multiplicities of the two classes(number
of objects of the given class) participating in the association, and the roles
that an instance of each class takes within the association. All of these labels
are optional.
The multiplicity associated with one end of an association can be given
Table 2.1: Multiplicity Keys and Their Interpretation

Key Interpretation
* Any number of objects (including none)
1 Exactly one object
n Exactly n objects (n is an integer)
1...1 Zero or one (indicates the association is optional)
n...m Range from n as minimum to m as maximum(n and m are integers)
2, 4 Discrete combination(as two doors or four doors)
Figure 2.11: Unidirectional Association
in any of the forms identified in Table. 2.1.

The default assumption about an association is that it can be traversed
by an object at either end of the association. In many cases, this assumption
is not valid. To indicate unidirectional traversal the line connecting the two
classes is replaced by an arrow pointing in the direction of traversal. This is
illustrated in Figure. 2.11.
Figure. 2.12 illustrates how an association class is expressed. The associ-
ation class is connected to the link between the two classes participating in
the association by a dashed line. The association class can have attributes
and operations associated with it.
Figure. 2.13 shows an association class that has been promoted to a full
class. A derived association has been introduced to capture the fact that
there is an association between Class A and Class B. The derived association
Figure 2.12: Association Class
Figure 2.13: Promoting an Association Class to a Full Class and Introducing

a Derived Association.
Figure 2.14: Qualified Association

Figure 2.15: Aggregation and Composition
Figure 2.16: Generalization and Specialization
Figure 2.17: Dependency

Figure 2.18: Interface Diagram Using Classes
Figure 2.19: Alternative Form for Representing Interface

2.8. SUMMARY 41
is denoted through the use of a “/” in front of the association name.

Figure. 2.14 illustrates the diagram for a qualified association. Qualifiers
can be used to denote key lookup in a map.
Figure. 2.15 illustrates how aggregation and composition are documented.
Unidirectional navigation across the aggregation or composition is illustrated
using an arrow in the same manner as for associations.
Figure. 2.16 shows generalization and specialization. The generalization
is indicated as the class with the point of the triangle pointing at it. Sub-
class 1 illustrates single generalization, while Subclass 2 illustrates multiple
generalization. Generalization can have a discriminator that distinguishes
between different kinds of generalizations.6
Figure. 2.17 illustrates how dependencies between classes are documented.
Dependencies are typically associations that are created dynamically.
Figure. 2.18 illustrate how an interface can be specified using classed. The
dashed line with triangle at the end is used to indicate that implementation
class realizes the interface. An alternative way of documenting interfaces
uses a lollipop style icon to represent the interface as show in Figure. 2.19.
2.8 Summary
• UML is just a syntax. It says nothing about how too create a model.
• UML is well documented but little understood.
• It was developed by Grady Booch, Jim Rumbaugh and Ivar Jacobon

6
This diagram can be used to express multiple and dynamic classification. For this
diagram, one employs a discriminator to establish which combinations are legal. Classifi-
cation is different than inheritance, in the sense that multiple classification allows types
for an object without defining a specific type for that purpose.
at Rational Software.
• UML specifies 8 different diagram. Not all are used in practice.
• UML can be extended through the use of stereotypes.
• A use case diagram show the functionality of the system from the out-
side in.
• Class diagrams show the static structure of the systems.
2.9 Quiz
1. Interaction diagrams include
(a) Collaboration and class diagrams
(b) Statecharts and sequence diagrams
(c) Sequence and class diagrams
(d) Collaboration and Sequence diagrams
(e) Class and object diagrams
2. UML is
(a) Language independent
(b) Process independent
(c) Easy to apply
(d) 2b and 2c
(e) 2a and 2b
3. The UML is currently controlled by

2.9. QUIZ 43
(a) Rational Software
(b) The Object Management Group
(c) James Rumbaugh
(d) Grady Booch
(e) Ivar Jacobson
4. Which of the following statements is true?
(a) Object diagrams are the most important diagram type
(b) Collaboration diagrams show the relationship between states for

a given object
(c) Flowcharts are used to show the order in which objects interact
(d) Activity diagrams can be used to show the overall flow of a use
case
(e) Deployment diagrams show the order in which functionality will

be made available to users
5. UML can be extended using stereotypes and used for
(a) Business modelling
(b) Web Applications
(c) 5a and 5b
(d) Any problem domain
6. A use case is
(a) A sequence of interactions between actors and the system

(b) A procedure by which actors interact with the system
(c) The way an actor to achieves the goal that is the name of the use
case
(d) A way of grouping together functional requirements
(e) All of the above
7. An association between two classes on a class diagram
(a) Allows interaction between the two classes
(b) Allows interaction between the objects of the two classes
(c) Shows inheritance between the two classes
(d) 7a and 7b
(e) 7b and 7c
Chapter 3
UML - Part 2
This chapter explains the rest of the different kinds of diagrams available
within UML.
3.1 Sequence Diagram
Sequence diagrams show potential interactions between objects in the system

being defined. Normally these are specified as part of a use case or use case
flow and show how the use case will be implemented in the system. See
Figure. 3.1. They include:
• Objects — rectangular boxes at the top or actors, named or just shown

as belonging to a class from or to which messages are sent to other
objects.
• Messages — solid lines for calls and dotted lines to data returns, show-
ing the messages that are send between objects. This includes the order
of the messages which is from top of the diagram to the bottom.
45
Figure 3.1: Sequence Diagram
• Object lifelines — dotted vertical lines showing the lifetime of the ob-
jects.
• Activation — the vertical oblong boxes on the object lifelines showing

the thread of control in a synchronous system.
A sequence diagram, such as shown in Figure. 3.1, is a diagram that shows

actual objects and interactions between objects in the horizontal direction
and sequence in the vertical direction. The vertical dotted lines represent
the lifetime of the object and the horizontal arrows the interactions of mes-
sages between objects. These messages can represent any kind of message
(specifically a call to an operation on the target object). Messages can in-
clude sequence numbers, operation names, and actual parameters. Narrow
elongated boxes on the object lifelines represent the “activation” of the ob-
ject when interactions are sequential and represent calls to operations. The
3.2. COLLABORATION DIAGRAM 47
Figure 3.2: Sequence Diagram For Using a Microwave Oven
operation remains active until all the sequential operations, which it calls,
have completed and returned, thus, allowing it to return control to its caller.
Figure. 3.2 shows a typical sequence diagram for using a microwave oven.
3.2 Collaboration Diagram
Collaboration Diagrams show similar information to sequence diagrams, ex-

cept that the vertical sequence is missing. See Figure. 3.3. In its place are:
Figure 3.3: Collaboration Diagram
• Object Links — solid lines between the objects. These represent the
references between objects that are needed for them to interact and so
show the static structure at object level. On the links are:
• Messages — arrows with one or more message name that show the
direction and names of the messages sent between objects
A collaboration diagram is functionally equivalent to a sequence diagram

with two exceptions:
• It shows links between objects along which messages can flow whereas
only the messages are shown in a sequence diagram.
item The order of the messages can only be seen in their numbering as
the vertical dimension is used to show static relationships along with
the horizontal dimension.1
A collaboration diagram is used to show how groups of objects work

together to perform a piece of functionality required for one path through a
1
This makes the collaboration diagram effectively an object diagram with messages on
the links.
3.2. COLLABORATION DIAGRAM 49
use case.2
The concepts and paths in this diagram are
• Object of a particular type (class or interface), represents the role that

the object plays in the interaction.
• Relationship role, represents role that the link may play within the
interaction.
• Message, represents communication between object.
Figure. 3.3 illustrates a collaboration diagram. The service request is of

the form:
sequence-number : [condition] : message (arglist)
where
• sequence-number indicates the order in which the service request

was dispatched
– “*” is used to indicate iteration (for example, 2* indicates that

the second service request repeats)
– sequence numbers can be sequential integers or based on a decimal

scheme
• condition is an optional condition that is to be evaluated to determine

if the request is sent
• message is a string identifying the service request
• arglist is a list of arguments formulated in the same fashion as the

arglist for an operation
2
Sequence diagrams are better for fully specifying a use case as they can include con-
ditional functionality in various ways without confusing the order of the messages.
3.3 Statechart Diagram

Statecharts, often used more in embedded systems than in information sys-
tems, show, for a class, the order in which incoming calls to operations nor-
mally occur, the conditions under which the operations respond and the
response. They are a class-centric view of system functionality as opposed
to sequence and collaboration diagrams which are a use case-centric view of
functionality. See Figure. 3.4. They include:
• States — rounded boxes which indicate the stable states of the object
between events. A state represents a period between events during the
object is stable. If an object has many internal states, the state model
can be simplified by using “nested state” within a simpler state model.
• Transitions — the solid arrows which show possible changes of state.

A transition represents a response by an object to an event received by
it. The response produces a change in the object, which can constitute
change in state. The mechanism for identifying if a change in state
occurs is a guard condition. A guard condition is a Boolean expression
in terms of event parameters and the state variables and the functions of
the object to which the state diagram belongs. When an event triggers
the transition, the value of the guard condition is evaluated. If the
value evaluates to true, the transition occurs; otherwise, the transition
does not occur. Not all transitions have an associated guard condition.
• Events — the text on the transitions before the “/” showing the in-
coming call to the object interface which causes the change of state.
• Conditions — a boolean statement in square brackets which qualifies

the event.
3.3. STATECHART DIAGRAM 51
Figure 3.4: Statechart Diagram
• Actions — the text after the “/” which represents a set of operations
that is done inside of a state or on a transition.
• Extra syntax which defines state centric functionality
In UML, three additional constructs are added: history state, activity

and timing mark.
• A history state is used to capture the concept that a state must

“remember” its sub-state when it is exited and be able to enter the
same sub-state on subsequent reentry into the state.
• An activity is an operation or set of operations within a state that

takes time to complete; thus, it is not instantaneous and can be in-
terrupted. Some activities continue until they are terminated by an
external event (usually a state change) and others terminate on their
own accord.
• a timing mark construct is used to capture real-time constraints on

transition. The most common use of a timing mark is to capture the
maximum limits in the elapsed time between events.
3.4 Activity Diagram

A UML Activity Diagram is a general purpose flowchart with a few extras.
It can be used to detail a business process or to help define complex iteration
and selection in a use case description. See Figure. 3.5. It includes:
• Active states — oblongs with rounded corners which describe what is

done.
• Transitions — which show the order in which the active states occur
and represent a thread of activity.
• Conditions — (in square brackets) which qualify the transitions.
• Decisions — (nodes in the transitions) which cause the thread to select

one of multiple paths.
• Swimlanes — (vertical lines the length of the diagram) which allow

activities to be assigned to objects.
• Synch States — horizontal or vertical solid lines which split or merge

threads (transitions)
An activity diagram is similar to a state diagram in that they represent

sequences of activity but are closer in semantics to flowcharts in allowing
action state. Swimlanes allow activities associated with action states to be
assigned to business level actors.
Figure. 3.5 shows a basic activity diagram. The solid circle at the top
indicates the start point. The rounded rectangles identify activities. The
arrows represent a transition. Conditional behavior is identifies by branches
and mergers. A diamond represents a branch point if one arrow enters and
multiple arrows exit or a merge if several arrows enter and one arrow exits.
3.5. COMPONENT DIAGRAM 53
Concurrent behavior is identified by forks and joins. A dark bar represents a

fork is on arrow enters and multiple arrows exit or a join if multiple arrows
enter and a single arrow exits.
3.5 Component Diagram

Component Diagrams show the types of software components in the sys-
tem, their interfaces and dependencies. Figure. 3.6 illustrates a component
diagram. The concepts and paths in this diagram are
• Component, which represents distributable physical units such as

source code, object code, or executable code.
• Dependency, which represents the dependency between components.
If a group of classes forms a component, we may define another way in

which other components use it by applying a special UML construct: an
interface. The interface allows components to be designed for use by other
components without any knowledge of the internal structure of the used
component. Thus, the using component depends on the interface to the used
component, not on its implementation. This makes it possible to design
components that are polymorphic (i.e., substitutable for one another).
3.6 Deployment Diagram

Deployment diagrams show the computing nodes in the system, their com-
munication links, the components that run on them and their dependencies.
Figure. 3.7 illustrates a deployment diagram. It consists of two processors
with a single component on each. The processors are connected by (TCP/IP).
Figure 3.5: Activity Diagram

3.6. DEPLOYMENT DIAGRAM 55
Figure 3.6: Component Diagram

Figure 3.7: Deployment Diagram
There is a dependency between the Graphical User Interface(GUI) compo-

nent on the central processing unit (CPU) 2 with the myComponent on CPU
1.
3.7 Modelling Architecture
Class diagrams can be used to model hi-level architecture with packages,

interfaces and dependencies. Packages are used to group together a set of
model elements for various purposes. Figure. 3.8. The results may show:
• Subsystems — the design view of a software component or re-useable

part of a component.
• Libraries of re-useable elements, usually classes.
• The hierarchic structure and layering of the system
• Client-server relationships between components and other model ele-

ments
• Logical dependencies of sub-systems and libraries on one another

3.7. MODELLING ARCHITECTURE 57
Figure 3.8: Modelling Architecture

3.8 Summary
• Sequence diagrams show potential interactions between objects in the
system in the order in which they normally occur.
• Collaboration diagrams also show interaction between objects, but em-

phasize the structure required to support them.
• Statecharts are a class-centric view of system functionality.
• An activity diagram is as general purpose flowchart.
• Component diagrams show the types of software components in the

system, their interfaces and dependencies.
• Deployment diagrams show the computing nodes in the system, their

communication links, the components that run on them and their de-
pendencies.
• Class diagrams can be used to model hi-level architecture with pack-

ages, interfaces and dependencies.
3.9 Quiz
1. The activation on a sequence diagram shows
(a) The messages between objects
(b) The objects involved in a use case
(c) The thread of control in the sequence
(d) The condition under which an operation is executed

3.9. QUIZ 59
2. A collaboration diagram shows
(a) The thread of control between objects
(b) References between objects
(c) Similar information to sequence diagrams
(d) 2a and 2b
(e) 2b and 2c
3. An event on a statechart shows
(a) What caused the transition
(b) What caused the change of state
(c) The action performed on the transition
(d) 3a and 3b
(e) 3b and 3c
4. In an activity diagram, which of the following is true?
(a) A synch state defines a stable state of the system
(b) A swim lane can be used to show object interaction
(c) A condition qualifies a transition
(d) A decision splits the thread into concurrent threads
(e) A transition shows a stable state of the system
5. A component diagram shows:
(a) Classes and their relationships
(b) The types of components in the system

(c) Dependencies between components
(d) 5a and 5b
(e) 5b and 5c
6. Which of the following is true?
(a) Packages appear on sequence diagrams
(b) Dependencies appear on class diagrams
(c) Packages show client-server relationships between components
(d) 6a and 6b
(e) 6b and 6c
7. Computing nodes on a deployment diagram
(a) Show connections between components
(b) The components that run on computers
(c) What communication links are available between subsystems
(d) What processors are available
(e) What communication links are available between computers

Chapter 4
The Software Development

Process
In order to make the development of software predictable and repeatable, a

process is needed which defines what is done by whom and in what order.
When using UML this revolves around the creation of models at different
levels of abstraction and increasing levels of detail. This chapter takes you
through each step of the process, shows what models are created, and how
information flows between them.
4.1 Business Process Modelling
A Business Model may be created to better understand the business, either

for the purpose of improving the business itself, or as a way of discovering
requirements for a computer system. Business processes can be modelled at
various levels within the organization. The model uses all the standard rules
of UML and includes some user defined extensions. See Figure. 4.1. The
differences include:
61
62 CHAPTER 4. THE SOFTWARE DEVELOPMENT PROCESS
Figure 4.1: Business Model
• Slightly different symbols for business actors and business use cases
(also known as business processes).
• Some of Jacobson’s stereotypes with additions to represent business

entities and business workers.
• The system boundary is now the business or the part of the business
being modelled.
4.2 System Requirements Definition

Implementation constraints are modelled separately from the use case model.
The logical functional requirements of a systems are modelled using use cases
and use case descriptions — documents associated with the use case giving a
detailed textual description of the use case flow and other logical constraints.
Using use cases for the logical requirements has a number of advantages:
4.3. THE SYSTEM ANALYSIS MODEL 63
• It is an outside-in view and easily understood by non-technical people.
• It is more likely to be complete than a classical functionally decomposed

specification.
• It directly maps into and is traceable to acceptance tests, user docu-

mentation and the analysis and design models.
4.3 The System Analysis Model

The System Analysis Model is made up of class diagrams, sequence or col-
laboration diagrams and statechart diagrams. Between them they constitute
a logical, implementation-free view of the computer system that includes a
detailed definitions of every aspect of functionality. This model:
• Defines what the system does not how it does it.
• Defines logical requirements in more detail than the use case model,
rather than a physical solution to the requirements.
• Leaves out all technology detail, including system topology.
4.4 System Model Information Flow

Figure. 4.2 illustrates the way in which the 3-dimensional system model is
developed iteratively from the uses case model in terms of the information
which flows between each view. Note that it is not possible fully to develop
any one of the three views without the other two. They are interdependent.
This is the reason why incremental and iterative development is the most
efficient way of developing computer software.
Figure 4.2: System Model Information Flow
4.5 The System Design Model

This model is the detailed model of everything that is going to be needed to
write all the code for the system components. It is the analysis model plus
all the implementation detail. Preferable it should be possible automatically
to generate at least frame code from this model. Then if any structural
changes to the code are made in the design model first and then forward
re-generated, this ensures that the design model accurately reflects the code
in the components. The design model includes:
• Class, sequence or collaboration and state diagrams, as in the analysis

model, but now fully defined ready for code generation.
• Component diagrams defining all the software components, their inter-

faces and dependencies.
• Deployment diagrams defining the topology of the target environment

4.6. OVERALL PROCESS FLOW 65
Figure 4.3: Overall Process Flow
including which components will run on which computing nodes.
4.6 Overall Process Flow
The overall process flow must allow for both rework and incremental devel-
opment. See Figure. 4.3.
• Rework — where changes need to be made, the earliest model that the
change affects is changed first and the results flowed forward through
all the other models to keep them up to date.
• Incrementation — increments can restart at any point, dependent on

whether the work needed for this increment has already been completed
in higher level models.
4.7 Incremental Development

Incremental Development is based on use cases or use case flows which define
working pieces of functionality at the user level. In an increment, the models
required to develop a working software increment are each incremented until
a working, tested executing piece of software is produced with incremental
functionality. This approach:
• Improves estimation, planning and assessment. Use cases provide bet-

ter baselines for estimation than traditionally written specifications.
The estimates are continuously updated and improved throughout the
project.
• Allows risks to the project to be addressed incrementally and reduced

early in the life-cycle. Early increments can be scheduled to cover the
most risky parts of the architecture. When the architecture is stable,
development can be speeded up.
• Benefits users, managers and developers who see working functionality

early in the life-cycle. Each increment is, effectively, a prototype for
the next increment.
4.8 Summary
• A software process is needed to make a software development pre-
dictable and repeatable.
• UML can be used to model business processes and structure.
• Functional requirements are defined with use cases and use case de-
scriptions.
4.9. QUIZ 67
• A system analysis model is a technology-free model of the detail of

what the system will do.
• The system design model is a detailed model of the software structure

of the system down to class property level.
• The use case model feeds the object, interaction and state models which
are interdependent.
• The classic waterfall process should be augmented by both rework (it-

erative) and incremental loops.
• Incremental development improves estimation, planning, assessment

and software quality.
4.9 Quiz
1. Business process modelling of use cases uses
(a) The same symbols as used in analysis
(b) Similar symbols with additions
(c) Different symbols entirely
(d) Doesn’t use symbols
2. System requirements defined with use cases map directly into
(a) User documentation
(b) System acceptance tests
(c) The analysis model
(d) The design model

(e) All of the above
3. The system analysis model leaves out
(a) Topology
(b) Technology
(c) Functionality
(d) 3a and 3b
(e) 3b and 3c
4. Information flows from the interaction model to the
(a) state model
(b) object model
(c) use case model
(d) 4a and 4b
(e) 4b and 4c
5. The UML system design model may include
(a) 1 diagram type
(b) 2 diagram types
(c) 3 diagram types
(d) 4 diagram types
(e) 5 diagram types
6. An increment starts at
4.9. QUIZ 69
(a) requirements
(b) analysis
(c) design
(d) coding
(e) any point in the waterfall
7. A increment produces
(a) increased system functionality
(b) a working executable
(c) a tested executable
(d) implemented use cases
(e) all of the above

Appendix A
Answers
• Chapter 1: 1b, 2c, 3d, 4c, 5d, 6c, 7c, 8d
• Chapter 2: 1d, 2e, 3b, 4d, 5d, 6e, 7b
• Chapter 3: 1c, 2e, 3d, 4c, 5e, 6b, 7d
• Chapter 4: 1b, 2e, 3e, 4d, 5e, 6e, 7e
71
72 APPENDIX A. ANSWERS
Appendix B
CRC
B.1 Introduction
It is difficult to introduce both novice and experienced procedural program-

mers to the anthropomorphic perspective necessary for object-oriented de-
sign. We introduce CRC cards, which characterize objects by class name,
responsibilities, and collaborators, as a way of giving learners a direct expe-
rience of objects. We have found this approach successful in teaching novice
programmers the concepts of objects, and in introducing experienced pro-
grammers to complicated existing designs.
B.2 Problem
The most difficult problem in teaching object- oriented programming is get-

ting the learner to give up the global knowledge of control that is possible
with procedural programs, and rely on the local knowledge of objects to ac-
complish their tasks. Novice designs are littered with regressions to global
thinking: gratuitous global variables, unnecessary pointers, and inappropri-
73
74 APPENDIX B. CRC
ate reliance on the implementation of other objects. Because learning about

objects requires such a shift in overall approach, teaching objects reduces to
teaching the design of objects. We focus on design whether we are teaching
basic concepts to novices or the subtleties of a complicated design to experi-
enced object programmers. Rather than try to make object design as much
like procedural design as possible, we have found that the most effective way
of teaching the idiomatic way of thinking with objects is to immerse the
learner in the ”object-ness” of the material. To do this we must remove as
much familiar material as possible, expecting that details such as syntax and
programming environment operation will be picked up quickly enough once
the fundamentals have been thoroughly understood. It is in this context that
we will describe our perspective on object design, its concrete manifestation,
CRC (for Class, Responsibility, and Collaboration) cards, and our experience
using these cards to teach both the fundamentals and subtleties of thinking
with objects.
B.3 Perspective
Procedural designs can be characterized at an abstract level as having pro-

cesses, data flows, and data stores, regardless of implementation language or
operating environment. We wished to come up with a similar set of funda-
mental principles for object designs. We settled on three dimensions which
identify the role of an object in a design: class name, responsibilities, and col-
laborators. The class name of an object creates a vocabulary for discussing
a design. Indeed, many people have remarked that object design has more
in common with language design than with procedural program design. We
urge learners (and spend considerable time ourselves while designing) to find
B.4. CRC CARDS 75
just the right set of words to describe our objects, a set that is internally
consistent and evocative in the context of the larger design environment.
Responsibilities identify problems to be solved. The solutions will exist in
many versions and refinements. A responsibility serves as a handle for dis-
cussing potential solutions. The responsibilities of an object are expressed
by a handful of short verb phrases, each containing an active verb. The more
that can be expressed by these phrases, the more powerful and concise the
design. Again, searching for just the right words is a valuable use of time
while designing. One of the distinguishing features of object design is that no
object is an island. All objects stand in relationship to others, on whom they
rely for services and control. The last dimension we use in characterizing
object designs is the collaborators of an object. We name as collaborators
objects which will send or be sent messages in the course of satisfying re-
sponsibilities. Collaboration is not necessarily a symmetric relation. For
example in Smalltalk- 80, View and Controller operate as near equals (see
example below) while OrderedCollection offers a service with little regard or
even awareness of its client. Throughout this paper we deliberately blur the
distinction between classes and instances. This informality is not as confus-
ing as it might seem because the concreteness of our method substitutes for
naming of instances. This also makes our method for teaching independent
of whether a class or prototype-based language is used.
B.4 CRC Cards
The cards started as a HyperCard stack which provided automatic indexing

to collaborators, but were moved to their current form to address problems of
portability and system independence. Like our earlier work in documenting
76 APPENDIX B. CRC
Figure B.1: A Class-Responsibility-collaborator (CRC) index card
the collaboration of objects, CRC cards explicitly represent multiple objects

simultaneously. However, rather than simply tracing the details of a col-
laboration in the form of message sending, CRC cards place the designer’s
focus on the motivation for collaboration by representing (potentially) many
messages as a phrase of English text.
A Class-Responsibility-collaborator (CRC) index card As we currently
use them, all the information for an object is written on a 4” x 6” index card.
These have the advantages that they are cheap, portable, readily available,
and familiar. Figure. B.1 shows an idealized card. The class name appears
underlined in the upper-left hand corner, a bullet- list of responsibilities
appears under it in the left two-thirds of the card, and the list of collaborators
appears in the right third.
CRC-cards describing the responsibilities and collaborations of Smalltalk’s
Model, View and Controller. Figure.B.2 shows an example taken from the
B.4. CRC CARDS 77
Figure B.2: CRC-cards describing the responsibilities and collaborations of

Smalltalk’s Model, View and Controller.
78 APPENDIX B. CRC
Smalltalk-80 image, the much-misunderstood model-view-controller user in-

terface framework. We have deliberately shown only a portion of the respon-
sibilities each of these objects assumes for clarity of exposition. Note that
the cards are placed such that View and Controller are overlapping (implying
close collaboration) and placed above Model (implying supervision.) We find
these and other informal groupings aid in comprehending a design. Parts,
for example, are often arranged below the whole. Likewise, refinements of
an abstraction can be collected and handled as a single pile of cards with
the most abstract card on top where it can represent the rest. The ability to
quickly organize and spatially address index cards proves most valuable when
a design is incomplete or poorly understood. We have watched designers re-
peatedly refer to a card they intended to write by pointing to where they will
put it when completed. Design with the cards tends to progress from knowns
to unknowns, as opposed to top-down or bottom up. We have observed two
teams arriving at essentially the same design through nearly opposite se-
quences, one starting with device drivers, the other with high-level models.
The problem demanded a certain set of capabilities which both teams dis-
covered in the course of fulfilling the requirements of the design. We suggest
driving a design toward completion with the aid of execution scenarios. We
start with only one or two obvious cards and start playing ”what-if”. If the
situation calls for a responsibility not already covered by one of the objects
we either add the responsibility to one of the objects, or create a new object
to address that responsibility. If one of the object becomes too cluttered dur-
ing this process we copy the information on its card to a new card, searching
for more concise and powerful ways of saying what the object does. If it
is not possible to shrink the information further, but the object is still too
complex, we create a new object to assume some of the responsibilities. We
B.5. EXPERIENCE 79
encourage learners to pick up the card whose role they are assuming while
”executing” a scenario. It is not unusual to see a designer with a card in each
hand, waving them about, making a strong identification with the objects
while describing their collaboration. We stress the importance of creating
objects not to meet mythical future needs, but only under the demands of
the moment. This ensures that a design contains only as much information
as the designer has directly experienced, and avoids premature complexity.
Working in teams helps here because a concerned designer can influence team
members by suggesting scenarios aimed specifically at suspected weaknesses
or omissions.
B.5 Experience
One of the contexts in which we have used CRC cards is a three-hour class
entitled ”Thinking with Objects,” which is intended for computing profes-
sionals who have programmed, but whose jobs do not necessarily involve
programming every day. The class proceeds by introducing a data flow ex-
ample (a school, with processes for teaching and administration) which is
then recast in terms of objects with responsibilities and collaborators (such
as Teacher, Janitor, and Principal). The class then pairs off and spends an
hour designing the objects in an automatic banking machine, an exercise
chosen because of everyone’s familiarity with the application and its ready
breakdown into objects to control the devices, communicate with the central
bank database, and control the user interface. (See the appendix for a sam-
ple solution.) The exercise is followed by a definition of the terms ”class”,
”instance”, ”method”, and ”message”, and the class concludes with a brief
discussion of the history and features of a variety of object- oriented pro-
80 APPENDIX B. CRC
gramming languages. In teaching over a hundred students this course we

have encountered no one who was unable to complete the exercise unaided,
although one pair in each class usually needs a few hints to get started. Al-
though we have done no follow-up studies, the class is considered a valuable
resource in the company and is still well attended with a long waiting list
almost a year after its inception. We have also asked skilled object pro-
grammers to try using CRC cards. Our personal experience suggests a role
for cards in software engineering though we cannot yet claim a complete
methodology. We- know of one case where finished cards were delivered to a
client as (partial) design documentation. Although the team that produced
the cards was quite happy with the design, the recipient was unable to make
sense of the cards out of context. Another experiment illustrates the im-
portance of the context established by the handling and discussing of cards.
We had videotaped experienced designers working out a problem similar to
the bank machine. Our camera placement made cards and the designers’
hands visible but not the writing on the cards. Viewers of the tape had no
trouble following the development and often asked that the tape be stopped
so that they could express their opinions. The most telling moments came
when a viewer’s explanation required that he point to a blurry card in the
frozen image on the screen. Finally, we have used CRC cards to advantage
in explaining complex designs. A few minutes of introduction is sufficient to
prepare an audience for a card based presentation. Cards can be made out in
advance or written on the spot. The latter allows the complexity in a design
to be revealed slowly, a process related to Dave Thomas’ ”lie management”.
The cards are being used as props to aid the telling of a story of computation.
The cards allow its telling without recourse to programming language syntax
or idiom.
B.6. CONCLUSION 81
B.6 Conclusion
Taking our perspective as a base we give novices and experienced program-
mers a learning experience which teaches them something valuable about
objects. CRC cards give the learner who has never encountered objects a
physical understanding of object-ness, and prepares them to understand the
vocabulary and details of particular languages. CRC cards also give useful
and convincing experience with objects to those who has learned the mecha-
nisms of objects but do not yet see their value. Ragu Raghavan has said that
in the switch to objects strong programmers become stronger, but weaker
programmers are left behind. Using the cards in group settings we found
that even weaker programmers, without a deep understanding of objects,
could contribute to object designs. We speculate that because the designs
are so much more concrete, and the logical relationship between objects ex-
plicit, it is easier to understand, evaluate, and modify a design. We were
surprised at the value of physically moving the cards around. When learners
pick up an object they seem to more readily identify with it, and are pre-
pared to deal with the remainder of the design from its perspective. It is the
value of this physical interaction that has led us to resist a computerization
of the cards. It is just this problem-integrating the cards with larger design
methodologies and with particular language environments, that we feel holds
the most promise for the future. The need to retain the value of physical
interaction points to the need for a new kind of user interface and program-
ming environment as far beyond what we have today as our current systems
are beyond the tool-oriented environments of the past.

Uml

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml

Uploaded by

Copyright:

Available Formats

UML and Object Oriented

July 19, 2006

4 The Software Development Process 61

Abstraction is a fundamental principle of modeling. A system model is cre-

• Looking only at the information that is relevant at the time

• Hiding details so as not to confuse the bigger picture

When we model, we create a number of views of the system being described,

Figure 1.1: Orthogonal View of a Plane

• Each view has information that is unique to that view

• Each view has information that appears in other views

• The information that is common between views is consistent(一致的,

1.3 Model Organization

All model syntaxes(语法, 句法) provide a number of model elements which

Figure 1.2: Model Diagram

1.4 Structured Analysis

• The functional view, made up of data flow diagrams(DFD), is the pri-

• The data view, made up of entity relationship diagrams(ERD), is a

• The dynamic view, made up of state transition diagrams(STD), defines

Traditional Structured Analysis and Design methods tend to fall short

Figure 1.3: Orthogonal Views in Structured Analysis

structured model that satisfies a static requirement. The model is, to a

1.5 Object Orientation

Object Oriented software is based on the static, or object model — the

• Functionality from the interaction model is mapped onto the object

Figure 1.4: Orthogonal Views in Object-Oriented Analysis

The object model is usually less affected by the changes to functional

sulation of objects lends itself to redistribution across distributed platforms

1.6 Encapsulation of Hardware

• Hardware encapsulates data and function at every level of abstraction

• Maximizes maintainability, reuse and extension

1.7 Encapsulation of Software

Figure 1.5: Encapsulation of Hardware

Figure 1.6: Encapsulation of Software

• Solid interface definitions Maximum maintainability, reuse and exten-

Encapsulation of primitive functions, together with the data upon which

If this is achieved, then, the network of objects, which collaborate to provide

• When modelling 2 or 3 orthogonal views of the system are created.

• Diagrams are independent views of the model and may be of different

• In structured analysis the functional view is the primary view of the

• Hardware engineering produces well encapsulated hardware designs

• Applying encapsulation techniques to software encourages maintain-

(a) Looking at things in detail

(b) Looking at relevant information only

(c) Focusing on one detailed point

2. Hiding details is a good idea because

(a) There is no need to worry about them as they are unnecessary

(b) Details are not important

3. In a model made up of multiple views

(a) Each view is a transformation of another view

(b) Views contain unique information

(c) Common information must be consistent

(d) 3b and 3c are true

(e) None of the above

(a) appear on one diagram only

(b) are distributed amongst the diagrams of the model

(c) can appear on multiple diagrams of the same or different types

(d) can appear on multiple diagrams of different types only

(e) 4a and 4b are true

(a) The functional view is the primary view

(b) The data view records what is in the system

(c) The dynamic view describes the flow of data

(d) 5a and 5b are true

(e) 5a, 5b and 5c are true

适应, 容纳) Incremental Development and Re-

• Use Case Diagrams — shows an outside-in(里面翻到外面的, 彻底