Praxis Proprietary Information Providing Practical Software Solutions Model Driven Systems...

Praxis Proprietary Praxis Proprietary InformationInformation

Providing Practical Software Providing Practical Software SolutionsSolutions

Model Driven Systems Development (MDSD) and IBM

Rational Tools in a System of Systems (SoS) Development

EnvironmentSaravana Kumar

Lead Architect

[email protected] 7, 2008


2

Agenda

Introduction MDSD MDSD in System of Systems

Development Q & A


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


4

Core Competencies

High Quality Software Development

BestPractices

RUP, Agile, XP, Scrum

Applying Using

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

Solutions:Architecture, Design, CM & EAM, Portfolio

Mgmt, Automated Test, Customization, Training


5

Agenda Introduction

Problem StatementProposed Solution

MDSD MDSD in System of Systems

Development Q & A


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.


7

Agenda Introduction

Problem StatementProposed Solution

MDSD MDSD in System of Systems

Development Q & A


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.


9

Agenda

Introduction MDSD

Why MDSDWhat MDSD addressesMDSD Core Activities

MDSD in System of Systems Development

Q & A


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.


11

Agenda

Introduction MDSD

Why MDSDWhat MDSD addressesMDSD Key Concepts


Q & A


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


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)


14

Agenda

Introduction MDSD

Why MDSDWhat MDSD addressesMDSD Key Concepts


Q & A


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


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


17

Agenda Introduction MDSD MDSD in System of Systems

Development MDSD Activities Collaboration & Traceability Summary

Q & A


18

MDSD ActivitiesDefine Goals and ObjectivesEstablish ContextOutline Use CasesDetail Use Case ScenariosDetermine System OperationsDefine Candidate ArchitectureRealize System Operations


19


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


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


21




Q & A


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)


23

Establishing Context – Context Diagram

Retail System

Number of Current UsersNumber of Open Sales Lists

<<System Service>> Initiate Instore Sale()<<System Service>> Complete Instore Credit Card Process()<<System Service>> Complete Online Sale()<<System Service>> Complete Instore Sale()<<System Service>> Report Sales Data()<<System Service>> Enter Online Sales Item()<<System Service>> Enter Instore Sales Item()<<System Service>> Initiate Instore Credit Card Process()

<<System>>

Sales and Tax Data

<<I/O>>

Accounting System

<<receive>>

Credit Card ID<<I/O>>

Bank Credit Card System

Credit Card Validation<<I/O>>

<<receive>>

<<send>>

Personal Information

<<I/O>>

Purchase Request

<<I/O>>

Product Information

<<I/O>>

Information Request

<<I/O>>

Online Customer

<<send>>

<<send>>

<<receive>>

<<send>>

Order Status<<I/O>>

<<receive>>

Sales Item I/O

Scan CodePrice

<<I/O>>

Credit Card

ProviderNumberExpiration Date

<<I/O>>

Receipt<<I/O>>

In Store Customer

<<send>>

<<send>>

<<receive>>


24

Establishing Context – Use Case


25




Q & A


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


27

Outline Use Case (UC) – UC Outline

Online sale Use Case

Brief DescriptionCustomer to purchase the item online on the retail website.

Basic Flow1. 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 information6. Customer enters credit card information7. System requests billing and shipping information8. Customer enters billing and shipping information9. Customer reviews the order and selects the purchase

option.


28

Outline Use Case (UC) – UC Outline

10. Customer receives order confirmation11. Customer logs off.

Alternative FlowsA1 Customer Gets additional productsA2 Anonymous CustomerA3 Online System UnavailableA4 Product UnavailableA5 Quit

ScenariosCustomer buys an item online: Basic FlowCustomer Gets Additional products: Basic Flow, Customer Gets

additional productsInvalid login: Basic Flow, Anonymous CustomerOnline System Unavailable: Basic Flow, Online System UnavailableProduct Unavailable: Basic Flow, Product UnavailableQuit Before Completion: Basic Flow, Quit


29




Q & A


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


31

Use Case Specification


32

Outline Use Case - Black Box


33



• Define Goals and Objectives• Establish Context• Outline Use Cases• Detail Use Case Scenarios• Define Candidate Architecture• Determine System Operations• Realize System Operations

Q & A


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


35




Q & A


36

Operations Analysis (Flowdown)

Operation Realization

Sequence Diagrams


37




Q & A


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


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


40

Agenda

Praxis Overview Introduction MDSD MDSD in System of Systems


Q & A


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


42

Integrated Tool Environment - Envisioned

DOORSRequirements Management

Required Interface to Customer

ClearQuest(Change Management

Solution)

Rational Test Manager(Organizes Test Plans & Test Cases

Provides Traceability to RequirementsProvides a single interface to test

execution)

Rational Rose/Rational Software ArchitectUML 1.4/2.0 Modeling Tool

Used for Architecture and Design

ClearCase(Configuration Management Solution)

Rational Performance Tester(Performance testing for Java

based applications)

Rational Robot(Rational’s legacy test script development tool for

functional and performance testing scripts

On BOM for screen scrapping capability)

DoorKeeper Defect Generation and Population

Rational Functional Tester(Functional testing for Java based

applications)

Manage Performance Tester Scripts

Manage Functional Tester Scripts

Manage Robot Test Scripts and Suites

Use Case to Design Traceability

Integrated UCM ClearCase and ClearQuest solution


43

Agenda

Praxis Overview Introduction MDSD MDSD in System of Systems


Q & A


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.


45

QUESTIONS


46

Thank YouThank You

Saravana KumarLead Architect

[email protected]

Date post:	28-Dec-2015
Category:	Documents
Upload:	michael-nickolas-tyler
View:	214 times
Download:	0 times

Praxis Proprietary Information Providing Practical Software Solutions Model Driven Systems...

Documents