Docstoc

Features

Document Sample
Features Powered By Docstoc
					Feature Number       Elab Order     Actor   Size




                 1                15 EA     Medium




                 2                14 EA     Medium




                 3                  EA      Medium
4   11 EA   Medium




5     EA    Medium




6     EA    Medium




7     EA    Medium
 8   5 EA     Small

 9     EA     Medium




10     EA     Small




11     EA     Large




12   16 ESW   Small




13   17 ESW   Small




14   18 ESW   Medium
15   13 ESW   Small




16   1 ESW    Large


17     ESW    Medium




18   2 ESW    Large
19    ESW    Large




20   7 ESW   Large




21   3 ESW   Large




22   8 AW    Large
23    9 AW            Medium




24   10 AW            Large

25   19 AW            Medium




26   20 EA;#ESW       Medium
27      EA            Medium

28     EA;#ESW        Large




29    4 EA            Small




30     EA             Small


31   12 EA            Small




32    6 EA            Medium
33      EA;#ESW;#AW   Medium
34   EA            Medium

35   EA;#ESW;#AW   Large

37   EA            Medium
38   ESW           Medium
39   EA;#ESW;#AW   Medium
40   EA            Medium
41   ESW           Large
Completed Tasks




UI Prototype Proposed




UI Prototype Proposed;#Experiments;#Requirements Proposed
UI Prototype Proposed;#Requirements Proposed
UI Prototype Proposed;#Experiments;#Requirements Proposed;#Requirements Accepted




UI Prototype Proposed




UI Prototype Proposed




UI Prototype Proposed;#UI Prototype Accepted
UI Prototype Proposed;#UI Prototype Accepted




UI Prototype Proposed;#UI Prototype Accepted




UI Prototype Proposed;#UI Prototype Accepted;#Experiments
UI Prototype Proposed;#Requirements Proposed




UI Prototype Proposed;#Experiments




UI Prototype Proposed;#Experiments;#Requirements Proposed;#Requirements Accepted
UI Prototype Proposed;#Experiments;#Requirements Proposed;#Requirements Accepted




UI Prototype Proposed;#Experiments;#Requirements Proposed;#Requirements Accepted

UI Prototype Proposed;#Requirements Proposed;#Requirements Accepted




UI Prototype Proposed;#UI Prototype Accepted




UI Prototype Proposed;#UI Prototype Accepted




UI Prototype Proposed;#UI Prototype Accepted




UI Prototype Proposed
Assigned to      Documents   Content Type   Created         Created By




Adlan Israilov               Item            2/15/2009 15:07 Andrew O Mellinger




Mohit Bhonde                 Item            2/15/2009 15:12 Andrew O Mellinger




                             Item            2/15/2009 15:16 Andrew O Mellinger
Mohit Bhonde   Item   2/15/2009 15:20 Andrew O Mellinger




Mohit Bhonde   Item   2/15/2009 15:24 Andrew O Mellinger




               Item   2/15/2009 16:05 Andrew O Mellinger




               Item   2/15/2009 16:06 Andrew O Mellinger
Majid Alfifi         Item   2/15/2009 15:26 Andrew O Mellinger

                     Item   2/15/2009 15:27 Andrew O Mellinger




                     Item   2/15/2009 15:27 Andrew O Mellinger




                     Item   2/15/2009 15:28 Andrew O Mellinger




Adlan Israilov       Item   2/15/2009 15:41 Andrew O Mellinger




Adlan Israilov       Item   2/15/2009 15:42 Andrew O Mellinger




Andrew O Mellinger   Item   2/15/2009 15:43 Andrew O Mellinger
Andrew O Mellinger   Item   2/15/2009 15:49 Andrew O Mellinger




Andrew O Mellinger   Item   2/15/2009 15:51 Andrew O Mellinger


                     Item   2/15/2009 15:53 Andrew O Mellinger




Andrew O Mellinger   Item   2/15/2009 15:58 Andrew O Mellinger
                 Item   2/15/2009 15:59 Andrew O Mellinger




Mohit Bhonde     Item   2/15/2009 16:09 Andrew O Mellinger




Adlan Israilov   Item   2/15/2009 16:10 Andrew O Mellinger




Majid Alfifi     Item   2/15/2009 16:12 Andrew O Mellinger
Majid Alfifi         Item   2/15/2009 16:15 Andrew O Mellinger




Majid Alfifi         Item   2/15/2009 16:17 Andrew O Mellinger

Majid Alfifi         Item   2/15/2009 16:18 Andrew O Mellinger




Mohit Bhonde         Item   2/22/2009 10:15 Andrew O Mellinger
                     Item   2/23/2009 18:20 Andrew O Mellinger

Mohit Bhonde         Item   2/23/2009 18:38 Andrew O Mellinger




Andrew O Mellinger   Item   3/22/2009 10:57 Andrew O Mellinger




                     Item   3/22/2009 10:58 Andrew O Mellinger


Andrew O Mellinger   Item   3/27/2009 16:01 Andrew O Mellinger




Adlan Israilov       Item    4/9/2009 17:57 Andrew O Mellinger
Andrew O Mellinger   Item   5/28/2009 13:36 Mohit Bhonde
Mohit Bhonde   Item   6/26/2009 19:02 Mohit Bhonde

Mohit Bhonde   Item   6/26/2009 23:49 Mohit Bhonde

Mohit Bhonde   Item    7/14/2009 0:40   Mohit Bhonde
Mohit Bhonde   Item    7/14/2009 0:51   Mohit Bhonde
Mohit Bhonde   Item    7/14/2009 0:55   Mohit Bhonde
Mohit Bhonde   Item   7/22/2009 14:42   Mohit Bhonde
Mohit Bhonde   Item   7/23/2009 19:31   Mohit Bhonde
Description                                                                                       ID




The feature allows the Evolution Architect to bring Evolution Styles into the Evolution
Project. Documentation should be available.                                                            1




Evolution Styles accessible (loaded/configured) in the Evolution Project can be accessed from
a particular Evolution Diagram. Documentation should be available for the styles.                      2




The EA should have access to all style documentation while using the style. This includes basic
style documentation, constraint documentation, property documentation, etc.                            3
The EA will need to be able view and set all the properties of nodes (Acme instances) and
edges (transitions). This should include all attributes of the properties.
As with the Pangea tool, properties are related to a path. E.g. If there is a property cost and
the node was used by two path (p1 & p2) then the node would have two properties: p1.cost
and p2.cost.                                                                                       4




Properties will need to be available at higher levels than that of just nodes and edges. One
may wish to have a particular properties on a Path (such as name, totals, etc.), or other
higher level.                                                                                      5




The EA shall be able to configure the constraints provided by the included evolution styles.
The EA shall be able to set:

Enabled
(Whether or not the constraint executes)                                                          18
The EA shall be able to configure theAnalysis provided by the selected evolution styles. The
EA shall be able to set:

-Severity (starts with value provided by ESW0
-Enabled (starts as true)
                                                                                                  19
The EA will need to be able to run an analysis. As with the previous AETool the analysis will
be listed in a menu and the user will select Execute. The analysis will execute over all paths
and will provide its own output.                                                                  6
DUPLICATE of F8: Along with executing an entire Style, the EA will want to be able to execute
a specific analysis provided by a style.                                                          7




The EA shall be able to export (save, print) the results of an Analysis. See Feature 30 for a
discussion of Analysis Output.                                                                    8




Analysis may have complicated output, certainly more than true/false. Analysis will need rich
ways to provide information to the architect.                                                     9




The ESW shall be able to open existing evolution styles and edit them.                           10




The user shall be able to create a new ES.                                                       11




Evolution Styles can inherit from multiple styles, bringing in all attributes, constraints and
analysis. The ESW shall be able browser available styles (view documentation) and select
ones to add. The ESW shall also be able to remove added styles.
Each Evolution Style must inherit from a root style supplied by the tool.                        12
Each style shall have properties such as Name, Author, Base Documentation etc. The ESW
shall be able to set/modify these. Each style shall have a list of Acme or third party functions
it expects to use in constraint. [- What is this for?]

                                                                                                   13

The ESW shall be able to declare which properties that need to be accessed on each node or
transition. The property declaration shall include:

-Name
-Property Type (Integer, String, etc.)
-Default Value
-Description
-Domain (Node, Arc, etc.)
At times this has been referred to as the 'utility dictionary.'


                                                                                                   14

The ESW shall be able to be specify properties that are on each path, graph, or project. The
properties will have the following attributes: Name Type (Integer, String, etc.) Default Value     15


The ESW shall be able to define constraints across paths. They are applied to all paths.
Constraints shall have the following attributes:

-Name
-Label: Description displayed instead of constraint text.
-Constraint (DSL)
-Severity (Low, Medium, High)
-Static output message (see F30)
-Help - To be used in the help feature (Nice to have)

Validation is considered under Feature 20 which discusses validation and checking, however
interaction with visual elements will be described here as needed.
Constraints can in fact call external functions, which declaration should be contained inside
the evolution style (for checking purposes).

The current plan is to make a parser/grammar "smart" enough to allow embedded Acme
Rules. The rules would be extracted and passed to the Acme rule evaluator instead of
evaluating ourselves. Similarly, syntax coloring for that portion would be handled by an Acme
component. This is all supported by the PDE development.

http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/editors.ht
m
                                                                                                   16
Analysis are not actually included in the an Evolution Style. They are brought in separately.
                                                                                                  17

There shall be a style check/validator that will check the style to make sure that all required
assets are available. This includes,
1. That the all the properties needed by the constraints are available.
2. All the constraints are well formed (parsed for syntax check)
3. No duplicate property name is specified in the style. ?
4. Validate all the required ES elements are specified and have no contradictions...

e.g. source arch style must be defined...


While other features may need to do some validation, this feature contains all the
checking/validating requirements.                                                                 20




An ESW will need to be able to save/publish an Evolution Style.
This is classified as large because this also covers package definition.                          21




The AW shall be able to create a new analysis plugin.                                             22
Analysis Writers will need to specify what external properties (parameters) will need to be
provided. The property description should contain: Name Type (Integer, String, etc.) This is
part of the analysis definition.                                                                 23




Analysis Writers will work through the Java API to traverse the various domain objects
accessing properties and the like.                                                               24
Analysis Plugins will need to be packaged and published in a way that the ES Workbench and
AETool can access this.                                                                          25

An eventual goal of the project is to have 'transformers' defined by the ESW that the EA can
apply to their architecture. The purpose of the operators is to group a variety of manual
operations into a semantically meaningful group. For example, and ESW might have a 'create
hub and spoke'. When the EA performs this operator on a selected set of components, it
would create a hub component with adapter components and connect the selected
components to the adapters. The functionality of this is out of scope, but the architectural
design should take this into account.                                                            26
The EA may want to add informational properties to their elements.                               27
It would be nice for the ESW to be able to specify architectural transformers to assist the EA
in making semantically meaningful changes.                                                       28
When the constraint is defined a static error message can be specified. This message is
displayed when the constraint is checked and violated. Paths that have violated constraints
should be marked in red.


                                                                                                 29




Analysis must have some sort of basic output.
                                                                                                 30

The EA shall be able to evaluate the constraints again the current diagram. This should not be
confused with validating the constraint itself when it is being defined.                         31
There is a need to have a specific Evolution Project for holding all architecture evolution
diagrams and specific to the evolution information.

===
Currently to create evolution diagram EA has to have Acme studio project.                        32
                                                                                                 35
This is a feature enhancement for the paths handling on the diagram. We need to update the
legacy way to show paths. The client does not like the current way to go to the properties
view. Click on the paths tab and then select the path.

The client was wondering if we can show the paths from some sort of the context menus or
from the pallete                                                                              36
The client would like to migrate the AETool to Eclipse 3.5 with their planned migration for
Acme Studio to be migrated on 3.5                                                             37
New feature which was not considered before is being added to complete the installation
feature                                                                                       39
Just to track this as a scope or a req creeep                                                 40
                                                                                              41
This is the bulk of features that we are inheriting.                                          42
                                                                                              43
Implementation Options




Option 1
Since one of the options is to use Eclipse plug-ins to package and publish evolution styles, we
can utilize standard Eclipse interfaces to dynamically load plug-ins to the framework, search
for them in web and remove them if necessary.


====
It is expected that we can use the same functionality as that used by Acme studio.
1) Standard plugin architecture which implements and extends the evolution style plugin
interface.

2) The style is loaded when AETool references it. No activator needed

3) The plugin xml holds the configuration for the file

4) New style can be chosen as the legacy feature
4.1) Start new AED project (create name)
4.2) Loaded list of evolution style (with usage documentation)

5) Select ES

IMPLEMENTATION DETAILS:: EXTEND LEGACY AT THE FOLLOWING

package edu.cmu.archevol.diagram.part;
public class ArchevolNewDiagramFileWizard extends Wizard




This could be accomplished with such things as tooltips or a side panel that shows the current
documentation.
This should be the same as currently exists, except should have different attributes.
RAV: It should also include the attributes defined from the analysis, not only the evolution
styles that apply to the current context.

MDB:

Legacy:
Properties Pane

Proposed:
Over the graph elements (as just in place edits)
+ Legacy way
RAV: Make the AW responsible for providing the mechanism to export the results.


Maybe three basic options: 1. Table 2. Scatter Plot 3. JFrame
RAV: Provide a way for the Analysis writer to create new modal windows (possibly multiple
ones) that he can use to show/manipulate/export the results




Option 1:
ESW can use Eclipse 'Import as Plug-in' feature to open already existent evolution styles.


Option 1:
ESW will use Eclipse 'New Project' wizard to create a new Evolution Style Project.
This interface design has been lifted from Acme Studio. The goal is to be able to simplify
our work by copy-pasting (no via refactoring) existing implementations.




AOM: I have investigated a few different technology choices. such as ANTLR and
OpenArchitectureWare (oAW).
ANTLR is an automatic parser/lexer generator for developing custom grammars. It has a
development workbench 'Antlrworks' which makes it very easy and fast to develop the
grammar.
oAW is designed for MDD applications. The developer provides a meta-model and the toolset
creates parser, editor(!) and compiler. As oAW is intended for MDD development it was not
readily apparent how to generate something from the AST (e.g. imperative code). Their
examples were more model (declarative based) not imperative based.
1. validate is an option invoked from ESW workbench

2. validate is a multi step process
2.1 we perform various checks on properties first
2.2 we perform various checks on constraints

3 we will show a progress bar indication about the things being validated

4. result of validation will hold all errors in the standard Eclipse "Errors/Warnings" console

Option 1:
-Plugins will be automatically generated during runtime (possible, see Experiments) and
stored in one place (lets call it repository).
-Evolution styles will be packaged in JAR files.
 JAR files will contain three components described above: manifest file, plugin.xml and
activator class.
-Plugin.xml file will contain information about style (properties, contraints (DSL expressions,
name and etc.), basically the whole evolution style model)


Option 2:
Another possible option is to generate just pure jar file, which won't be plugged in Eclipse
framework and registeredy by IRegistry. However later it can be imported to evolution
project by EA and used as a library. (this option has not been investigated thoroughly enough,
which means I didn't try to actually code this part, but as far as I see from Eclipse
documentation it's also possible and could be less painful)

Which option we choose depends on a way we are going to apply evolution styles on
evolution diagrams.
For the most part the existing plugin system should support this without modification.




Do not have all necessary information to propose the implementation option




Proposal: A tab at the bottom to hold the analysis output.
Question for Majid, how can one create that?




Option 1:
EA can use Eclipse 'New Project' wizard (interface), which should be configured
(implemented) for our purposes.
Issues/Concerns
MDB: "Remove". part for this feature was not on a priority list for client if they want it at all.
But since it is reuse of AcmeStudio thingy we need to make sure it supports this part of the
feature MDB: Or does remove mean remove an applied evolution style on the evolution
project? MDB: Do we need the "Save" feature for all evolution projects.
AGI: Why we just not show all styles we have in our library as a list of tabs, which can be
unrolled by clicking on it (just like in Acme)? In case if this features implies downloading and
searching through web or even locally I guess we should explicitly state it in the description?
Just to make more clear and to avoid ambigiouty.
AOM: Adlan, I'm not sure what you mean by "library" of styles. THe point of this feature is to
get a style into the system (maybe library) from some external (like on-disk file). So the
question really is, how does one get styles into Acme. As regarding removal, the client never
mentioned it, but usually when an add feature exists, a remove feature exists.
RAV: I really don't think we'll be able to "reuse" that part of Acme, they suggested we
followed the same design but I didn't hear anything about reusing that code (It seems as one
of those things you wouldn't offer through the extension points). If we don't have the remove
thing it would be a hell to test this! I really think we need to dwelve deeper into how things




MDB: If remove means remove the evolution style from the currect project. Does it go here
to compliment the Add ES ?
AGI: 'Add' or 'Apply'?
AOM: As I understand it from the client, the project (the whole file) has a set of styles loaded
into it. Each Diagram can then choose which styles it uses. I used the term add because
"Apply" is generally an imperative term for "do it now" which could be construed as "execute
the style now." Add may not be the right term, it might be more like Select.
RAV: We have to discuss how changes on the diagram's style affect the elements in the
diagram. Also how changes on the project's styles change the diagram's styles. How does
Acme handle this? Are the styles per diagram or per project in Acme? <- This was clarified in
the domain model work
MAA: Acme has assign and unassign family. if a family is assigned to the project then it's
applied. ???

AGI: Do we want to make as a plain boring text or with pictures and such stuff? We
should understand how we are going to document information about constraints and
properties, using formal description or prose?

RAV: I really suggest making this a frame where a webpage can be put into. That is flexible
enough for the client's needs and I don't think it pays off to try and organize the information
of the style's element (since any change we make there is going to be reflected here) <---
Disregard this, thought this was about style documentation, not help
Legacy implementation has model extender which sources defaults and names from the
plugin configuration at run time and that it is not specified in the EMF model, it will be hard
to extend the model and provide a variation point for the es model




MDB: are you considering the meta properties... like "default", "completed", "settable",
"units".. i am not sure if in the EA scenario the property meta data is modifiable..
AGI: I think Andrew is talking about making Report calculations on the background and make
them always available as a "total" property of Graph for example. Is that what you were
saying? I also don't understand the difference between Project and Graph? I guess project it
is not something that we can see or touch inside the pallete. How can we assign properties to
it? And I think we should focus on Graph properties (evolution styles applied, all path names,
number of nodes, number of transitions).
AGI: Btw, guys when are making the comments be more explicit. Sorry, I didn't get you Mohit.
AOM: Mohit, I did not yet consider the meta-properties. I'm not really sure how they fit in,
and if we need them.
RAV: There is no indication on the domain model of paths, diagrams or projects having
properties on their own. This was actually discussed and no business case for it was found.

AGI: Does it mean that EA and ESW will share some of the functionality?

AOM: I'm not sure what you mean. The ESW will produce, and the EA will consume. The
ESW will mark constraints based on how they value their importance, but an EA can override
because they feel it is more or less important to their specific work.

RAV: From the domain model work, changing the severity is not possible. Deactivating checks
is still desirable.




RAV: From the domain work, analyses are configured at the project level in the same way as
the evolution styles (include/do not include). They are not configured at the diagram level (all
analyses defined for the project apply to all evolution diagrams inside it)
RAV: I think this is the way the analysis should be executed, not just an "additional" way to do
them
AGI: What kind of results?
RAV: From the domain model discussions, there is no way to tell if the results will have a
specific structure that can be exported or to what formats it would be appropiate to export it
to. This is for the analysis writer to decide depending on the specific analysis he intends to
implement.
This is a pretty open ended requirement. We need to evaluate the scenarios and make sure
they describe what sorts of visualizations we need.

RAV: From the domain model talks, results can have any structure and is up to the Analysis
writer to define it and how those results are managed.

AOM: So everything happen in Eclipse in a project. How do we package for editing an ESW. Is
it just a file? This is part of the packaging question. How are acme families packaged?

RAV: If I heard Bradley correctly the other day, it seems that families are just text definitions.
The thing is that families can rely upon code functions and other stuff and so many families
are "deployed" through a plugin that along with putting the definitions in the global
definitions part, also registers code modules with functions that are used in the constraints
part. We might be able to follow a similar solution.... it still feels weird because all our
analysis (code parts) are general to all styles.... so it makes more sense to just deploy them
separately and then configuring the linkage on each project by mapping input/outputs of the
analysis to properties in the styles of the project. <-- from the domain model work, analysis
are really separate entities from evolution styles. Their common point is that both can define
properties. Still, both analyses and evolution styles packages could potentially include code
(in the analyses case the result production, and in the evolution styles case the additional
technical functions for use inside constraints)
AGI: User is ESW?

RAV: This should be merged with the one about opening existing styles. Or are you expecting
dropping the other one?

This will need to be resolved with packaging. Do we embed the inherited style into the new
styles, or simple 'reference' it.
AGI: I would say that references might create increase latency, which is not good for us. Since
the actual use of ESs by EA is our destination goal it makes sense to slow down the process of
creation than application of the style. Adding might be easy, but removing could be more
painful, especially if two styles have the same names of attributes and so on. Btw, how should
we understand Inheritance term? Does it mean that children's properties and constraints will
override parents' properties and constraints?
AGI: As far as I know AETool define these properties inside of the extension point definition
throught the standard Eclipse plugin for creation a new extension point. The thing is you can
add any property there and add meta-properties to them. Pangea has not only "name, type
and default value", but "applied_element(node or transition), unit, is_path_dependent". I
don't know how can we reuse it or should we create something similar..

And also what is the differnece between Arc and Transition or it's the same?

-We need to resolve what to do with the Default portion when the base type changes.
Q: Nice to Have: In second version allow a large way to view the description.


RAV: From the domain model, this no longer applies since these items are not expected to
have properties




-Q:Will the constraint edit field be able to support the the syntax coloring/content assist as
we'd like?
-Q:(nice to have)Consider the new feature in acme for generating automatic constraints.
MDB: Need clarification. So by including analysis. Do we mean including analysis plugin? Who
writes the spec api for the external analysis plugin to conform? Do we have to make it
extensible to inlcude some third party plugins like e.g. COCOMO etc with possible
adaptation?
RAV: From the domain model work, there is no relationship between evolution styles and
analysis so this no longer applies. Instead choosing the appropiate analysis to include at the
project level should be developed.




Need info regarding the extent of this feature. Syntax checking is one aspect for properties..
How do we validate instace properties?
RAV: It is not clear how this relates with the syntax validation done when developing a
constraint. Is this related to being able to change the definition of properties or expected
external functions after having written (and validated) the constraints that used them?




AOM: Do we embed other styles, and used analysis? So how do we package and share these
things? As a file, plugin, etc.
AGI: I don't really know how Acme save their architectural styles, but Pangea created a
separate plugin for each ES. I guess someone will have to take a look at Acme's families more
closely.
RAV: I would strongly vote for these packages to be "self-defined". I'm also worrying about
the "versioning" of this and if these packages include code they should be "safe" as well.
From the domain work, an evolution style includes:

Name
Parent styles
Properties
Constraints
Initial Architectural Style
Final Architectural Style
Expected external functions
Documentation
The current AETool provides this. Is there anything new we need to do?
AGI: I think Pangea just created one simple cost-benefit analysis plugin. Our task is to create a
comprehensive API and document the actual guidelines.
RAV: I agree, our work should be extending the existing API and documenting it better. But
we should also work on how the Analysis Writter is able to define the properties needed for
that style to run.
AOM: Do we just put these into the plugin xml? This depends on the packaging.

RAV: We should probably re-formulate this feature to a list of the things the API should
support such as:
+ Model traversing: both at the evolution level and acme instances
+ Registering export options
+ Registering result mechanism
We can break it down into more features if the things in the list have different priorities.




RAV: This are now called "transformers" or "architectural transformers".




RAV: This are now called "transformers" or "architectural transformers"




AOM: Pangea tool builds a basic table for their output. I would expect that would be special
for the analysis. I would expect some sort of formatted text as the basic output. But where
does it go in the UI? Shall we have some sort of little window?




How much can we change in the problems dialog?
Does the new version of Eclipse have new version of EMF/GMF, will the migration cost be
heavy?
Modified          Modified By         Priority




  5/1/2009 15:55 Adlan Israilov       1-Must Have




  4/24/2009 0:35 Mohit Bhonde         1-Must Have




 4/12/2009 18:31 Andrew O Mellinger   2-Nice To Have
 4/24/2009 1:25 Mohit Bhonde         1-Must Have




5/18/2009 16:48 Mohit Bhonde         2-Nice To Have




4/12/2009 18:34 Andrew O Mellinger   2-Nice To Have




4/10/2009 14:56 Andrew O Mellinger   4-Abandoned
 5/6/2009 14:46 Majid Alfifi         1-Must Have

4/13/2009 18:50 Andrew O Mellinger   4-Abandoned




4/13/2009 18:58 Andrew O Mellinger   2-Nice To Have




4/13/2009 18:58 Andrew O Mellinger   2-Nice To Have




 5/1/2009 15:55 Adlan Israilov       1-Must Have




 5/1/2009 15:55 Adlan Israilov       1-Must Have




 5/6/2009 15:29 Andrew O Mellinger   1-Must Have
 5/6/2009 15:29 Andrew O Mellinger   1-Must Have




 5/2/2009 11:42 Andrew O Mellinger   1-Must Have


4/13/2009 18:53 Andrew O Mellinger   2-Nice To Have




 5/2/2009 11:32 Andrew O Mellinger   1-Must Have
4/12/2009 18:34 Andrew O Mellinger   4-Abandoned




4/24/2009 10:19 Mohit Bhonde         1-Must Have




 5/1/2009 15:55 Adlan Israilov       1-Must Have




 5/6/2009 14:47 Majid Alfifi         1-Must Have
 5/6/2009 14:50 Majid Alfifi         1-Must Have




 5/6/2009 14:59 Majid Alfifi         1-Must Have

 5/6/2009 15:01 Majid Alfifi         1-Must Have




 5/6/2009 15:29 Andrew O Mellinger   1-Must Have
 4/7/2009 18:53 Andrew O Mellinger   2-Nice To Have

 5/1/2009 15:49 Raúl Véjar           3-Enhancement




 5/6/2009 15:29 Andrew O Mellinger   1-Must Have




 4/7/2009 18:54 Andrew O Mellinger   4-Abandoned


 5/2/2009 11:43 Andrew O Mellinger   1-Must Have




 5/1/2009 15:55 Adlan Israilov       1-Must Have
5/28/2009 13:36 Mohit Bhonde         1-Must Have
 8/4/2009 21:19 Mohit Bhonde     3-Enhancement

6/26/2009 23:49 Mohit Bhonde     3-Enhancement

 8/4/2009 21:19   Mohit Bhonde   2-Nice To Have
 7/14/2009 0:51   Mohit Bhonde   2-Nice To Have
 7/14/2009 0:55   Mohit Bhonde   1-Must Have
7/24/2009 13:32   Mohit Bhonde   3-Enhancement
7/23/2009 19:31   Mohit Bhonde   1-Must Have
Questions For Client




Can you start with no or blank evolution style to start?
And then apply evolution style on a project without Evolution Style? Can you select a new
evolution style on a project with an existing Evolution style?
-What does it mean to 'include' functions? Were the functions to be exported as a
replacement for embedding them in constraints?
-If we have functions, should we just 'automatically' include the all the acme functions?




-Do we want to support meta-properties here?
-Do we support really need to support enum, record, sequence, set, other?




-Where the external functions come from? It is not clear if the ESW should provide the code
module or if the evolution style should just expect it to be present when executing the
constraints.
-At this point it looks as if we have no functions and should just call into Acme directly.
-Would it be okay to require 'bracketing' of acme rules with parenthesis, brackets, etc? (This
would simplify parsing.)
During some discussion with the client, when loading Analysis, it would be nice if the available
Analysis were presented in a tree view organized by category. TBD: How are categories
defined, and what do they mean?




What does it mean to validate a style? we need any style semantics check? or just internal
properties and constraints validation is ok?
Are you currently aware of any functions that are currently missing?




So what does it mean to keep an extension point? is it a plugin extension point? Is there any
sort of model we need to expose to the extension point? What Acme interfaces will be
exposed for this extension point?




Are we expected to mark a path that has a violation in the drawing? And if so, then what sort
of marking should there be.




1) Pangea's cost/benefit is a table. Is text sufficient for basic?
2) Where do we display it?




What is the value add of the Evolution Project?
Does the client have the feasibility support for Eclipse 3.5 for Acme Studio? Are there any
issues identified?
Title




Find/Load/Remove ES




Select Evolution Styles For Diagram




Help
View and Set Node and Arc Properties




View and Set Path/Diagram/Project/Analysis properties




Configure Constraints




Configure Analysis
Run Analysis

Execute Analysis




Export Analysis Results




Visualize (Rich) Analysis Results




Open ES




New ES




Configure Inheritance (Add/Remove)
Define Style Base Properties




Declare Node and Arc Properties


Declare Path/Diagram/Project properties




Define Path Constraints
Include/Configure Analysis




Style Checker / Validator




Save/Publish Style (Packaging)




Create new Analysis Plugin
Specify Analysis External Properties




Analysis Writer Java APIs

Package/Publish Analysis Plugin




Transformers Extension Point
Add new properties to Node/Arc [/Path/Diagram/Project]

Transformers




Constraint Output (Basic)




Analysis Output (Basic)


Evaluate Constraints




Create Evolution Project
Package & Install the AETool
Introduce a better interaction model for showing paths

Migration of the AETool to Eclipse v3.5

Uninstall evolution style and analysis plugin
Add function support for constraints definition
Property Types for ES and Analysis Properties
Pangea Leagacy Features
Add functions to support richer constraints
Use Case               Item Type




Select Styles          Item




Select Styles          Item




Review Documentation   Item
View and Set Evolution Style Properties   Item




                                          Item




Disable Constraints                       Item




                                          Item
Execute Analysis    Item

                    Item




Execute Analysis    Item




Execute Analysis    Item




Create/Open Style   Item




Create/Open Style   Item




Select Inherits     Item
Speciy Style Properties      Item




Specify Utility Dictionary   Item


                             Item




Specify Tech Constraints     Item
                  Item




                  Item




Publish Style     Item




Create Analysis   Item
Specify Required Properties                                                      Item




                                                                                 Item

                                                                                 Item




Specify Transformations                                                          Item
                                                                                 Item

Specify Transformations                                                          Item




Evaluate all Constraints / Check the conformance of project to evolution style   Item




                                                                                 Item


Show Non-Conformities                                                            Item




Create/Open Evolution Project                                                    Item
                                                                                 Item
Set Evolution Paths   Item

                      Item

                      Item
                      Item
                      Item
                      Item
                      Item
Path




requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List
requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List
requirements/Lists/Feature List

requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List
requirements/Lists/Feature List




requirements/Lists/Feature List


requirements/Lists/Feature List




requirements/Lists/Feature List
requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List
requirements/Lists/Feature List




requirements/Lists/Feature List

requirements/Lists/Feature List




requirements/Lists/Feature List
requirements/Lists/Feature List

requirements/Lists/Feature List




requirements/Lists/Feature List




requirements/Lists/Feature List


requirements/Lists/Feature List




requirements/Lists/Feature List
requirements/Lists/Feature List
requirements/Lists/Feature List

requirements/Lists/Feature List

requirements/Lists/Feature List
requirements/Lists/Feature List
requirements/Lists/Feature List
requirements/Lists/Feature List
requirements/Lists/Feature List

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:8/1/2012
language:Latin
pages:77