cs 451 software engineering
play

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

CS 451 Software Engineering Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1 Drexel University Design Engineering A systematical way to translate SRS into design Start with use cases from SRS


  1. CS 451 Software Engineering Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1 Drexel University

  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  Data Design  Architecture Design  Interface Design  Component Design  Detailed/Data Design  2 Drexel University

  3. SOLID  Information Hiding [Parnas 1972] Drexel University

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

  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 Drexel University

  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 Drexel University

  7. CRC Cards 7 Drexel University

  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 Drexel University

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

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

  11. An Example CRC Card - Back Slide 11 Drexel University

  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. Drexel University

  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. Drexel University

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

  15. Clear Intersection Example  From the Use Cases to Design Drexel University

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

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

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

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

  20. 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  Drive way.  Join  Car approaches the intersection and the  Collaborator light is red.  Traffic light  Car is in the queue and the light turns  Queue green.  Intersection  Car Drexel University

  21. 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. 4 X 6 Class Name (or 3 X 5) Index card Main Responsibility Responsibilities Collaborators . . . . . . Drexel University

  22. Candidate Classes  Car  Traffic light Car Light Queue  Queue Green?  Intersection green Clear? Clear go  What else? 22 Drexel University

  23. Class Diagram 1 1 1 1 23 Drexel University

  24. From Classes to Components < < component > > Model < < component > > < < component > > Controller View 24 Drexel University

  25. Component Diagram (UML 2.0) < < component > > Model < < component > > View < < component > > Controller 25 Drexel University

  26. Component Diagram (UML 2.0) < < component > > Model < < component > > Model changed() View Model changed() < < component > > Controller View changed() 26 Drexel University

  27. Deployment Diagram Tux < < component > > < < component > > Model View < < component > > Controller 27 Drexel University

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

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

  30. The Design of Traffic Simulator 1 1 1 1 30 Drexel University

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

Recommend


More recommend