Elements of the Analysis Model:

Scenario-based elements
Describe the system from the user's point of view using
scenarios that are depicted in use cases and activity
diagrams
Class-based elements
Identify the domain classes for the objects manipulated
by the actors, the attributes of these classes, and how
they interact with one another; they utilize class
diagrams to do this
Behavioral elements
Use state diagrams to represent the state of the
system, the events that cause the system to change
state, and the actions that are taken as a result of a
particular event; can also be applied to each class in
the system
Flow-oriented elements
Use data flow diagrams to show the input data that
comes into a system, what functions are applied to that
data to do transformations, and what resulting output
data are produced

TESTING:
Black-box testing
Knowing the specified function that a product has been
designed to perform, test to see if that function is fully
operational and error free

 Includes tests that are conducted at the software

interface
Not concerned with internal logical structure of the
software
Complements white-box testing by uncovering different
classes of errors
Focuses on the functional requirements and the
information domain of the software
Used during the later stages of testing after white box
testing has been performed
The tester identifies a set of input conditions that will
fully exercise all functional requirements for a program
The test cases satisfy the following:
Reduce, by a count greater than one, the number of
additional test cases that must be designed to achieve
reasonable testing
Tell us something about the presence or absence of
classes of errors, rather than an error associated only
with the specific task at hand
White-box testing
Knowing the internal workings of a product, test that all
internal operations are performed according to
specifications and all internal components have been
exercised
Involves tests that concentrate on close examination of
procedural detail
Logical paths through the software are tested
Test cases exercise specific sets of conditions and loops
Uses the control structure part of component-level
design to derive the test cases
These test cases
Guarantee that all independent paths within a module
have been exercised at least once
Exercise all logical decisions on their true and false
sides
Execute all loops at their boundaries and within their
operational bounds

 Exercise internal data structures to ensure their validity

Cyclomatic Complexity:
Provides a quantitative measure of the logical
complexity of a program
Defines the number of independent paths in the basis
set
Provides an upper bound for the number of tests that
must be conducted to ensure all statements have been
executed at least once
Can be computed three ways
The number of regions
V(G) = E N + 2, where E is the number of edges and N
is the number of nodes in graph G
V(G) = P + 1, where P is the number of predicate nodes
in the flow graph G
Results in the following equations for the example flow
graph
Number of regions = 4
V(G) = 14 edges 12 nodes + 2 = 4
V(G) = 3 predicate nodes + 1 = 4

Levels of Testing for Conventional Software:

Unit testing
Concentrates on each component/function
software as implemented in the source code

of

the

Integration testing
Focuses on the design and construction of the software
architecture
Validation testing

 Requirements are validated against the constructed

software
System testing
The software and other system elements are tested as
a whole

Alpha and Beta Testing:

Alpha testing
Conducted at the developers site by end users
Software is used in a natural setting with developers
watching intently
Testing is conducted in a controlled environment
Beta testing
Conducted at end-user sites
Developer is generally not present
It serves as a live application of the software in an
environment that cannot be controlled by the developer
The end-user records all problems that are encountered
and reports these to the developers at regular intervals
After beta testing is complete, software engineers make
software modifications and prepare for release of the
software product to the entire customer base

Components
A component is a standard building unit in an organization
and is used to develop applications. When Jacobson talks
about components in this book, he refers to software

components which are subject to reuse. He also calls these

objects. By having components built on a programming
language we will get a higher level of the application layer
on which to develop our applications (a higher level than the
primitive constructs in a programming language). A
component is general and of high quality since it is
developed with the aim of reuse in more than one
application. Typically several applications share a common
set of such reusable application objects.
Use of components can help in designing large systems.
There are two basic advantages with a component approach:
- Development time is reduced (cost)
- Quality is increased
Development time is reduced since we have more powerful
components ready for implementation as a basis. This also
reduces complexity and leads to less code writing. Using
complete components also means they are very well tested much time has been spent on their development and they
have (perhaps) been used in other applications.