Solution de génération de rapport OpenDocument à partir de plusieurs sources par Régis Chevrel

1,554 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,554
On SlideShare
0
From Embeds
0
Number of Embeds
552
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Solution de génération de rapport OpenDocument à partir de plusieurs sources par Régis Chevrel

  1. 1. }Click to edit Master subtitle styleOpenDocument ReportS GenerationFrom Several Sources
  2. 2. Who is SODIUS? ● SODIUS is specialized in Systems Engineering and Interoperability ● Leading company to bridge different tools used by engineers ● Technology provider for IBM, No Magic, 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 / OpenDocument 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)
  3. 3. What SODIUS do?  SODIUS is an interoperability expert  SODIUS is a software publisher  Main product is MDWorkbench, an Eclipse based MDE tools  DXL Editor a complete IDE for DOORS/DXL developpers  MDWorkbench provides facilities to:  Transform models to model (M2M)  Transform model to Text (M2T) including document generator  SODIUS use MDWorkbench to develop COTS services MDWorkbench
  4. 4. Why interoperate? Engineers are connected by a process. No engineers work alone, need for higher quality, more efficient communication, ability to do more with models (analysis, …) Project Ctrl Quality Mission Experts MDWorkbench & Test SE Process Design System Teams Architects
  5. 5. Document generation for completeintegration  Many tools, many domains implies several disconnected models  Each tools has a document generator but support only data from a considered tool (comparable to a metamodel)  Only documents could produce human readable summary of scattered modelisation  => We need a generic document generator from multiple model having different metamodel
  6. 6. How interoperate?  MDWorkbench is an Eclipse-based IDE for model-driven engineering to build:  Text generators (any kind - document or code)  Model transformers Models Models Code Word / OpenDocument MDWorkbench Projects Customizable rules and templates on multiple metamodels
  7. 7. How interoperate?  SODIUS interoperability approach is based on :  Separated approach between the data (I/O) and the required transformation ○ Connectors to access Applications + Interoperability Rules § Metamodels to abstract data model (instead of syntax views) No dependency to § Connectors to enable tools access in multiple, reusable ways context, can be used for § Rules/Templates for specific mapping other use cases (other tools, other formats) § Human readable (textual formats, docs) § Machine readable (models, data) Rules Export Capability to upgrade or add one specific « plugin » Applicatio n Rules § to handle metamodel changes Import § to handle framework changes § to handle format changes § to handle new applications or MMs & Rules APIs Pivot MDWorkbench Services are 100 % available through APIs Fully Deployable Outside Eclipse
  8. 8. Connecting ApplicationsThe MDWorkbench Catalog RSA/RSM MEGA MagicDraw Rhapsody Matlab Simulink System Architect DoDAF/NAF/UPDM SODIUS Statemate PLM Windchill UML / SYSML Tau PowerPoint DOORS WindchillNot exhaustive / RTC Visio ExcelNot close
  9. 9. New interoperability needs  Connecting different tools, different processes need a mechanism to aggregate data in an human readable format  Use document generation to present:  Summary of transformation  Data aggregation from disconnect processes  Specific point of view  Standardized documents (e.g. DoDAF, MoDAF, NAF views)
  10. 10. New interoperability needs  WYSIWYG (What You See Is What You Get) template  Use OpenOffice editor to define templates  Some reserved expressions are directives  Mechanism for expression resolution (such as model instance query)
  11. 11. SODIUS OpenDocument generatoreatures  WYSIWYG  Support of style (Title, Title1…)  Support of font (size, font, color, italic…)  Support of table  Generate iterative rows  Generate conditionnal rows  Conditionnal generation block  Static / Dynamic text
  12. 12. MDWorkbench facilities  Support of multiple metamodels  Large list of ready to use metamodels and connectors (the way we populate models)  Open to any new / custom metamodel (input format: Ecore, UML, XSchema)  Graph navigation facilities through SODIUS MQL language (Model Query Language)  List manipulation (select / collect / detect / reject)  Model exploration (model.getInstances(«Metatype»))  Load / save model easily (metamodel.createModel(); model.read(…), model.write(…))  Less test needed (some Exception are automaticly caught)
  13. 13. New language for graphmanipulation Collection features = cls.getFeature(); Collection names = new ArrayList(); Iterator i = features.iterator(); while (i.hasNext()) { Feature f = (Feature) features.next(); Java String name = f.getName(); if (name != null) { names.add(name); } } Primary goal: to allow the user to focus on the semantics of the MQL model transformation names = cls.features.name; instead of programmatic details
  14. 14. solate complex expression inscripts  Scripts  Extension of the metamodel (comparable to UML derived attributes)  Could be defined in  MQL: use the graph manipulation facilities for queries  Java: use Java power for all other treatments (e.g. String manipulation)  Scripts could also be used to reuse code  Complex condition
  15. 15. Demonstration
  16. 16. ntegration in Eclipse  Drag and drop facilities  Drag ad drop directives from a dedicated Eclipse view to OpenOffice (if, foreach…)  Expression / directive contained in the template is evaluated in MDWorkbench  Error are reported in Eclipse Problem view
  17. 17. OpenDocument vsWordML/OpenXML  Open document is a more opened/supported standard  Ensure perennity  Tool independant  Some free tools support OpenDocument (at least OpenOffice)  Required for some administrations  OpenOffice is supported by several platform  Windows  Mac OS  Linux
  18. 18. Strength and weakness  Multi metamodel supported in same template  Support of image/diagram in template  WYSIWYG template  Integration in Eclipse (early error detection)  But a little bit disconnected: no marker in OpenOffice  Flat formatting template => only one line => error line 2 whatever the errors  Drag and drop tool in Eclipse for the directives  Difficult to use => tool outside of OpenOffice  Large catalog of ready to use connectors for industrial tools
  19. 19. Future evolution  Development of an OpenOffice toolbar for MDWorkbench directive  Easy to define with some tool (using macros for example)  Demonstration  Errors highlighting in OpenOffice editor
  20. 20. Thank youQuestions? Paris Nantes New York SODIUS SAS SODIUS SAS SODIUS Corp. 1 Rue André Gide 2 impasse Joseph Marie Fourage 60 Broad St, Suite 3502 75015 Paris 44300 Nantes New York, NY 10004 France France USA Tel. : +33 (0)1 43 21 16 12 Tel. : +33 (0)2.28.23.60.60 Tel. : +1 (917) 727-3020 Fax : +33 (0)2.28.23.60.57 Fax : +1 (917) 210-4208

×