1. Team Skill 6 - Building The Right System Part 1: Applying Use Cases
Sriram Mohan

2. Outline Use Cases in Design and Implementation
From Use Cases to Test Cases

3. Use Cases in Design and Implementation

4. What Are the Design Issues?
Sometimes it is easier to design and implement a system feature than others
For instance, if a feature mostly involves interaction between the software and one or more actors, the use case events correspond well with the steps of the implementation algorithm

5. What Are the Design Issues? (continued)
When quality requirements or complex data structures are involved, the design does not follow as directly
When the form of the requirements and the form of the design and implementation are different, we say that their correlation is orthogonal.
You have to stir in use cases and those quality attribute scenarios

6. Solving the Orthogonality Problem
Object-oriented design
Well written use cases
Modeling Software Systems
A typical OO design process (like CRC cards) assumes you are running on a single processor, without ever saying so…
OO hides architectural problems, along with other “detail”. It is a representation of the real world object and even if the underlying process changes, the real world abstraction doesn’t
Software systems are complex. It is difficult to keep track of the entire system, so we model to provide something that we can understand. The model should help us understand the system. The model should be carefully selected to ensure that it doesn’t misrepresent things and lead us down the wrong path.

7. Solving the Orthogonality Problem
A potential solution: comes from the software architecture
The software architecture helps us understand
“what the system does and how it works, how the elements interact, and what type of patterns and pieces or the system are involved”

8. Solving the Orthogonality Problem (continued)
Architectural views :
Logical (for users)
Implementation (programmers)
Process (integrators)
Deployment (system engineers)
Use-case view (designers/testers; ties things together)

9. From Use Cases to Test Cases

10. Types of Testing Acceptance Black box
How does the presence of a use case change this?
Acceptance (or validation) test cases are ones that are performed from the user’s point-of-view.
They are examples of black-box test cases (i.e. no knowledge of internal working of the software)
Use cases are not exactly validation test cases, although use cases do drive the process of validation test case generator

11. How do we use the usecase?
Steps in creating a test case:
Identify use-case scenarios (basic and alternate flows)
Identify the test cases
Identify the test conditions
Add data values to the test case

12. Test Case Description Table For a Use Case
Test Case Id
Scenario
Description
Cond. 1 2 3
Expected Result
Actual Result
Use as many conditions as necessary for a use case,

13. Test Plans There’s a “test plan” for how to do all these test cases.
The use cases each become multiple test cases in the test plan.

14. Some final remarks How much do we test?
Black box testing tests the functionality. What about the internal design decisions?