Rules and Standards |
CAA V5 Component RulesStandard patterns for CAA V5 applications |
Technical Article |
AbstractCAA V5 introduces various components at different levels (interface-based components, framework components, modeler components, product components). Those components have to be designed so that they:
In order to achieve these goals, here are compulsory architecture rules dealing with the CAA V5 components: |
Basically, besides ordinary C++ or Java objects, CAA V5 provides four kinds of object-oriented components:
[Top]
Rule Title | Rule Description | Explanation | Metric | Objective |
---|---|---|---|---|
1-True Interface Based Component | A component should adhere to pure interfaces, i.e., interfaces inherited from IUnknown (C++) or Object (Java). |
|
By Framework public part (Nb CATBaseUnknown Interfaces) / (Nb Interfaces) |
0% |
2-Interface Stability |
|
It will allow BP and customers to re-use their L1-based development on all Service Packs | By framework, and by public parts Nb of deviations |
0 |
3-Component Licensing | A component instantiation should required a license from the interactive product it belongs to: the component has to be located in an authorized framework, that is, a framework covered by an interactive license. |
|
For all entities (Nb licensed factories) / (Nb factories) |
100% |
[Top]
Rule Title | Rule Description | Explanation | Metric | Objective |
---|---|---|---|---|
4-Public/Protected Dependencies |
|
Framework encapsulation must not be violated. | Nb of illegal frameworks links
("Erreurs_prereqs_inconnus") |
0 |
5-Acyclic Prerequisite Frameworks | Frameworks are located in a non cyclic oriented graph. | Compiling a framework is a process that cannot handle cycles nor circular references. | Nb of cyclicities
("Anomalies_cyclicité") |
0 |
6-Framework identifications | Frameworks must specify their role in the Model/Presentation paradigm : Interfaces / Model / UI. | Identifying frameworks lead to consistent frameworks dependancies ; a framework is associated to a product/domain with the same tag. | (Nb of tagged frameworks) / (Nb of frameworks) | 100% |
7-Interface Framework Contents | An interface framework only contains interfaces or global function declarations acting as factories. Their implementations are not contained within the interface framework | It must insure a loose coupling between frameworks. | By framework, public parts (Nb of concrete class)/(Nb of entities) |
0% |
8-Model or UI Framework Contents | Model or UI frameworks public part has to be empty. | Product interfaces are located within the product interfaces frameworks. | Public part: (Nb of entities) | 0 |
[Top]
Rule Title | Rule Description | Explanation | Metric | Objective |
---|---|---|---|---|
9-UI / Model / Interfaces Segregation | UI functionalities and model functionalities should be located in two different frameworks, isolated by an interface frameworks. |
|
Nb of identified frameworks / products (or domains) | >3 (at least 1 Interfaces Fmk + 1 Model + 1 UI) |
|
||||
10-UI, Model and Interfaces frameworks Dependencies |
|
|
By model framework: (Nb of UI dependencies) | 0 |
By UI framework: (Nb of model dependencies) | 0 | |||
By Interface frameworks: (Nb of UI + Model dependencies) | 0 | |||
11-Run Time Dependencies | A product should define at its very beginning its runtime dependencies (Model frameworks IdentityCards) minimizing dependencies between products. | Coupling several products will require runtime licenses from all pre-requisite products ; that could be a major packaging issue when unwanted resources from another domain are picked-up lately in the implement process. | By packaged products : Nb of internal products/domains (sets of associated Interfaces/UI/Model frameworks) | Ranking (complexity criteria) |
[Top]
Version: 1.0 [Sep 2000] | Document created |
Version: 1.1 [Oct 2000] | Metrics added; simplified UI/Model/Interfaces view |
[Top] |
Copyright © 2000, Dassault Systèmes. All rights reserved.