Download - IBM Software Group ® Use Cases & System of Systems Ivar Jacobson IBM Rational [email protected] Jaczone AB [email protected].

IBM Software Group

®

Use Cases & System of Systems

Ivar JacobsonIBM Rational

[email protected]

Jaczone AB

[email protected]

IBM Software Group | Rational software

Agenda The Ericsson Success Story

Use Cases

System of Systems


The Ericsson Success Story

What we can’t learn from a 30 year old case story Layered architecture – we had two

layers only

Middle-ware and system-ware – only system-ware

Software tools – there was only an IDE What we can we learn from it

What development processes to employ

• Software

• Software+Hardware+Peopleware What modeling language to use

Systems of Systems

Transitioning to a reuse business

• Reengineering of organization


Lessons learnt – Software Process

Development approach was

Component-based

Requirements-driven

Architecture-centric

Visual Modeling

Configuration management

Today we would request process to also be

Use-case driven

Iterative & incremental

Risk-driven

Verify & validate from the beginning

Tool supported

Etc.


Lessons learnt -- Modeling language

A first generation modeling language

Block diagrams

Sequence diagrams

Collaboration diagrams

State transistion diagrams with activity diagrams

Activity diagrams with swimlanes

These ideas are now in SDL and UML. But no tools were used!

Today we have tools – lifecycle point tools and cross-lifecycle tools

Ivar Jacobson

Check the language


Feb 1968Feb 1968

Block diagram (component diagrams)


Sequence diagrams

!970-06-25!970-06-25



Use Cases

System of Systems


Use Cases are part of a LifeCycle Process

The Unified Process It is the UML process It is component-based It is

Use-case driven

Architecture-centric

Iterative and incremental

Configurable


Use Cases Capture Requirements

Use cases reside inside the system

A use case describes the actions the system takes to deliver to the actor

Taken together, all use cases constitute all ways of using the system

A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor

Withdraw money Bank customer

Actor Use Case


Use cases are identified in Requirements

FURPS Functionality

Usability

Reliability

Performance

Supportability

Design Constraints Operating systems

Environments

Compatibility

Application standards

Use cases address these requirements!

}


Use Case DrivenReq’t Design & Impl. Test

Capture the Use Cases

Design to Implement

the Use Cases

Test that the Use Cases are Fulfilled

}Users’ Needs areUse Cases !

Use Case Driven Development

Any product development should follow three steps:

Capture the users’ needs

Design to fit those needs

Test that the needs are fulfilled


Requirements: Capture the use cases

A use case model

BankSystem

BankCustomer

Deposit Money

Withdraw Money

Transfer Between Accounts

ATMATM


Use cases versus traditional feature spec’s? A feature specification attempts to reply to the question:

“What is the system supposed to do?”

The use case strategy forces us to add three words to the end of that question: “… for each user?”


Design & Implementation: use case design

Use cases are eventually realized as components

Cash Withdrawal

ComponentsComponents

BankSystem

BankCustomer

Deposit Money

Withdraw Money


ATMATM


Use cases – use case realizations -- components Each use case is realized by a collaboration - a set of classes A class plays different roles in different use case realizations The total responsibility of a class is the composition of these roles

Withdraw Cash

Deposit Funds

Transfer Funds

Cash Withdrawal

Cash Interface

Cash Interface Deposit Funds

Transfer Funds

Interface Interface

Funds Deposit

Cash Transfer Funds

CashWithdrawal

Use case Specification

Use case design

Component design &implementation


Test: use case tests

Test Cases

Cash Withdrawal of a pre-set amount

Cash Withdrawal of custom amount

Etc. Many Test Cases for every Use Case

Use Case Modeling Done!

Plan Testing & DefineTest Cases

Generate Test Cases From Sequence diagramsand State-Chart diagrams

Design Done!

Basis for the Test Specification

BankSystem

BankCustomer

Deposit Money

Withdraw Money


ATMATM

Use Case Scenarios


Invalid PIN CodeValid PIN Code

AmountInvalid

Use Case: Withdraw Money

Valid Card Invalid Card

Amount> Account Balance

Amount > Daily Limit

. . .

Identifying Use Case Scenarios

AmountValid and in Range


The Role of Use Cases

UseCases

Requirements

Architecture

Analysis &Design

Test

User ExperienceDesign

BusinessModeling

IterationPlanning

…Reuse


UCDAnalyze: Design: Test:

Capture, Clarify and Validate

the Use Cases

Design to Implement

the Use Cases

Test that the Use Cases

are Fulfilled

Use Case DrivenReq’t Design & Impl. Test

Capture the Use Cases

Design to Implement

the Use Cases

Test that the Use Cases are Fulfilled

In One SentenceIn One Sentence

Use Cases are the glue that binds the lifecycle process together



Use Cases

System of Systems


System of Interconnected Systems

Use case of the superordinate system is realized by use cases of the subordinate systems Superordinate use cases and subordinate use cases


Common Development Concerns

Enterprise architecting Defining an architecture that underpins a number of systems

Strategic reuse Developing reusable assets that are used within a number of systems

Systems engineering Developing a system that contains elements of hardware, software, workers and

data Enterprise Application Integration

Developing a solution that includes the integration of a number of legacy systems Packaged application development

Developing a solution that includes the configuration of a packaged application, such as an ERP or CRM solution

Outsourced development Defining an architecture that lends itself to the outsourced development of its

constituent parts, whilst ensuring the quality and integrity of these parts


What is a System?

UML A system is a top-level subsystem in a model. A subsystem is a grouping

of model elements that represents a behavioral unit in a physical system. A subsystem offers interfaces and has operations. In addition, the model elements of a subsystem can be partitioned into specification and realization elements.

RUP A system is a collection of connected units that are organized to

accomplish a specific purpose. A system can be described by one or more models, possibly from different viewpoints.

RUP-SE A system provides a set of services that are used by an enterprise to carry

out a business purpose. System components typically consist of hardware, software, data, and workers.


Applying Systems of systems Enterprise Architecting

The decomposition of an enterprise into its respective elements can be expressed in terms of a “system of systems”

Strategic Reuse Reusable assets and their relationships can be described in terms of a “system of systems”

Systems Engineering The system as a whole can be expressed in terms of a superordinate system, and each of

the elements that comprise the system can be expressed in terms of a subordinate system Enterprise Application Integration

The context within which a legacy system fits can be described in terms of a superordinate system, with the legacy system itself represented as a subordinate system

Packaged Application Development The packaged application may represent a subordinate system (if it is a “piece”) or a

superordinate system (if it is a “whole”) Outsourced Development

The overall architecture can be described in terms of a superordinate system, with the constituent parts described in terms of subordinate systems


Rounding Up

From a Swedish Perspective TBD


For More Information

www.rational.com The UML Books (Booch, Jacobson, Rumbaugh with Addison Wesley)

The UML User Guide

The UML Reference Manual

The Unified Software Development Process


Other Readings by Ivar Jacobson Object-Oriented Software Development--A Use Case Driven Approach

(Addison Wesley)Jacobson et al, Addison Wesley Longman (1992)

The Object Advantage: Business Process Reengineering with Objects (Addison Wesley)Jacobson et al, Addison Wesley Longman (1994)

Software Reuse: Architecture, Process and Organization for Business Success (Addison Wesley) Ivar Jacobson, Martin Griss & Patrik Jonsson, Addison Wesley Longman (1997)

The Unified Software Development Process Jacobson, Booch, Rumbaugh, Addison Wesley Longman (1999)

The Road to the Unified Software Development Process Ivar Jacobson, Stefan Bylund, Cambridge University Press, 2000

Aspect-Oriented Software Development with Use Cases Ivar Jacobson, Pan Wei Ng, 2004, NEW