D.2     AADL Graphical Symbols

(1)   AADL graphical symbols are shown with the AADL logo placed as decorator in the upper left corner of the symbol.  This logo may be omitted if its absence does not cause confusion with other graphical notations.

(2)   In this section we define the graphical symbols for component categories, ports and port connections, shared access to data and buses, subprograms and subprogram calls, execution platforms and binding of application components to execution platforms.  We also define the representation for component types, component implementations, and component instances.  These symbols are provided as a standard set to be used in toolsets implementing the graphical AADL.  If the standardized set is not fully supported a graphical toolset then, the toolset must define its mapping with respect to the standardized set.

Component Categories

(3)   Figure 24 shows the graphical symbols of the component categories in AADL.   

Figure 24 AADL Components Graphical Symbols

(4)   These graphical symbols are used to describe a system instance and its components. The same basic symbol is used to represent component types, component implementations, subcomponents, and component instances of a particular category.

Figure 25 Decorators on Threads

(5)   Decorators may be attached to graphical symbols.  Figure 25 illustrates the decoration of threads with threads properties that are relevant in a timing-related view, i.e., it shows whether threads are periodic, aperiodic, sporadic, timed, hybrid, or background. In the case of periodic, sporadic, timed, and hybrid threads the decorator indicates the period or timeout value. 

(6)   Introduction of such decorators is permitted for any AADL property or other characteristic of model objects represented by the graphical symbol.  For example, a decorator may be used to indicate completeness of timing specification in a component, or to mark a Wi-Fi device.  The use of decorators is optional.

Component Classifiers

(7)   Figure 26 illustrates the use of the graphical component category symbols to describe the components in terms of their type, implementation, and the content of the implementation.  Component types are shown using the basic graphical symbol for the categories.  The extension relation of a component type in terms of another component type is shown with a solid line and an hollow triangle arrow head.  These symbols are typically used in library views that show the content of AADL specifications or AADL packages, i.e., component classifiers and their extends relationships (see Annex A.2).

(8)   In the example of Figure 26, the system type SecureGPSSender extends the system type GPSSender. If a component type that is an extension of another component type is shown graphically, then both the features that are locally declared and the features inherited from the component type being extended may be shown graphically.

(9)   The example shows labels for component classifiers and ports.  The display of those labels is optional and may be achieved through hovering popup mechanisms. Labels may be placed outside a symbol, inside a symbol, or as labels with a line attachment appropriate with the available display real estate.

Figure 26 Component Types and Implementations

(10)  Figure 26 also shows the representation of component implementations; its graphical symbol is shown using the bold-lined graphical symbol of the category.  This bold-lining technique is optional, but recommended if component implementations must be visually distinguished from component types or subcomponents.  The relation to the component type is expressed by a dashed line with an hollow triangle arrow head.  Component implementation names are shown with a dot (“.”) separated the component type identifier and component implementation identifier.

Figure 27 Subcomponents

(11)  Subcomponents are shown using the graphical symbol of the component category as illustrated in Figure 27.  The subcomponent label shows the subcomponent name, optionally followed by the component classifier after a colon (:).  An underline may be used for the name as necessary to visually distinguish the name from the component classifier label.  Multiplicities of components and features can be shown as a decorator in the upper right corner of the graphical symbol.

(12)  It is permitted to include a text box with additional information regarding the context of the graphical view, such as the name, category, and property values of the AADL model object that is the root of the graphical view. Figure 28 shows the content of a system implementation without the enclosing component symbol and with a text box that contains information relevant to the enclosing component.  The dashed rectangle is used to indicate the boundary of the view panel. AADL model elements may have a label.  This label consists of the name and optionally the component classifier – separated by a colon (:).  Figure 28 illustrates the use of labels for a subcomponent and a port.

implementationcontext

Figure 28 Component Implementation Content with Text Box

(13)  Components may be parameterized with prototypes. Figure 29 shows how such prototypes can be illustrated graphically. A paper symbol represents the collection of prototypes and is attached to the right corner. The content of graphical symbol can be the prototype specification or the prototype bindings.

Figure 29 Components and Prototypes

Abstract Features, Ports, and Connections

(14)  Figure 30 shows the graphical symbols for abstract features and ports.  In this figure, the text represents the graphical symbol legend rather than text label examples in a graphical AADL model.  The features are placed anywhere on the perimeter of the component graphical symbol.  The orientation of the graphical symbol indicates the direction of the feature. 

Figure 30 Abstract Features, Ports and Connections

(15)  Abstract features are represented by a solid circle, data ports by a solid triangle, event ports by an open angle arrow, and event data ports by a combination of both.  The port direction is indicated by the direction of the symbol tip.  In the case of an abstract feature an angle arrow is added to indicate the direction. The orientation of the symbol must be adjusted according to the placement on the perimeter.  For example, the triangle of an incoming data port must always be oriented such that the tip points into the component graphical symbol.

(16)  The abstract feature and port connections are shown as a single solid line. A legal AADL model requires connections to always be connected to ports.  In other words, a diagram showing a connection attached to only one port is not acceptable except during the operation of creating or modifying a connection graphically.

(17)  Data ports may also have immediate and delayed connections. A single solid line with a double arrow indicates an immediate connection.  A delayed connection is marked with a double line crossing the connection line.  If the direction of the connection cannot easily be inferred from the feature symbols, then a single arrow may be added to the connection line.

Figure 31 Connections & Branch Points

(18)  A connection connects two features.  Connections can be made between components that are the same level of the system hierarchy, i.e., subcomponents within the same implementation, or between a component and its enclosing component. 

(19)  If a port has multiple outgoing or incoming connections, they may either be shown as separate lines or as a single line with lines branching out from it (see Figure 31).  The branch points may be marked by a dot to distinguish them from crossing lines. 

 

Feature Groups

(20)  Feature groups are represented by a half circle and a solid ball with the ball always facing to the outside of a component symbol.  Inside a component, individual ports or feature groups of subcomponents may be connected to the half circle of the feature group as shown in Figure 32.  The half circle and solid ball represents a collapsed view of a feature group. Feature group connections are shown as solid line.  The direction of a feature group connection may be indicated by an arrow.

Figure 32 Feature Groups & Connections

(21)  Feature group types may be shown by using an expanded symbol for the feature group and by attaching the feature group elements to the enlarged half circle of the feature group symbol (see Figure 33).  Alternatively the half circle may be replaced by a vertical bar, which can be expanded to accommodate a larger number of feature group elements. The expanded symbol is useful for graphically representing feature group type declarations and for detailing connections to feature groups (see Figure 34).

Figure 33 Expanded Port Group Type Symbol

(22)  Figure 34 shows a set of feature groups in a system hierarchy.  Starting from the left, one thread supplies a data port and the other thread furnishes a feature group.  This composite feature group is routed from a process via its enclosing system to another system.  Within that system the feature group is decomposed into one data port and a feature group (shown using an expanded feature group symbol).  That feature group is routed to a process, which decomposes it into its constituents, a data port and an event data port.

Figure 34 Feature Group Composition and Connections

(23)  The expanded feature group symbol can be used to visually distinguish between a connection that passes the whole feature group to a subcomponent and a connection that passes a port group element that itself is a feature group to a subcomponent by connecting the former to the feature group half moon and the latter to the feature group element (see Figure 34).

Shared Access to Data and Buses

(24)  In AADL components may require access to other components and provide access to components contained in them.  The standard limits such shared access to data components and buses.  The same symbol is used to represent access to bus and to data.  Figure 35 illustrates the graphical notation to represent sharing of data.  Thread1 requires access to a data component and contains a data component Data1, to which it provides access to other components.  The provides data access and requires data access features are shown pointing in the direction of the component requiring data access.  Data access connections are shown as a single solid line.  Both ends of a data access connection must be connected.  In our example the required data access of Thread2 is resolved to the data component Data1.  Similarly, the required data access of Thread1 is resolved to the data component Data2, which exists at the same system level as Thread1. 

Figure 35 Shared Data Access

(25)  Figure 36 illustrates access between processors, memory, and devices through shared access to buses.   Memory, devices, processors, and systems can have required bus access.  Processors and systems can have provided bus access.  Bus access connections are shown as a solid line.  Both ends of a data access connection must be connected.  Required bus access is resolved to a bus component the same way required data access is resolved to a data component. Also shown in the figure is a provided bus access symbol to indicate that the bus is made accessible outside the system.

Figure 36 Shared Bus Access

Subprogram Calls and Subprogram Access

(26)  Figure 37  illustrates the graphical symbols for subprogram call sequences and parameter passing.    The sequence of calls is shown by a set of subprogram graphical symbols with the call order indicated by a single solid line with an open arrow head.  The graphical display of the call sequence order by use of the solid line with the open arrow head is optional.  If not shown, the call sequence can be inferred from the left to right ordering of the subprogram symbol placements. 

Figure 37 Subprogram Calls and Parameter Passing

(27)  Figure 37 shows a subprogram call sequence with two calls f1 and f2 to the same subprogram filter.  Subprogram call labels follow the convention of subcomponent and feature labels discussed earlier.  The call sequence ordering is determined by the placement of the subprogram graphical symbols from left to right. 

(28)  Optionally, the call sequence ordering can be explicitly shown. Subprogram parameters are shown using a solid triangle - the same symbol as used for data ports.  A parameter connection is shown as a solid line between two parameters or between a parameter and a data port of a thread containing the subprogram call.  The direction of parameter connections must follow the direction of the call sequence. 

Figure 38 Subprogram Access Features

(29)  Figure 38 illustrates the subprogram and subprogram group access feature symbols. The arrow direction indicates whether the feature is provided or required and aligns with the direction of the call.  Subprogram access connections and subprogram group access connections use a solid line. 

Modes and Mode Transitions

(30)  Figure 39 illustrates the graphical representation for modes. Components and connections involved in a mode are shown in the context of the enclosing component implementation.  Individual modes are shown as hexagons.  The initial mode is shown with a bullet and a transition to the appropriate mode.  Mode transitions are shown as simple lined arrows.  The events triggering a mode transition can be shown with dashed lines connecting the event port to the mode transition, or by attaching the event name as a transition label (shown in Figure 39). 

(31)  Tools may show mode membership of connections and subcomponents in the following way.  Components and connections involved in a mode, i.e., the modal configuration of a component, are shown in the context of the enclosing component implementation.  Mode1 is shown in one color (shown in black in Figure 39) to indicate it as the selected mode. The components, ports, and connections that are part of the selected mode are highlighted in the same color.  Other modes and inactive components, ports, and connections are shown in a different color (shown in gray in Figure 39).   In other words, the selection of a mode defines a subset view.

Figure 39 Modes and Mode Transitions

  Modeling of Flows

(32)  Figure 40 shows the graphical symbols for flow source, flow sink, and flow path specifications and their use in a component type.  Flow path symbols are connected to two ports, while flow source and flow sink symbols are connected to one port.

Figure 40 Flow Specifications

(33)  Figure 41 illustrates how tools may graphically visualize a flow implementation using the selection technique for mode modeling.  A flow implementation can be shown in black by selecting the flow of interest as a flow specification in the text box. Subcomponent flows and connections that are not part of the flow are shown in gray.  An editor can use this visualization both for displaying flows and for defining flows.  End-to-end flows can be visualized in a similar manner.  The text box has a compartment showing end-to-end flow names.  Selection of one results in showing the flow in black while graying out the rest.

Figure 41 Flow Implementation Selection

Packages, Property Sets, and Annexes

(34)  The graphical symbol for packages is a folder with the tab on the left.  The graphical symbol for a property set is a folder with the tab on the right. The graphical symbol for annex libraries is a folder with the tab on the left and the annex name embedded in the annex-specific brackets from the textual AADL syntax.

(35)  The content of packages may be shown in a nested fashion.  Public and private sections of packages may be shown as appropriately labeled compartments. Alternatively, component classifiers in a package may be labeled using the UML convention of a plus (“+”) for public and minus (“-“) for private classifiers.

Figure 42 Packages, Property Sets, and Annex Libraries