Uploaded by syednouman2021

SA E&D-UGrandGr-Dr.Rainey-CDR-2.01

Dr. James L. Rainey III
Adjunct Professor
University of Detroit Mercy
System Analysis and Design
Order of Lecture Content;
1.
2.
3.
4.
Key Terms from Chapters 4 & 5,
Use-cases,
Flow of events and project artifacts
Elements of an activity diagram
Lecture (CDR) 2
Rainey_SA&D-U-Grad&Grad
Use-cases
Sequence of Content:
 Describe a use-case model, its components, and its
importance.
 The why and what of a use-case model
 Elements of a use-case diagram
Rainey_SA&D-U-Grad&Grad
2
Use Cases / Continued


Why Create a Use-Case Model?
A use-case model allows the customer and
system developer to communicate WHAT
the system should do, in a language
understandable to the customer.
Consider the use-case model as the visual
contract between customer and developer.
Rainey_SA&D-U-Grad&Grad
3
Use Cases / Continued



The use-case model should be the basis for all
system design activities.
If it isn’t in the use-case model, it should NOT be
in your system.
In fact, the system being built should “trace” back
to the use-case model.
Rainey_SA&D-U-Grad&Grad
4
Use Cases / Continued
What Is a Use-Case Model?
 A use-case model is a representation of the
system’s intended functions and its
environment.
 It is created in the Use-Case View and can
include the following; (Use-case diagrams, Usecase flow of events, supplemental information
and activity diagrams).
Rainey_SA&D-U-Grad&Grad
5
Use Cases / Continued

Is a model of the systems intended
functions and its environments.

Serves as a contract between
customer and developer.

Is essential to analysis and design
activities.
Rainey_SA&D-U-Grad&Grad
6
Use Cases / Continued

Can include use-case diagrams, use-case
flow of events, supplemental information,
and activity diagrams.

Is created using artifacts developed by the
software architect (enterprise architect)
and system analysts in concert with the
customer.
Rainey_SA&D-U-Grad&Grad
7
Use Cases / Continued

Are described textually in a document
called a flow of events.

In an iterative process, the software
architect identifies the use cases used
in the current iteration.
Rainey_SA&D-U-Grad&Grad
8
Use Cases / Artifact



An artifact is information produced,
modified, or used by a process.
It defines an area of responsibility and
is subject to version control.
An artifact can be a model, a model
element, or documentation.
Rainey_SA&D-U-Grad&Grad
9
Use Cases / Elements
What Is a Use-Case Diagram?

A use-case diagram is an illustration
that shows the relationships among
use cases and actors and among
related use cases.
Rainey_SA&D-U-Grad&Grad
10
Use-Case Diagram
Is typically created from numerous sources that
may include the following;
- Glossary
- Stakeholder’s request
- Vision Document
- Use-case modeling guidelines
- Business use-case model
- Business object model
- Supplemental specifications
Rainey_SA&D-U-Grad&Grad
11
Use-Case Diagram

Is a visual representation of what the customer
wants the system to do.

Represents a major piece of functionality that is
complete from beginning to end.

Shows a sequence of actions a system
performs that yields an observable result and is
of value to a particular actor.
Rainey_SA&D-U-Grad&Grad
12
Use-Case Diagram
Use-case diagrams can depict:




All actors and use cases.,
All the use cases for a selected actor.,
A single use case and all it’s relationships., &/or
All the use cases used in an iteration.
Rainey_SA&D-U-Grad&Grad
13
USE Cases / Elements
What Is a Use-Case Actor?


An actor is someone or something
outside the system that interacts with
the system.
Can typically be found in the problem
statement or from conversations with
customers and domain experts.
Rainey_SA&D-U-Grad&Grad
14
USE Cases / Elements
Elaborate on the “Relationships” (thus the lines
which connect the components)


A relationship illustrates a semantic
connection among model elements.
May exist between an actor and
between use cases (It can also exist
between classes and interfaces).
Rainey_SA&D-U-Grad&Grad
15
USE Cases / Relationships

Are the most general relationships and indicate
communication only.

Is often referred to as a “communicate”
relationship since it refers to communication
between actor and use case.

Can be navigable in one or both directions.
Rainey_SA&D-U-Grad&Grad
16
USE Cases / Relationships

The navigation direction represents who is initiating the
communications.

An association with an arrowhead denotes communication
in one direction and is called a unidirectional association.

The end with the arrow indicates who or what is receiving
the communication.

An association without an arrowhead denotes
communication in both directions and is called a bidirectional association.
Rainey_SA&D-U-Grad&Grad
17
USE Cases / Elements
What are Artifacts?

Artifacts are documents, models or
model elements used to capture
and convey project information.
Rainey_SA&D-U-Grad&Grad
18
Artifacts / Continued

Can be both input and output artifacts
depending on the activity.

Should be easily accessible by the
project team (when following Agile).
Rainey_SA&D-U-Grad&Grad
19
USE Cases / Elements
What are Activity Diagrams?

A flowchart showing flow of control
from activity to activity.
Rainey_SA&D-U-Grad&Grad
20
Activity Diagrams / Continued

The workflow of a use-case describes that which
needs to be done by the system to provide the
value, the served actor is looked for.

It consists of a sequence of activities that,
together, produce something for the actor.
Rainey_SA&D-U-Grad&Grad
21
Activity Diagrams / Continued

The workflow often consists of a basic flow and one or
several alternative flows.

Activity diagrams can also be used in business modeling
and to model the workings of an operation, an object, or
anything that involves modeling the sequential steps in a
computational process.

Activity diagrams represent the dynamics of the system
Rainey_SA&D-U-Grad&Grad
.
22
Activity Diagrams / Continued

Activity diagrams are not required.

Some prefer its textual counterpart, the flow of
events.

It’s up to you, whether you created them to
illustrate the workflow of a use case.
Rainey_SA&D-U-Grad&Grad
23
Rainey_SA&D-U-Grad&Grad
24
Rainey_SA&D-U-Grad&Grad
25
Rainey_SA&D-U-Grad&Grad
26
Rainey_SA&D-U-Grad&Grad
27
Rainey_SA&D-U-Grad&Grad
28
Rainey_SA&D-U-Grad&Grad
29
Rainey_SA&D-U-Grad&Grad
30
Use Cases and Flow of Events:

Are understood by the customer.

Describe how and when the use case starts and
ends, when the use case interacts with the actors,
and the information exchanged between an actor
and the use case.

Does not describe user interface details.
Rainey_SA&D-U-Grad&Grad
31
Rainey_SA&D-U-Grad&Grad
32

The workflow of a use case describes that which
needs to be done by the system to provide the
value the served actor is looking for.

It consists of a sequence of activities, that
together, produce something for the actor.

The workflow often consists of a basic flow and
one or several alternative flows.
Rainey_SA&D-U-Grad&Grad
33
In this example, you can see that someone signs on to the system and begins to create a
curriculum. They select the courses to teach, which in turn begins to create our catalog. At that
point, two things are done—an order is placed with the bookstore and the catalog is mailed to
potential students. Registration is then opened and when the time period to register for a course
ends, registration is closed. This is the basic activity for a course registration process.
Rainey_SA&D-U-Grad&Grad
34
Nouns and Verbs, Adjectives and Adverbs

Try to think of the system behavior,
grammatically.

If you can describe the intended
behavior of the system in simple
sentences, you can analyze the
grammar of these sentences to
derive deeper analysis and even test
cases.
Rainey_SA&D-U-Grad&Grad
35
Nouns and Verbs, Adjectives and Adverbs / NOUNS

Many software systems exist to
manipulate specific kinds of data.

The kinds of data sets are the nouns.

These data sets are the subjects—
the actors—and the objects--the
things acted upon.
Rainey_SA&D-U-Grad&Grad
36
Nouns and Verbs, Adjectives and Adverbs / VERBS

The manipulations are the verbs.

These are actions the system will
take on the objects at the direction of
actors.
Rainey_SA&D-U-Grad&Grad
37
Nouns and Verbs, Adjectives and Adverbs / ADJECTIVES & ADVERBS

Adjectives and adverbs affect the
way the manipulation occurs.
Rainey_SA&D-U-Grad&Grad
38
Nouns and Verbs, Adjectives and Adverbs / STEPS




Identify data items.
Write the descriptions of the system
actions in sentences.
Analyze these sentences grammatically
and analyze or test accordingly.
Trace your analysis and/or test coverage
back to these sentences that describe the
system.
Rainey_SA&D-U-Grad&Grad
39
Nouns and Verbs, Adjectives and Adverbs / STEPS

The short sentences become a form
of use case or requirements
specification for the system.
Rainey_SA&D-U-Grad&Grad
40
Nouns and Verbs, Adjectives and Adverbs / EXAMPLE
An ATM System should do things such
as the following;



Accept deposits,
Process withdrawals,
Answer inquiries
*You can take this further and describe the kinds of deposits,
withdrawals, and inquiries. You can then look at adverbs and adjectives
that modify the system’s actions. Should the actions be performed
quickly? How about securely?
Rainey_SA&D-U-Grad&Grad
41
James Marcus Bach is a software tester, author,
trainer and consultant. He is a proponent of
exploratory testing and the context-driven school of
software testing and is credited with developing
session-based testing. He was a member of the
Board of Directors of the Association for Software
Testing. Lessons Learned in Software Testing, a
book he co-authored, has been cited over 130 times
according to Google Scholar, and several of his
articles have been cited dozens of times including
his work on heuristics for testing and on the
Capability Maturity Model. He has written numerous
articles for the IEEE Computer Society.
Rainey_SA&D-U-Grad&Grad
42
Bach defined exploratory testing
and analysis as “an interactive
process of simultaneous learning,
test design, and test execution.”
Exploratory Testing
and Analysis
Rainey_SA&D-U-Grad&Grad
43
The exploratory testing process is simple to describe
but challenging to perform.
Learn a bit about they system by
using it, reading source documents
like requirements specifications,
asking people how the system
works, looking at past and current
test results , and exploiting any
other source of information you
have.
Rainey_SA&D-U-Grad&Grad
Exploratory
Testing and
Analysis
44
Make an educated guess about where you
might find some bugs or observe some other
interesting behavior. This guess (some might
call it a heuristic or bug hypothesis or theory
of error) would be influenced by your own
past experiences as a tester and the field
performance of previous similar products.
*Heuristic – (Adjective) enabling a person to
discover or learn something for themselves.
Exploratory Testing
and Analysis
Rainey_SA&D-U-Grad&Grad
45
Design a test for deeper
analysis to check for the
presence or absence of
those bugs or to observe
those behaviors.
Exploratory Testing
and Analysis
Rainey_SA&D-U-Grad&Grad
46
Run the test for deeper analysis,
observing carefully for the bugs
you guessed were there, other
bugs that might also be there, and
the various behaviors the system
exhibits.
Exploratory Testing
and Analysis
Rainey_SA&D-U-Grad&Grad
47
Reflect on the meaning of your observations,
then return to step 1 to revise your learning
about the system, your guess about where
other bugs might be, and your concept of
what interesting behaviors might be worth
seeing.
Exploratory Testing
and Analysis
Rainey_SA&D-U-Grad&Grad
48
For Next CDR, the following will be
discussed;

1.
2.
Concept of Operations (CONOPS)
Undergrads – “Putting conceptualizations on paper, in a way in which
the customer and most technical team members can understand
adds value to your work and to the team.”
Graduate Students – “There is a such thing as ‘Analysis Paralysis’ so
planning sessions must be managed in a way to avoid Scope Creep.”
Rainey_SA&D-U-Grad&Grad
49