The ArCon project is a proposed open source project under the PolarSys Container Project.
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 Eclipse Proposals Forum.
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.
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.
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.
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ö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:
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.
This code was developed within a group of commiters and is licensed under Eclipse Public License (EPL 1.0).
Overall design of the code
At top level the project is divided into three packages:
backboneCode: 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.
eArCon.applications: This package contains the main class. It will make use of the other classes to do the conformance check.
rulePackage: 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
There are no known legal issues.
The following individuals are proposed as initial committers to the project:
We welcome additional committers and contributions.
The following Architecture Council members will mentor this project:
The following individuals, organisations, companies and projects have expressed interest in this project:
The ArCon project intends to have a first code contribution ready by June 1st, and hopefully the first builds to be ready soon therafter.
Back to the top