Model Driven Systems Development (MDSD) and IBM Rational Tools in a System of Systems (SoS) Development Environment

1. Model Driven Systems Development (MDSD) and IBM Rational Tools in a System of Systems (SoS) Development Environment Saravana Kumar Lead Architect skumar@praxiseng.com October 7, 2008

2. Agenda Introduction MDSD MDSD in System of Systems Development Q & A 2

3. Praxis Is … Small Business Providing innovative software technologies, products, and solutions Expanding Operations in Dallas Government agencies & Commercial Entities Making significant investments to support our customers’ objectives 3

4. Core Competencies Technologies: Java/JEE, ASP, ESB, XML, TIBCO, WebLayers, Oracle, IBM, ETL, BI, HP, BEA Solutions: Portals, Scalable & Secure Architectures, Data Mgmt, Service Design Implementation & Governance, Visualization Technologies: IBM, Borland, MKS, Trolltech, Datapath, WebLayers, Computer Associates Solutions: Architecture, Design, CM & EAM, Portfolio Mgmt, Automated Test, Customization, Training Technologies: C/C++, VxWorks, Linux, Unix, Windows CE, eCos Solutions: FASTRAK, WiFi4000, Praxis PinPoint, HW Drivers, Packet/Protocol Processing, Wired/Wireless, DSP, SDR High Quality Software Development Best Practices RUP, Agile, XP, Scrum Applying Using 4

5. Agenda Introduction Problem Statement Proposed Solution MDSD MDSD in System of Systems Development Q & A 5

6. Problem Statement Development of a complex distributed system along with the uncertainties and risks associated with them Difficulty in managing change and ensuring that the system, software, test models meet the ever changing requirements. Required automated tools - considered expensive and add more work than save time. 6

7. Agenda Introduction Problem Statement Proposed Solution MDSD MDSD in System of Systems Development Q & A 7

8. Proposed Solution A spiral development approach (a variant of the Rational Unified Process (RUP) framework) will be flexible enough to address the ever changing end-customer requirements will be compliant with the customer’s spiral-development life-cycle model, providing seamless integration with their overall program objectives and schedule. An integrated tool environment will help automate the process of syncing up the changes in the customers System of Systems architectures and models, and would mean lesser hours for requirements, architecture and model maintenance and up-keep. will aid in establishing a requirements, architecture, design and test traceability. 8

9. Agenda Introduction MDSD Why MDSD What MDSD addresses MDSD Core Activities MDSD in System of Systems Development Q & A 9

10. Why MDSD??? MDSD is the set of architectural methods in RUP SE, which is the extension of Rational Unified Process (RUP) to systems development a method for managing complexity and change that can help us in our complex world. the progressive, iterative refinement of a set of models to drive development of our system. 10

11. Agenda Introduction MDSD Why MDSD What MDSD addresses MDSD Key Concepts MDSD in System of Systems Development Q & A 11

12. MDSD addressed… The following complex system development issues: Overwhelming complexity System of Systems (SOS) development Models Levels of Decomposition Drive requirements, define capabilities and interfaces that the customer does not understand Appropriate view points not being considered Hardware Software User Data viewpoints addressing different concerns 12

13. MDSD addressed… Functional, performance and other system concerns not met by the system Distribution of tasks to resources and accomplish them under schedule budget other constraints Unable to being scalable Recursive methodology (Spiral development process) 13

14. Agenda Introduction MDSD Why MDSD What MDSD addresses MDSD Key Concepts MDSD in System of Systems Development Q & A 14

15. Key Concepts Definitions System – Group of interacting, interrelated, or interdependent elements forming a complex whole Black Box / White Box Services and requirements seen from the outside Objects collaborating to meet requirements System Decomposition Partitioning by requirements Partitioning by architecture Requirements and Use Cases System Context and behavior Facilitate agreement with customers 15

16. Key Concepts Use Cases versus Operations What the system does how the system does Viewpoints and Joint Realization - provide the ability to reason about Separation of Concerns Group like things together Separate disparate things Integration of concerns How elements of separate views collaborate to provide system services Derivation of non functional requirements Flowdown - provides architectural consistency and traceability Finding actors and use cases at multiple levels of abstraction Requirements derivation and allocation Operation identification and realization 16

17. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Collaboration & Traceability Summary Q & A 17

18. MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Determine System Operations Define Candidate Architecture Realize System Operations 18

19. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Determine System Operations Define Candidate Architecture Realize System Operations Q & A 19

20. Define Goals and Objectives Initial activities that were involved to organize and focus the project Gathered/Received Requirements Requirements Environment established Requirements and Interface Management Plans (RMP, IMP) were created Requirements Management Tool (DOORS) was configured and the requirements were placed in it and controlled Worked with stakeholders in clarifying and rewriting the requirements Requirements spanned over several systems and changed constantly broke down the requirements based on the system architecture Separated functional and non-functional requirements Created a vision document Captured and communicated the high level capabilities that reflect the focus of the development effort The capability matrix provided the customer a high level feature list to be implemented in the various iterations 20

21. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Determine System Operations Define Candidate Architecture Realize System Operations Q & A 21

22. Establish Context Context Diagram Helped in establishing the systems relationship with the environment in which the system will exist and the functionality the system will provide to the environment Helped in analyzing the requirements effectively Helped in managing the data and as well as the external interfaces Helped in understanding how the system integrated with system of systems and data used as the method of integration Helped in creating a requirements gap analysis report (what it should be as opposed to what it is) Helped in decomposing the system (understanding the context shift from the system level to subsystem level) 22

23. Establishing Context – Context Diagram 23

24. Establishing Context – Use Case 24

25. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Determine System Operations Define Candidate Architecture Realize System Operations Q & A 25

26. Outline Use Cases Focus was on Identification of the actor/system interactions at a higher level and establishing significant scenarios Had difficulty in clearly keeping the separation between system and software level use cases Struggled in staying with the level of abstraction (moving back and forth from what the system does to how the system does) Changed frequently on how the services were grouped in keeping up with the changing requirements Not having an automated tool environment initially made it difficult in maintaining the trace between requirements, architecture and design. Helped managing the data from disparate sources providing overlapping pieces of information 26

27. Outline Use Case (UC) – UC Outline Online sale Use Case Brief Description Customer to purchase the item online on the retail website. Basic Flow 1. Customer logs on. 2. Customer selects “Item to Purchase”. 3. Customer receives product information. 4. Customer reviews product information. 3. Customer adds the item to the shopping cart . 4. Customer selects the checkout option. 5. System requests credit card information 6. Customer enters credit card information 7. System requests billing and shipping information 8. Customer enters billing and shipping information 9. Customer reviews the order and selects the purchase option. 27

28. Outline Use Case (UC) – UC Outline 10. Customer receives order confirmation 11. Customer logs off. Alternative Flows A1 Customer Gets additional products A2 Anonymous Customer A3 Online System Unavailable A4 Product Unavailable A5 Quit Scenarios Customer buys an item online: Basic Flow Customer Gets Additional products: Basic Flow, Customer Gets additional products Invalid login: Basic Flow, Anonymous Customer Online System Unavailable: Basic Flow, Online System Unavailable Product Unavailable: Basic Flow, Product Unavailable Quit Before Completion: Basic Flow, Quit 28

29. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Determine System Operations Define Candidate Architecture Realize System Operations Q & A 29

30. Detail Use Case Scenarios Fleshing out the system Use Case scenarios in the Use Case specification Had difficulty in keeping the level of detail that a system level use case showed Helped in refining the requirements matching to the customers needs Provided a way to highlight to the customer the mapping between the feature set and the system level architecture Expanding each Use Case scenario in the Use Case specification to the next level of abstraction Struggled in staying with the level of abstraction (moving back and forth from what the system does to how the system does) Helped us to understand better on how the data provided the integration with other systems 30

31. Use Case Specification 31

32. Outline Use Case - Black Box 32

33. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Define Candidate Architecture Determine System Operations Realize System Operations Q & A 33

34. Define Candidate Architecture Identification of the architectural and design elements that comprise the internal elements of the system under development Provided a way to highlight to the customer the mapping between the system level architecture and the capability matrix 34

35. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Define Candidate Architecture Determine System Operations Realize System Operations Q & A 35

36. Operations Analysis (Flowdown) Operation Realization Sequence Diagrams 36

37. Agenda Introduction MDSD MDSD in System of Systems Development MDSD Activities Define Goals and Objectives Establish Context Outline Use Cases Detail Use Case Scenarios Define Candidate Architecture Determine System Operations Realize System Operations Q & A 37

38. Realize System Operations Definition on how the elements of the white box architecture collaborate to fulfill each identified system operation Core Process Identify the collaboration Delineate the steps Identify collaborators Delineate the collaboration Who requests? Who provides? What is the request? What are the constraints on the request? Received requests are requirements on the receiver Sending a request may be a requirement in the context of the collaboration, but is not necessarily publicly exposed Constraints are also requirements [QoS] Repeat process at next level 38

39. Realize System Operations Created an Interface Requirements Specification (IRS), detailing the interfaces the system was working with Table listing the operations between the system and the external interfaces Detailed the messages that composed the operation and the data that got transferred as part of the operation Helped derive the requirements put forth by the system on the external systems and vice-versa Helped in separating the requirements derived from above into functional and non-functional requirements Helped in establishing the business process and workflows in interfacing with the external systems 39

40. Agenda Praxis Overview Introduction MDSD MDSD in System of Systems Development MDSD Activities Collaboration & Traceability Summary Q & A 40

41. Collaboration & Traceability Systems & Software Engineering (SE & SW) teams collaborated in an Integrated Environment for systems development Integrated tool environment provided an automated way of providing the trace between requirements, architecture, design and test Helped in automating the manual process of keeping the requirements, use cases and models in sync The test tools in the integrated environment were not used in the first iteration 41

42. Integrated Tool Environment - Envisioned 42

43. Agenda Praxis Overview Introduction MDSD MDSD in System of Systems Development MDSD Activities Collaboration & Traceability Summary Q & A 43

44. Conclusions Was the Basic Problem Solved? YES Pre-MDSD Complex distributed system developed under the influence of ever changing requirements with system, software and test models not in sync with them Post-MDSD Scalable, Flexible framework setup for spiral development Integrated tool environment facilitating an automated process of providing trace between requirements, architecture, design and test Successful completion of the first development spiral using this methodology with very positive feedback Customer planning to replicate this model of MDSD implementation in some of the other projects. 44

45. QUESTIONS 45

46. Thank You • Saravana Kumar • Lead Architect • skumar@praxiseng.com