CS 451 Software Engineering

Transcription

1 CS 451 Software Engineering Yuanfang Cai Room 104, University Crossings

2 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

3 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

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

5 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

6 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

7 CRC Cards 7

8 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

9 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 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

10 An Example CRC Card - Front Main Responsibilit y A patient makes appointments, review or configure insurance information, and provides medical history Slide 10

11 An Example CRC Card - Back Slide 11

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

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

14 An ATM Example See Class Exercise 14

15 ATM All Nouns 15

16 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

17 ATM Example: 17

18 More ATM CRC Cards 18

19 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

20 ATM BankAccount Class 20

21 ATM Dispenser class 21

22 ATM Transaction Class 22

23 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

24 CRC Cards Relationship 24

25 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

26 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

27 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

28 Clear Intersection Example From the Use Cases to Design

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

30 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

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

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

33 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 Main Responsibility 4 X 6 (or 3 X 5) Index card Responsibilities Collaborators......

34 The Design of Traffic Simulator

35 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

36 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

37 The Design of Traffic Simulator

38 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

39 Data Modeling Concepts Data objects can then be represented as tables: 39

40 Data Modeling Concepts Data attributes define properties of a data object. RELATIONSHIPS Data objects connect to one another in different ways. 40

41 Data Modeling using Classes 41

42 The Data Model Design of TheraWii 42

43 Database Scheme Design Entity Relation Diagram 43

44 The Database Design of Vodka 44

45 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

46 The Component and Interface Design of TheraWii 46

47 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