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 #4 Use Case Modeling III

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: Pictures of MES/MSIT-SE Students

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 Traceability in use case modeling Traceability in use case modeling From use cases to user interface design From use cases to user interface design Conclusion Conclusion Use Cases  Chocolate or Broccoli Use Cases  Chocolate or Broccoli 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 Traceability via Use Cases Specification Architecture Design Implementation Testing The ability to trace the implementation through the development stages signifies quality software? The ability to track relationships and relate them is the key in many modern software development process? 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 Traceability Relationship The degree to which a relationship can be established between two or more products of the development process The degree to which a relationship can be established between two or more products of the development process The degree to which each element in a software product establishes its reason for existing The degree to which each element in a software product establishes its reason for existing Predecessor-successor relationships Predecessor-successor relationships Master-subordinate relationships Master-subordinate relationships 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 Traceability Links Software requirements and use cases to test plans/test specifications/test results Software requirements and use cases to test plans/test specifications/test results Needs to features Needs to features Features to requirements Features to requirements Requirements to use cases Requirements to use cases Requirements and use cases to implementation units Requirements and use cases to implementation units Use cases to test cases Use cases to test cases …… …… 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 Neglecting Traceability Results in Revisions, thus increased cost and time Revisions, thus increased cost and time Loss of knowledge Loss of knowledge Misunderstandings, miscommunication Misunderstandings, miscommunication Losing even the simplest, but very crucial aspects of the overall software development life cycle Losing even the simplest, but very crucial aspects of the overall software development life cycle e.g.. Where did this use case come from? There is a price to pay for though There is a price to pay for though Significant resource allocation Significant resource allocation 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 Today ’ s Class Traceability in use case modeling Traceability in use case modeling From use cases to user interface design From use cases to user interface design Conclusion Conclusion Use Cases  Chocolate or Broccoli Use Cases  Chocolate or Broccoli 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 User Centered Design User centered design seeks to answer questions such as: User centered design seeks to answer questions such as: Who are the users of this 'thing'? Who are the users of this 'thing'? What are the users ’ tasks and goals? What are the users ’ tasks and goals? What are the users ’ experience levels with this thing, and things like it? What are the users ’ experience levels with this thing, and things like it? What functions do the users need from this thing? What functions do the users need from this thing? What information might the users need, and in what form do they need it? What information might the users need, and in what form do they need it? How do users think this 'thing' should work? How do users think this 'thing' should work? How can the design of this ‘ thing ’ facilitate users' cognitive processes? How can the design of this ‘ thing ’ facilitate users' cognitive processes? Undoubtedly directly influential on the selection of use cases, the actors – defined by entities who initiate behavior – form the users of the system Undoubtedly directly influential on the selection of use cases, the actors – defined by entities who initiate behavior – form the users of the system 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 From Use Case Modeling to Conceptual Modeling Partition the use case model Partition the use case model Decompose the use cases into transactions Decompose the use cases into transactions Determine the information content for each transaction Determine the information content for each transaction Establish logical screen order Establish logical screen order Group and layout logical screens Group and layout logical screens 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 Quality Measures for Requirement Specification IEEE Std 830 – 1998 defines quality by 8 attributes for requirement specification IEEE Std 830 – 1998 defines quality by 8 attributes for requirement specification Correctness Correctness Unambiguity Unambiguity Completeness Completeness Consistency Consistency Ranked for importance and/or stability Ranked for importance and/or stability Verifiability Verifiability Modifiability Modifiability Traceability Traceability How does use case modeling target these attributes? How does use case modeling target these attributes? The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

14. Fall 2005 14 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Class Traceability in use case modeling Traceability in use case modeling From use cases to user interface design From use cases to user interface design Conclusion Conclusion Use Cases  Chocolate or Broccoli Use Cases  Chocolate or Broccoli 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 Chocolate and Use Cases “Chocolate is tempting, delicious and sweat, but is it nutritious?” Use cases unsupported by domain descriptions are vague Use cases unsupported by domain descriptions are vague Must be accompanied by a thorough understanding of the problem context Must be accompanied by a thorough understanding of the problem context You do not get it correct the first time around You do not get it correct the first time around Use cases may pull the attention from the real world to the limited domain of direct interactions Use cases may pull the attention from the real world to the limited domain of direct interactions Some systems are simply not use case driven Some systems are simply not use case driven e.g. algorithm driven, rule based e.g. algorithm driven, rule based 1/2 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 Chocolate and Use Cases Use cases can be ambiguous to describe Use cases can be ambiguous to describe Use cases can turn into hacking when not accompanied by domain analysis Use cases can turn into hacking when not accompanied by domain analysis Use cases do not directly lend themselves into object oriented systems Use cases do not directly lend themselves into object oriented systems Typically fallen into course is treating each scenario independently, creating code for each thread of control modeled in each scenario Typically fallen into course is treating each scenario independently, creating code for each thread of control modeled in each scenario 2/2 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 Broccoli There is no one method suitable for all problems There is no one method suitable for all problems There may be alternative ways to apply one method in different contexts There may be alternative ways to apply one method in different contexts Resources will effect the method of choice more than you may predict Resources will effect the method of choice more than you may predict Good tools may become handy at even unexpected circumstances Good tools may become handy at even unexpected circumstances The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

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