notes of rational related cyt. 2 outline 3 capturing business requirements using use cases practical...

Notes of Rational Related

cyt

2

Outline

3

Capturing business requirements using use cases

• Practical principles Find the right boundaries for your business requirements (Principle 1:

Get the scope right)

Structure your use case model appropriately (Principle 2: Challenge your use case goals and Principle 3: Use requirement attributes to determine the best use case model)

Elaborate your business requirements further (Principle 4: Divide et impera: Decompose by business worker)

Describe your business use cases appropriately (Principle 5: Use case descriptions: State what and not how)

Connect your business use cases, avoid redundancies, and validate your requirements (Principle 6: Produce a domain model and Principle 7: Use entity lifecycles)

4

• Ivar Jacobson is known as the father of Use Cases.

5

UML Concepts-The 4+1 view

• Use Case view Understandability

• Logical View Functionality

• Process View Performance Scalable Throughput

• Implementation View Software management

• Deployment View System topology Delivery Installation

6

Things in UML

Structural Things Annotational ThingsGrouping ThingsBehavioral Things

1. Class

2. Interface

3. Collaboration

4. Use Case

5. Active Class

6. Components

7. Nodes

2. State Mechanism

1. Interaction 1. Packages 1. Notes

7

• Rational Software Development Process iterative and incremental object-oriented managed and controlled

• Inception —The good idea: specifying the end-product vision and its business case, defining the scope of the project.1

• Elaboration —Planning the necessary activities and required resources; specifying the features and designing the architecture.

• Construction —Building the product, and evolving the vision, the architecture and the plans until the product—the completed vision—is ready for transfer to its users community.

• Transition —Transitioning the product to its user’s community, which includes manufacturing, delivering, training, supporting, maintaining the product until the users are satisfied.

8

9

Inception phase• Entry criteria:

an original vision a legacy system an RFP (request for proposal) the previous generation and a list of enhancements some assets (software, know-how, financial assets) a conceptual prototype, or a mock-up

• Exit criteria: an initial business case containing at least:

a clear formulation of the product vision—the core requirements— in terms of functionality, scope, performance, capacity, technology base

success criteria (for instance revenue projection) an initial risk assessment an estimate of the resources required to complete the elaboration phase.

Optionally at the end of the inception phase, we may have: an initial domain analysis model (~10%-20% complete), identifying the top key use

cases, and sufficient to drive the architecture effort. an initial architectural prototype, which at this stage may be a throw-away prototype.

10

Elaboration Phase

• Entry criteria: The products and artifacts described in the exit criteria of the

previous phase. The plan was approved by the project management, and funding

authority, and the resources required for the elaboration phase have been allocated.

• Exit criteria: a detailed software development plan a baseline vision, in the form of a set of evaluation criteria for the

final product objective, measurable evaluation criteria for assessing the results of

the initial iterations of the construction phase a domain analysis model (80% complete), sufficient to be able to call

the corresponding architecture ‘complete’. a software architecture description) an executable architecture baseline.

11

Construction Phase

• Entry criteria: The product and artifacts of the previous iteration. The iteration plan

must state the iteration specific goals: additional capabilities being developed: which use cases or scenarios wil

l be covered risks being mitigated during this iteration defects being fixed during the iteration.

• Exit criteria: A release description document, which captures the results of an iter

ation Test cases and results of the tests conducted on the products, An iteration plan, detailing the next iteration Objective measurable evaluation criteria for assessing the results of

the next iteration(s).

12

13

History of UML

14

Use Cases are Employed Throughout the Process

15

Analysis and Design Overview

16

• Use case analysis Understand the problem Behavior Functional requirements A small model

• Use case design Understand the solution Close to real code Add non-functional requirements A large model

17

Use Case Analysis

18

Find key abstraction

• Essential of the system• Source of key abstraction

Domain knowledge Requirements Glossary Domain model, or the business model

19

Boundary class handles interfaces

• Intermediate between the interface and something outside the system

• User interface, system interface, device interface classes

• At least one boundary class per actor/use case pair

20

Control class coordinates behavior

• They decouple boundary and entity objects from one another.

• Make the system more tolerant of changes in the system boundary.

• One control class for per use case

21

For each use case allocate responsibilities

• Identify analysis classes for basic and alternate flows

• Assign responsibilities to classes

• Build interaction diagram

22

Guidelines for assigning behavior

• Boundary class Communication with actor

• Entity class Encapsulation/manipulation of data in use case

• Control class Control and coordination of use case

23

24

View of Participating Classes (VoPC) for Each Use Case

• Collect each unique class from all interaction diagrams in the use case

• Consolidate different names, like behavior

• Separate like names, different behavior

25

Use Case Design

26

Incorporate subsystem interaces

27

28

Class Design

29

30

31

32

33

Classes with ports and interfaces