Experiments by liamei12345


									ID     Assigned To      Feature

     2 Mohit Bhonde     Save/Publish Style (Packaging)

     3 Adlan Israilov   Save/Publish Style (Packaging)
4 Majid Alfifi         Declare Node and Arc Properties

5 Andrew O Mellinger   Define Path Constraints

6 Majid Alfifi         Create new Analysis Plugin
 7 Majid Alfifi     Specify Analysis External Properties

 8 Majid Alfifi     Analysis Writer Java APIs

 9 Mohit Bhonde     Select Evolution Styles For Diagram

10 Adlan Israilov   Save/Publish Style (Packaging)

11 Mohit Bhonde     Transformers Extension Point

To understand how ES properties and constraints can be applied over AED project and how
AETool stores them inside AED.
This means that we apply a newly packaged (including properties, constraints) on a new
evolution diagram.
The purpose was to finalize the new Evolution Style plugin model and ensure that the
constraints can be packaged and applied

To understand whether we can use plugin extension points provided for us by Pangea.

AETool currently consists of several plugins. To create Architecture Evolution project we need
to include(integrate) all these plugins into Eclipse, so that we need to run new Eclipse
instance which will include them as a part of Eclipse.
Possible problem is that Pangea implemented Evolution Styles as plugins (trying to make it
more extensible?) and in order to create a new evolution style we have to create a new
plugin and then run a new Eclipse instance again.
For our part we need to provide redistributable version of AETool and we can't afford
creation of a new version of AETool every time ESW creates a new Evolution Style. Plugins
either should be created dynamically and included dynamically in AETool or we should try
some other approached.
To understand UI capabilities of SWT
To use as a base for estimation future experiments and implementations in summer

OpenArchitecureWare is a MDD-oriented DSL generation/editing platform for eclipse. It is
intended to allow one to design a meta-model (like for entities) and get a parser, editor and
compiler for that language. The compiler can then generate back java model classes for that.
However it was not clear how to generate code for a traditional set of code (like an
expression) and if this would be applicable to the constraint DSL.

The purpose of this experiment is to determine what the steps required to create a new
analysis plugin and how to do that. This is also to investigates how the results of analysis are
Determining how to provide external properties support.

To know what the are the current services provided by the analysis api and what are the
extensions needed.

To check the wizard capability of the legacy AETool, for rich documentation purpose

To understand whether it's possible or not to do it in Eclipse, because it might be necessary
for that feature.
The purpose of this experiment is,

1. To find out the model for transformation
2. To find out if plugin is a correct way to get this extension point
3. To find how to access acme interfaces needed for transformation

1. Find out how to add new properties to Evolution Style and how AED stores it in the model.
2. Repeat same procedure for the constraints.
3. Test whether constains and properties properly displayed and editable through the
graphical panel of AETool.

1. Understand how Eclipse includes plugins
2. Understand how Eclipse generates plugins
3. Try to find alternative way of creating ES (just XML files?)
4. Coordinate with Mohit considering application of ES over AED to understand how difficult
it is to replace plugins with XML files or something else, such that AETool won't lose current
1. Find out how to build the ui using SWT
2. Coding the ui following that standard
3. Wiring up correctly
4. Writing a test
5. Field Validation (lenght, numrical, pop ups)
6. Find out how much time it takes to (check in/check out)

Follow a process similar to the oAW tutorial but make a simple calculator to be able to
evaluate expressions such as 4 * 5, ((4 + 2) * 2), etc.

using the current AETool, identify how the current example analysis is done and create a new
similar analysis. keep data about time needed for teh differnet tasks that are found to be
Currently the tool has an API that provides properties from arcs and nodes in the system. The
Analysis needs it's own properties. The purpose of this experiement is to determine how
those external properties are represented and how will this affect the current API library.

First see how the current AETool uses the API and how did they extend when they needed to
provide support for analysis. Then list things that are needed but missing in the API

Find the legacy code.

Associated feature for 2 "Select new evolution style..." (EA scenario)
Basically try to do all following things:

1. Generate java code from java source files.
2. Compile that generated source
3. Archive that file to a JAR file
Exit Criteria

Experimenter understands how to architecture evolution project stores applied evolution
style with corresponding properties and constraints.


Experimenter finds out that it's not feasible.


Results are thoroughly documented.

All 4 points explored and results are thoroughly documented.
1. Experimenter understands all the ui components used
2. Results documented (+estimation data)

When the above calculator is implemented, or is determined unfeasible and an
understanding of how long it will take.,

1. the existing analysis is understood
2. a new example analysis (ExpAnalysis) is created and steps documented
3. the presentation of the results is understood and documented
1. at least one approach to manage external properties is determined and documnted.
2. a decision on if the current API can support these extra properties and if a change is
needed and what is this change going to be.

1. A list of existing api functionalities is determined and documnted.
2. A list of new functionalities that need to be supported is determined and documented.
1) Find the legacy code
2) Identify the new generation point
3) Add a new text field to the wizard which choose a dynamic text

All three areas of experimented investigated. Not necessarily implemented completely.


Result: The approach seems usable, with issues identified

1.Does not have to change the Evolution Style model for constraints. Properties are
modeled as eclipse plug-in properties and not in the model. This might be a redesign point for
the legacy AETool for properties
2.The plug-in xml was used for configuring the ES Plug-in. See configuration below
3.The ModelExtenderImpl creates all the maps for properties and can be used for
constraints and potentially operators
4.No linkage to ecore model (EMF/ GMF) model was found yet
5.The configuration for plug-in xml can be changed and interpreted in AETool. This stands a
basis for feature 21 for the EA Scenario that when the new ES is to be applied, this
configuration of the model will come from the ES plugin

There are some issues identified with respect to possible legacy code change. But the feature
is evaluated as usable. The model extender might inhibit modifiability to the new evolution
style model
1. From v3.0 Eclipse moved to a new platform, OSGi framework, which allows it to create,
load and register plugins dynamically. In OSGi language we can simply call plugins as

2. To generate the plugin we need three major components:
-activator class, which is responsible for running and stopping plugin.
-manifest.mf file, which contains information about Eclipse version, OSGi version, activator
class and names of libraries, which plugin is dependable on.
-plugin.xml file, which contains such information like 'extension point' and in our case
properties and constraints for evolution styles.

Another important thing is naming of plugins. If we create plugin in Eclipse it will
automatically assign name and version to it, however in our case if we are creating plugin
manually we need to track version of plugins. Example of plugin naming:

Points 3 and 4 are not more relevant.

-Automatic generation of plugins in Eclipse is possible.
-Evolution styles will be packaged in JAR files.
-JAR files will contain three components described above: manifest file, plugin.xml and
activator class.
There are straightforward ways to create the following:
1. A table with configurable header and columns
2. Each cell in the table can be editable or not
3. A pop up menu that appears when clicking anywhere in the table with any list of actions
4. Actions that can be linked to menu items or buttons or check boxes on the table
I estimate it will take 1.5 hours to create a table with the following:
  1. 4 columns
  2. data source already available and ready to be hooked to the table
 3. a button or a pop menu item to add a new row
 4. code that makes the addition
I am excluding from this estimation the time needed to write validation and testing
SWT/JFace in Action by Manning

A calculator or other imperative type thing can be constructed. However, as it was designed
for model based design, this example might not be the best. Further design experiments
should be pursued before a decision is made.

To create a new analysis plugin follow the following steps:
1. create a new plugin.
2. open plugin.xml and provide a name and id
3. in dependencies add the following:
4. in extension point add edu.cmu.archevol.diagram.evolutionPathAnalysis which was
designed by Pangea
5. create four classes in src folder as follows:
   Activator: this is auto-generated to start the plugin
   PathAnalysis1 this extends IPathAnalysis as provided in the extension provided by Pangea
   AnalyzeAction this extends Action and is called from the PathAnalysis1 class. This class has
the logic for doing the analysis. It uses API functions from the AnalysisHelper to get arc and
nodes from the model
   ResultDialog. this uses SWT features to present the results. It's called from AnaylizeAction
and a list of details to view are provided when created. It maybe cumbersome to write this
class because of the many details needed to draw the diagram.
Getting those external properties from users won't affect the current workings of the system.
Normal input dialogs from swt could be used.
The AETool has one class (AnalysisHelper) which is part of the edu.cmu.archevol.diagram
plugin. This is the only point of access to the AE Model. The following services are provided by
this class:
  1. getArchitectureEvolution() which returns an object representing the model in the AETool.
basically using this one can reterieve any object needed from the model as this object
contains almost the whole model
 2. getArchitecutreInstances() which gives a list of all instances in the diagram
 3. getTransitions() which returns all transitions in the diagram.

After getting the architecureInstance for example the analysis will get the proerties needed
from the object to perform the analysis at hand.

To add new functionality one can extend this AnalysisHelper class although i expect this to be
rarely needed.

All three operations are possible in Eclipse using one of its libraries, Java Development Tools
(JDT) and packaging can be done in various ways. One of the possible options for packaging is
passing a command line to Runtime.getRuntime().exec("jar ... ") function.


There are some issues identified with respect to possible legacy code change. But the feature
is evaluated as usable.

It is possible to load plugins to Eclipse, but I have had a hard time to do it, because of lack of
documentation and time.
see http://msesrv4e-
for static design
see http://msesrv4e-
for static view of the design

CONFIRM WITH CLIENTS: how to get values for properties from the evolution style? do we
ask the user to enter them agian or use values already provided.
Currently the the AETool has the conept of evolution style with properties and an analysis
that says I am using this style and use properties from the style to calculate analysis.

Compilation has not been done, but that shouldn't be an issue, because Eclipse provides a
built-in compilator plus we should probably be able to use JDT's compilation unit.

Content Type   Created           Created By      Modified         Modified By

Item             3/27/2009 3:45 Adlan Israilov     5/1/2009 15:53 Raúl Véjar

Item             3/27/2009 4:06 Adlan Israilov     5/1/2009 15:55 Raúl Véjar
Item   3/27/2009 12:13 Majid Alfifi          5/1/2009 15:47 Raúl Véjar

Item   3/29/2009 13:54 Andrew O Mellinger   4/12/2009 18:38 Andrew O Mellinger

Item   4/13/2009 15:26 Majid Alfifi          5/1/2009 15:34 Raúl Véjar
Item   4/13/2009 15:34 Majid Alfifi      5/1/2009 15:36 Raúl Véjar

Item   4/13/2009 15:43 Majid Alfifi     4/24/2009 15:35 Majid Alfifi

Item    4/24/2009 0:31 Mohit Bhonde      4/24/2009 0:32 Mohit Bhonde

Item    4/24/2009 4:54 Adlan Israilov    5/1/2009 15:55 Raúl Véjar

Item   4/24/2009 10:33 Mohit Bhonde     4/24/2009 10:33 Mohit Bhonde
Title                                                                                     Item Type

Applying Evolution Style properties and constraints over Architecture Evolution Diagram   Item

Automatic generation of Eclipse plugins                                                   Item
Creating a table view for declaring Arc and Node properties   Item

OpenArchitecureWare constraint compilation                    Item

Investigate Creating a new Analysis Plugin                    Item
Investigate how to extend the current AETool so support Analysis properties   Item

Invistigate the capabilities of the current analysis API                      Item

Check wizard for selecting new evolution style with documentation             Item

Automatic generation, compilation and packaging of java source files to JAR   Item

Transformers Extension point experiment                                       Item









To top