1 Mind Visual Diff An architecture comparison tool December 16 th, 2014 – v0.2.2 Seyvoz Stephane Assystem

2 Summary 1.Concepts & Usage 2.Behind the scenes…

3 Concepts & Usage

4 Mind-what ? >Diff: A tool for developers to compare documents >Text >Used between documents, or to view differences between commits of a source code repository, to create patches… >Mind (Visual) Diff >Text is OK but… -Needs time to read & understand changes, across multiple files >We like architecture visualizations !

5 For Who ? Why ? >Architects >Whiteboard vs Reality >Increments during development >Software updates >Product line differences -Linked to market(ing) demands >Difference measure  Re-use measure >Developers >Divide & Conquer development -Easier integration of individual parts >Already used to textual diff… -Should be consulted for feedback >Everybody Improved team communication !

6 Composition Sample Binding target change >Diff >Line per line >No semantics >S2 -> S2 seems changed -But wasn’t >S1 -> S1 becomes S1 -> S3 >Visual Diff Legend: Old – New – Type Change – No change

7 How ? >‘Mind-diff’ available in the Mind4SE nightlies since august 2014 >Expected first version in next stable release >Possible comparisons >Same repository, 2 applications mind-diff --src-path= –o Application1 Application2 >2 different repositories, same application mind-diff --base-src-path= --head-src-path=“srcdir2” –o Application >2 different repositories, 2 different applications mind-diff --base-src-path= --head-src-path=“srcdir2” –o App1 App2 >Note >Base = Old - Head = New >Open generated TopLevel.gv as usual with any ‘mindot-viewer’ version

8 Advanced features >Works with --flatten option >Global application changes - in one glance ! > >3 deleted components refined as 6 new components, 25 unchanged

9 Confidential Property of Schneider Electric Behind the scenes…

10 How: Plugin >A compiler-based tool >Contextualize target components (and their internals) in their respective repositories Visualization files C ADL ITF Mind Diff Mind compiler C ADL ITF GV Base Repo Head Repo Comp1 Comp2

11 Simple algorithm overview (Only Components shown as example, no Binding or Source or Interface) >Phase 1 >Load Base tree >Load Head tree >According to their respective repositories (context) >Phase 2 >Dual navigation >Full Result tree construction >Clone all old and new nodes -Decorated with old/new/changed info -Definition of “change”: Same instance name, with different type names -No content comparison / matching -Links still functional (click to Eclipse) -Latest info preferred on change >Phase 3 >Serialization with custom GV generator Base (Remote sensor) Head (Remote display) Boot c0 Proxy Com c1 Sensor c2 Buffer c4 Sender c5 Boot c0 Stub Com c1 Display c6 Buffer c4 Receiver c7 Result Boot c0 Sensor c2 Buffer c4 Sender c5 Display c6 Receiver c7 Stub Com c1

12 Additional details and Perspectives >Current limitations & Proposed solutions >If between Base and Head a same composite definition has the same name but different sub- components, bindings etc, the information is not shown at the upper level (only name change is checked !) -You have to click on every composite to know -Or generate the “flatten”-ed comparison for a quick overview -Could be implemented with new node decoration, and rendering color in upper level ? >Same for interface types (definitions) (only name change checked) >Output content and style are not separated in our GV format -No late change of rendering at runtime (style, information selection) -Result tree serialization designed to be replaceable -SVG (XML), -Synthetic textual report, -JSON… >Other perspectives >Use the diff class from Mindoc HTML documentation generator to show differences between super-types, children types, siblings types ? >Generate a as a legend for each step ? >Need an appropriat full “movie” of architecture changes along a project’s SCM history ? -Problem of root file possible changes -With commit message e renderer (web gallery ?)