Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 7 Next »


Using Software Architecture Models



Purpose

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 here have been done with AIP Console 1.9.0.

Use case

As an Application Owner you on-boarded an application in AIP Console and you want to control if the software architecture that has been designed by Software Architects is respected. 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 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 pages and click the ARCHITECTURE tab. The page that appears 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 to allow 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.

Test a model against an application

Before attaching a model to an application, you may want 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. Designing an Architecture Checker model is typically a job for the 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:

Note that you must have produced at least one snapshot for the application to provide Architecture Checker with the information it needs.

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. This one will allow you to make some changes as well.
To open the model editor, click the ellipsis button at the right-side of the model line and select the View item:

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

If you want to see or maybe update the model properties (name, ID, documentation, weight, …), then simply click the edit button close to the model name:

The dialog that appears displays these properties:

You can add new Layers, Sets, and Dependencies by using the tool bar:

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

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

Do not forget to save your changes before exiting the model editor. Even Layer and Set objects position will be saved.

Consideration when moving a model to production

Architecture Checker models are used to control the application implementation with regards to the software architecture. 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:

Knowing that, 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. That said, prefer moving stable models only to production.
Changing the model documentation does not impact the rule results but can increase the understanding regarding the model checks. In that case, it is a good thing we promote!

  • No labels