Requirements Modeling:

Class-Based
Prof. Alex Bardas
Class-Based Modeling
• A class-based model contains
• Objects
• What the system will manipulate
• Operations (methods or services)
• What to be applied to the objects to effect the manipulation
• Relationships (some hierarchical) between objects
• Collaborations between the classes that are defined

EECS 448 Software Engineering

Identifying Classes
6 selection characteristics
1. Retained information
The potential class will be useful during analysis only if information about it must be
remembered so that the system can function.
2. Needed services
The potential class must have a set of identifiable operations that can change the value of its
attributes in some way.

EECS 448 Software Engineering

Identifying Classes
6 selection characteristics
3. Multiple attributes
During requirement analysis, the focus should be on “major” information.
A class with a single attribute may, in fact, be useful during design, but is probably better
represented as an attribute of another class during the analysis activity.
4. Common attributes
A set of attributes can be defined for the potential class and these attributes apply to all
instances of the class.

EECS 448 Software Engineering

Identifying Classes
6 selection characteristics
5. Common operations
A set of operations can be defined for the potential class and these operations apply to all
instances of the class.
6. Essential requirements
External entities that appear in the problem space and produce or consume information
essential to the operation of any solution for the system will almost always be defined as
classes in the requirements model.

EECS 448 Software Engineering

Attributes
• Attributes define a class
• For the same class, attributes can be very different in different contexts
• What data items fully define this class in the problem context?
The Player class for professional baseball players
• Playing statistics software
• Name, position, batting average, fielding percentage, years played, and games played, …
• Pension fund software
• Name, average salary, pension plan options chosen, mailing address, …

EECS 448 Software Engineering

Operations
• Operations define the behavior of an object:
• Manipulate data
• e.g., adding, deleting, reformatting, selecting
• Perform a computation
• Inquire the state of an object
• Monitor an object for the occurrence of a controlling event
• e.g., communications between objects

EECS 448 Software Engineering 7

Case Study: Safe Home
Potential Class Type

The SafeHome security function enables the

homeowner to configure the security system when it’s
installed, monitors all sensors connected to the
security system, and interacts with the homeowner
through the Internet, a PC, or a control panel.

EECS 448 Software Engineering 8

Case Study: Safe Home
Potential Class Type

homeowner role
The SafeHome security function enables the
homeowner to configure the security system when it (security) system thing
is installed, monitors all sensors connected to the sensor external entity
security system, and interacts with the homeowner control panel external entity
through the Internet, a PC, or a control panel.

EECS 448 Software Engineering 9

Case Study: Safe Home
Potential Class Type

homeowner role
During installation, the SafeHome PC is used to system thing
program and configure the system. Each sensor is
assigned a number and type, a master password is sensor external entity
programmed for arming and disarming the system, control panel external entity
and telephone number(s) are input for dialing when a
sensor event occurs.

EECS 448 Software Engineering 10

Case Study: Safe Home
Potential Class Type

homeowner role
During installation, the SafeHome PC is used to
program and configure the system. Each sensor is system thing
assigned a number and type, a master password is sensor external entity
programmed for arming and disarming the system,
control panel external entity
and telephone number(s) are input for dialing when a
sensor event occurs. Installation event
number, type thing
master password thing
telephone number thing
sensor event event

EECS 448 Software Engineering 11

Case Study: Safe Home
Potential Class Type

homeowner role
When a sensor event is recognized, the software system thing
invokes an audible alarm attached to the system. After
sensor external entity
a delay time that is specified by the homeowner during
system configuration activities, the software dials a control panel external entity
telephone number of a monitoring service, provides Installation event
information about the location, reporting the nature of
number, type thing
the event that has been detected. The telephone
number will be redialed every 20 seconds until master password thing
telephone connection is obtained. telephone number thing
sensor event event

EECS 448 Software Engineering 12

Case Study: Safe Home
Potential Class Type

homeowner role
When a sensor event is recognized, the software system thing
invokes an audible alarm attached to the system. After
sensor external entity
a delay time that is specified by the homeowner during
system configuration activities, the software dials a control panel external entity
telephone number of a monitoring service, provides Installation event
information about the location, reporting the nature of
number, type thing
the event that has been detected. The telephone
number will be redialed every 20 seconds until master password thing
telephone connection is obtained. telephone number thing
sensor event event
audible alarm external entity
delay time thing
monitoring service external entity

EECS 448 Software Engineering 13

Recap: Identifying Classes
6 selection characteristics
1. Retained information

2. Needed services

3. Multiple attributes
4. Common attributes

5. Common operations

6. Essential requirements
 Potential Class Type Class Selection Characteristics

homeowner role
system thing
sensor external entity
control panel external entity
Installation event
number, type thing
master password thing
telephone number thing
sensor event event
audible alarm external entity
delay time thing
monitoring service external entity

EECS 448 Software Engineering 15

 Potential Class Type Class Selection Characteristics

homeowner role No Does not retain info

system thing Yes All 6 apply
sensor external entity Yes All 6 apply
control panel external entity Yes All 6 apply
Installation event No None applies
number, type thing No Attributes of sensor class
master password thing No Does not have multiple attributes
telephone number thing No Does not have multiple attributes
sensor event event Yes All 6 apply
audible alarm external entity Yes All 6 apply
delay time thing No Attribute of system class
monitoring service external entity No So far it does not need service

EECS 448 Software Engineering 16

Analyzing Class Elements (1/2)
• Consider more fine-grained element types
• Roles and external entities (actors)
• Roles played by people who interact with the system
• External entities that produce or consume information
• Organizational units that are relevant to an application
• e.g., team, group, division
• Structures
• Define a class of objects or related classes of objects
e.g., sensors, computers, four-wheeled vehicles
Analyzing Class Elements (2/2)
• Consider more fine-grained element types
• Things
• Part of the information domain for the problem
• e.g., reports, displays, letters, signals
• Occurrences
• Events occur within the context of system operation
• Places
• The context of the problem and the overall function
Case Study: Safe Home
• Let’s look at the system class
• Alarm response information
System
• delayTime, telephoneNumber
delayTime
• Activation/deactivation telephoneNumber
• masterPassword masterPassword
• number of tries
• temporary password
• Identification
• system ID, status

EECS 448 Software Engineering 19

Case Study: Safe Home
• Let’s look at the system class
• Alarm response information
System
• delayTime, telephoneNumber
systemID
• Activation/deactivation systemStatus
• masterPassword delayTime
telephoneNumber
• number of tries masterPassword
• temporary password tempPassword
numberTries
• Identification
• system ID, status

EECS 448 Software Engineering 20

Case Study: Safe Home
During installation, the SafeHome PC is used to
program and configure the system. Each sensor is
assigned a number and type, a master password is System
programmed for arming and disarming the system, systemID
and telephone number(s) are input for dialing when a systemStatus
sensor event occurs. delayTime
telephoneNumber
masterPassword
tempPassword
numberTries

EECS 448 Software Engineering 21

Case Study: Safe Home
During installation, the SafeHome PC is used to
program and configure the system. Each sensor is
assigned a number and type, a master password is System
programmed for arming and disarming the system, systemID
and telephone number(s) are input for dialing when a systemStatus
sensor event occurs. delayTime
telephoneNumber
• Display() typically should exist too. masterPassword
tempPassword
• Divide operations into sub-operations if needed numberTries
• e.g., program() program()
arm()
disarm()
display()

EECS 448 Software Engineering 22

Class-Responsibility-Collaborator Modeling

• CRC model:
• Used to identify and organize classes
• Originally introduced as a technique for teaching object-
oriented concepts
• Use a collection of (actual or virtual) index cards
representing classes
EECS 448 Software Engineering 23
CRC Modeling
• A CRC model - index cards represent classes

Anything the class Classes required to

knows (attributes) or provide info needed to
does (operations) complete a responsibility

EECS 448 Software Engineering 24

CRC Modeling

Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

EECS 448 Software Engineering 25

Classes
• Entity classes
• Extracted directly from the statement of the problem
• Represent things to be stored or persist throughout the development
• Boundary classes
• Create/display interface
• Mange how to represent entity objects to users
• Controller classes
• Create/update entity objects
• Initiate boundary objects
• Control communications
• Validate data exchanged
EECS 448 Software Engineering 26
Responsibilities (1/3)
• System intelligence should be distributed across classes
• Intelligence: what the system knows and what the system can do
• How to distribute across classes?
• Distributed more evenly to enhance maintainability: avoid extra long list
• Each responsibility should be stated as generally as possible
• Responsibility reside high in the class hierarchy
• Can be applied to subclasses

EECS 448 Software Engineering 27

Responsibilities (2/3)
• Information and the behavior related to a responsibility should reside
within the same class
• Achieves encapsulation

• Information about one thing should be localized with a single class, not
distributed across multiple classes
• Avoid spreading across classes
• Encapsulation is good in testing and maintenance

EECS 448 Software Engineering 28

Responsibilities (3/3)
• Responsibilities should be shared among related classes,
when appropriate
• When some related objects need to exhibit the same behavior at
the same time
e.g., Play, PlayerHead, PlayerBody classes in video game: update()
and display()

EECS 448 Software Engineering 29

Collaborations
• A class may collaborate with other classes to fulfill responsibilities
• If a class cannot fulfill every single responsibility itself, it must interact with
another class
• Collaboration refers to identifying relationships between classes
• is-part-of relationship
• Aggregation
• has-knowledge-of relationship: one class must acquire information from
another class
• Association
• depends-upon relationship: dependency other than the above two

EECS 448 Software Engineering 30

 Relationships between Classes
DisplayWindow Camera

<<access>>

{password}

dependency
Player Wall

composition association
1 1 1

is used to build is used to build

PlayerHead PlayerBody PlayerArms PlayerLegs 1..* 0..* is used to build 0..*

WallSegment Window Door

EECS 448 Software Engineering 31

Class Diagram
FloorPlan

type
name
outsideDimensions
determineType()
positionFloorplan()
scale()
changColor()
Is placed within
Is part of
Wall

type
Camera wallDimensions
type determineType()
ID computeDimensions()
location
fieldView Is used to build Is used to build
panAngle Is used
zoomSetting to build
determineType() WallSegment Window Door
translateLocation() type type type
displayID() startCoordinates startCoordinates startCoordinates
displayView() stopCoordinates stopCoordinates stopCoordinates
displayZoom() nextWallSegment nextWindow nextDoor
determineType() determineType() determineType()
draw() draw() draw()

EECS 448 Software Engineering 32

Validating a Class Diagram
• One of the most important, and often overlooked issues is how to
validate a class diagram.

• Given a specification or a use-case, can you look at the class diagram

and use features of it to manually “execute” the use case?

Coming up: Questions

Reviewing a CRC Model
• Stakeholders review the CRC model once it is developed
• All participants are given a subset of CRC index cards
• No reviewer should have two cards that collaborate
• Organize all use-case scenarios into categories
• Review leader reads the use case
• When it comes to an object, pass a token to the person holding the corresponding
class index card
• Check the responsibility on this index card, find the collaborator
• Pass the token to the person with the collaborator index card
• Describe the responsibilities on the card
• The entire group checks the responsibilities
• If cannot accommodate the use case, make modifications

EECS 448 Software Engineering 34

UML Class Modeling

• An object-oriented modeling language developed in 1997

• Models structure (static) and behavioral (dynamic) aspects of a system
• Semi-formal: UML 2.0 added much more formality
• Process-independent: can be used with a variety software
development process models
• Customizable and extensible

EECS 448 Software Engineering 35

Abstraction Levels
• Three perspectives for class models
• Analysis
• Represents concepts in the domain
• Drawn with no regard for implementation (language independent)
• Specification
• Focus on interfaces not on how implementation is broken into classes
• Implementation
• A blue-print for coding
• Direct code implementation of each class in the diagram

EECS 448 Software Engineering 36

Student Records Management System
{Joe, Sue, Mary, Implementation
Frank, Tim, …} Student
-major: String
Student
-GPA: Real
-standing: String

Analysis Specification +add(Course)

+drop(Course)
Student :Student
-- Handle a registration in
name name: String
major major: String courses
GPA 0..1
GPA: real 1
standing standing: Scode
interests add(Course)
CourseList
drop(Course)
-- The set of students -- Display a dynamic list
-- Software representation of students;
known to the registration
support registration in courses courses
system

EECS 448 Software Engineering 37

Classes in UML Diagrams
• An abstraction which describes a collection of objects sharing some
commonalties
• Syntax
• Name: noun, singular
• centered, bold, first letter capitalized
• Attribute
• left justified, lower cases
• Operations
• Visibility
+ public
- private
# protected
EECS 448 Software Engineering 38
Attributes
• An attribute can be defined for individual objects or a class of objects
• Static: if defined for a class, every object in the class has that attribute
(place holder)
• An attribute relates an object to some other object

joe: Student name

joe: Student Joe Jones : String
1
name: String = “Joe Jones”

EECS 448 Software Engineering 39

Objects
• Object is an instance of a class
• Fundamental building blocks of object-oriented systems
• Instance name and class path are separated by a “:”
• Operation syntax:
joe: Student
name (params) : return type
major: String = “CS”
• An instance may have some value gpa: Real = 4.0
• Instance orderPaid of the Date class has standing: String = “”

the value July 31, 2011 3:00 pm add(Class Section)

drop(Class Section)

EECS 448 Software Engineering 40

Type of Relationships in Class Diagrams
• Class diagrams show relationships between classes.
Relation

Generalization Association Dependency

Binary Association N-ary Association

Aggregation

EECS 448 Software Engineering 41

Associations
• An association is a structural relationship that specifies a connection
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…)
• Depends whether it “uses” that argument

EECS 448 Software Engineering 42

Associations
• Associations
• Links are instances of associations
• Association names are typically verb phrases (in lower case)
• The name should include an arrow indicating the direction in
which the name should be read
• Often interaction diagrams are useful for modeling objects

EECS 448 Software Engineering 43

Associations
• A solid line connecting two classes

is registered for>
Student Semester

g>
tak

rin
es>

du
ld
he
is
teaches> Class
Instructor
Section
is
<works for

ins
ta
nc
eo
f>
sponsors>
Department Course

EECS 448 Software Engineering 44

N-ary Associations
• Associations can connect more than one class

Student Advisor

Major

EECS 448 Software Engineering 45

Multiplicity
• How many objects from two classes are linked?
• An exact number: indicated by the number
• A range: two dots between a pair of numbers
• An arbitrary number: indicated by * symbol
• (Rare) A comma-separated list of ranges

• e.g., 1 1..2 0..* 1..* * (same as 0..* )

• Implementing associations depends on multiplicity

EECS 448 Software Engineering 46

Multiplicity

is registered for>
Student Semester
1..*
0..* 1

g >
tak

rin
e s>

du
ld
he
0..8 1..*

is
teaches> Class
Instructor
1..3 0..6 Section
1..* is
<works for

in
sta
n ce
of
1 >
1 sponsors> 1..*
Department Course

EECS 448 Software Engineering 47

Generalization
Person

• Generalization is an association between classes

• A subclass is connected to a superclass by an arrow

Generalization
with a solid line with a hollow arrowhead.

Specialization
Student

• From an analysis perspective, it represents

generalization/specialization:
• Specialization is a subset of the generalization
Graduate
Student

EECS 448 Software Engineering 48

Generalization
• Generalization represents implementation inheritance
• You model “inheritance” early, but not implement it at the conceptual level

Student
Person
major: String
name: String GPA: Real
address: String standing: String

changeAddress(new_address) add(Class Section)

drop(Class Section)

EECS 448 Software Engineering 49

Aggregation
• Aggregation: is a special kind of association that means “part of”
• Aggregations should focus on a single type of composition (physical,
organization, etc.)

Crust 1 1

1
1 1 *
Sauce Serving Pizza Order
1..3 1 1
Cheese Serving
0..9 1 4..*
Topping Serving
Slice

Coming up: Composition (very similar to aggregation)

Composition
• Very similar to aggregation:
• Think of composition as a stronger form of aggregation
• Composition means something is a part of the whole, but cannot
survive on it’s own

Room Building

Coming up: Using a class diagram

Dependencies
• A using relationship
• A change in the specification of one class may affect the other
• But not necessarily the reverse

Student

Prerequisite
add(Course)
drop(Course)

Coming up: Dependencies

Properties/Stereotypes
• Extends the “vocabulary” of UML
• Syntax: <<property/stereotype>>
• UML predefines many:
• Classes: <<interface>>, <<type>>, <<implementationClass>>,
<<enumeration>>, <<thread>>
• Constraints: <<precondition>>
• Dependencies: <<friend>>, <<use>>
• Comments: <<requirement>>, <<responsibility>>
• Packages: <<system>>, <<subsystem>> (maybe classes, too)
• Or, create your own if needed

EECS 448 Software Engineering 53

Analysis Packages
Package name
Environment
+ public +Tree
+Landscape
+Road
– hidden +Wall
+Bridge
# accessible only to a +Building RulesOfTheGame
given package +VisualEffect +RulesOfMovement
+Scene +ConstraintsOnAction

Characters
+Player
+Protagonist
+Antagonist
+SupportingRole

EECS 448 Software Engineering 54

Revisit Class Diagrams
• Class diagrams are like the paragraphs of a technical paper
• Each diagram should focus on a specific topic
• A diagram provides supporting details for the main concept that is
trying to communicate
• The level of the abstraction used in the diagrams should be consistent
• Together, all the diagrams for a system comprise a “model” of
that system

Coming up: Class Diagrams

Class Diagrams
• Pitfalls of Class Diagrams
• Using class diagrams alone can cause developers to focus
too much on structure and ignore behavior
• Using the wrong (or a mixed) perspective can lead to
misunderstanding
• Using the wrong level of abstraction can be confusing to the
target audience
• Using mixed levels of abstraction can reduce the usefulness
of diagram
Coming up: Multiplicity Constraints
Example
• University Courses
• Some instructors are professors, while others have job title adjunct
• Departments offer many courses, but a course may be offered by
more than 1 department
• Courses are taught by instructors, who may teach up to three courses
• Instructors are assigned to one (or more) departments
• One instructor also serves a department chair

EECS 448 Software Engineering 57

Class Diagram

EECS 448 Software Engineering 58

Another Example
• Problem Reporting Tool: a CASE tool for storing and tracking
problem reports
• Employees are assigned to a project
• A manager may add new artifacts and assign problem reports to developers
• Each report contains a problem description and a status
• Each problem can be assigned to someone
• Problem reports are made in one of the “artifacts” of a project

EECS 448 Software Engineering 59

Class Diagram
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

EECS 448 Software Engineering 60

References
• Prof. Fengjun Li’s EECS 448 Fall 2015 slides

• This slide set has been extracted and updated from the slides
designed to accompany Software Engineering: A Practitioner’s
Approach, 8/e (McGraw-Hill 2014) by Roger Pressman

61