1. © 2010- 2011 GooBiz.com Agile System Modeling using UML and SysML How to assure MRD - PSD traceability and deal with changes using a Goal-Driven Modeling ? An ‘MP3 Player’ Case Study… To visualize presentation slides, please use the full screen mode and click to progress © 2010 – 2014 Birol Berkem - GooBiz.com (*) MRD : Marketing Requirement Document PSD : Product Specification Document

2. © 2010- 2011 GooBiz.com Main Steps of the System Development Life Cycle (Exemple : using Harmony from IBM / Telelogic)

3. …or using RUP or Scrum Methods to Gather Requirements Example of Scrum’s User Story : « As a Listener of an MP3 Audio-Player System, I would like to Listen Audio and Record Audio with satisfaction » The underlying system requirements for the MP3 Player are : How to apply these methods to gather and structure requirements in order to deal with changes ? 3

4.  Step 1. Compose hierarchically business requirements (1) and system requirements (2) that refine them  Step 2. Derive system functions (3) that satisfy these requirements and use cases that invoke system functions  Step 3. Model how system functions are triggered in the Product Life Cycle ?  Step 4. Establish Test Cases on the basis of Use Case Scenarios that realize System Functions (1) Business Requirement : A needed achievement and the quality measures expressed in terms of broad outcomes the business requires. (2) System Requirement : A condition or capacity required by a user from the system in order to fulfill the business requirements (the goal). (3) System Function : Action requested from a product or realized by itself to partially satisfy a requirement 4 Main Steps to « Smartly Gathering Requirements » Let’s look at each step on the same case study… Requirements and System Analysis 4

5. Step 1 - Compose hierarchically business and system requirements to better manage impact analysis when requirements evolve Business Requirement : A need and the quality measures expressed in terms of broad outcomes the business requires System Requirement : A condition or capacity required from the system in order to fulfill the business requirements Functional Boundary of the System under discussion 5 How to assign these requirements to system functions ? (cf. next)

6. Step 2 – Formalize the System Boundary by assigning requirements to system functions System Functions : Actions requested from a product or realized by itself to satisfy partially a user requirement 6 How to capture the internal behaviors of the ‘ Player Controler’ function ?

7. 7 Step 3 – Model states and transitions of the ‘Player Controler’ function to better understand its internal behaviors by clicking on the « Surrounding » state we will specify how the « Surrounding function » is used (slide 9) In each state a system function is triggered by the Player Controler Now …how to specify usage of these functions by the Actors of the system ?

8. Step 4.1 – Determine first how Use Cases invoke System Functions The Audio Player Functions are based on the previous system requirements A base Use Case that processes the actor’s interactions with the system functions 8 How are these functions invoked within Use Case Scenarios ? (see next slide)

9. 9 Step 4.2 – …then elaborate UC Scenarios that invoke System Functions Actor / System Interactions formalize invocation scenarios of system functions in the UC « Listen Audio » This Surround scenario will be available just by a simple click on this (see next slide) Actor / System interactions for the ‘ Surrounding’ Scenario (cf.next)

10. Steps 4.3/4.4 – Describe each Scenario and deduce behaviors of the related System Function Actor / system interactions describe the black box test case for the « Surround » function. These Messages become operations to test this function (click to visualize) 10 Object Functional State More accurately (see next slide)…

11. 11 Step 4.4 – Specify a Test Case Component for each System Function  Transform each system function into an object in the desired functional state  Map actor/system interactions that realizes this system function as its contextual operations 11 How to design the Architecture Backbone using system functions ? (see next slide)… Object State An ‘Operation Contract’ is to be built up for the ‘black box testing’ of each operation

12. The controler of the Player orchestrates execution of these functions External components participate to the realization of functions via required and provided interfaces Step 4.5 – Design a draft ‘Architectural Backbone’ of the whole system before designing its system functions The Surrounding function is expressed by the [Surrounding] state of the Player object. The actor / system interactions (scenario) that realize this function become its operations Recording function of the Player … 12

13.  Step 5. Elaborate a High-Level Block Diagram of the System using Parts, Ports and Interfaces  Step 6. Refine and Optimize the initial architecture design to better deal with changes  Step 7.1 Model white box interactions by use case scenario (user story)  Step 7.2 Map corresponding Operations on the Components (Parts) of Blocks 13 Steps for the « System Design » Click to visualise these steps on the ‘MP3 Player’ Case Study… 13 System Design

14. 14 Step 5 – Elaborate the Internal Blocks and Ports of the System : The « User Interface » and « Processing » Subsytems of the ‘MP3 Player’ are shown below An Application Controler block may be designed inside the CPU block to Orchestrate execution of the above functions (see next slide) Functional Blocks will be deployed there to better deal with evolutions of these functions (see next slide) Click to visualize detailed parts and interfaces on the next slide…

15. 15 Etape 6 –A more detailed architecture to better deal with changes An Application Controler designed for the cpu block to Orchestrate execution of the above functions (MVC pattern) Surround, Record and Play « Components » designed for the memory (mem) block to better deal with evolutions of these functions (OCP pattern) Provided and required interfaces between the CPU and Mem components How to accurately determine operations of these components ? (see next slide)

16. 16 Step 7.1 - Describe each white box scenario to prepare the Integration Test for the corresponding software component These interactions describe WHITE BOX test case realization for the « Surround » function. Messages will give up operations to test this function (see next slide) Operations of system components will be updated on the basis of these interactions (cf. next slide)

17. 17 Etape 7.2 – Update components with operations on the basis of white box interactions The White box interactions (previous slide) that realize the ‘Surrounding’ function become operations of the corresponding block

18. 18 How to deal with changes ?  Model hierachically changed business and system requirements grouping them by goals  Impact changes on system functions (services) to satisfy these requirements  Transform system functions to map them into the system architecture Let’s look at each step on our case study… System Analysis and Design Requirements and System Analysis 18

19. Model changed business and system requirements Changing Business Requirements that cause extension to previous functions Additional Requirements that must be supported by the system functions to satisfy Business Requirements 19

20. Impact changes on the system functions to satisy new requirements New Complex Functions are added to the functional architecture to satisfy changes on requirements Requirements and System Analysis 20

21. Map these functions with corresponding requirements to the existing system architecture for tests New complex functions are mapped into the existing architecture using association and specialization relationships System Analysis and Design 21 Notice how the «Goal-Driven Modeling » approach brings agility particularly to better deal with changes

22. More complete Agile System Development Training Courses using standards… © 2011 / 2014– GooBiz.com e-Mail to : birol.berkem@goobiz.com 22