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_at_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 C/C, VxWorks, Linux, Unix,
Windows CE, eCos Solutions FASTRAK, WiFi4000,
Praxis PinPoint, HW Drivers, Packet/Protocol
Processing, Wired/Wireless, DSP, SDR
Technologies IBM, Borland, MKS, Trolltech,
Datapath, WebLayers, Computer Associates Solution
s Architecture, Design, CM EAM, Portfolio
Mgmt, Automated Test, Customization, Training
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 customers
  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_at_praxiseng.com