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

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

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

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

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

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

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

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

SYST30009 - Engineering Quality Software J.N.Kotuba

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. SYST30009 - Engineering Quality Software J.N.Kotuba

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. SYST30009 - Engineering Quality Software J.N.Kotuba

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. SYST30009 - Engineering Quality Software J.N.Kotuba

Objectives for today Learn 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 SYST30009 - Engineering Quality Software J.N.Kotuba

The Pharmacy System Finalize the Event Table Identify the Actors Build the Use Case Diagram SYST30009 - Engineering Quality Software J.N.Kotuba

Event table “Process”  Use Case Event Table is a tool which helps the developer/analyst determine what an information system should do. There are three type of events of interest to the developer. External events Usually initiated by an external agent or the user Temporal events When a point in time is reached State events Something changes within the system “Process”  Use Case

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

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

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. SYST30009 - Engineering Quality Software J.N.Kotuba

Your Turn… See SLATE I-C-E-01 Develop System Architect Context Diagram Event table Use Case Diagram System Architect SYST30009 - Engineering Quality Software J.N.Kotuba

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

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

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

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

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

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. SYST30009 - Engineering Quality Software J.N.Kotuba

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

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

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

Use Case Narrative: Do’s Don’ts Use complete sentences How is the use case initiated and how does it end What the initial and final actions and state of the system look like Don’ts Use abbreviations or sentence fragments SYST30009 - Engineering Quality Software J.N.Kotuba

SYST30009 - Engineering Quality Software J.N.Kotuba

Components of the Use Case Diagram Actor Automation Boundary SYST30009 - Engineering Quality Software J.N.Kotuba

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

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

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

.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. SYST30009 - Engineering Quality Software J.N.Kotuba

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

SYST30009 - Engineering Quality Software J.N.Kotuba

Notation

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. SYST30009 - Engineering Quality Software J.N.Kotuba

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

What comes next? Next Class Read Chapter 2 & Chapter 3 P27-34 Use Cases Class Diagrams Read Chapter 2 & Chapter 3 P27-34 SYST30009 - Engineering Quality Software J.N.Kotuba