cs 451 software engineering

47
Drexel University CS 451 Software Engineering 1 Yuanfang Cai Room 104, University Crossings 215.895.0298 [email protected]

Upload: others

Post on 14-Feb-2022

4 views

Category:

Documents


0 download

TRANSCRIPT

Drexel University

CS 451 Software Engineering

1

Yuanfang Cai

Room 104, University Crossings

215.895.0298

[email protected]

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

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 Responsibility

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

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 17

ATM Example:

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

Data Structures: e.g. Card, Process Class

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

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

The Design of Traffic Simulator

34

1

1

1

1

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

37

1

1

1

1

Drexel University

Data Model Design Why Data Model Design is needed?

Performance consideration Interface consideration Adaptability consideration

Different types of Data Design 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