1

Mind Visual DiffAn architecture comparison tool

December 16th, 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

> EverybodyImproved team communication !

6

Composition SampleBinding 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=<srcdir> –o <outdir> Application1 Application2

> 2 different repositories, same application

mind-diff --base-src-path=<srcdir1> --head-src-path=“srcdir2” –o <outdir> Application

> 2 different repositories, 2 different applications

mind-diff --base-src-path=<srcdir1> --head-src-path=“srcdir2” –o <outdir> 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 !

> < Removed diagram: Internal use only>

> 3 deleted components refined as 6 new components, 25 unchanged

9Confidential 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 filesC

ADL

ITF

Min

d D

iffMind compiler

C

ADL

ITF

GV

BaseRepo

HeadRepo

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)

Bootc0

ProxyComc1

Sensorc2

Bufferc4

Senderc5

Boot c0

StubComc1

Displayc6

Bufferc4

Receiverc7

Result

Bootc0

Sensorc2

Bufferc4

Senderc5

Displayc6

Receiverc7

StubComc1

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 appropriatfull “movie” of architecture changes along a project’s SCM history ?- Problem of root file possible changes- With commit message e renderer (web gallery ?)