october 15, 2003 copyrights statesoft inc., 2003. this information is protected by one or more...

October 15, 2003 Copyrights StateSoft Inc., 2003. This information is protected by one or more patent or patent pending.

1

Janusz DobrowolskiJanusz Dobrowolski

StateSoft Inc,StateSoft Inc,[email protected]

Prof. Bogdan KorelProf. Bogdan Korel

Illinois Institute of TechnologyIllinois Institute of [email protected]

MDA -Model Driven Architecture for 3G/NGN

Automatic Generation andValidation

or Platforms and Services

StateSoft


2

OMG’s Mission Since 1989

• Develop an architecture, using object technology, for distributed application integration, guaranteeing:– reusability of components– interoperability & portability– basis in commercially available software

• Specifications freely available• Implementations exist• Member-controlled not-for-profit


3

Who Are OMG?

AT&T

BEA

Borland

Boeing

CA

Citigroup

Compaq

Compuware

Ericsson

Ford

Fujitsu

Glaxo SmithKline

Hewlett Packard

Hitachi

Hyperion

IBM

IONA

io Software

Kabira

Kennedy Carter

John Deere

Microsoft

MITRE

MSC.Software

NASA

NEC

NetGenics

NTT

OASIS

Oracle

Pfizer

Rational

SAGA Software

SAP

SAS Institute

Secant

Siemens

Sprint

Sun

Unisys

Vertel


4

MDA Benefits

• Full support for your “20 year architecture” across the application lifecycle

• Smooth integration across intra- and inter-business boundaries (across deployment technologies)

• Reduced costs from beginning to end• Reuse of applications, code, training and people• Technology-independent representation of the business• Scalability, robustness & security via generated code• Stable model-based approach maximizes ROI• Rapid inclusion of the next best thing

The CIO Problem Solver


5

To Get More Information

• MDA Information Page– http://www.omg.org/mda/

• OMG General Information– http://www.omg.org/

• Contact the Author of previous 3 slides– [email protected]

• See the first products!


6

Model Driven Architecture


7

3G/NGN Must Deliver what other Technologies Can’t

– Instantaneous Real-Time Collaboration

– Predictable and Reliable Deployment of New Services and Applications

– Self-Healing Connectivity


8

To_Program or To_Model

Programming == Expense

Modeling == Investment in your domain of expertise

Product of Modeling: Retargetable Architectures and Services


9

UML Most Recognized Problem

“The weak area of UML is in the behavioral or dynamic part.” From the 2003 book “MDA Explained”

by A. Kleppe, J. Warmer, W. BastThe term “weak”, as understood by a prospective, user may relate to:• Varying degree of automated code generated by existing tools • Limited automated analysis (validation)• Partially executable models

VeUML proposed solution: 100% executable model generation and validation is possible for complex behavior modeling.


10

The Big Goal

“The goal over the next 20 years will not be speed, cost or performance; it will be a question of complexity.”

Bill Raduchel, Chief Strategy Officer, Sun Microsystems


11

Things hard or impossible to achieve without MDA

– Automatic Platform and Services Generation

– Automatic Validation

– Services Feature Interactions Tracing


12

Current Telco Systems Architectures: limited potential for Reuse, Automatic Validation and Features Interaction Traceability

PIM Platform Independent Model PSM Platform Specific Model

Presentation

Applications

Services

Platform

Protocols

NOT MUCH HERE !!!


13

VeUML- Based 3G/NGN Systems Architectures optimized for Reuse and an Automatic Validation

PIM PSMInheritanceConcrete

Presentation

Concrete Applications

Concrete Services

Concrete Platform

Concrete Protocol

Abstract Presentation

Abstract Applications

Abstract Services

Abstract Platform

Abstract Protocol


14

#1 Software Industry Misconception

“ Though state models offer very good support in somedomains (including the telecom, some embedded systems, certain styles of UI), others have only little use of state models (e.g. medical picture processing, accounting, insurance systems).”

Popular perception

VeUML: For the same complexity of behavior problem, VeUML state models are equally usable regardless of the domain including IT, telecom, embedded systems, medical picture processing, accounting and insurance systems.


15


“FSM’s are by far not complete.” Popular perception

VeUML: delivers complete FSM based solution for the complex systems

behavior modeling.


16


“State transition diagrams aren’t created for every class; they are used only for very complex classes”.

Source: Book by Wendy Boggs, Michael Boggs “Mastering UML withRational Rose®”

Reality: In the above approach by the time the state transition diagrams (STD) complexity is fully understood it becomes overwhelming.


17

Coupling Data and Behavior creates substantial validation scalability problems for Complex Systems

• State explosion

• Inefficient validator execution time

• Excessive validator memory requirements

• Validator complexity


18

Proposed solution: VeUML

Separation of Class Data from a Class Behavior:

A viable and proven approach


19

Components of a Class Model in UML

Data Representation

BehaviorRepresentation

Shared with other classes,mixed with data,incomplete, or missing

Attributes:

• Data_1• Data_2• Data_3

CLASSOperations

Methods ONLY defined:

get_this() /* unclear when */put_there() /* unclear when */


20

Components of every PIM Class in VeUML

Data Representation

AbstractBehavior

Representation

VFSM Component

• States• Virtual Events• Virtual Actions• Behavior viewable as(STD, XML, Table, SDL)

Attributes:

• Data_1• Data_2• Data_3

CLASS

Methods:get_this() /* as per VFSM order*/put_there() /* as per VFSM order */

Operations


21

VeUML – Value Added Proposition

VeUML = MDA (UML) + VFSM

VFSM Domain Independent Behavior Modeling and Validation

VFSM (Virtual Finite State Machine) a key element of a System Complexity Problem Solution


22

VeUML Key Approach to Conquer Behavior Complexity: Separation of Domains

Separation of:

Service and Application Logic from Platform Class Data from Class Behavior Behavior from Concurrency -

(Generalized Objects Factory Pattern) Events from Data Actions from Data Class behavior from the PSM Programming

Language (e.g., C++, Java)


23

Key Elements of VeUML behavior notation:

Virtual Environment:

• Virtual Events (independent from data)

• Virtual Actions (independent from data)

• States (contain no data)


24

EJB Stateless Session Bean(Enterprise and Telco Systems Convergence)

Vchart / VeUML Notation

Does-Not-Exist

Method-Ready-Pool

input / BMrequest1 / Action1input / BMrequest2 / Action2

……..input / BMrequestN / ActionN

PIM PSM

ejbCreate

ejbRemove


25

VeUML Approach to Conquer Behavior Complexity

• VFSM Behavior Model for Every PIM Class Advantage: simplifies the behavior modeling

• Automatic Executable Generation for behavior model

Advantage: increased reliability, performance and degree of automatically generated system

• Eliminating shortcomings of Round Trip Engineering for the behavior models

Advantage: Executable always in synch with the models


26

VeUML Approach to Conquer Behavior Complexity

• Automatic Model Validation Advantage: Increased reliability and early defect

detection

• Reuse and Portability of Behavior Models Advantage: True productivity gains

• Behavior Models Tied to Formal Models Advantage: Reliable and deterministic executable

generation and validation


27

VeUML remedy for Software Development Pain

Problem VeUML Solution

Complexity Separation of concerns – data from behavior; events from data, behavior from concurrency, actions from data etc..

Cost Automatic executable generation, automatic validation and simplified test. Resulted savings 45% (AT&T/Lucent Data)

Portability to different platforms

Service/Business Logic represents Interlingua - model and automatically generated executable are platform independent

Quality Late defects reduction by 40% by exhaustive validation and early detection (AT&T/Lucent Data)

Performance Optimized Predictable performance of VFSM executor


28

Fundamental VeUML System Decomposition Paradigm: PSM Inherits from PIM

PIM PSM

Domain Model

VeUML

System Linkage

Domain Transformation

Environmental Transformation

InheritanceDesign

Environment


29

VeUML extensions: VeSTD, VeXML, VeMSC, VeSDL:

* Immediate automatic representation conversion always possible:

VeSTD <-> VeMSC <-> VeSDL <-> VeXML

* Consistency in OOA/OOD view:According to the OOA/OOD principle Architect/Designer/Implementer view of a system should be the same. In VeUML the MDA behavioral model is the only target executable representation Architect/Designer/Implementer work with.


30

VeSTD Example – Partial diagram

Wait_to_brew

entry / Turn_Boiler_Off, Turn_Indicator_Off; Turn_Warmer_Off; Close_Valve

boilerEmpty / Turn_Boiler_Off; Turn_Indicator_On

Empty_pot_removed

startBrew & boilerNotEmpty & potEmpty / Close_valve; Turn_Boiler_On; Turn_Indicator_Off

Brewing_pot_Empty

warmerEmpty / Open_valve; Turn_Boiler_Off

This Coffeemaker example is based in part on the book by Robert C. Martin, “Object-Oriented C++ Applications Using The Booch Method”, Prentice Hall, 1995.


31

VeSDL Example – Partial diagram

Wait_to_Brew

Empty_pot_removed

startBrew & boilerNotEmpty & potEmpty

Brewing_Pot_Empty

Close_valve; Turn_Boiler_On;

Turn_Indicator_Off

startBrew & boilerNotEmpty & potEmpty

Open_valve;

Turn_Boiler_Off

boilerEmpty

Turn_Boiler_Off;

Turn_Indicator_On

32

• <?xml version=“2.0"?>• • <XML>• <STATE>• <TRANSITION> • <CONDITION> “potNotEmpty / “ • <ACTION>• “Close_valve; Turn_Boiler_On; Turn_warmer_On”• </ACTION>• <NEXTSTATE>• “Empty_Pot_removed”

</NEXTSTATE>

• • </CONDITION>• <TRANSITION> • </STATE> </XML>

VeXML Example – Partial listing


33

VeMSC Classes Behavior Generation from System Model MSC

In VeUML one can automatically synthesize target executable model from elementary representations.

Other approaches often use elementary representation for high level simulation only.

atm bank

StateB1

StateA2

StateA3

StateA1

StateB3

ActionA2

StateB2

ActionB1

MSg1

MSg3

MSg2

ActionA1

ActionB2


34

VeUML extension concepts: VeSTD, VeXML, VeMSC, VeSDL. What do they represent as a Modeling Language Category?

It may be:

T E M L – (new term) Target Executable Modeling Language

Interlingua – (IBM® term) where source model and executable are programming

language independent.


35

Conclusions: Benefits of Separation of Domains

in VeUML Behavior Modeling

• Automatic executable generation and validation for systems of substantially higher complexity

• Significant degree of reuse due to

separation of domains

• Potential for Services Features Interaction

october 15, 2003 copyrights statesoft inc., 2003. this information is protected by one or more...

Documents