| <!-- |
| 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ö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örn Lundell, University of Skö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> |