Overview

CS 494
Object-Oriented Analysis & Design • How class models are used? Perspectives
• Classes: attributes and operations
• Associations
– Multiplicity
UML Class Models • Generalization and Inheritance
• Aggregation and composition

• Later: How to find classes

– small and larger systems

© 2001 T. Horton
2/7/00 G-1 2/7/00 G-2

Developing Class Models Class Model Perspectives (cont’d)

• Specification
• Class diagrams developed iteratively – Interfaces defined: a set of operations
– Details added over time during lifecycle – But, each implementation class can include more than
– Initially: missing names, multiplicities, other details one interface
• Some define particular perspectives for class models: – A given interface can be shared by more than one class
– Conceptual – Sometimes known as a “type”
– Specification
• Implementation
– Implementation
– Direct code implementation of each class in the diagram
• Conceptual perspective
– A blue-print for coding
– Represents concepts in the domain
– Drawn with no regard for implementation (language
independent)
– Used in requirements analysis

2/7/00 G-3 2/7/00 G-4

Documenting Your Objects Classes in UML Diagrams

• Need some kind of record of your definitions • Attributes in middle

• Operations at bottom Book
– Your white-board?
– Can be suppressed. (What level
– A simple glossary of abstraction?)
– A data dictionary (perhaps in a CASE tool) • Attribute syntax: +title : string
name : type = default
• What to define? • Operation syntax:
– Attributes, operations for each class name ( params) : return type
– Also relationships between classes • Visibility Book
+ public
• Can you define classes of related objects? - private -title : string
– Inheritance, Java interfaces # protected etc.
+borrow(c : Copy) : void
nothing? Java’s default-
+copiesOnShelf() : int
package?
+getTitle() : string

2/7/00 G-5 2/7/00 G-6

A-1
 Associations
• For “real-world objects” is there an association
between classes?
• Classes A and B are associated if:
– An object of class A sends a message to an object of B
– An object of class A creates an instance of class B
– An object of class A has an attribute of type B or
collections of objects of type B
– An object of class A receives a message with an
argument that is an instance of B (maybe…)
• Will it “use” that argument?
• Does an object of class A need to know about some
object of class B?
2/7/00
More on Associations
• Associations should model the reality of the domain
and allow implementation
• Associations are between classes
– A link connects two specific objects
– Links are instances of associations
– Note we could draw an object diagram to show objects
and links
• But often interaction diagrams are more useful for
modeling objects
• Note: In practice, early in modeling, we may not name
associations
• Note: One may choose to have a dynamic view
associations: if at run-time two objects exchange
messages, their classes must be associated
G-7 2/7/00 G-8

Multiplicity Examples of Associations

• Also known as cardinality Book
• Objects from two classes are linked, but how many? • From a Library catalog
– An exact number: indicated by the number
example 1

– A range: two dots between a pair of numbers • One book has 1 or more Is A Copy Of
– An arbitrary number: indicated by * symbol copies 1..*

– (Rare) A comma-separated list of ranges • One copy is linked to

Copy
exactly one book
• Examples:
1 1..2 0..* 1..* * (same as 0..* but…) • Should there be two 0..*
associations: borrows
• Important: If class A has association X with class B
and returns? Borrows/Returns
– The number of B’s for each A is written next to class B 0..1
• One copy is borrowed
– Or, follow the association past the name and then read
the multiplicity by either zero or one LibraryMember
LibraryMember
• Implementing associations depends on multiplicity
2/7/00 G-9 2/7/00 G-10

Generalization and Inheritance Aggregation and Composition

• You may model “inheritance” early but not implement it • Again, just a specific kind of association
– Generalization represents a relationship at the conceptual level
between classes
– Inheritance is an implementation technique
• Generalization is just an association between classes – An object of class A is part of an object of
– But so common we put a “triangle” at the superclass class B
• Note this is a relationship between classes – A part-whole relationship
– So no multiplicities are marked. Why not?
• Put a diamond on the end of the line next to
• Inheritance may not be appropriate when it’s time to
implement the “whole”
– Objects should never change from one subclass to another – Aggregation (hollow diamond): really no
– Composition can be used instead semantics about what this means!
– Composition (solid diamond): a stronger
relationship
2/7/00 G-11 2/7/00 G-12

A-2
 Aggregation and Composition (cont’d) Example 1: University Courses
• Composition
– The whole strongly owns the parts • Some instructors are professors, while others
have job title adjunct
– Parts are copied (deleted, etc.) if the whole is
copied (deleted, etc.) • Departments offer many courses, but a
– A part cannot be part of more than one whole course may be offered by >1 department
– Mnemonic: the stronger relationship is • Courses are taught by instructors, who may
indicated by the stronger symbol (it’s solid) teach up to three courses
• Aggregation and composition associations • Instructors are assigned to one (or more)
are not named departments
• They do have multiplicities • One instructor also serves a department chair
• They can be used too often. If in doubt, use a
“plain”, named association. 2/7/00 G-13 2/7/00 G-14

Class Diagram for Univ. Courses Example 2: Problem Report Tool

chairs
0..1
• A CASE tool for storing and tracking problem
reports
Department 1
1..* assigned to 1..* – Each report contains a problem description
and a status
1..*
Instructor
– Each problem can be assigned to someone
offers
1 – Problem reports are made on one of the
teaches “artifacts” of a project
1..* 0..3
– Employees are assigned to a project
Course Adjunct Professor – A manager may add new artifacts and assign
problem reports to team members

• Note this implies adjuncts can be chairs

2/7/00 G-15 2/7/00 G-16

Class Diagram for Prob. Rep. Tool Example from Fowler

0..*
Assigned To Artifact
Employee 1..* Project 1

0..* +name : string

+name : string +name : string
+status : enum
1
1
Responsible For
0..n About

Manager Developer Problem Report 0..n

1
1 0..*
Managed By History Log
0..n

History Entry
Code Bug Report

-when : Date
-whatDone : string

2/7/00 G-17 2/7/00 G-18

A-3
 Objects, Object Diagrams Class Attributes, Operations

• Objects drawn • Recall in Java and C++ you may have class
like classes, but
names for all
attributes and class operations
instances – keyword static used
underlined – One attribute for all members of class
• Objects may be – An operation not encapsulated in each object,
“anonymous” but “defined in” that class’ scope
• Attributes are
given values • In UML class diagrams, list these in the class
box’s compartments, but underline them

2/7/00 G-19 2/7/00 G-20

Navigability More on Associations: Navigability

• Some call this “direction of visibility”
• Does each class really store a reference to
each other?
• Do we need to decide this now? (When is
“now”?)
• We can add arrows to associations to indicate
this
– What does a line with no arrows mean?
2/7/00
• One reason for having an association
between classes:
Messages between objects of those classes
• But, often “knowledge” indicated by
association is only in one direction
– Example: In a computer system, a User needs
access to his/her Password
– From a Password object we should not be able
to get back to a User!
• Note: Often ignored until design!
G-21 2/7/00 G-22

More on Associations: Roles Dependencies

• Review: • Dependency: A using relationship between two
classes
– Associations have an optional name – A change in the specification of one class may affect the
– Name might have a “direction” indicator other
• But, direction or semantics often easier to – But not necessarily the reverse

understand if we simply but a role name at • Booch says: use dependencies not associations
when one class uses another class as an argument in
one or both ends of the line
an operation.
• Often used for other things in UML: A general
relationship between “things” in UML
Student Professor
advises – Often use a stereotype to give more info
• Uses: binding C++ class to template; Java interfaces;
advisee
Student Professor a class only instantiates objects (a factory)
advisor
2/7/00 G-23 2/7/00 G-24

A-4
 Stereotypes Stereotypes (cont’d)

• Extends the “vocabulary” of UML • UML predefines many:

• Creates a new kind of building block – Classes: <<interface>>, <<type>>,
– Derived from existing UML feature <<implementationClass>>, <<enumeration>>, <<thread>>
– But specific for current problem – Constraints: <<precondition>> etc.
– Dependencies: <<friend>>, <<use>>
• Also, some pre-defined stereotypes
– Comments: <<requirement>>, <<responsibility>>
• UML allows you to provide a new icon!
– Packages: <<system>>, <<subsystem>> (maybe classes,
• Syntax: Above name add <<stereotype>> inside too)
guillemets (French quotes)
• Or, create your own if needed.
• Again, used to provide extra info about the UML
modeling construct

2/7/00 G-25 2/7/00 G-26

Class Categories Stereotype Example

«Interface» Module
• You can use IStringifiable
stereotypes
to organize stringify() : string
things by «use» prints
category
within a • IStringifiable is not a class Printer
class box
– Interface (as in Java)
– Module implements this interface
• Printer depends on what’s in the interface

2/7/00 G-27 2/7/00 G-28

Interface Example Diagram

Interfaces

• Interface: specifies a set of operations that

any class implementing or realizing the
interface must provide
– More than one class may realize one interface
– One class may realize more than one interface
– No attributes, and no associations
• Notation:
– Use <<interface>> with a class; list operations
– “Lollipop” notation

2/7/00 G-29 2/7/00 G-30

A-5
 Classes Realize an Interface Tagged Values, Properties
• Every modeling element in UML has its set of
• “Realizes” AKA implements, supports, matches, etc. properties
• This means that class provides all the operations in – Classes have: name, attributes, operations, etc.
the interface (and more?) – What if we want to add our own? (e.g. author?)
– Remember, no implementation in interface definition
• Just add text in curly-brackets, with
• Realization shown with dashed line, hollow arrow name=value, and put below the element name
– Like dependency plus generalization
• Note: These tell you something about the
• Why have this?
model, not about the final system to be built!
– Just factor out common functionality?
– Often used for code generation, version
• Better “pluggability”, extensibility control, etc.
• Example: {abstract} classes instead of italics

2/7/00 G-31 2/7/00 G-32

Abstract Classes Constraints

• Implementation not provided for one or more • Conditions that restrict Portfolio Corporation

operations values, relationships,…

– So, a subclass must extend this to provide • Can be free text or {secure}
implementations Object Constraint {or}
Langauge (OCL)
• How to show this in UML? BankAccount
(see textbook)
– Either italics for class name and operations
• Recommendation: Use
– Or, use {abstract} property by name sparingly!
Person

• An abstract class with no attributes and all • This example: from

gender : {female, male}

abstract operations is effectively an interface UML User Guide, p. 82 husband 0..1 0..1 wife
– But Java provides a direct implementation {self.wife.gender = female and
self.husband.gender = male}

2/7/00 G-33 2/7/00 G-34

Constraints and Semantics Derived Associations

• Often an association in a model be deduced
• Example from UML User from the existence of one or more other
Guide, p. 88 Department
associations
• A dependency and a
constraint used • Do we show it? Is it redundant?
* *
• Shows Manager must be • Option: Draw it but mark it as derived
one of Members of a {subset} – Use a slash symbol / before name
Department
member 1..* manager 1 • Can use slash in front of class attributes too!
• One link (say, Jane-to-
DeptA) is a subset of all Course
teaches
Professor
links between Persons Person
and DeptA is taking
/ teaches student

Student
2/7/00 G-35 2/7/00 G-36

A-6
 Example: Ticket Sales
Unused slides follow

2/7/00 G-37 2/7/00 G-38

Association Classes Association Class Example

• Recall that qualified associations really mean

that the link between two objects has an Company
attribute
0..* employer
• Often associations are “first-class” things Job
– They have a life-time, state, and maybe
description : string
operations dateHired : Date
employee 1..*
– Just like objects! salary : Money

• Association classes Person

– Same name as the association because...

– They represent the same thing!

2/7/00 G-39 2/7/00 G-40

World Cup Example World Cup Problem: Class Model

• We need a system to handle the World Cup. pre

sen
ts 0…
1
Re
Teams represent countries and are made up Team Hotel
of 22 players. 2 *
Reservation *
Qualifying Unit
• Countries qualify from zones, where each
22
zone is either a country or a group of Player Play
3

s at City
countries. 1 *
Pla

Country Zone 2
• Each team plays a given number of games in
ysI

4
n

1 1
a specific city. Referees are assigned to Represents

games. Hotel reservations are made in the city 3 *

*
* Referee Game
where the teams play. *

Assignment
5

2/7/00 G-41 2/7/00 G-42

A-7
 Qualified Associations Qualified Association Examples:
• Equivalent to programming language idea of lookup, 0..1
map, dictionary, associative array, etc. Show
sales
Ticket
1
• An object is associated with some number of other
objects in a class
– How do we identify which one we want given that
perf: Date, 0..1
association? Show Ticket
seat: Number 1 sales
• The qualifier documents attribute(s) used to identify
which object
– The “key” for “lookup”
• Formally, these are attributes of the association
0..1
RepairDesk jobID: int ReturnedItem

2/7/00 G-43 2/7/00 G-44

Identifying Classes for Requirements Noun Extraction

• From textual descriptions or requirements or • Take some concise statement of the requirements
use cases, how do we get classes? • Underline nouns or noun phrases that represent
• Various techniques, and practice! things
– Key Domain Abstractions: – These are candidate classes

• Real-world entities in your problem domain • Object or not?

– Inside our system scope?
– Noun identification
– An event, states, time-periods?
• Not often useful (but easy to describe)
– An attribute of another object?
• Remember: external view of the system for – Synonyms?
requirements • Again, looking for “things”
– Not system internals, not design components!

2/7/00 G-45 2/7/00 G-46

Identifying Good Objects Actors and Classes

• Don’t forget from earlier: • In some diagrams, actors represented as

– attributes and operations are encapsulated in objects class boxes
– objects have a life-cycle
– With special stereotype above class name:
• Also, don’t worry about user interface <<actor>>
– Think of user-commands as being encapsulated in the
actors • UML allows special graphical symbol (e.g. a
• Consider: stick figure) to replace stereotyped classes
– Collections, things in a container – See Richter, p. 53
– Roles
– Organizations

2/7/00 G-47 2/7/00 G-48

A-8