blob: 53557909988e55d2bf61f0b42d9bfd651fe48f9b [file] [log] [blame]
This document is provided as a template along with some guidance for creating
your project proposal. This is just a template. Feel free to change it as
you see fit (add sections, remove section). We feel, however, that the
suggestions represented in this document represent the reasonable minimum
amount of information to move forward.
Please keep the formatting in this document simple. Please do not edit
this document in Microsoft Word as it adds huge piles of markup that make
it difficult to restyle.
More information is available here:
Direct any questions about this template to
Include the title here. We will parse it out of here and include it on the
rendered webpage. Do not duplicate the title within the text of your page.
We make use of the 'classic' HTML Definition List (dl) tag to specify
committers. I know... you haven't seen this tag in a long while...
dt {
display: list-item;
dd {
<p>The ArCon project is a proposed open source project under the PolarSys Container Project</a>.</p>
The communication channel must be specified. Typically, this is the
"Proposals" forum. In general, you don't need to change this.
<p>This proposal is in the Project Proposal Phase (as defined in the
Eclipse Development Process) and is written to declare its intent and
scope. We solicit additional participation and input from the Eclipse
community. Please send all feedback to the
<a href="">Eclipse Proposals</a>
Work with architectural validation of a system model can be a tedious work and
unless you are very meticulous, it is easy to make a mistake, espacially if it is
a large system.
With the help of ArCon, the system architect doesn't have to check every version
of the system model against the architectural rules to see if the system model is
following the predefined rules.
Instead, the developer can use ArCon to automatically check if the system model is conforming to
the architectural rules.
This way the project is saving money and time with the conformity check, and is
avoiding possible mistakes from manually checking.
All projects must have a well-defined scope. Describe, concisely, what
is in-scope and (optionally) what is out-of-scope. An Eclipse project
cannot have an open-ended scope.
ArCon is integrated with Eclipse and supports model developers in following given
architectural rules for the developed system. ArCon interprets an architectural metamodel,
created in UML, and extracts rules. The extracted rules are applied in an analysis of the
developed system model. ArCon currently supports the developer in a reactive way resulting in
a list of issues presenting violations to the rules. The scope also includes a
proactive way of supporting the developer by presenting only allowed options when adding
new elements and element properties. ArCon utilizes the Eclipse GUI and target modeling
tools/editors are for now Papyrus and Topcased.
Describe the project here. Be concise, but provide enough information that
somebody who doesn't already know very much about your project idea or domain
has at least a fighting chance of understanding its purpose.
ArCon is a tool for architecture conformance validation of systems modelled in UML/SysML.
ArCon provides an easy to use and intuitive way of specifying architectural rules and
a mechanism to automatically validate that the system under development conforms to the
rules specified. ArCon validates a model and detect errors in the model breaking predefined
rules. ArCon is primarily intended for, but not limited to, products of high complexity
and/or subject to long term maintenance needs.
<h4>What problem does ArCon solve?</h4>
The traditional process (in architecture driven development) starts with the definition of
the architecturally significant requirements; these are essentially the quality and
non-functional requirements. The architect undertakes the architectural design with
addressing the architecture requirements. Essentially the architect makes a number of
decisions on how the system should be designed in order to ensure that architectural
requirements are fulfilled. The results is typically a high-level structure of the
system, a framework of base-classes implementing the communication infrastructure
of the system, and a set of structural and behavioural rules to follow in the design
the components that populates the system model. The high level structure and the
framework goes into the system-model and the rules are specified in a textual document.
During the architectural design, the architecture is regularly validated against the
architecture requirements and if necessary the requirements are renegotiated. When the
architecture has been validated against its requirements, the next development phase
begins. In this phase the system is developed in a number of increments with increasing
functionality. Each development increment begins with a definition of the requirements
to be implemented in the increment. Each development team then does a preliminary
design defining how the required functionality is allocated to new and existing
components according to the architectural design rules. Before the development team
is allowed to start the detailed design of the components, the preliminary design must
pass the architectural review. In the architectual review the architect checks that the
design does not violate the architectural design rules. During preliminary design and
detailed design the architect supports the development teams and guides them in how to
follow the architectural design rules. If any problems with the architecture revealed
during preliminary design necessitate changes to the architecture, these changes are
done by the architect in parallel with the development work.
The problem with this process is that manual enforcement of the architectural design rules
takes a lot of time from the architect. This makes architectural enforcement a bottleneck
in MDD projects that leads to a plethora of problems.
To address these problems the method to model architectural design rules that is supported
by ArCon has been developed by Combitech with support from researchers at the University
of Sk&ouml;vde and the University of Limerick. Using this approach we get a process where the
manual architectural reviews are eliminated.
This removes the architect as a bottleneck in the development and increases significantly
the amount of time available for guiding the teams. Anther difference is that the
architect models the architectural design rules instead of expressing them as informal
text which also increases the quality of the architecture and makes it simpler to communicate.
The task of ArCon is basically split into two major activities:</p>
<li>Read the architecture meta model pointed out from the system model and interpret the
expressed rules.</li>
<li>Read and traverse the system model which shall conform to the rules and analyse
conformance. Report detected violations to the developer.</li>
The report is presented in the console window but shall also be indicated by markers in
the model browser or diagram.
<h2>Why Eclipse?</h2>
Answer these two questions: What value does this project bring to the Eclipse
community? What value do you expect to obtain from hosting your project at Eclipse?
What value do you get by having your project at Eclipse over and above the value
of hosting at Eclipse Labs?
Open source tools in general and Eclipse based ones in particular are becoming more and
more interesting solutions for many companies, large and small. ArCon was originally
developed to operate with a commersial modeling tool, but in pace with increasing
capability of Eclipse based UML/SysML modeling, such as Topcased/Papyrus, the opportunity
to provide a fully open source based tool chain within the scope of Polarsys has become
interesting. The task of automatic architecture conformance validation of systems developed
in UML (or SysML) against rules expressed in UML has not been concretely adressed before
in Eclipse. The easy to to understand rules (for UML familiar developers) will broaden the
offer of Eclipse to the user community.
As companies now are getting interested in using ArCon they would be more comfortable with
the long term ambitions and sustainability of ArCon if it is adopted and hosted by Eclipse.
Some companies se Eclipse affiliation as a demand for start using an open source tool seriously.
ArCon will be more visible and it will increase the possibility to build both user and developer
communities around it.
<h2>Initial Contribution</h2>
Projects are expected to arrive at Eclipse with existing code.
Describe the existing code that will be contributed to the project. Please provide
a couple of paragraphs describing the code with modest detail, including important
information like code ownership (who holds the copyright?), and some consideration
of community that exists around the code. Include a listing of third-party libraries
and associated licenses.
The initial contribution of ArCon would consist of the core codebase that can be viewed
<a href="">here</a>
and the ArCon documentation, design model and test models which can be viewed
<a href="">here</a>.
This code was developed within a group of commiters and is licensed under Eclipse Public License (EPL 1.0).
<b>Overall design of the code</b>
At top level the project is divided into three packages:
<b>backboneCode:</b> This package contains classes that are used to extract and traverse
the UML models, or store the information about
which rules that applies to which element for the conformance check and in the end reports it all
to the user via the Eclipse GUI. The report is prepared by traversing the system model elements
to see if they deviate from the rules.
<b>eArCon.applications:</b> This package contains the main class. It will make use of the other
classes to do the conformance check.
<b>rulePackage:</b> In this package, classes are oriented towards the differnt steps in the conformance check
of the system model. It's everything from defining the parameters used to specify the rules for
each UML element to later validating the the system model against the rules from the achitectural model
<h2>Legal Issues</h2>
Please describe any potential legal issues in this section. Does somebody else
own the trademark to the project name? Is there some issue that prevents you
from licensing the project under the Eclipse Public License? Are parts of the
code available under some other license? Are there any LGPL/GPL bits that you
absolutely require?
There are no known legal issues.
List any initial committers that should be provisioned along with the
new project. Include affiliation, but do not include email addresses at
this point.
<p>The following individuals are proposed as initial committers to the project:</p>
<dt>Gert Johansson, Combitech (lead)</dt>
<dt>Anders Mattsson, Husqvarna (lead)</dt>
<dt>Johan Norberg, Combitech</dt>
<dt>Emil Fridell, Combitech</dt>
<dt>Carl-Oscar Varnander, Combitech</dt>
<dt>Leila Azari, Combitech</dt>
<dt>Rikard Soler Avellen, Combitech</dt>
<p>We welcome additional committers and contributions.</p>
Describe any initial contributions of code that will be brought to the
project. If there is no existing code, just remove this section.
New Eclipse projects require a minimum of two mentors from the Architecture
Council. You need to identify two mentors before the project is created. The
proposal can be posted before this section is filled in (it's a little easier
to find a mentor when the proposal itself is public).
<p>The following Architecture Council members will mentor this
<li>Michael Scharf</li>
<li>Wayne Beaton</li>
<h2>Interested Parties</h2>
Provide a list of individuals, organisations, companies, and other Eclipse
projects that are interested in this project. This list will provide some
insight into who your project's community will ultimately include. Where
possible, include affiliations. Do not include email addresses.
<p>The following individuals, organisations, companies and projects have
expressed interest in this project:</p>
<li>Dominique Toupin, Ericsson</li>
<li>Ronan Barrett, Ericsson</li>
<li>Andreas Jakobik, Ericsson</li>
<li>Patrik Nandorf, Ericsson </li>
<li>Stefan Grufman, Husqvarna</li>
<li>Bo Hagerf, Combitech</li>
<li>Erik Herzog, Saab</li>
<li>Henrik Andersson, Saab</li>
<li>Jonas Andersson, Volvo</li>
<li>Tobias den Braver, Saab EDS</li>
<li>Bj&ouml;rn Lundell, University of Sk&ouml;vde</li>
<h2>Project Scheduling</h2>
Describe, in rough terms, what the basic scheduling of the project will
be. You might, for example, include an indication of when an initial contribution
should be expected, when your first build will be ready, etc. Exact
dates are not required.
The ArCon project intends to have a first code contribution ready by June 1st, and
hopefully the first builds to be ready soon therafter.
<h2>Changes to this Document</h2>
List any changes that have occurred in the document here.
You only need to document changes that have occurred after the document
has been posted live for the community to view and comment.
<td>Document created</td>