CNIC Information System with Pakdata Cf In Pakistan
Â
Sodius cassidian mdday2010
1. }
SODIUS / EADS CASSIDIAN
MD DAY 2010
MODEL DRIVEN ARCHITECTURE FOR SUPPORTING SYSTEMS ENGINEERING AT CASSIDIAN
25 November 2010
Yann LEBEAUPIN â SODIUS â CTO
Jean-Baptiste CARTIER â EADS CASSIDIAN - PLM Technical Expert
2. Agenda
ï Introduction
ï Who is SODIUS?
ï Collaboration with CASSIDIAN (EADS D&S) since 2009
ï Enterprise Architecture Framework Interchange Solution Definition
ï Application and Feedback on a tool migration project
ï IPSE project and System Engineering collaborative software
perspectives
ï Model driven architecture for supporting systems engineering at Cassidian
3. Who is Sodius ?
ï SODIUS, started in 1999
ï SODIUS is specialized in Systems Engineering and Interoperability
ï SODIUS is recognized as a leading company to bridge different tools used
by engineers involved in systems or software projects.
ï SODIUS, is a technology provider for IBM, NoMagic, and a certified IBM
Business Partner.
ï SODIUS provides solutions to interoperate with a number of engineering
tools : to transform models, to customize code generators, and create Word
documentation from multiple models.
We have highly specialized tools and skills for:
âą Model-Driven Engineering
âą Multidisciplinary Systems Engineering
âą Legacy Models handling
âą Long Life Cycle handling (>10 years)
4. Model Integration and Tools Interoperability Projects
Who is Sodius ?
Based on a common Moded-Based approach and
MDWorkbench technology platform and assets
5. SODIUS &
ï Since 2009, SODIUS develops for CASSIDIAN (former EADS Defence & Security)
solutions enabling interchange of data between modeling (architecture framework)
tools in the context of System Engineering projects.
ï These solutions are achieved as part of a common CASSIDIAN corporate effort
named IPSE (Integrated Project Support Environnement) which goal is to provide a
suite of tools for System Engineering.
First phase of project
Communication between tools for data and diagram exchange
Second and subsequent phases :
Implementation of a "bus" to communicate with more advanced features
as configuration management and automation of authoring activities
6. ï Introduction
ï Who is SODIUS?
ï Collaboration with CASSIDIAN (EADS D&S) since 2009
ï Enterprise Architecture Framework Interchange Solution Definition
ï Scope and solution architecture
ï Application and Feedback on a CASSIDIAN migration project
ï IPSE project and System Engineering collaborative software perspectives
ï Model driven architecture for supporting systems engineering at Cassidian
Agenda
7. Exchange the models
ï In the real world, a single toolset is not possibleâŠhowever we need:
ï Be able to âexchangeâ models with partners/external customers/subcontractors on a single target even if
teams have different/heterogeneous choices (historical, national, businness)
ï To re-use âarchitecture modelsâ, integrate or migrate âlegacyâ components
ï Reuse legacy models (as components) and insert them into new designs
ï âŠenhance/customize them to support specific features and manage specific value
DBMS
TOOL A
DBMS
TOOL B
DBMS
TOOL C
?Accept the diversity !
Development of complex systems requires dedicate solutions to enable
exchange, reuse or integrate models helping systems engineers to
handle complete scope and challenges of systems architecting and
management throughout the lifecycle of the system
8. CASSIDIAN Project context
BorderShield Project Legacy
3 Tools currently used on the BorderShield project in DoDAF context
2
DoDAF
Models initially
created and
used on German
CASSIDIAN
project, then on
BorderShield
1
Change authoring ?
How migrate models and diagrams ?
MEGA 2009
Recommended by our
business Unit
3
9. Drivers for Change
ï Facts on the Bordershield project
ï Initial choice : SA as common language â legacy models
ï Collateral architecture team shift from SA to EA
ï Bordershield Technical Opportunity to move to another modelling solution ?
ï MEGA has been selected on technical criteria
ï Identified in an internal justification table
ï Mainly
â Cosmetic features
â Power of the tool itself
ï DoDAF SV3 views useless on System Architect
ï Higher consistency check with MEGA, close to the MetaModel
â Few support on System Architect in the French « community »
Translation from SA to MEGA 2009 decided
and performed in June 2010 by SODIUS and CASSIDIAN teams
10. Problem statement
ï The scope of the solution is to provide an
architecture for
ï Exchanging models and diagrams
ï Between MEGA and System Architect
ï Considering future extensibility needs
DoDAF
One thing that is sure: Actors, Tools, Process,Standards (DoDAF, NAF, UPDM, etcâŠ) WILL CHANGE
The challenge is to integrate architectures in 2010 (t)
AND maintain this capability in 2011, 2015,etc⊠(t+n) !
NAF
The SAM project had to consider
too the underlying movement to
NAF (NATO Architecture
Framework) in the domain of
complex systems of systems
(NATO, Defence actors, LSI
European projects)
ï General Capability Requirements
ï Model Exchange should cover the content of DoDAF ,
and later of NAF
ï Model Exchange should be âvendor neutralâ
11. Proposed Solution
ï Adopt NAF V3 Metamodel (NMM) as the pivot format for EA models
ï NAF V3 has the largest user support
ï NAF V3 has almost a complete coverage for System Engineering projects
ï Adopt UML2 diagrams as the diagram types for NAF
ï NMM is defined as a abstract UML profile using underlying UML concepts
ï Ensure application connectivity maintenability
Direct tool integration (P2P) should be avoided because:
âą There are too many tools involved
âą Such integration depends on tools internal architectures which are not under control of the
integration platform
12. Architecture of the NAF solution
SODIUS has built a NMM 1.0 pivot-based solution, including support of diagrams using connectors to
import/export native âRAWâ data from applications and NMM UML models to store intermediate data.
Benefit of the approach: The solution supports both of CORE Data AND Diagrams
exchange. As NMM has been defined as a UML âconceptualâ profile (abstract syntax),
implementation is 100% conforming with the specification (NMM 1.0).
NMM
Profile
UML2
MM
DI Profile
NAF MM Assets
(Tool Agnostic Pivot)
Conforms To
DBMS1
TOOL 1
TOOL1
Metamodel
TOOL2
Metamodel
DBMS2
TOOL 2
Model 1
Model 2
Interoperability Rules
RulesRules
DI
UML2
Models
Rules
NMM
UML2
Models
MDWorkbench
Connector Connector
13. Interoperability approach
ï SODIUSâ interoperability approach is based on MDWorkbench platform:
ï Separated approach between the data (I/O) and the required
transformation : Connectors + MMs + Rules
ï§ Metamodels to abstract data model (instead of syntax views)
ï§ Connectors to enable tools access (read/write) in multiple, reusable ways and
feed models (conforming to previous MMs)
ï§ Rules for specific mapping
ï§ Capacity of SODIUS to create new connectors quickly (using any text or xml
formats, apis, web-services or database access)
DBMS1
TOOL 1
Rules
TOOL1
Metamodel
Model 1
Benefit of the approach: Rules manage specific exchange process, connectors are
reusable assets encapsulating complexity of connection with tools.
Connector =
MM + Reader
+ Writer
Connectors are
able to manage
many kind of
formats
14. Diagram Support
ï SODIUS is involved in the XMI Interchange Workgroup
ï Even if normalization consensus has not been reached, UML DI Extension referencing UML
semantic elements is a good way to represent âcommonâ denominator between applications in a
pragmatic way
ï Based on DI format, connectors use diagramming apis or proprietary formats of tools to re-create
diagrams from neutral DI defintions
ï To manage diagrams in the closest way that target authoring environment allow it, some layout
rules have to be add for each tool (anchors management, edges/nodes support differences
between tools, default shapes) â there is a âhumanâ interpretation to find consensus
(âcommon denominatorâ).
DI Profile
NMM
Profile
UML2
MM
NAF MM Assets
âXMIâ DI File
DI Model
Semantic
Data
DI Metamodel
15. Diagram Support
âTool-Agnosticâ Viewers of
NAF Models
DI Model
Connectors use diagramming apis or proprietary
formats serializers to re-create diagrams into
authoring tools from neutral DI definitions
16. Samples of managed views
MEGA
System
Architect
Diagrams and Data can be exchanged between tools (each time view
concepts are supported by the authoring tool)
UML Base Classes
«metaclass»
InformationFlow
«metaclass»
Property
«metaclass»
Class
whole
1
*
part
1
*
target
1
*
source
1
*
Node
«extends»
NodeAssemblyUsage
InformationExchange
target
1
*
source
1
*
class
1
*
type
1
*
NOV-2 Stereotypes
«metaclass»
Package
1
ownedMember
*
ArchitecturalDescription
NodeRelationshipDescription
ArchitecturalProduct
CompositeStructureModel«extends»
«extends»
owningArchitecture
1
products
*
«metaclass»
PackageableElement
«metaclass»
Dependency
«extends»
«extends»
«extends»
NodeConnector
«metaclass»
Connector
«metaclass»
ConnectorEnd
«extends»
12
NodeConnectorEnd
«extends»
supportingNeedlines
Needline
NestedConnectorEnd
role
connectionContext
«metaclass»
StructuredClassifier
1
ownedConnector
*
1
end
*
realizingConnector
«metaclass»
Activity
«extends»
OperationalActivity
NodeHasBehavior
conductedAt
1
*
activityConducted
1
*
«metaclass»
NamedElement
supplier
1..*
*
client
1..*
*
NAF Metamodel
17. CASSIDIAN Lessonâs learnt on SAM
ï Semi-automatic procedure including two stages
ï MDWorkbench automatic on the full modelling DataBase (100% Data/90% Diagrams)
ï Some manual modification on geometry and layout of elements
ï Inputs
ï Mapping of objects sometimes tricky between SA and MEGA ï Common work on
Specification Document
ï Outputs
ï Quick translation : one week workload on 150 views / 1500 modelling items
â Some manual fixes
ï Mainly due to IDEF0 notation origin use in OV05 DoDAF Views, artefacts items to be
corrected
ï Geometry ï cf. manual work
ï Hidden objects ï Board side effect still to be fixed
ï Much quicker than modelling from scratch
ï No lost or wrong migration of modelling objects and diagrams
19. ï Introduction
ï Who is SODIUS?
ï Collaboration with CASSIDIAN (EADS D&S) since 2009
ï Enterprise Architecture Framework Interchange Solution Definition
ï Application and Feedback on a EA tool migration project
ï IPSE project and System Engineering collaborative software perspectives
ï Model driven architecture for supporting systems engineering at Cassidian
Agenda
20. Introduction
ï The problem:
ï LSI Projects are more and more complex
ï High cost / High risk projects
ï Long life cycle projects
ï Lot of actors (engineers, suppliersâŠ)
ï Rapidly changing requirements
ï The need:
ï an integrated environment of system engineering
tools throughout the LSI product life cycle:
â Requirement management
â Architecture design
â Change management
â Integration & Validation
21. The system engineering spiral
Requirements
Management
Operational and
System Rules Model
engineering
Business Process &
System Evaluation
Requirement refinement
requirement update from
the prototyping experience
Architecture design.
Operational and System Rules
elements will be linked to
requirements
V & V in simulation.
Business Process & System
elements prototyping
22. Requirements
Management
Operational and System
Rules Model engineering
Business
Process &
System
Evaluation
Traceability & consistency
Stakeholder
Req.
System
Req.
Technical
Req.
DB
Organic View
System View
Operational View
requirement
traceability
requirement
traceability
Stakeholder
Req.
System
Req.
Technical
Req.
23. The IPSE Added Value â SE Collaboration
ï IPSE (Integrated Project Support Environment) is a collaborative software environment for system
engineering from Requirement Engineering, Behaviour & Architecture Modelling, Validation through
Process Simulation, Verification with Systems Simulation to Data Management.
Info traceability (from reqs
to delivery) + SoS
maintenance
Data re-use (business
objects & logic) to avoid
re-inventing the wheel
Info flow control
(powerful workflow
centric approach)
Data coherency
maintenance (link
project & BMS F1)
System Engineering life-cycle
collaboration (shared
repository)
SAM
Bordershield IPSE
Connectors
24. The IPSE framework
Requirements
Engineering
DOORS
SoS Architecture
Design
SA
Process
Simulation
Product development
PLM
Project
Management
Configuration
Management
SoS
Architecture
Design
MEGA
SoS
Architecture
Design
EA
Connector
Backbone
MDWorkbench
25. SODIUS IPSE Components
ï SODIUS is developing CASSIDIAN integration and automation tooling
for the IPSE framework
ï MDWorkbench Authoring tool to configuration management client application
ï MDWorkbench Model Artifacts Web Viewer
Configuration Management Web Server
MEGA CLIENT MDWorkbench DOORS CLIENT
Web services
Configuration Management Web Server
MDWorkbench
Web Client
HTTP
26. SODIUS IPSE Components
ï MDWorkbench âInterface Layerâ RCP Eclipse Application
ï Ensuring communication between configuration management and
authoring tools (user workspace or baseline restore,
checkin/checkout operations)
Configuration
Management
Authoring Tools
MDWorkbench
âInterface Layerâ
M
E
G
A D
O
O
R
S
27. SODIUS IPSE Components
DB
MDWorkbench
Interface Layer
Authoring Tools
Configuration
Management
Specify, Design, Produce
Requirement/Architecture
MDWorkbench Web Viewer
Inspect/Review
Architecture &
Produce Change
Request
Exported Model âUnitâ
Authoring
ModelCheckin