<!-- 
	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:
	
	http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase
	
	Direct any questions about this template to emo@eclipse.org
 -->

<html><html>
<head>

<!-- 
	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.
 -->

<title>ArCon</title>
</head>

<!-- 
	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...
 -->
 
<style>
dt {
display: list-item;
list-style-position:outside;
list-style-image:url(/eclipse.org-common/themes/Phoenix/images/arrow.gif);
margin-left:16px;
}
dd {
margin-left:25px;
margin-bottom:5px;
}
</style>

<body>
<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="http://www.eclipse.org/forums/eclipse.proposals">Eclipse Proposals</a>
Forum.</p>

<h2>Background</h2>

<p>
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.
</p>

<p>
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.
</p>


<h2>Scope</h2>

<!-- 
	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.
 -->
  <p>
  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.
  </p>

<h2>Description</h2>


<!-- 
	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.
 -->
 <p>
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. 
</p>

<h4>What problem does ArCon solve?</h4>
<p>
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.
</p>
<p>
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.
</p>
<p>
The task of ArCon is basically split into two major activities:</p>
<ul>
	<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>
</ul>
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?
 -->
<p>
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.
</p>
<p>
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.
</p>
<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.
 -->
<p>
The initial contribution of ArCon would consist of the core codebase that can be viewed 
<a href="http://code.google.com/a/eclipselabs.org/p/arcon/source/browse">here</a>
and the ArCon documentation, design model and test models which can be viewed 
<a href="http://code.google.com/a/eclipselabs.org/p/arcon/downloads/list">here</a>. 
</p>

<p>
This code was developed within a group of commiters and is licensed under Eclipse Public License (EPL 1.0).
</p>
<p> 
<b>Overall design of the code</b>
<br>
At top level the project is divided into three packages:
</p>

<p>
<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.
</p>

<p>
<b>eArCon.applications:</b> This package contains the main class. It will make use of the other
classes to do the conformance check.
</p>

<p>
<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  
</p>
 
<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?
 -->
 <p>
 There are no known legal issues.
 </p>
 
<h2>Committers</h2>

<!-- 
	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>

<dl>
	<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>
	</dd>
</dl>

<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.
 -->

<h2>Mentors</h2>

<!-- 
	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
project:</p>

<ul>
	<li>Michael Scharf</li>
	<li>Wayne Beaton</li>
</ul>

<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>

<ul>
	<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>
	<li>Airbus</li>
</ul>

<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.
 -->
<p>
The ArCon project intends to have a first code contribution ready by June 1st, and 
hopefully the first builds to be ready soon therafter.
</p>
 
<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.
 -->

<table>
	<tr>
		<th>Date</th>
		<th>Change</th>
	</tr>
	<tr>
		<td>25-February-2013</td>
		<td>Document created</td>
	</tr>
</table>
</body>
</html>