Lecture 6: Test-based Use case & Process Modeling December 7, 2014

Lecture 6: Test-based Use case& Process Modeling

December 7, 2014

Use Case Analysis

Chapter 5

Key Ideas

• Use cases are a text-based method of describing and documenting complex processes

• Use cases add details to the requirements outlined in the requirement definition

• Systems analysts work with users to develop use cases

• System analysts develop process and data models later based on the use cases

5 - 4

Roles of Use Cases

• A use case is a set of activities that produce some output result

• Describes how the system reacts to an event that triggers the system

• Trigger -- event that causes the use case to be executed

• Event-driven modeling – everything in the system is a response to some triggering event

Role of Use Cases

• All possible responses to the event are documented

• Use cases are helpful when the situation is complicated

Elements of a Use Case

• Basic information– Name, number and brief description– Trigger – event that causes the use case to being

• External trigger – some from outside the system• Temporal triggers – time-based occurrences

– Viewpoint of the use cases should be consistent• Major inputs and outputs

– Sources and destinations– Goal is to be all inclusive

• Details– Steps performed and the data inputs and outputs

Sample Use Case

Building Use Cases

Process of Developing Use Cases

• Identify the major use cases• Identify the major steps within each use case• Identify elements within steps• Confirm the use case• Cycle through the above steps iteratively

Step 1: Identify the major use cases

ActivitiesTypical Questions Asked

Start a use case form for each use case

If more than nine, group into packages

Ask who, what, and where about the tasks and their inputs and outputs:

What are the major tasks performed?

What triggers this task? What tells you to perform this task?

What information/forms/reports do you need to perform this task?

Who gives you these information/forms/reports?

What information/forms/reports does this produce and where do they go?

5 - 11

Sample List of Events-Actions Based on Requirements Definition

Step 2: Identify the major steps within each use case


For each use case, fill in the major steps needed to process the inputs and produce the outputs

Ask how about each use case:

How do you produce this report?

How do you change the information on the report?

How do you process forms?

What tools do you use to do this step (e.g., on paper, by email, by phone)?

Step 3: Identify elements within steps


For each step, identify its triggers and its inputs and outputs

Ask how about each step

How does the person know when to perform this step?

What forms/reports/data does this step produce?

What forms/reports/data does this step need?

What happens when this form/report/data is not available?

Step 4: Confirm the use case


•For each use case, validate that it is correct and complete

•Ask the user to execute the process using the written steps in the use case – that is, have the user role-play the use case

CD SELECTIONS

CD SELECTIONS

5 - 17

CD SELECTIONS

Summary

• The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes.

• Use cases record the input, transformation, and output of business processes and are the basis for process models.

• Eliciting use cases and modeling business processes are critically important skills for the systems analyst to master.

Process Modeling

Key Definitions

Process model Illustrates the activities that are performed and how data moves among them (business processes)A process model is a graphical way of representing how a business system should operate.

Data flow diagrammingdiagrams the business processes and the data that pass

among them ..

Key Definitions

Logical process models describe processes

without suggesting how they are conducted

Physical process models provide information that is needed to build the system

DATA FLOW DIAGRAMS

PowerPoint Presentation for Dennis, Wixom, & Roth

Systems Analysis and Design, 3rd Edition

Copyright 2006 © John Wiley & Sons, Inc. All rights

reserved.

6 - 23

Reading a DFD

How to read DFD

Start reading diagrams from left to right, top to bottom.

Elements of a DFD

ProcessAn activity or function performed for a specific business reason Manual or computerizedData flowA single piece of data or a logical collection of dataAlways starts or ends at a process

DFD Elements

Data StoreA collection of data that is stored in some wayData flowing out is retrieved from the data storeData flowing in updates or is added to the data storeExternal entityA person, organization, or system that is external to the system but interacts with it.




reserved.

6 - 28

Naming and Drawing DFD Elements

Process

Data flow

Data store

Externalentity

6 - 29

Using a DFD to Define Business Processes

Business processes are too complex to be shown on a single DFDDecomposition is the process of representing the system in a hierarchy of DFD diagramsChild diagrams show a portion of the parent diagram in greater detail

Key Definition

Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

Relationship among Levels of DFDsContext diagram

Level 0 diagram

Level 1 diagram

Level 2 diagram

Context DiagramFirst DFD in every business process

-Shows the context into which the business process fits

-Shows the overall business process as just one process (process 0)

-Shows all the external entities that receive information from or contribute information to the system

Level 0 Diagram

*Shows all the major processes that comprise the overall system – the internal components of process 0

*Shows how the major processes are interrelated by data flows

*Shows external entities and the major processes with which they interact

*Adds data stores

Level 1 Diagrams

*Generally, one level 1 diagram is created for every major process on the level 0 diagram

*Shows all the internal processes that comprise a single process on the level 0 diagram

*Shows how information moves from and to each of these processes

*If a parent process is decomposed into, for example, three child processes, these three child processes wholly and completely make up the parent process

Level 2 Diagrams

*Shows all processes that comprise a single process on the level 1 diagram

*Shows how information moves from and to each of these processes

*Level 2 diagrams may not be needed for all level 1 processes

*Correctly numbering each process helps the user understand where the process fits into the overall system

Alternative Data Flows

Where a process can produce different data flows given different conditionsWe show both data flows and use the process description to explain why they are alternativesTip -- alternative data flows often accompany processes with IF statements

Process Descriptions

*Text-based process descriptions provide more information about the process than the DFD alone

*If the logic underlying the process is quite complex, more detail may be needed in the form of

*Structured English *Decision trees *Decision tables

CREATING DATA FLOW DIAGRAMS

Integrating Scenario Descriptions

*DFDs start with the use cases and requirements definition

*Generally, the DFDs integrate the use casesNames of use cases become processes

*Inputs and outputs become data flows“Small” data inputs and outputs are combined

into a single flow

Steps in Building DFDs

*Build the context diagram *Create DFD fragments for each use case

*Organize DFD fragments into level 0 diagram *Decompose level 0 processes into level 1 diagrams as

needed; decompose level 1 processes into level 2 diagrams as needed; etc.

*Validate DFDs with user to ensure completeness and correctness

Creating the Context Diagram

*Draw one process representing the entire system (process 0)

*Find all inputs and outputs listed at the top of the use cases that come from or go to external entities; draw as data flows

*Draw in external entities as the source or destination of the data flows

A Context Diagram Example

Creating DFD Fragments

*Each use case is converted into one DFD fragment *Number the process the same as the use case

number *Change process name into verb phrase

*Design the processes from the viewpoint of the organization running the system

Creating DFD Fragments

*Add data flows to show use of data stores as sources and destinations of data

*Layouts typically place processes in the center *inputs from the left *outputs to the right

*stores beneath the processes

6 - 45

A DFD Fragment Example

Another Example

Creating the Level 0 Diagram

*Combine the set of DFD fragments into one diagram

*Generally move from top to bottom, left to right

*Minimize crossed lines *Iterate as needed

DFDs are often drawn many times before being finished, even with very experienced systems analysts

A Level 0 DFD Example

Creating Level 1 Diagrams (and Below)

-Each use case is turned into its own DFD -Take the steps listed on the use case and depict each

as a process on the level 1 DFD -Inputs and outputs listed on use case become data

flows on DFD -Include sources and destinations of data flows to

processes and stores within the DFD -May also include external entities for clarity

Creating Level 1 Diagrams (and Below)

When to stop decomposing DFDs?Ideally, a DFD has at least three processes and no more than seven to nine.

Validating the DFD

Syntax errors – diagram follows the rulesAssure correct DFD structure

For each DFD:Check each process for: A unique name: action verb phrase; number; descriptionAt least one input data flowAt least one output data flowOutput data flow names usually different thaninput data flow namesBetween 3 and 7 processes per DFD

Validating the DFDFor each DFD:Check each data flow for:A unique name: noun; descriptionConnects to at least one processShown in only one direction (no two-headed arrows)A minimum number of crossed linesCheck each data store for:

A unique name: noun; descriptionAt least one input data flowAt least one output data flow

Check each external entity for:A unique name: noun; descriptionAt least one input or output data flow

Validating the DFDAcross DFDs:

Context Diagram:Every set of DFDs must have one Context Diagram

Viewpoint:There is a consistent viewpoint for the entire set of DFDsDecomposition:Every process is wholly and complete described by the processes on its children DFDsBalance:Every data flow, data store, and external entity on a higher level DFD is shown on the lower level DFD that decomposes it No data stores or data flows appear on lower-lever DFDs that do not appear on their parent DFD

Validating the DFD

Semantics errors – diagram conveys correct meaningAssure accuracy of DFD relative to actual/desired business processesTo verify correct representation, useUser walkthroughsRole-play processesExamine lowest level DFDs to ensure consistent decompositionExamine names carefully to ensure consistent use of terms

6 - 56

A Quick Review of Decomposition for CD Selections




reserved.

6 - 57

Context Diagram for CD Selections Internet Sales System




reserved.

6 - 58

Level 0 DFD for CD Selections Internet System




reserved.

6 - 59

Level 1 DFD for CD Selections Process 1: Take Requests

BALANCING EXAMPLES Balancing ensures that the input and output data flows of

the parent DFD are maintained on the child DFD .The order system diagram 0 is shown at the top of the figure, and theexploded diagram 3 DFD is shown at the bottom.

The two DFDs are balanced, because the child diagram at the bottom has the sameinput and output flows as the parent process 3 shown at the top.

To verify the balancing, notice that the parent process 3, APPLY PAYMENT, has one incoming data flow from an external entity, and three outgoing

data flows to external entities .Now examine the child DFD, which is diagram 3. Now, ignore the internal data flows and count the data flows to and from external entities. You will see that the three processes maintain the same one incoming and three outgoing data flows as the parent process.

Important Announcements

Grading for the course:

Final Exam: 70 pointsYear Work: 30 points - 10 Midterm, 2 Attendance, 12 assignments, 6 presentation & Discussion

Implementation 3 extra credit

Documents

Lecture 6: Test-based Use case & Process Modeling December 7, 2014