1. Engineering Quality Software Week02 J.N.Kotuba1 SYST30009 - Engineering Quality Software

2. Agenda Schedule Recap last lesson Learning outcomes for today o Develop the requirements model o Use cases Associations between Use Cases o Use case diagrams o Use case narratives o Activity Diagrams J.N.Kotuba SYST30009 - Engineering Quality Software 2

3. Last Class Introduced Unified Process (UP) and Unified Modeling Language (UML) Discussed o Models o Tools o Techniques Introduced Event Tables J.N.Kotuba SYST30009 - Engineering Quality Software 3

4. The Unified Process Four key stages. o Inception. o Elaboration o Construction o Transition J.N.Kotuba SYST30009 - Engineering Quality Software 4

5. Unified Process: Inception Go ahead on project. Scope determined. Business case developed for project. J.N.Kotuba SYST30009 - Engineering Quality Software 5

6. Unified Process: Elaboration Basic architecture of the system developed. Construction plan is approved. Risks are identified. J.N.Kotuba SYST30009 - Engineering Quality Software 6

7. Unified Process: Construction. Iterative approach to developing software. Product will be a beta. J.N.Kotuba SYST30009 - Engineering Quality Software 7

8. Unified Process:Transition Beta product is introduced to users and information is collected from users during roll-out. J.N.Kotuba SYST30009 - Engineering Quality Software 8

9. J.N.Kotuba SYST30009 - Engineering Quality Software 9

10. Modeling Software development is the production of ‘executable models’. These models often are abstractions of the original problem with classes added to solve the user’s problems. J.N.Kotuba SYST30009 - Engineering Quality Software 10

11. Different Types of Models Use Case Model. The system from the users point of view. Static Model. The elements of the system and how they relate to one another. Dynamic Model. Outlines the behaviour of the system in the context of Object interactions. J.N.Kotuba SYST30009 - Engineering Quality Software 11

12. UML The Unified Modeling language is (UML) a language for development object-oriented models and system designs. It provides a complete set of graphical diagrams to specify use cases, class diagrams and the dynamic model (object interactions) of a system. Can be used with different programming languages. J.N.Kotuba SYST30009 - Engineering Quality Software 12

13. Objectives for today Review how to construct a use case diagram from an event table Learn how to build a use case narrative for each use case and why the narratives are important. Learn how to draw an activity diagram J.N.Kotuba SYST30009 - Engineering Quality Software 13

14. The Pharmacy System Event Table Analysis of the events that result in responses from the system. Identify the Use Cases The system activities/processes that respond. Identify the Actors Actors are the actual users of the system. Construct the Use Case Diagram Add system boundary and title. J.N.Kotuba SYST30009 - Engineering Quality Software 14

15. Event table “Process”  Use Case

16. Using System Architect Create the UC for Pharmacy System J.N.Kotuba SYST30009 - Engineering Quality Software 16

17. Identifying the Actors Where do you look? o Context Diagram o Existing system documentation (our case) Ask the following questions o Who or what provides inputs,such as forms, voice commands, fields on input screens, etc to the system? o Who or what receives outputs, such as email notifications, reports, voice messages, etc from the system? o Are interfaces required to other systems? o Are there any events that are automatically triggered at a predetermined time? o Who (User) will maintain the information system? J.N.Kotuba SYST30009 - Engineering Quality Software 17

18. Use Case - Actors An actor is always outside the automation boundary of the system but may be part of the manual portion of the system an actor is not always the same as the source of the event in the event table. A source of an event is the initiating person, such as a customer, and is always external to the system, including the manual system. an actor in use case analysis is the person who is actually interacting (hands-on) with the computer system itself. J.N.Kotuba SYST30009 - Engineering Quality Software 18

19. Use Case Identifies What Users Want Use cases focus on usage of the system o Services o Behaviors o Responses No internal structural details of the system Can be considered as the “responsibilities” of the system J.N.Kotuba SYST30009 - Engineering Quality Software 19

20. Use Case Identifies What Users Want Next o Validate use case names o Write narrative descriptions for each use case J.N.Kotuba SYST30009 - Engineering Quality Software 20 Refining the name o May “discover” more than one use case E.g register member o Register new member o Renew existing member Purchase o Retail o Trade o Dealer o staff

21. Use Case Identifies What Users Want Refining the name o Does it tell the whole story? o Any exceptions? o Special cases? o Possible errors? o Occasional variations? o Does the name cover several related or similar processes? o Is there a more informative or enlightening name? J.N.Kotuba SYST30009 - Engineering Quality Software 21

22. Use Case Identifies What Users Want Write a narrative description o Sequence of events or steps user goes through. Focus on mainline o Straight-line sequence o Then consider exceptions, options errors J.N.Kotuba SYST30009 - Engineering Quality Software 22

23. Use Cases Analysts define use cases at three levels Brief Intermediate Fully developed J.N.Kotuba SYST30009 - Engineering Quality Software 23

24. J.N.Kotuba SYST30009 - Engineering Quality Software 24 Brief Description of Create New Order Use Case

25. J.N.Kotuba SYST30009 - Engineering Quality Software 25 Intermediate Description of Telephone Order Scenario for Create New Order Use Case

26. J.N.Kotuba SYST30009 - Engineering Quality Software 26 Fully Developed Description of Telephone Order Scenario for Create New Order Use Case

27. Use Case Narrative: Fill Prescription Step 1.Pharmacist inputs Patient ID Step 2.System displays patient medical record Step 3.Pharmacist verifies dosage, potential allergic reactions and/or interaction with other medications. Step 4.The Pharmacist fills the prescription and updates the patient’s medical record on the system with details of the new prescription. Step 5. The system prints a label which is sent to the nurses station and the Billing Dept is given Patient and Prescription details. Alt Step 3. If the pharmacist determines a possible negative condition exists, then the Doctor is contacted Alt Step 4. The prescription is held for disposition. J.N.Kotuba SYST30009 - Engineering Quality Software 27

28. Use Case Narrative: J.N.Kotuba SYST30009 - Engineering Quality Software 28

29. Use case scenarios… Jerry Kotuba SYST30009 - Engineering Quality Software 29 Case In Point

30. Use Case Relationships Jerry Kotuba SYST30009 - Engineering Quality Software 30 Includes o Case In Point – “Stop Payment” Extends o Case In Point – “Register Student”

31. Comments on Include & Extend Jerry Kotuba SYST30009 - Engineering Quality Software 31 Tend to see more includes. Extends are fewer.

33. Components of the Use Case Diagram Use CaseActor System Boundary J.N.Kotuba SYST30009 - Engineering Quality Software 33

34. Use Case Guidelines Names o Noun + Verb SYST30009 - Engineering Quality Software 34 J.N.Kotuba

35. Use Case Guidelines Nouns SYST30009 - Engineering Quality Software 35 J.N.Kotuba

36. Use Case Guidelines Avoid using implementation system specific language when writing use case narratives SYST30009 - Engineering Quality Software 36 J.N.Kotuba

37. .Summary- Developing the Requirements Model: The Use Case Model Use Cases are an informal description of the system; They do not give information about how the system does things Or any other details internal to the system. They just tell us what the system will do for the users. Concentrating on what rather than how makes them more a tool for analysis than design, but... They do give us a good starting point for both Testing the system, and Prototyping the user interface. J.N.Kotuba SYST30009 - Engineering Quality Software 37

39. Activity Diagram A type of workflow diagram that describes the user activities and their sequential flow. Illustration: o The following slide summarizes the workflow of how a customer request for a quotation to modify a computer system is handled. J.N.Kotuba SYST30009 - Engineering Quality Software 39

40. SYST39409 - Object Oriented Methodologies 40

41. Design Quality A key factor in the quality of a system is how well the full effects of the individual components the system can be understood. It is difficult to change individual components in a system unless their function is understood. J.N.Kotuba SYST30009 - Engineering Quality Software 41

42. Recap Lesson Learning outcomes for today Develop the requirements model Use cases Use case diagrams Use case narratives Activity Diagrams J.N.Kotuba SYST30009 - Engineering Quality Software 42

43. What comes next? Next Class Building Test Cases for Use Cases J.N.Kotuba SYST30009 - Engineering Quality Software 43