1. © 2009 – 2010 GooBiz.com Agile and Smart Modeling with UML and SysML on the basis of your Project Vision Goal-Driven Modeling to assist Agile Methods (*) on a short Case Study To visualize presentation slides, please use the full screen mode and click to progress © 2010 Birol Berkem - GooBiz.com (*) Agile Methods : SCRUM, AUP (S.W. Ambler), Lean & Agile Development (C.Larman), XP,...

2. Agile Requirements Writing using UP and Scrum Case Study : « As a Listener of an MP3 Audio-Player System, I would like to Listen and Record Audio with satisfaction » Acceptance Checking : The system must verify the following requirements : How to smartly gather these requirements in order to deal with changes ? 2

3.  Step 1. Compose hierarchically business requirements (1) and system requirements (2) that refine them  Step 2. Derive and formalize system functions (3) that satisfy these requirements and use cases that invoke system functions  Step 3. Model the System Life Cycle that control transitions between states where functions are triggered  Step 4. Model Use Cases and System Functions to establish Test Cases on the basis of 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 3 Main Steps for « Smartly Gathering Requirements » Let’s look at each step on the same case study… Requirements and System Analysis 3

4. 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 by a user from the system in order to fulfill the business requirements Functional Boundary of the System under Discussion 4

5. 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 5 When these system functions are triggered ? (see next slide)…

6. 6 Step 3 – Model rigorously states and transitions of the system where system functions are triggered Example : The GOAL of the « Surrounding » state is to support realization of the « Surrounding function » scenario as described next (slide 9) Each state in which a system function is triggered corresponds to a particular GOAL for the system How these functions are USED by the Actors of the system ? (see next slide)…

7. Step 4.1 – Determine 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 7 How these functions are precisely invoked in Use Case Scenarios ? (see next slide)

8. 8 Step 4.2 – 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 described just by a simple click on it (see next slide) Actor / System interactions for the Surround scenario is described next

9. Step 4.3- Describe each scenario to prepare the Test Case for the Function These actor / system interactions describe BLACK BOX test case realization Ffor the « Surround » function. They will become at the design time operations to test this function (see next slide) 9 How to go toward testing black box system functions before architecture design ? (see next slide)

10. 10 Step 4.4 – Specify a Test Component for each System Function to deploy later into the System Architecture  Transform each system function into a Goal- Oriented Object (1)  Map actor/system interactions that realize each function as contextual operations of this object (1) Goal-Oriented Object : An object in a state in which a system function scenario can be completely tested on the basis of its actor/system interactions Example : All of the interactions that realize the Surrounding function (see previous slide) can be tested in the [Surrounding] state of the Player object How to prototype Orchestration of these system functions ? (see next slide)… System Analysis A Goal-Oriented Object whose goal is to support The « Surrounding Function » within the Player System 10

11. 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 – Prototype Orchestration of System Components before designing and deploying them into the System Architecture 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 … 11

12.  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 12 Steps for « System Design » Click to visualise these steps on our Case Study… 12 System Design

13. 13 Step 5 – Elaborate the Internal Blocks and Ports of the System : The « User Interface » and « Processing » Subsytems of the Player are shown below An Application Controler block must 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…

14. 14 Etape 6 –An optimized 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 determine precisely operations of these components ? (see next slide)

15. 15 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. They will become operations to test this function (see next slide) Operations of system components will be updated on the basis of these interactions (see next slide)

16. 16 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 Notice that black box system components were already succesfully specified with these expected behaviours before design time Using the same «Goal-Oriented Objects » (see slide 10 and 11)

17. 17 How to deal with changes ?  Model hierachically changed business and system requirements  Impact changes on system functions (services) to satisfy these requirements  Transform system functions into Goal-Oriented Objects to map them to the system architecture using associations or specialization relationships Let’s look at each step on our case study… System Analysis and Design Requirements and System Analysis 17

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

19. 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 19

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

21. More complete Agile Modeling and SOA Trainings with BMM, BPMN, UML, SysML and SoaML… © 2010 – GooBiz.com Increasing Business Agility with the Goal-Driven SOA using EA (1 day on your site) Goal-Driven SOA Specification et Realization using BPMN, UML and SoaML (3 days on your site) Goal-Driven SOA Specification et Realization using BPMN, UML and SoaML (3 days on your site) Goal-Driven Agile Business Modeling with BMM, BPMN and SOAML using EA (3 days on your site) Efficient Requirement Analysis with UML 2 using EA (3 days on your site) Component Based System Design with UML 2 using EA (2 days on your site) Agile Embedded System Design with UML 2 and SysML using EA (3 days on your site) e-Mail to : birol.berkem@goobiz.com 21