4.2      Packages

(1)   A package provides a way to organize component types, component implementations, feature group types, and annex libraries into related sets of declarations by introducing separate namespaces. Package names are built using identifiers that are separated by double colons (“::”). This avoids the problem of duplicate names which might occur when packages are developed independently and then combined to model an integrated system.  In other words, complete_sys::first_independent::fuel_flow is distinct from complete_sys::second_independent::fuel_flow.  Packages cannot be declared inside other packages.

(2)   Packages have public and private sections. Classifier declarations in public sections are accessible to other packages, while classifiers in private sections can only be referenced within the private section of the same package. This allows classifiers used in the implementation of public components to be kept private.

(3)   Visibility to other packages is specified by a with declaration.  Only classifiers in the packages listed in the with declaration can be referenced from within a given package.  A renames declaration can be used to introduce a local alias to a qualified component type and feature group type reference.

(4)   Visibility to property sets is specified by a with declaration.  Only properties, property types, and property constants defined in the property sets listed in the with declaration can be referenced from within a given package unless they are predeclared properties, property types, or property constants.

Syntax

package_spec ::= 
    package defining_package_name 
     ( public package_declarations [ private package_declarations ]
       | private package_declarations )
    [ properties ( { basic_property_association }+  |                
      none_statement ) ]
end defining_package_name ;

 

package_declarations ::=

    { name_visibility_declaration }* { AADL_declaration }*

 
package_name ::= 
    { package_identifier :: }* package_identifier
 
none_statement ::= none ;
 
AADL_declaration ::= 
    classifier_declaration 
    | annex_library 
 
classifier_declaration ::= 
    component_classifier_declaration | feature_group_classifier_declaration
   
component_classifier_declaration ::= 
    component_type | component_type_extension | 
    component_implementation | component_implementation_extension
 
feature_group_classifier_declaration ::= 
        feature_group_type | feature_group_type_extension
 
name_visibility_declaration ::= 
        import_declaration |
        alias_declaration 
 
import_declaration ::= 
       with ( package_name | property_set_identifier )
            { , ( package_name | property_set_identifier ) }* ; 
 
alias_declaration ::= 
    ( defining_identifier renames package package_name ; ) |
    ( [ defining_identifier ] renames 
      ( component_category unique_component_type_reference | 
      feature group unique_feature_group_type_reference ) ; ) |
    ( renames package_name::all ; )
 

NOTES:

The properties subclause of the package is optional, or requires an explicit empty subclause declaration.  The latter is provided to accommodate AADL modeling guidelines that require explicit documentation of empty subclauses. An empty subclause declaration consists of the reserved word of the subclause and a none statement     ( none ; ).

Naming Rules

(N1)     A defining package name consists of a sequence of one or more package identifiers separated by a double colon (“::”).  A defining package name must be unique in the global namespace. 

(N2)     The public and private section of a package may be declared in separate package declarations; these two declarations introduce a single defining package name.

(N3)     Associated with every package is a package namespace that contains the names for all the elements defined within that package.  This means that component types, feature group types, and defining entities declared in an annex library using an annex-specific sublanguage can be declared with the same name in different packages. 

(N4)     The package namespace is divided into a public section and a private section.  Items declared in the public section of the package namespace can be referenced from outside the package as well as within the package. 

(N5)     The reference to an item declared in another package must be an item name qualified with a package name separated by a double colon (“::”).  The package name must be listed in the import_declaration (with) of the package with the reference, i.e., in the import_declaration of the public section, if the reference is in the public section, and in the import_declaration of the public or private section if the reference is in the private section of the package.  Only classifiers in the public package section can be referenced.

Note: References to items declared in the same package as the reference do not have to be qualified. If they are quailified the package is not required to be listed in the import_declaration.

(N6)     The reference to a property other than predeclared properties must be an property name qualified with a property set name separated by a double colon (“::”).  The property set name must be listed in the with declaration of the package with the reference.  Predeclared properties may be, but are not required to be qualified by the property set name.

(N7)     The package name in a import_declaration must exist in the global name space.

(N8)     The property set identifier in a import_declaration must exist in the global name space.

(N9)     Items declared in the private section of the package can only be referenced from within the private section of the package. 

(N10)   If the qualifying package identifier of a qualified reference is missing, the referenced component classifier, feature group type, or item in an annex library must exist in the same package as the reference.

(N11)   The package name referenced in an alias_declaration must exist in the global namespace and must be listed in the import_declaration.

(N12)   The classifier referenced by the alias_declaration must exist in the name space of the public section of the package being referenced by the alias_declaration.

(N13)   The classifier referenced by the alias declaration must refer to a component type or a feature group type.

(N14)   The defining identifier of an alias_declaration must be unique in the namespace of the package containing the alias_declaration.  If an alias_declaration defines an alias for a package then the alias name must not conflict with any package name listed in an import_declaration or that of the package containing the alias_declaration.

(N15)   The alias_declaration makes the publicly visible identifier of classifiers declared in another package accessible in the name space of the package containing the alias_declaration.   If the alias declaration for a classifier does not include a defining identifier then the referenced classifier identifier is used as defining identifier and this identifier must be unique in the namespace of the package with the alias declaration. 

(N16)   If the alias_declaration renames all publicly visible identifiers of component types and feature group types by naming the package and all, then all those identifiers must also be unique in the namespace of the package with the alias declaration.

(N17)   The identifiers introduced by the alias_declaration are only accessible within the package.  When declared in the public package section, they can be referenced within the public and private package section, but not from other packages.  When declared in the private package section, they can be referenced within the private package section only.

(N18)   The alias declared for a component type can be used instead of a qualified component type in a reference to a component implementation.

Legality Rules

(L1)      The defining package name following the reserved word end must be identical to the defining package name following the reserved word package.

(L2)      For each package there may be at most one public section declaration and one private section declaration.  These two sections may be declared in a single package declaration or in two separate package declarations.

(L3)      A component implementation may be declared in both the public and private part of a package.  In that case the declaration in the public part may only contain a properties subclause and a modes subclause.

(L4)      The component category in an alias declaration must match the category of the referenced component type.

Semantics

(5)   A package provides a way to organize component type declarations, component implementation declarations, feature group types, and annex libraries into related sets of declarations along with relevant property associations.  It provides a namespace for component types, feature group types, and annex libraries with the package name acting as a qualifier.  Nested package names allow for unique package naming conventions that address potential name conflicts in component type and implementation names when independently developed AADL specifications are combined.  Note that component implementations are named relative to component types. Thus, qualified component type names act as unique qualifier for component implementation names.  Packages can be organized hierarchically by giving them nested package names.  These package names represent absolute paths from the root of the package hierarchy.

(6)   Packages have a public and a private section.  Declarations in the public section are visible outside the package, i.e., names declared in the public part can be referenced by declarations in other packages. Declarations in the private section are visible only within private section of the package, i.e., they cannot be referenced from the public section or from other packages. 

(7)   Component type and component implementation declarations model execution platform and application software components of a system.  A component type denotes externally visible characteristics of a component, i.e., its features and its properties.  A component implementation denotes the internal structure, operational modes, and properties of a component.  A component type can have several component implementations.  This can be used for example to model product line architectures running on different execution platforms.  Packages allow such declarations to be organized into separate namespaces. 

(8)   Feature group types provide the definition of an interface to a component that represents a collection of features or feature groups defined within the component implementation (see Section 5.3).  This group of features may be accessed externally as a single unit.

(9)   A component implementation can be declared in both the public and private section of a package. If it is declared in both, then the public declaration is limited to containing property associations and modes and only those items are visible outside the package.  This allows component implementations to be made visible to other packages as variants of the same component type, while the details of the implementation, i.e., its realization expressed by the subcomponents and connections subclauses, are hidden in the private part.  The two declarations represent the same component implementation.

(10)  When a component implementation is declared as an extension of another component implementation and it is declared in both the public and private section of a package, then the extends is specified with the public section and the extension may include prototype bindings. The component implementation in the private section is considered to complete the declaration in the public section, i.e., its name can be interpreted as reference to the defining name of the component implementation declaration in the public portion.

(11)  An import_declaration specifies which packages and property sets can be named in qualified references to items in other packages or property sets. Packages can initially be declared with import_declaration without classifiers to set up an initial collection of package with use restrictions on other packages.

(12)  An alias_declaration introduces local identifiers as short names for long names.  It does so for package names and for classifier type references qualified by a package name.  The short name may differ from the identifier of the long name to avoid name conflicts.

(13)  Property associations declared in the properties section of a package are associated with the package represented by the declaration. Packages with separate public and private package declarations can have different property values for the same property.

Processing Requirements and Permissions

(14)  A method of implementation is permitted to enforce that the with declaration in a package not be changed to enforce the use restrictions between packages when classifiers are added to the package.

Examples

package Aircraft::Cockpit

public

   with Avionics::DataTypes, Safety_Properties;

   AirData renames data Avionics::DataTypes::AirData;

   system MFD

   features

      Airdata: in data port AirData;

   properties

      Safety_Properties::Safety_Criticality => high;

   end MFD;

end Aircraft::Cockpit;