object oriented methodologies

SYST39409 - Object Oriented Methodologies 1

OBJECT ORIENTED METHODOLOGIES

Week02J.N.Kotuba

SYST39409 - Object Oriented Methodologies

2

Agenda

J.N.Kotuba

Assignment No 1 posted Review details

SLATE-Weekly Topical Outline and Schedule modified

Recap last lesson Learning outcomes for today

Develop the requirements model & the Unified Process

Use cases Use case diagrams Use case narratives


3

Last Class

J.N.Kotuba

Introduced Unified Modeling Language (UML)

Discussed Models Tools Techniques


4

Context Diagram –Pharmacy System

J.N.Kotuba


5

Objectives for today

J.N.Kotuba

Explain the difference between the Waterfall SDLC and the unified process

Learn how to use the Event Table Technique to identify use cases

Learn how to construct a use case diagram Learn how to build a use case narrative for

each use case and why the narratives are important

Be able to explain the difference between the system boundary and the automation boundary


6

The Unified Process

J.N.Kotuba

Four key stages. Inception. Elaboration Construction Transition


7

Unified Process:Inception

J.N.Kotuba

Go ahead on project. Scope determined. Business case developed for project.


8

Unified Process: Elaboration

J.N.Kotuba

Basic architecture of the system developed.

Construction plan is approved. Risks are identified.


9

Unified Process: Construction.

J.N.Kotuba

Iterative approach to developing software.

Product will be a beta.


10

Unified Process:Transition

J.N.Kotuba

Beta product is introduced to users and information is collected from users during roll-out.

Iterative Development

J.N.Kotuba

Planning

Use Cases

Analysis

Design

Test

Implement

Analysis

Design

Test

Implement

Analysis

Design

Test

Implement


12

Modeling

J.N.Kotuba

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.


13

Different Types of Models

J.N.Kotuba

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.


14

UML

J.N.Kotuba

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.


15

System Boundary vs Automation Boundary

J.N.Kotuba


16

J.N.Kotuba

System Boundary vs Automation Boundary

Use Case Model

A use case is a script: A step-by-step

description of how a user might make use of the system to do a task

It is a “case of the usage of the system.”

17

User Goals, Events, and Use Cases

Use Case -- An activity the system performs in response to a user request

Techniques for identifying use cases User goal technique

Each goal at the elementary business process (EBP) level is a use case

EBP – a task performed by one user, in one place in response to a business event, that adds measurable business value, and leaves system and data in consistent state

18

User Goals, Events, and Use Cases (continued)

CRUD analysis technique (create, read, update, delete)

Event decomposition technique

19

Identifying Use Cases Based on User Goals

20

Use Case Based on CRUD Technique

21

SYST39409-Object Oriented Methodologies

22

CRUD Matrix Example

© Jerry Kotuba


23

Discovering Use Cases

Event – in the real worldEvent occurs when something happens Events drive or trigger all processing that a system

does. What events occur that will affect the system being

studied? What events occur that will require the system to

respond in some way? Black Box view – focus on “what” not “how”

© Jerry Kotuba

Event Decomposition Technique

Event – an occurrence at a specific time and place and which needs to be remembered

Business events trigger elementary business processes (EBPs)

EBPs are at correct level of analysis for use cases

Identify business events to decompose system into activities/use cases

24

Types of Events External

Outside system Initiated by external agent or actor

Temporal Occur as result of reaching a point in time Based on system deadlines

State Something inside system triggers processing

need

25

Events – (affecting a system)


27

External event checklist

© Jerry Kotuba


28

Temporal Event Checklist

© Jerry Kotuba


29

Listing events

When analyzing a system we must list all events

Identify other information about each of them

© Jerry Kotuba

Identifying Events Can be difficult to determine

Often confused with conditions and responses

May be useful to trace a transaction’s life cycle

Certain events left to design phase

System controls to protect system integrity

Perfect technology assumption defers events

30

Sequence of Actions that Lead Up to Only One Event Affecting the System

31

Sequence of “Transactions” for One Specific Customer Resulting in Many Events32

Events Deferred Until the Design Phase

33

SYST39409-Object Oriented Methodologies34 © Jerry Kotuba

Event table

“Process” Use Case


35

Event Table Exercise- Pharmacy System

J.N.Kotuba


36

Identifying the Actors

J.N.Kotuba

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?


37

Use Case - Actors

J.N.Kotuba

An actor is always outside the automation boundary of the system but may be partof the manual portion of the system

an actor is not always the same asthe 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.


38

Use Case Identifies What Users Want

J.N.Kotuba

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

39



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

J.N.Kotuba


40


J.N.Kotuba

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?


41


J.N.Kotuba

Write a narrative description Sequence of events or steps user goes

through. Focus on mainline

Straight-line sequence Then consider exceptions, options errors


42

Use Cases

J.N.Kotuba

Analysts define use cases at three levels Brief Intermediate Fully developed


43

Use Case Narrative:Fill Prescription

J.N.Kotuba

Step 1.Pharmacist inputs Patient IDStep 2.System displays patient medical recordStep 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 and the process terminates with the pharmacist proceeding to the next prescription in the queue.

SYST39409 - Object Oriented Methodologies44 J.N.Kotuba

Brief Description of Create New Order Use Case


Intermediate Description of Telephone Order Scenario for Create New Order Use Case


Fully Developed Description of Telephone Order Scenario for Create New Order Use Case


Package:

Pharmacy System

Use Case Name: Review Prescription

Primary Actor: Pharmacy Technician

Other Participating Actors:

Summary Description:

When prescriptions are received at the Mercy Hospital Pharmacy, they are directed to the Pharmacy Technician. He reviews the prescription and then decides, based on the type of medication, which of three stations to direct it to for filling.

Preconditions: The prescription must be for a current patient of Mercy Hospital and issued by a licensed Medical Doctor.

Trigger: Prescription is received by the pharmacy.

Typical Course of events: 1. Pharmacy Technician (PT) verifies that the patient is an admitted

patient.2. PT verifies that a licensed Medical Doctor issued the prescription.3. PT logs the prescription into the system and it is assigned a serialized

ID number by the system.4. PT checks the type of medication; if it must be formulated (made-on-

site), sends it to the lab station; if it is an off-the-shelf medication, sends it to the shelving station; narcotics are sent to the secure station.

5. PT enters the shelving station ID to which it was sent into the system.

Alternative Paths: If the patient is not currently admitted to the Hospital, the prescription is returned to the Doctor. If the Doctor is not listed in the Pharmacy database, the prescription is referred to the Pharmacist for disposition.

Post conditions: The prescription is assigned to a filling station and logged into the system for tracking.

Assumptions:

Related Business Rules: Prescriptions can only be accepted from licensed Physicians for patients admitted to Mercy Hospital.

Author: J.N.KotubaDate: May 2012

Example“ReviewPrescription”Use CaseFully Developed

49


Use Case Narrative:

Do’s 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

J.N.Kotuba


51

Components of the Use Case Diagram

J.N.Kotuba

Use Case Actor System Boundary


52

Draw the Use Case with SA

J.N.Kotuba


53

Your Turn…

J.N.Kotuba

See SLATE – I-C-E-01 Use Case For the Dental Office

Appointment System, develop; Context Diagram Event table Use Case Diagram Create a narrative for each use case

(Intermediate Level)


54

Use Case Guidelines

Names Noun + Verb

J.N.Kotuba


55

Use Case Guidelines

Nouns

J.N.Kotuba


56

Use Case Guidelines Avoid using

implementation system specific language when writing use case narratives

J.N.Kotuba


57

.Summary Developing the Requirements Model:

The Use Case Model

J.N.Kotuba

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.


58

Recap Lesson

J.N.Kotuba

Learning outcomes for today Develop the requirements model Use cases Use case diagrams Use case narratives

J.N.Kotuba

What Comes Next?

object oriented methodologies

Documents

context of object interactions

system designs

unified processlearn

use case diagramlearn

business case

use caseslearn

static model

users problems