4.6      Abstract Components

(1)   The component category abstract represents an abstract component.  Abstract components can be used to represent component models.  Abstract component can contain any component and can be contained in any component. The abstract component category can later be refined into one of the concrete component categories: any of the software components, hardware components, and composite components.  When an abstract component is refined into a concrete component category it must adhere to the containment rules imposed by the concrete category. For example, an abstract subcomponent of a process can only be refined into a thread or thread group.

Legality Rules

Category

Type

Implementation

abstract

Features:

·         port

·         feature group

·         provides data access

·         provides subprogram access

·         provides subprogram group access

·         provides bus access

·         requires data access

·         requires subprogram access

·         requires subprogram group access

·         requires bus access

·         feature

Flow specifications: yes

Modes: yes

Properties: yes

Subcomponents:

·         data

·         subprogram

·         subprogram group

·         thread

·         thread group

·         process

·         processor

·         virtual processor

·         memory

·         bus

·         virtual bus

·         device

·         system

·         abstract

Subprogram calls: yes

Connections: yes

Flows: yes

Modes: yes

Properties: yes

 

(L1)      An abstract component type declaration can contain feature declarations (including abstract feature declarations), flow declarations, as well as property associations.

(L2)      An abstract component implementation can contain subcomponent declarations of any category.  Certain combinations of subcomponent categories are only acceptable if they are acceptable in one of the concrete component categories.

(L3)      An abstract component implementation can contain a modes subclause, a connections subclause, a flows subclause, and property associations. 

(L4)      An abstract subcomponent can be contained in the implementation of any component category. 

(L5)      If an abstract subcomponent is refined to a concrete category, the concrete category must be acceptable to the component implementation category whose subcomponent is being refined.

(L6)      An abstract subcomponent can be declared as an array of subcomponents.

(L7)      If an abstract component type is refined to a concrete category, the features, modes, and flow specifications of the abstract component type must be acceptable for the concrete component type.

(L8)      If an abstract component implementation is refined to a concrete category, the subcomponents, call sequences, modes, flow implementations, and end-to-end flows of the abstract component implementation must be acceptable for the concrete component implementation.

Standard Properties

(2)   An abstract component can have property associations of properties that apply to any concrete category.  However, when refined to a concrete category, properties that do not apply to the concrete category will be ignored. A method of processing may provide a warning about ignored properties.

Semantics

(3)   The component of category abstract represents an abstract component.  It can be used to represent conceptual architectures.  This abstract component can be refined into a runtime architecture by refining the component category into a software, composite, or hardware component.  Such a refinement from a conceptual architecture to a runtime architecture is illustrated in the example below.

(4)   Alternatively, the conceptual architecture can be defined in terms of abstract components and the runtime architecture can be defined separately in terms of threads and processes.  A user-defined property of the reference property type can be used to specify the mapping of conceptual components to runtime architecture components.

Examples

(5)   A conceptual architecture and its refinement into a runtime architecture.

package CarSystem

public

bus Manifold

end Manifold;

 

abstract car

end car;

 

abstract implementation car.generic

subcomponents

  PowerTrain: abstract power_train;

  ExhaustSystem: abstract exhaust_system;

end car.generic;

 

abstract power_train

features

  exhaustoutput: requires bus access Manifold;

end power_train;

 

abstract exhaust_system

features

  exhaustManifold: provides bus access Manifold;

end exhaust_system;

 

-- runtime architecture

system carRT extends car

end carRT;

 

system implementation carRT.impl

   extends car.generic

subcomponents

    PowerTrain : refined to system power_train;

    ExhaustSystem : refined to system exhaust_system;

end carRT.impl;

end CarSystem;