Drexel University CS 451 Software Engineering 1 Yuanfang Cai Room 104, University Crossings 215.895.0298 [email protected]
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Drexel University
CS 451 Software Engineering
1
Yuanfang Cai
Room 104, University Crossings
215.895.0298
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
Presenter
Presentation Notes
CRC stands for Class Responsibility Collaborator card. The purpose of conducting a CRC card brainstorming session is to interactively develop an initial class design. It is best when a CRC card session can be conducted with about four (or maybe a few more) people. CRC cards were invented by Kent Beck and Ward Cunningham in 1989.
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
Presenter
Presentation Notes
A CRC card starts out as a blank regular old index card. On it, you will eventually write the CRC – the Class Responsibility Collaborators. The Class is the name of the object-oriented class. The Responsibilities are the things this class is responsible for doing. The Collaborators are the other classes this class must collaborate with in order to carry out the responsibility. You start out by taking a blank index card and making a grid – of sorts – as is shown on this slide. There is a space for the class name, the responsibilities, and the collaborators. There is also a spot for a main responsibility statement. When the CRC card session is done, it is a good exercise to write down a one or at most two sentence description of what the class does. If it is impossible or not easy to summarize EVERYTHING the class does in such a short statement, it is highly likely that a single class is handling too much and the class should be split into multiple classes. It is also a good idea to turn the card over and on the back write the data members the class needs to have in order to carry out its responsibilities.
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.
Presenter
Presentation Notes
The next step is to come up with a set of specific scenarios for the requirements. A scenario is a sequence of actions that illustrates behavior. For example, while a requirement may be general like The alarm close shall allow a user to set the time, a specific scenario is 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.
Presenter
Presentation Notes
After you come up with a good set of scenarios, as a group you run through each scenario. It’s a good idea to start with the simplest first and then get more complicated. For each scenario, the group determines which classes are involved in fulfilling the scenario. When a class is involved, you write down the responsibility the class has in fulfilling the scenario & what other classes need to get involved for the job to get done in the collaborators. Also, you can turn the card over and write down the knowledge a class needs to have to fulfill the responsibility – what data it need o know. During this brainstorming, the need for additional classes might arise – and at the end of all the scenarios, some classes might end up never being used. That’s OK!
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.
Presenter
Presentation Notes
When you are done with all the scenarios that have been defined – you are left with a set of index cards. So, now what do you do with them? First, you write the main responsibility for each class – and split (or maybe even join) the classes when you have trouble with that statement or when you realize two classes have almost the same main responsibility. Then, essentially, these index cards become your class diagram. In your class diagram, you create a class for each card that was used. The responsibilities on the card become the method of the class. All collaborators indicate that an association between the two classes must be drawn (and the class will need to have an instance of the collaborating classes). Finally, the data members on the back of the card become the attributes of the class. You’ll probably need to make some adjustments to this initial design – for example recognizing and handling inheritance – but its usually a great start!
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
Related Documents
