Rules and Standards

CAA V5 Component Rules

Standard patterns for CAA V5 applications
Technical Article

Abstract

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

  • Increase object reusability
  • Ensure build time and run time CAA developments upward compatibility
  • Handle a multi-tier architecture
  • Insure high performance.

In order to achieve these goals, here are compulsory architecture rules dealing with the CAA V5 components:


Introduction

Basically, besides ordinary C++ or Java objects, CAA V5 provides four kinds of object-oriented components:

[Top]

Interface-based Component Rules

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).
  • It will allow a runtime compatibility between modelers (C++)
  • This reduces code coupling between component providers and components users.
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.
  • All factories or commands have to be secured when used thru API
  • The Enterprise Architecture framework provides component default licensing behaviors which have to be "manually" completed when instantiating objects with a non standard manner.
For all entities
(Nb licensed factories) / (Nb factories)
100%

[Top]

Framework Component Rules

Rule Title Rule Description Explanation Metric Objective
4-Public/Protected Dependencies
  • Public interfaces only rely on other public interfaces.
  • Protected interfaces only rely on public or other protected interfaces.
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]

Product Component Rules

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.
  • It will allow batch developments and avoid loading of bundles of useless code
  • It is one of the key factors to insure a multi-tier architecture.
Nb of identified frameworks / products (or domains) >3 (at least 1 Interfaces Fmk + 1 Model + 1 UI)

Product functional dependencies

10-UI, Model and Interfaces frameworks Dependencies
  • UI frameworks only rely on UI frameworks or Interface frameworks
  • Model frameworks only rely on model frameworks or Interface frameworks
  • Interface frameworks only rely on interface frameworks
  • UI and model frameworks of a given product only communicate thru their interface framework.
  • It will minimize the bundle of code that has to be loaded at run time to insure a given functionality.
  • It will minimize the build time impacts.
  • It will insure a true batch mode.
  • It will provide a weak coupling between UI and model.
  • It will generate weak build time dependencies between modelers or products.
  • It will allow build time dependencies controls.
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]


History

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.