CS 451 Software Engineering Yuanfang Cai Room 104, University - - PowerPoint PPT Presentation

Drexel University

CS 451 Software Engineering

1

Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu

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 

Data Design



Architecture Design



Interface Design



Component Design



Detailed/Data Design

2

Drexel University

SOLID

 Information Hiding [Parnas 1972]

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

classes, attributes and responsibilities

4

Drexel University

 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

Step 1: Identify and assign candidate classes

Drexel University

Noun identification

 Two stages:

 identify candidate classes by picking all nouns and noun phrases out of

requirements specification document;

 discard inappropriate candidates.

 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

and the system at a very high level (system, rule, information, or reporting requirements)

 outside the scope of the system (time)  an attribute (name)  Nouns are outlined

6

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 . . . . . . 4 X 6 (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

Slide 10

An Example CRC Card - Front

Main Responsibilit y

A patient makes appointments, review or configure insurance information, and provides medical history

Drexel University

Slide 11

An Example CRC Card - Back

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

Step 4: Different types of analysis classes

 Entity Class

 Data Structures

 Process Class

 Classes that work

 Boundary Class

 Interface with external systems

14

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

Possible Future Changes

 Graphical UI vs. Console UI  4-way intersection may become T interaction  Lights are usually Green, Red and Yellow  Light Changing rules may change

17

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

 Drive  Join

 Collaborator

 Traffic light  Queue  Intersection  Car

 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.

Drexel University

CRC Cards  What next?

Class Name Main Responsibility Responsibilities Collaborators . . . . . . 4 X 6 (or 3 X 5) Index card

 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.

Drexel University

Candidate Classes

 Car  Traffic light  Queue  Intersection  What else?

22

Car Light Queue

Green? Clear? green Clear go

Drexel University

Class Diagram

23

1 1 1

1

Drexel University

From Classes to Components

24

< < component > > View < < component > > Model < < component > > Controller

Drexel University

Component Diagram (UML 2.0)

25

< < component > > Model < < component > > Controller < < component > > View

Drexel University

Component Diagram (UML 2.0)

26

< < component > > Model < < component > > Controller < < component > > View

View changed() Model changed() Model changed()

Drexel University

Deployment Diagram

27

< < component > > Model < < component > > Controller < < component > > View

Tux

Drexel University

Final Implemention

 Process/Model 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.

28

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

29

Drexel University

The Design of Traffic Simulator

30

1 1 1

1

Drexel University

Different types of analysis classes

 Entity Class

 Data Structures: CarQueueCollection, LightCollection

 Process Class

 Classes that work: Traffic Controller

 Boundary Class

 Interface with external systems: Traffic

31