IBM Software Group ® Use Cases & System of Systems Ivar Jacobson IBM Rational Jaczone AB

IBM Software Group | Rational software Agenda  The Ericsson Success Story  Use Cases  System of Systems

IBM Software Group | Rational software 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

IBM Software Group | Rational software 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.

IBM Software Group | Rational software 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

IBM Software Group | Rational software Feb 1968 Block diagram (component diagrams)

IBM Software Group | Rational software Sequence diagrams !

IBM Software Group | Rational software Agenda  The Ericsson Success Story  Use Cases  System of Systems

IBM Software Group | Rational software 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

IBM Software Group | Rational software 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

IBM Software Group | Rational software 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! }

IBM Software Group | Rational software Use Case Driven Req’tDesign & Impl.Test Capture the Use Cases Design to Implement the Use Cases Test that the Use Cases are Fulfilled } Users’ Needs are Use 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

IBM Software Group | Rational software Requirements: Capture the use cases  A use case model Bank System Bank Customer Deposit Money Withdraw Money Transfer Between Accounts ATM

IBM Software Group | Rational software 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?”

IBM Software Group | Rational software Design & Implementation: use case design  Use cases are eventually realized as components CashWithdrawal Components Bank System Bank Customer Deposit Money Withdraw Money Transfer Between Accounts ATM

IBM Software Group | Rational software 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 Funds Deposit Cash Transfer Funds Cash Withdrawal Use case Specification Use case design Component design & implementation

IBM Software Group | Rational software 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 & Define Test Cases Generate Test Cases From Sequence diagrams and State-Chart diagrams  Design Done!  Basis for the Test Specification Bank System Bank Customer Deposit Money Withdraw Money Transfer Between Accounts ATM Use Case Scenarios

IBM Software Group | Rational software Invalid PIN CodeValid PIN Code Amount Invalid Use Case: Withdraw Money Valid CardInvalid Card Amount > Account Balance Amount > Daily Limit... Identifying Use Case Scenarios Amount Valid and in Range

IBM Software Group | Rational software The Role of Use Cases Use Cases Requirements Architecture Analysis & Design Test User Experience Design Business Modeling Iteration Planning … Reuse

IBM Software Group | Rational software UCD Analyze:Design : Test : Capture, Clarify and Validate the Use Cases Design to Implement the Use Cases Test that the Use Cases are Fulfilled Use Case Driven Req’tDesign & Impl.Test Capture the Use Cases Design to Implement the Use Cases Test that the Use Cases are Fulfilled In One Sentence Use Cases are the glue that binds the lifecycle process together

IBM Software Group | Rational software Agenda  The Ericsson Success Story  Use Cases  System of Systems

IBM Software Group | Rational software 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

IBM Software Group | Rational software 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

IBM Software Group | Rational software 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.

IBM Software Group | Rational software 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

IBM Software Group | Rational software Rounding Up  From a Swedish Perspective  TBD

IBM Software Group | Rational software For More Information   The UML Books (Booch, Jacobson, Rumbaugh with Addison Wesley)  The UML User Guide  The UML Reference Manual  The Unified Software Development Process

IBM Software Group | Rational software 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