Transcript Final Presentation

Development of a visual studio
plugin to visualize a
Blocks-Graph
Students: Alex Tarasiuk , Alex Gorodetsky
Supervisors: Adam Levi
Definitions
 Block - Logical part of an application structure. A block can
contain services, configurations, event kits, and endpoints. Each Block can interact with another blocks
through services by consuming/publishing them.
 Blocks Graph - A data structure (extracted by Helper
library) that contains a collection of blocks metadata.
 Helper library – A tool developed by Microsoft that can
extract Block metadata from internal libraries.
 DGML - An XML-based file format for directed graphs.
Goals
Build a plug-in for Visual Studio 2012 that utilizes the blocks
metadata to visualize the graph in a developer friendly
manner.
 Getting acquainted with Helper Library, Visual Studio SDK,
DGML Interface (GraphModel API).
 Defining Block Graph structure.
 Design and implement a GUI.
 Using GraphModel to visualize the Blocks as a directed graph.
 Integrating the functionality to Visual Studio 2012 (using Visual
Studio SDK).
Work Flow
GUI
DGMLGraph
Create Data
Structure
representing the
Blocks Graph
DGML
DGML
Blocks Graph
Visualized
Used Technologies
 C#
 XML(VSCT, XAML,DGML)
 Visual Studio 2012 SDK
 Visual Studio GraphModel API
Methodology
 Extending the Visual Studio IDE
 In order to extend the IDE (integrated development environment),
we use the Visual Studio SDK tools that helps you develop your
own applications that extend the IDE and integrate seamlessly with
it.
Methodology
 The concept of software
application is absent. Instead, the
IDE hosts software components,
called VSPackages, that provide
application functionality.
 This functionality, in turn, is shared
across the IDE as services.
VSPackages offer services that
they and other VSPackages use.
Methodology
 Therefore we,
 Define our Toolbar
 Adding Commands, to the
toolbar, with suitable
handlers to our
Service(Package)
 Define our Package
 Connect our Toolbar to it
Methodology
 Our package extends the
Shell.Package class.
 The commands are defined in a
VSCT file, XML-based file format
that defines the actual layout and
type of the commands.
 Then we link them to our service
with suitable handlers.
 The result:
Methodology
 The GUI, presented above, analyzes the users choice and acts
accordingly.
 Each graph that is created/loaded has a List of loaded internal
libraries.
 Only one graph can be presented at a time.
 Keep the toolbar concurrent with the presented graph.
 Protect the user from harmful behavior.
Methodology
 Blocks-MetaData (BMD)
BMD contains the following information (some of the data is not obligated) :
block type, block consumed services, block published services, blocks source
location, configuration (a set of used variables) and more..
 DGMLGraph
Responsible for converting assemblies metadata into a graph and modify it.
 An assembly loaded into DGMLGraph instance will be analyzed by the helper
library in order to extract BMD for each block in the assembly. This
information will be used to create a dependency graph from the
blocks were each node is a block (including it’s properties) and
each directed edge will represent a dependency between two
blocks.
Methodology
 DGMLGraph (cont.)
 Block A depends on Block
B if Blocks A consumes a
service which Block B
publishes.
 Building the graph:
When a new assembly is loaded into DGMLGraph instance, we create a
node for each block. Also we will keep 2 extra lists of blocks. One is for
nodes with consumed service (Consumed List), and the other is for
nodes with published services (Published List).
Methodology
 DGMLGraph (cont.)
 Building the graph (cont.):
In order to add the edges between the nodes, we do the following:
 For each node in Consumed List
 Find a block in Published List, which publishes the requested service.
 If a match was found, add an edge. Otherwise do nothing.
By doing so, we make sure that if a block with consumed service was
loaded and there is a block (which was loaded into the graph at some
point) which publishes the required service, there will be an edge
between them.
Methodology
 DGMLGraph (cont.)
 Graph Model API (in VS2012)
We chose to use Graph Model since it already integrated into Visual
Studio and it creates and manages all the elements we need in dgml.
 Deployment Scenario
 Easy plug-in installation into VS 2012 using the VSIX, VS Extension
Deployment.
Demo
Time!
Completed Goals
Data Structure design
Generation of a graph using DGML
GUI and graph integration into VS 2012 framework
Graph modification by user
Hide/unhide blocks, view blocks content, change graph
layout, load/unload assemblies, save/load/export view
Graph Save/Load ability
A Plug-In with easy deployment scenario
Documentation
Conclusion
 From the beginning we tried to use Graph-Sharp to create the graph,
we found it unintuitive and we ran into a lot of issues integrating it
into Visual Studio. Our conclusion from this experience is that we
should do a wider research.
 We must make sure we understand the goals properly, since only in
the midway meeting we learned some crucial information about the
project.
 Visual Studio SDK is very complex, and the documentation lacks in
code examples.
 We have found that dividing the requirements into several parts,
makes the work more efficient and gives the possibility to work
simultaneously.
Questions?