The purpose of this How-To doc is to explain how to import Architecture Checker models into AIP Console and to use them to detect application structural flaw.
The different actions presented explained here have been done with AIP Console 1.9.0.
As an Application Owner you on-boarded an application in AIP Console and you want to control check if the software architecture that has been designed by Software Architects is respectedfollowed. This can be done by using Architecture Checker and, for that, you must have analyzed a version (and generated a snapshot) and you need an architecture model.
Software Architects may have one that corresponds to the software architecture to be verified. If not, then a new one can be created with the client-server version of Architecture Checker since as it is not yet possible to do that in AIP Console.
Import an Architecture Checker model
To import an Architecture Checker model in AIP Console.
- Go to the application Config page
- Click the ARCHITECTURE tab. The displayed page shows the models that might have been previously uploaded.
To add a new model to that list, click the button. A file selection dialog opens and lets you to select a model.
Once done, the model will be uploaded and added to the list.
However, before importing a model, ensure this one has been assigned to a valid ID. Otherwise, this will prevent importing that model. You can refer to the product documentation for more details: AIP Console - Architecture.
|Note that in v. 1.20, you may find .castrule files are available for selection. These files should not be added as they do not contain Architecture Models (they contain details of Quality Rule models).|
Test a model against an application
Before attaching a model to an application, you have to validate if it is the right one to find structural flaws.
An Architecture Checker model is mainly based on layers and dependencies. Layers capture objects that should belong to a given software layer. Dependencies specify which links are authorized between objects belonging to different layers and which ones are not.
For instance, a model can define 3 layers: Database, DB Access, and Front, with authorized dependencies between Front and DB Access and between DB Access and Database. It means that objects belonging to Front layer cannot be linked to objects belonging to the Database layer. Only objects belonging to the DB Access layers can have such links.
|An Architecture Checker model is typically designed by an Software Architect.|
To control an application immediately, click the ellipsis button at the right-side of the model line and select the Check item:
AIP Console opens a dialog and applies the Architecture Checker model against the application. As a result, the dialog shows the list of links that violate the model:
View and edit models
If you want to view how the model is designed to detect structural flaws, then you can open the model editor. Edit model page allows you to make changes.
To open the model editor:
- Click the ellipsis button at the right-side of the model line and select the View item.
2. The model editor opens and displays the layers (in blue) and sets (in green) that define the model, with the associated dependencies (in bold green) and composition links (in doted green).
3. If you want to see or maybe update the model properties (name, ID, documentation, weight, and so on), then simply click the edit button near the model name:
4. The dialog box displays these properties:
5. You can add new Layers, Sets, and Dependencies by using the tool bar.
6. From left to right, you can add a new Layer object to the model, you can add a new Set object, you can add a new Dependency between 2 Layer objects
You can remove an existing Dependency from the model.
To change the selection criteria defined to capture objects in layers and sets, use the Add, Edit, Remove icons associated to the different graphical elements:
Save your changes before exiting the model editor. Even Layer and Set objects position will be saved.
Moving a model to production
Architecture Checker models are used to control the application implementation. For that, a model must be attached to the considered application and a snapshot must be produced. Attaching a model means a new dedicated rule is added to the Assessment Model with the contribution specified in the model properties.
The rule is violated when there is at least a link that does not respect the dependencies defined in the model.
The below screen shot shows the rule generated from the above Architecture Checker model with the violations that have been detected:
You should manage models carefully. If you move a model to production (i.e. you attached it to an application), then we recommend to not change it, detach it, or remove it without having evaluated the impact on dashboard results.
For instance, if you change the ID, then the rule with the previous ID will disappear and a new one with the new ID will appear. If you change the weight or the critical attribute, then the grade will be impacted. Changing the selection criteria may impact the layer content and therefore the rule results.
Move only the stable models to production.
Changing the model documentation does not impact the rule results but can increase the understanding regarding the model checks.