Transcript Engineering Quality Software

Engineering
Quality
Software
Week02
SYST30009 - Engineering Quality
Software
J.N.Kotuba
1
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
SYST30009 - Engineering Quality
Software
J.N.Kotuba
2
Last Class
• Introduced Unified Process (UP) and Unified
Modeling Language (UML)
• Discussed
o Models
o Tools
o Techniques
• Introduced Event Tables
SYST30009 - Engineering Quality
Software
J.N.Kotuba
3
The Unified Process
• Four key stages.
o
o
o
o
Inception.
Elaboration
Construction
Transition
SYST30009 - Engineering Quality
Software
J.N.Kotuba
4
Unified Process: Inception
• Go ahead on project.
• Scope determined.
• Business case developed for project.
SYST30009 - Engineering Quality
Software
J.N.Kotuba
5
Unified Process: Elaboration
• Basic architecture of the system developed.
• Construction plan is approved.
• Risks are identified.
SYST30009 - Engineering Quality
Software
J.N.Kotuba
6
Unified Process: Construction.
• Iterative approach to developing software.
• Product will be a beta.
SYST30009 - Engineering Quality
Software
J.N.Kotuba
7
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
8
SYST30009 - Engineering Quality
Software
J.N.Kotuba
9
Modeling
Software
development is the
production of
‘executable
models’.
SYST30009 - Engineering Quality
Software
These models
often are
abstractions of the
original problem
with classes added
to solve the user’s
problems.
J.N.Kotuba
10
Different Types of Models
Use Case Model.
The system from
the users point of
view.
Dynamic Model.
Outlines the
behaviour of the
system in the
context of Object
interactions.
Static Model.
The elements of
the system and
how they relate
to one another.
SYST30009 - Engineering Quality
Software
J.N.Kotuba
11
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
12
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
SYST30009 - Engineering Quality
Software
J.N.Kotuba
13
The Pharmacy System
Event Table
Identify the Use
Cases
Identify the
Actors
Construct the Use
Case Diagram
• Analysis of the events that result in responses from the
system.
• The system activities/processes that respond.
• Actors are the actual users of the system.
• Add system boundary and title.
SYST30009 - Engineering Quality
Software
J.N.Kotuba
14
Event table
“Process”  Use Case
Using System Architect
• Create the UC for Pharmacy System
SYST30009 - Engineering Quality
Software
J.N.Kotuba
16
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?
SYST30009 - Engineering Quality
Software
J.N.Kotuba
17
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
18
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
SYST30009 - Engineering Quality
Software
J.N.Kotuba
19
Use Case Identifies What Users Want
• Next
o Validate use case
names
o Write narrative
descriptions for
each use case
• 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
o
o
o
SYST30009 - Engineering Quality
Software
Retail
Trade
Dealer
staff
J.N.Kotuba
20
Use Case Identifies What Users Want
• Refining the name
o
o
o
o
o
o
o
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
21
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
SYST30009 - Engineering Quality
Software
J.N.Kotuba
22
Use Cases
Analysts define
use cases at
three levels
• Brief
• Intermediate
• Fully developed
SYST30009 - Engineering Quality
Software
J.N.Kotuba
23
Brief Description of Create New Order Use Case
SYST30009 - Engineering Quality
Software
J.N.Kotuba
24
Intermediate Description of Telephone Order Scenario for Create New
Order Use Case
SYST30009 - Engineering Quality
Software
J.N.Kotuba
25
Fully Developed Description of Telephone Order Scenario for Create New Order
Use Case
SYST30009 - Engineering Quality
Software
J.N.Kotuba
26
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
27
Use Case Narrative:
SYST30009 - Engineering Quality
Software
J.N.Kotuba
28
Use case scenarios…
• Case In Point
SYST30009 - Engineering Quality
Software
Jerry Kotuba
29
Use Case Relationships
• Includes
o Case In Point – “Stop Payment”
• Extends
o Case In Point – “Register Student”
SYST30009 - Engineering Quality
Software
Jerry Kotuba
30
Comments on Include & Extend
• Tend to see more includes.
• Extends are fewer.
SYST30009 - Engineering Quality
Software
Jerry Kotuba
31
Components of the Use
Case Diagram
Use Case
Actor
System
Boundary
SYST30009 - Engineering Quality
Software
J.N.Kotuba
33
Use Case Guidelines
• Names
o Noun + Verb
J.N.Kotuba
SYST30009 - Engineering Quality
Software
34
Use Case Guidelines
• Nouns
J.N.Kotuba
SYST30009 - Engineering Quality
Software
35
Use Case Guidelines
• Avoid using implementation
system specific language
when writing use case
narratives
J.N.Kotuba
SYST30009 - Engineering Quality
Software
36
.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
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
SYST30009 - Engineering Quality
Software
Or any other details
internal to the
system.
Prototyping the user
interface.
J.N.Kotuba
37
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.
SYST30009 - Engineering Quality
Software
J.N.Kotuba
39
Generate a quotation
The customer initiates the process by requesting a quote. A
salesperson receives the request and writes down the details
of the request and then decides whether she can do it herself
or whether she needs help. If she does not need help, then
the salesperson enters the information into the computer
system. If the salesperson needs help, then the technical
expert performs the next step. The expert reviews the quote
request to make sure that the requested components can be
integrated into a functioning computer system. The expert
then enters the information into the computer system. At
this point, the computer system generates the detailed quote.
The customer reviews the quote and decides whether it needs
changes or is acceptable. If acceptable, places the order.
40
SYST39409 - Object
Oriented Methodologies
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
41
Recap Lesson
Learning outcomes for
today
Develop the
requirements
model
Use cases
SYST30009 - Engineering Quality
Software
Use case
diagrams
Use case
narratives
Activity
Diagrams
J.N.Kotuba
42
What comes next?
Next
Class
• Building Test
Cases for Use
Cases
SYST30009 - Engineering Quality
Software
J.N.Kotuba
43