Transcript Analysis (Class Diagrams)

Software Engineering
OO Analysis (Object-Relationship and
Object-Behaviour Models)
Objectives
1. To show the object-relationship design process
2. To introduce the core UML class diagram notation
Analysis = Process + Models
Process
Model Output
1. Elicit customer
Use-Case Diagrams
requirements and identify
use-cases
2. Extract candidate classes,
Class Responsibility
Identify attributes and
Collaborator (CRC) Cards
methods, Define a class
hierarchy
3. Build an object-relationship Conceptual Class Diagram
model (structural)
4. Build an object-behaviour
model (dynamic)
Interaction Diagrams
What is structural modeling?
 Structural model: a view of a system that emphasizes the
structure of the objects, including their classifiers,
relationships, attributes and operations.
 Illustrates meaningful concepts in a problem domain
 the most important artifact to create during OO analysis
 usually expressed in the form of static diagrams
 is a representation of real-world things; not software
components
 no operations are defined in conceptual model
 should show concepts, associations between concepts,
attributes of concepts
Class Diagrams
 Descendent of Entity-Relationship Diagrams
 Show the static structure of the model
 the entities that exist
 internal structure
 relationship to other entities
 Static View
 Do not show temporal information
 Used in both analysis (conceptual) and design
(specification and implementation)
 Conceptual class diagrams only require a subset of
the full UML notation
Developing an Object-Relationship
Model
 With reference to the CRC model:
1. An unlabelled network of collaborating classes is
drawn.
2. Connections are named and oriented from client
to server.
3. Each end of a connection is evaluated to determine
cardinality.
UML Class Diagram Example
Label and Navigability
contains u
system
1
1
control
panel
polls u
1
1
sensor
1..*
1
produces
q
recognizes
q
Multiplicity
*
*
Association
audible
alarm
Class
sensor
event
Class
Construct
Description
class
a description of a set of objects that
share the same attributes, operations,
methods, relationships and semantics.
Syntax
 Derived from the CRC Cards:
 Each card represents a class
 Its responsibilities become attributes and methods
 Sections: name, attributes, methods
 BUT don’t provide any details for
the attributes and methods
Name
Attributes
Methods
Association
Construct
Description
association
a relationship between two or more
classifiers that involves connections
among their instances.
Syntax
 Focus on those associations for which knowledge of the
relationship needs to be preserved for some duration
(“need-to-know”)
 It is more important to identify classes than to
identify associations
 Too many associations can be confusing
 Classes may have association with themselves
person
*
1
manages
q
Navigability
 Navigability indicates that it is possible to move
uni-directionally across the association from
objects of the server to client class.
 Indicated by an arrow head
polls u
 Implies visibility; usually attribute visibility.
 For an object A to send a message to B. B must be
visible to A.
Multiplicity
Description
Syntax
An A is always associated with one
B
An A is always associate with one
or more B
An A is associated with zero or one
B
An A is associated with zero, one
or more B
1
1..*
0..1
*

Multiplicity is not always symmetrical. The relationship of B to A may
not be the same as A to B

Example: A system may produce many audible alarms BUT each
audible alarm is produced by only one system.

Use the labels and classes names to help in deciding
Generalization
Construct
Description
generalization a taxonomic relationship between a
more general and a more specific
element.

Generalization: identifying
commonality among classes
and defining supertype and
subtype relationships.

Is-a Rule: use phrase
“Subtype is a Supertype” to
test

100% Rule: all the functionality
of the supertype is true in the
subtype
Syntax
Defining Subtypes
 Additional Information:
 The subtype has additional attributes of interest
 The subtype has additional associations of interest
 Additional Behaviour:
 The subtype is operated upon, handled, reacted to, or
manipulated differently than the supertype or other
subtypes
Defining Supertypes
 The potential subtypes represent variations on a
similar concept.
 The subtypes will conform to the 100% and Is-a
rules.
 All subtypes have some attributes (and methods)
which can be factored out and expressed in the
supertype.
 All subtypes have the same association with
another class which can be factored out and
related in the supertype.
Aggregation
Construct
Description
aggregation
A special form of association that
specifies a whole-part relationship
between the aggregate (whole) and
the component part.
Syntax
 A composite aggregation (filled diamond) means
that the multiplicity at the composite end may be
at most one.
 Shared aggregation (hollow diamond) means that
the multiplicity at the composite end may be more
than one.
Aggregation Guidelines
 There is an obvious physical or
logical assembly
 The part and composite have the
same lifetime
 Some properties of the composite
propagate to the parts. Example:
the limbs of a robot are offset
from a common origin
 Operations applied to the
composite propagate to the parts
such as destruction, movement,
recording. Example: moving the
torso of a robot also moves the
attached limbs
Package Diagrams
Construct
Description
package
An element that refers to a set of
classes contained in another class
diagram.
Syntax
6. Control
panel
 If the class diagram becomes too large it may be
necessary to bundle it into packages.
 Each package:
 Provides a pointer to a more detailed class diagram
 Represents a black box with well defined external
associations
Example: Package Reference
Class Diagram Tips
 Don’t try and use all the notation every time
 Make certain of and don’t mix perspectives:
 Conceptual class model for analysis
 Specification class model when building software
 Don’t draw models for everything. A few key
diagrams that are frequently used are better than
many forgotten, obsolete models
 Don’t get bogged down in implementation details
too early