Professional Documents
Culture Documents
1
System Use Case Modeling
• Composed of use case diagrams and documentation describing the use
cases, actors and associations
• Describes a sequence of actions that provide a measurable value to an actor
and is drawn as a horizontal ellipse
• An actor is a person, organization or external system that plays a role in one
or more interactions with your systems
– Drawn as stick figures
• Associations between actors and classes are indicated in use case diagrams, a
relationship exists whenever an actor is involved with an interaction
described by a use case
– Exist between use cases
– Depicted as a line (arrows are optional)
• System Boundary Box – Rectangle around the use cases
3
There can be 5 relationship types
in a use case diagram.
Association between actor and
use case
Generalization of an actor
Extend between two use cases
Include between two use cases
Generalization of a use case
4
5
6
7
8
9
10
Sequence Diagrams
• Used to model the logic of usage scenarios
• A description of a potential way your system is used
• One entire path through a use case
• Model the flow of logic within your system in a visual manner
• The boxes across the top of the diagram represent classifiers or
their instances, typically uses cases, objects, classes or actors
• Because you can send messages to both objects and classes,
objects respond to messages through the invocation of an
operation, and classes do so through the invocation of static
operations, it makes sense to include both on sequence
diagrams
• Because actors initiate and take an active part in usage
scenarios, they are also included in sequence diagrams
How to draw sequence diagrams
• Identify the scope of the sequence diagram
• List the use case steps down the left hand side
• Introduce boxes for each actor
• Introduce controller classes
• Introduce a box for each major UI element
• Introduce a box for each included use case
• Identify appropriate messages for each use case step
• Add a method – invocation box for each invocation of a method
• Add destruction messages where appropriate
• Add your business classes and objects
• Update your class model
• Update your user interface model
• Update your use case model
Component Modeling
• OO is a preferred foundation from which to build components
• UML includes a component diagrams that can be used to
analyze and design your component based software
• Components are modeled as rectangles with two smaller
rectangles jutting out from the left hand side
• Implement one or more interfaces, modeled using the same
“lollipop” notion that UML class diagrams use
• Components have dependencies on the interfaces of other
components, modeled using the standard UML dependency
notation
Faciliities
Security
Seminar <<infrastructure>>
Management
<<application>> Student
Persistence
<<infrastructure>>
Seminar
Student
Administration
<<application>>
University DB
Schedule <<infrastructure>>
17
Definition
18
Software Testing Types
Manual Testing:
Manual testing is the process of testing software by hand
to learn more about it, to find what is and isn’t working.
This usually includes verifying all the features specified
in requirements documents.
Automation Testing:
Automation testing is the process of testing the software
using an automation tool to find the defects.
In this process, testers execute the test scripts and
generate the test results automatically by using
19
automation tools.
Testing Methods
1. Static Testing
2. Dynamic Testing
Static Testing:
It is also known as Verification in Software Testing.
Verification is a static method of checking documents
and files.
Verification is the process, to ensure that whether we are
building the product right.
20
Cont’d
Dynamic Testing:
It is also known as Validation in Software Testing.
Validation is a dynamic process of testing the real
product.
Validation is the process, whether we are building the
right product.
21
Testing Approaches
There are three types of software testing approaches.
24
Cont’d
2. Integration Testing:
Integration Testing is the process of testing the
connectivity or data transfer between a couple of unit
tested modules.
It is subdivided into
Top-Down Approach,
Bottom-Up Approach and,
Sandwich Approach (Combination of Top Down and
Bottom Up).
25
Cont’d
3. System Testing (end to end testing):
It’s a black box testing.
Testing the fully integrated application this is also called
as end to end scenario testing.
To ensure that the software works in all intended target
systems.
Verify thorough testing of every input in the application
to check for desired outputs.
Note:
o This level of testing uses also to test the users experiences
with the application.
26
Cont’d
4. Acceptance Testing:
To obtain customer sign-off so that software can be
delivered and payments received.
Types of Acceptance Testing are Alpha, Beta & Gamma
Testing.
27
Difference Between Alpha, Beta, and Gamma Testing
Alpha Beta Gama
Why? Validate all software in Get end user’s Check the software
all perspective, ensure feedback, ensure readiness to the
readiness for beta readiness for release specified requirements
testing
When? At the end of After alpha testing After beta testing
development process
28
The End of Chapter 5
29