CS 451
Software Engineering
Yuanfang Cai
Room 104, University Crossings
215.895.0298
[email protected]
1
Drexel University
Design Engineering

A systematical way to “translate” SRS into
design


Start with use cases from SRS
Find analysis classes from use cases







Create CRC cards from use cases
Refine CRC cards into UML class diagrams
Different types of classes
Architecture Design
Interface Design
Component Design
Detailed/Data Design
2
Drexel University
From Use Cases to Class diagrams
Step 1: Identify and assign candidate classes
 Step 2: Determine a set of specific scenarios
 Step 3: Walk through the scenario, naming cards
and responsibilities

3
Drexel University
Step 1:
Identify and assign candidate classes

Read requirements specification.

Highlight nouns and noun phrases to give
candidate classes (excluding abstract nouns).

Write each candidate class down on an index
card.

Assign each index card to one person who is
participating in the CRC card modelling session.
Drexel University
Step 1:
Identify and assign candidate classes
 Consists
of classes of domain objects.
Example: any ATM model will involve Card,
BankAccount classes
 Names are important.

 Class
identification is a key process for a
good class model:
noun identification;
 responsibility driven approach.

5
Drexel University
Noun identification

Two stages:



A candidate is an inappropriate class when it is

redundant (ex: book, book in many volumes; member of the
library,library member)
vague (item it may be either book or journal etc)
an event or an operation (a loan – an event: lending a book)

meta-language element: used to describe and explain requirements





identify candidate classes by picking all nouns and noun phrases out of
requirements specification document;
discard inappropriate candidates.
and the system at a very high level (system, rule, information, or
reporting requirements)
outside the scope of the system (time)
an attribute (name)
6
Nouns are outlined
Drexel University
CRC Cards
7
Drexel University
Introduction to CRC Cards

CRC Card = Class Responsibility Collaborator
Card

Purpose: interactively brainstorm an initial
design of a program or program segment

Invented in 1989 by Kent Beck and Ward
Cunningham
Drexel University
CRC Cards



Class – the name of an OO class (a good descriptive noun)
Responsibility – the things the OO class does (behavior responsibility)
Collaborator – the relationship the class has with other classes
Class Name
Main Responsibility
Responsibilities
Collaborators
...
...
4X6
(or 3 X
5)
Index
card
Some also suggest writing down the classes properties
(what the class must know about itself – knowledge
responsibility) on the back of the card
Drexel University
An Example CRC Card - Front
Main
Responsibilit
y
A patient makes appointments, review or configure
insurance information, and provides medical history
Slide 10
Drexel University
An Example CRC Card - Back
Slide 11
Drexel University
Step 2:
Determine a set of specific scenarios

Develop a comprehensive and specific set of
end-to-end scenarios based upon the
requirements.


A scenario is a sequence of actions that illustrates
behavior.
Example:


Requirement: The alarm clock shall allow a user to
set the time.
Scenario: The user sets the time for 1:15PM.
Drexel University
Step 3: Walk through the scenario, naming
cards and responsibilities

Walk through the handling of a scenario case
pointing to or picking up the cards, naming their
responsibilities and how they handle and
delegate each request.

Add new cards as classes are needed.

Note: It’s always good to do very
basic/mainstream use cases first, then explore
alternative/complicated use cases.
Drexel University
An ATM Example

See Class Exercise
14
Drexel University
ATM –All Nouns
15
Drexel University
ATM- Classes

Class candidates:





card
bank account
(ATM) dispenser &
session – vague (it might become of interest)
Data associated






PIN - attribute of card
current balance - attribute of bank account
amount – attribute in various classes
overdraft limit – attribute of bank account
card limit per day – attribute of card
dispenser amount – attribute of ATM dispenser
16
Drexel University
ATM Example:
17
Drexel University
More ATM CRC Cards
18
Drexel University
ATM –Card Class
Card class’ attributes and operations;
validatePIN() validates the PIN introduced against the value in pin;
changePIN() changes the current pin value with what this operation provides;
startWithdraw() initiates the withdrawal by i) checking that the amount requested is
within dayLimit range; ii) checks with BankAccount that there is enough in the
current bank account or the overdraft limit is sufficient for this transaction; iii) it also
checks that there is enough cash in dispenser; if all these are fulfilled it asks
BankAccount to update the balance and Dispenser to release the cash.
19
Drexel University
ATM –BankAccount Class
20
Drexel University
ATM –Dispenser class
21
Drexel University
ATM Transaction Class
22
Drexel University
ATM additional requirements




Let’s consider that transactions involving cash withdrawal, either
failed or successful, are recorded. In this case
session (retained as vague) will be reconsidered and Transaction is
the class that will be identified for session.
Reconsider CRC cards: when Card class will initiate cash
withdrawal then another collaboration will be added, i.e. Transaction
class will record this transaction.
A new CRC card will be then generated for Transaction class.
23
Drexel University
CRC Cards Relationship
24
Drexel University
ATM –Class Diagram

Class diagrams is obtained directly from CRC cards by
considering collaborations identified; it shows business
classes.

Classes are shown with no attributes and operations.
25
Drexel University
ATM-Refined Class Diagram





For each Card there is one bank account, one dispenser and an
arbitrary number of transactions.
Each BankAccount should have one or more cards associated with.
The Dispenser refers to all cards.
Each Transaction has a unique card on it.
All associations are named, directed and unidirectional.
26
Drexel University
Different types of analysis classes

Entity Class


Process Class


Data Structures: e.g. Card,
Classes that work: Transactions
Boundary Class

Interface with external systems: Dispenser
27
Drexel University
Clear Intersection Example

From the Use Cases to Design
Drexel University
1. Flow of Events for the Clear Intersection Use Case
1.1 Preconditions
Traffic light has been initialized.
1.2 Main Flow
This use case begins when a car enters the intersection. The car
checks it’s status (S-1). The use case ends when the car clears the
intersection (S-4).
1.3 Subflows
S-1 Check Status
Check status (S-2, S-3). If the light is green, and the queue is
empty, the car clears the intersection (S-4). Otherwise, it joins a
queue (S-5).
S-2 Check Light
Get information on whether the light is red, yellow, or green.
S-3 Check Queue
Get information on whether the queue is empty or not
S-4 Go
The car clears the intersection and the use case ends.
S-5 Join a Queue
Car is added to queue.
Drexel University
Step 1:
Identify and assign candidate classes

The Clear Intersection use case:
 “This use case begins when a car enters the intersection. The


car checks it’s status (S-1). The use case ends when the car
clears the intersection (S-4).”
“Check status (S-2, S-3). If the light is green, and the queue is
empty, the car clears the intersection (S-4). Otherwise, it joins
a queue (S-5).”
Candidate Classes
Car
Traffic light
Queue
Intersection
Drexel University
Step 2: Determine a set of specific
scenarios-From Use Cases

Scenarios


The car can only drive through the intersection if the
traffic light is green and there are no cars in the
intersection.
Otherwise, the car needs to join a queue.
Drexel University
Step 3: Walk through the scenario,
naming cards and responsibilities
Index Card: Car
 Responsibility






Car approaches the intersection and the
light is green and there are no cars in the
way.

Car approaches the intersection and the
light is red.

Car is in the queue and the light turns
green.
Drive
Join
Collaborator


Traffic light
Queue
Intersection
Car
Drexel University
CRC Cards  What next?

Turn these cards into your class diagram
 Responsibilities --- Methods
 Collaborators --- Associations (need to have instances of
collaboration classes)
 Data members on the card back --- Attributes.
Class Name
4X6
(or 3 X 5)
Main Responsibility
Index card
Responsibilities
Collaborators
...
...
Drexel University
The Design of Traffic Simulator
1
1
1
1
34
Drexel University
Final Implemention

Process Class: 255 LOC








Car.java: 31 LOC
CarQueue.java: 51 LOC
CarQueueCollection.java: 52 LOC
Direction.java: 13 LOC
LightCollection.java: 31 LOC
LightColor.java: 7 LOC
TrafficController.java 70 LOC
UI class:


Traffic.java: 251 LOC
Including menu, car queue
initialization, etc.
35
Drexel University
Design Engineering


Start with use cases from SRS
Find analysis classes from use cases







Create CRC cards from use cases
Refine CRC cards into UML class diagrams
Different types of classes
Architecture Design
Interface Design
Component Design
Detailed/Data Design
36
Drexel University
The Design of Traffic Simulator
1
1
1
1
37
Drexel University
Data Model Design

Why Data Model Design is needed?




Different types of Data Design





Performance consideration
Interface consideration
Adaptability consideration
In-memory data structure
Input-output file format
Database scheme
Classes attributes
Principles: abstraction and modularization
38
Drexel University
Data Modeling Concepts
Data
objects can then be represented as tables:
39
Drexel University
Data Modeling Concepts



Data attributes define properties of a data object.
RELATIONSHIPS
Data objects connect to one another in different ways.
40
Drexel University
Data Modeling using Classes
41
Drexel University
The Data Model Design of
TheraWii
42
Drexel University
Database Scheme Design

Entity Relation Diagram
43
Drexel University
The Database Design of Vodka
44
Drexel University
Interface Design

Why interface design is needed?



Task parallelism
Performance analysis
Different types of Interface Design






Graphical interface design
Boundary class design
Database interface design
File storage interface design
Hardware interface design
More…
45
Drexel University
The Component and Interface
Design of TheraWii
46
Drexel University
Software Design Document
Syntax
 Component Diagram



High-level Component Diagrams
Detailed Component Diagrams (Classes and relations
within a Component)
Interface Design (Boundary Class)
 Data Model /Data Storage Design (Entity
Classes), data attributes have to be specified
 Other models



Deployment Diagram
Algorithm Explanation
47
Drexel University