1. Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture #3 Use Case Modeling II

2. Fall 2005 2 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Announcements The class schedule after the Chooseok holiday has been changed The class schedule after the Chooseok holiday has been changed On 9/20, we will discuss about various software development methods On 9/20, we will discuss about various software development methods

3. Fall 2005 3 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Picture of the Day: The Cave

4. Fall 2005 4 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Plan for This Unit 09/02 : Fundamentals 09/02 : Fundamentals Scoping the problem through use cases Scoping the problem through use cases 09/06 : Structuring a well use case model 09/06 : Structuring a well use case model 09/09 : External viewpoints reports on understanding client ’ s needs 09/09 : External viewpoints reports on understanding client ’ s needs Make a 15 minute presentation Make a 15 minute presentation Send an abstract description of the main idea by 09/06 Send an abstract description of the main idea by 09/06 Suchman: Plans and Situated Accidents  TTA Suchman: Plans and Situated Accidents  TTA Carroll: Making Use  Posdata Carroll: Making Use  Posdata Moody: I Sing the Body Electronic  Hyundai Moody: I Sing the Body Electronic  Hyundai 09/13 : Project presentations of technical requirements of the studio projects through use cases 09/13 : Project presentations of technical requirements of the studio projects through use cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

5. Fall 2005 5 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Class Business and domain modeling Business and domain modeling Writing effective use cases and functional decomposition Writing effective use cases and functional decomposition Use cases and the overall project development cycles Use cases and the overall project development cycles The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

6. Fall 2005 6 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Projects Goal: Describe the technical requirements of your studio problem via use case modeling Goal: Describe the technical requirements of your studio problem via use case modeling Purpose: Purpose: Start brainstorming about your problem scope – functionalities you intent to deliver Start brainstorming about your problem scope – functionalities you intent to deliver Differentiate stakeholders and actors early on Differentiate stakeholders and actors early on Exercise use case modeling Exercise use case modeling Share your problem with rest of us who may not have a clear understanding Share your problem with rest of us who may not have a clear understanding Challenges: Challenges: You may or may not have a chance to meet with your client, but use case modeling (as opposed to task analysis) can be approached as your view of the problem as a requirement communication medium You may or may not have a chance to meet with your client, but use case modeling (as opposed to task analysis) can be approached as your view of the problem as a requirement communication medium 1/3 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

7. Fall 2005 7 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Projects Suggested outline Suggested outline Give a brief description of your problem Give a brief description of your problem Identify and briefly describe actors (not stakeholders) Identify and briefly describe actors (not stakeholders) Identify an initial set of use cases, structure the use case diagram Identify an initial set of use cases, structure the use case diagram Perform domain modeling Perform domain modeling Brainstorm alternative scenarios for use cases Brainstorm alternative scenarios for use cases Describe select high priority use cases Describe select high priority use cases Discuss possible nonfunctional requirements your use cases may have not captured, comment on possible alternative problem scoping paths and bottlenecks you see in your problem Discuss possible nonfunctional requirements your use cases may have not captured, comment on possible alternative problem scoping paths and bottlenecks you see in your problem 2/3 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

8. Fall 2005 8 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Projects Criteria for presentations and reports Criteria for presentations and reports How well have you identified the actors of your system? How well have you identified the actors of your system? How well have you defined your system scope, performed domain modeling? How well have you defined your system scope, performed domain modeling? How well have you focused on outlining the system through use cases? How well have you focused on outlining the system through use cases? How well are you aware of the possible pitfalls? How well are you aware of the possible pitfalls? 3/3 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

9. Fall 2005 9 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Issues Use case modeling is not good for everything Use case modeling is not good for everything Selecting the right tool at the right time Selecting the right tool at the right time Balancing resources, benefits and needs is crucial Balancing resources, benefits and needs is crucial Aspects to think in evaluating use case modeling Aspects to think in evaluating use case modeling Critical quality attributes Critical quality attributes Balance between system and human actors Balance between system and human actors Use case development process Use case development process Completeness versus resources available Completeness versus resources available The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

10. Fall 2005 10 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Business Modeling Understanding the business Understanding the business Understanding the “business system” Understanding the “business system” To develop a business model To develop a business model Business use case model Business use case model Business object model Business object model Workers, entities, work units Workers, entities, work units The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

11. Fall 2005 11 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Domain Modeling A special case of a business model A special case of a business model Creation of a common vocabulary that reflect tangible objects in the domain Creation of a common vocabulary that reflect tangible objects in the domain A tool to aid in eliciting A tool to aid in eliciting Business objects Business objects Real-world objects Real-world objects Events Events Represented usually as a UML class diagram Represented usually as a UML class diagram Sometimes replaced by glossary of terms Sometimes replaced by glossary of terms 1/2 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

12. Fall 2005 12 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Domain Modeling Domain modeling for the course management subsystem of AIMS Domain modeling for the course management subsystem of AIMS Domain object Description Use case Course Information The information object about a course entered by an instructor Add syllabus, Edit evaluation criteria, … Student Users who intend to use AIMS for course registration Register course, Check prerequisites, …. 2/2 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

13. Fall 2005 13 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Modeling Activities Create test cases and documen- tation Organize the use cases Prepare for use case modeling Perform stakeholder analysisPerform stakeholder analysis Select & customize use case frameworkSelect & customize use case framework Select standards, templates, and toolsSelect standards, templates, and tools Determine training and mentoring needsDetermine training and mentoring needs Perform initial use case modeling Develop context diagramDevelop context diagram Identify the major actorsIdentify the major actors Discover the conceptual system use casesDiscover the conceptual system use cases Develop initial use case diagramDevelop initial use case diagram Determine/refine the conceptual business objectsDetermine/refine the conceptual business objects Perform advanced use case modeling Develop base use case descriptionsDevelop base use case descriptions Elaborate the base use case descriptionElaborate the base use case description Model extend, include, and generalization relationshipsModel extend, include, and generalization relationships Map use cases to object modelsMap use cases to object models Develop instance scenariosDevelop instance scenarios

14. Fall 2005 14 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University The Context The focus is in defining what is part of the system, what is not The focus is in defining what is part of the system, what is not External entities become candidate actors, i.e. External entities become candidate actors, i.e. The roles and responsibilities that will be carried by that external entity The roles and responsibilities that will be carried by that external entity The system to be implemented External entities The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

15. Fall 2005 15 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Requirement Capture via Use Cases A single use case carries multiple requirements A single use case carries multiple requirements A single use case can involve many specific interactions and behaviors A single use case can involve many specific interactions and behaviors A single use case when initiated by different actors may trigger different events A single use case when initiated by different actors may trigger different events General descriptions draw the outline, but requirement capture mostly occurs in instance scenarios General descriptions draw the outline, but requirement capture mostly occurs in instance scenarios The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

16. Fall 2005 16 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Extra Functional Requirements Use cases are vague in capturing low level system requirements Use cases are vague in capturing low level system requirements … ilities  modifiability, extensibility, usability … … ilities  modifiability, extensibility, usability … Performance  security, capacity, … Performance  security, capacity, … Associations, generalizations, hierarchies, dependencies Associations, generalizations, hierarchies, dependencies Object modeling is offered as a method to fill the gaps Object modeling is offered as a method to fill the gaps Identify the candidate objects that participate in use cases and perform “ object to use case modeling to object modeling ” iterations Identify the candidate objects that participate in use cases and perform “ object to use case modeling to object modeling ” iterations Typical rule of the thumb approach offered Typical rule of the thumb approach offered Verbs  use cases Verbs  use cases Nouns  objects Nouns  objects The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

17. Fall 2005 17 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Initial Use Case Modeling Find use cases based on actor’s perspective Find use cases based on actor’s perspective Check if a use case does not provide value to any actor, then, it may be a candidate to remove Check if a use case does not provide value to any actor, then, it may be a candidate to remove Capture use cases at the same level of granularity Capture use cases at the same level of granularity Validate use cases and their descriptions with actors and other stakeholders Validate use cases and their descriptions with actors and other stakeholders  May have workshops to find and validate conceptual use case descriptions (a training session  multiple workshop groups  a review session)

18. Fall 2005 18 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Business and domain modeling Business and domain modeling Writing effective use cases and functional decomposition Writing effective use cases and functional decomposition Use cases and the overall project development cycles Use cases and the overall project development cycles The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

19. Fall 2005 19 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Modeling - Describing a Use Case 1/3 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. Name: Actors: Description: Name: Actors: Description: Initial use case descriptions Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Base use case descriptions Broad descriptions of system behaviors initiated by actors Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Elaborated use case descriptions Detail descriptions of behaviors including condition logic and alternative flows

20. Fall 2005 20 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Modeling - Describing a Use Case If the flow of events is important, you can describe it by: If the flow of events is important, you can describe it by: Using natural language Using natural language Using “ sequence of action ” approach Using “ sequence of action ” approach Maps nicely to interaction diagrams and object decompositions Maps nicely to interaction diagrams and object decompositions Using states Using states Good for representing multiple nonlinear paths (state diagrams) Good for representing multiple nonlinear paths (state diagrams) 2/3 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

21. Fall 2005 21 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Modeling - Describing a Use Case Black box versus white box approach Black box versus white box approach Do you represent internal system details or not Do you represent internal system details or not Advantages of black box Advantages of black box Does not assume a technical solution Does not assume a technical solution Focuses on users, taking the process one step ahead from actors Focuses on users, taking the process one step ahead from actors Advantages of white box Advantages of white box Draws focus to the internal details when they are essential to identify requirements Draws focus to the internal details when they are essential to identify requirements Forces to start thinking about technical aspects  what is a wish list, what is a doable sequence Forces to start thinking about technical aspects  what is a wish list, what is a doable sequence 3/3 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

22. Fall 2005 22 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Diagram – Structuring in the UML Context The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. Relationships Communication Generalization Includes or uses Extends [Booch, Rumbaugh, Jacobsen (1999) The Unified Modeling Language Guide] communication generalization Validate User Check Password Retinal Scan Place Rush OrderPlace Order set priority > Customer Track Order >

23. Fall 2005 23 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Diagram – Further Structuring Vertical versus horizontal division Vertical versus horizontal division Variations based on different initiators Variations based on different initiators e.g., BBS in AIMS – ‘ show BBS categories ’ use case - functions different for students and instructors e.g., BBS in AIMS – ‘ show BBS categories ’ use case - functions different for students and instructors Conditional logic points Conditional logic points The branches may be triggering other use cases The branches may be triggering other use cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

24. Fall 2005 24 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University CRUD Matrix Create, Read, Update and Delete use cases Create, Read, Update and Delete use cases To map use cases to object models To map use cases to object models Example: A financial planner Example: A financial planner Use cases Objects Evaluate a goal Check spending Submit spending Account Read, Update ReadCreate GoalCreateReadUpdate UserCreateRead The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

25. Fall 2005 25 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Business and domain modeling Business and domain modeling Writing effective use cases and functional decomposition Writing effective use cases and functional decomposition Use cases and the overall project development cycles Use cases and the overall project development cycles The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

26. Fall 2005 26 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University From Use Cases to Objects Domain object modeling Domain object modeling A domain or business level of abstraction A domain or business level of abstraction Determine the key elements of the system that all the involved parties need to have an agreed understanding on Determine the key elements of the system that all the involved parties need to have an agreed understanding on Analysis object modeling Analysis object modeling A logical or requirements level of abstraction A logical or requirements level of abstraction Utilize use cases to extract system level objects Utilize use cases to extract system level objects Design object modeling Design object modeling Map the analysis objects to design objects for implementation Map the analysis objects to design objects for implementation 1/2 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

27. Fall 2005 27 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University From Use Cases to Objects Jacobsen, Booch, Rumbaugh view [JBR 1999] - RUP Jacobsen, Booch, Rumbaugh view [JBR 1999] - RUP Analysis Model Specified by Deployment Model Distributed by Design Model Realized by Implementation Model Implemented by X OK X OK X OK Test Model Verified by Use Case Model 2/2 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

28. Fall 2005 28 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Realizations Use case model Design model participating classes Bank Customer Money Receptor Cashier Interface Dispenser Withdrawal Transfer Deposit Account Deposit Money Transfer between Accounts Withdraw Money Bank Customer Use case model Analysis model The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

29. Fall 2005 29 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University From Use Cases to Design and Code One-to-one cases from flow of events One-to-one cases from flow of events “ Launch help when the user enters a valid password ” “ Launch help when the user enters a valid password ” “ Support eight-digit floating-point input parameters ” “ Support eight-digit floating-point input parameters ” Orthogonal cases: challenge of moving from real world items to structural constructs like stacks, queues, hash tables …, lack of direct relationship Orthogonal cases: challenge of moving from real world items to structural constructs like stacks, queues, hash tables …, lack of direct relationship Process structure of implementation Process structure of implementation Interaction between requirements Interaction between requirements Non-functional requirements Non-functional requirements The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

30. Fall 2005 30 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Test Cases Use Case 2 Use Case 1 Use Case 2.1 Use Case Model Test Case 2 Test Case 1 Test Case Model (traceability links) The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

31. Fall 2005 31 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Test Case Design Test Case ID Event description Input 1 Input 2 Expected Result Basic Flow 2001 Resident presses control switch Any enabled button Light was on before button pressed Light is turned off 2002 Light was off Light is turned on 2003 Resident releases button in less than 1 second Light on Stays off 2005 Resident releases button in less than 1 second Light off Stays on Test case for ‘Control Light’ use case The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

32. Fall 2005 32 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Questions??