Transcript Chapter 3

Chapter 3
Class Diagrams:
The Essentials
1
Terms and Concepts
• A class is ...
– The most important building block of any objectoriented system.
– A description of a set of objects that share the same
attributes and behaviors.
– A blueprint for creating an object.
– An abstraction (simplification) of reality.
– A representation of a software thing, a hardware thing,
or even a conceptual thing.
– Graphically represented as a rectangle.
2
Terms and Concepts
• All classes have …
– Names - Used to distinguish one class from another. A
class must have a name.
– Attributes - Member data
– Operations (behaviors) - Member functions (C++) or
methods (Java)
– Responsibilities
• Class names are …
– extracted from the problem domain (statement)
– nouns or noun phrases
– concise and descriptive
3
Terms and Concepts
• Class attributes are …
–
–
–
–
–
usually nouns or noun phrases.
extracted or inferred from the problem statement.
used to represent properties of the enclosing class.
determine the state of an object
usually notated using the format
• visibility name: type multiplicity = default {property string}
• example: - firstName: String = ‘Bob’ {read only}
– optionally notated as associations
4
Terms and Concepts
• Class operations (behaviors) are …
–
–
–
–
named using a verb or verb phrases.
inferred from the problem statement.
Provide a requested service.
usually notated using the format
• visibility name (parameter-list) : return-type {property-string}
• example: +printFirstName( ) : void
• Class responsibility…
– Is a contract or obligation of a class to the users of the
class.
– Maps directly to the Responsibility field of a CRC card.
• CRC - Class Responsibility Collaboration
5
Class Artifact
6
Simple
Class
Diagram
7
Common Modeling Techniques
• Identify the classes that are to be included in the
design.
– Formulate a problem statement. The problem statement
may be scenarios associated with use cases.
– Identify the nouns in the problem statement.
– Use CRC (Class, Responsibility, Collaboration) cards
or use-cases to isolate each class.
• Determine the responsibilities of each class.
– Even out the work load between classes.
• A class with too much responsibility should be broken up into
multiple classes.
• A class with too little responsibility should be absorbed into
another class.
8
Common Modeling Techniques
• Classes should exhibit high cohesion and low
coupling.
– A class should have a single well-defined purpose.
• This promotes software reusability
– A class should interact with a limited number of other
classes.
• This simplifies modifications to the program.
• Feel free to model abstract (non-software) things
(such as people) that are outside of the system
boundaries.
9
Associations
• An association is …
– a type of relationship that can exist between one or
more classes.
– used to show a ‘knows-a’ relationship.
– either unidirectional or bidirectional.
– graphically represented by a solid line which may
optionally be labeled and have a name direction
indicator or navigability arrows.
– an alternative notation for a class attribute
• Association names are verbs or verb phrases.
• The same class can be on both ends of an
association.
10
Associations
• Associations may optionally have role names and
multiplicity symbols on either end of the
association line (next to the class icon).
• Role
– The face that a class on one end of an association
presents to the class on the other end of the association.
– A class can participate in many associations and thus
have multiple (different) roles.
– Role names are nouns.
– Role names are usually used in place of association
names.
11
Attributes Modeled as
Associations
12
Multiplicity
• Multiplicity
– Indicates how many object may be connected across an
instance of an association.
– Commonly used multiplicities
• 1
• 0..1
• *
– The default multiplicity of an attribute is ‘1’
13
Terms and Concepts
14
Generalization
• Generalization is …
– a type of relationship that can exist between two
classes. One of the classes is the base (or parent) class;
the other class is the derived (or child) class.
– used to show a ‘kind-of’ relationship.
– another name for inheritance.
– graphically represented by a solid line with an open
triangular arrowhead on the base class end.
• The parent class has no knowledge of the child
class.
• All OO programming languages support single
inheritance; some (C++) also support multiple
inheritance.
15
Common Modeling Techniques
• Modeling inheritance (generalization)
– Make it a priority to look for possible inheritance
relationships. This will reduce code redundancy.
• Use the “ClassA ‘is-a-kind-of’ ClassB” test.
– Do not model relationships using multiple inheritance
unless the implementation language supports multiple
inheritance. This will save programmers having to
develop messy work-arounds.
– Look for classes that have similar attributes and
behaviors and then factor those attributes and behaviors
into a common base class.
16
Notes and Comments
• Use notes to embed comments into UML
diagrams.
– The comment may contain links to other documents.
• A note may stand alone or be attached to a
graphical element.
– A dashed line is customarily used as the connector
• Use notes when a picture is not enough.
17
Dependency
• A dependency is ...
– A type of relationship that can exist between two
classes.
– An indication that one class ‘uses’ another class.
– If the ‘used’ class changes it can have an impact on the
‘using’ class.
– Graphically represented as a dashed line with an open
arrowhead on one end.
– Rarely labeled.
• The ‘used’ class is frequently an argument to one
of the member functions of the ‘using’ class.
• The “used” class has no knowledge of the “using”
class.
18
Dependency Relationships
19
Common Class Relationships
20
Terms and Concepts
21