Use Cases & System of Systems

Use Cases & System of Systems Ivar Jacobson IBM Rational ivar@rational.com Jaczone AB ivar@jaczone.com

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

Block diagram (component diagrams) Feb 1968

Sequence diagrams !970-06-25

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 • A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor • 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 Bank customer Withdraw money Actor Use Case

FURPS Functionality Usability Reliability Performance Supportability Design Constraints Operating systems Environments Compatibility Application standards } Use cases address these requirements! Use cases are identified in Requirements

} Users’ Needs are Use Cases ! Use Case Driven Req’t Design & Impl. Test Capture the Use Cases Design to Implement the Use Cases Test that the Use Cases are Fulfilled 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 ATM Withdraw Money Deposit Money Bank System Bank Customer Transfer Between Accounts

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 ATM Withdraw Money Deposit Money Bank System Bank Customer Transfer Between Accounts Withdrawal Cash Components

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 Use case Specification Use case design Component design & implementation Cash Cash Interface Cash Withdrawal WithdrawCash Withdrawal Transfer Interface Cash Transfer Funds Interface Transfer Funds Funds Interface Deposit Cash Deposit Funds Funds Deposit Funds

Use Case Modeling Done! Use Case Scenarios Test: use case tests Cash Withdrawal of a pre-set amount ATM Withdraw Money Cash Withdrawal of custom amount Test Cases Etc. Many Test Cases for every Use Case Deposit Money Bank System Bank Customer Transfer Between Accounts  Plan Testing & DefineTest Cases • Design Done!  Generate Test Cases FromSequence diagramsand State-Chartdiagrams • Basis for the Test Specification

Identifying Use Case Scenarios Use Case: Withdraw Money Valid Card Invalid Card Valid PIN Code Invalid PIN Code . . . Amount Valid and in Range Amount Invalid Amount > Daily Limit Amount > Account Balance

The Role of Use Cases Requirements Architecture Reuse … Use Cases Iteration Planning Analysis & Design Business Modeling Test User Experience Design

In One Sentence Use Cases are the glue that binds thelifecycle process together Use Case Driven UCD Req’t Design & Impl. Test Analyze: Design: Test: Capture, Clarify and Validate the Use Cases Design to Implement the Use Cases Test that the Use Cases are Fulfilled Capture the Use Cases Design to Implement the Use Cases Test that the Use Cases are Fulfilled

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 A "System of Systems" • 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

Use Cases & System of Systems