Basic Constructs

Data Model

There are three kinds of classifiers in Capella : classes (including unions and collections), complex types and simple types.

A data type is a special kind of classifier, similar to a class. It differs from a class in that instances of a data type are identified only by their value. All copies of an instance of a data type and any instances of that data type with the same value are considered to be equal instances. There are two kinds of data types: simple or [ complex types].

Note that Capella does not provide a way to distinguish primitive classes from non-primitive classes in class diagrams.

Simple Type

Capella provides five different families of simple data types: [ Boolean Type], [ Enumeration], [ Numeric Type], [ String Type] and [ Physical Quantity].

By default a new Capella project comes with a set of predefined simple data types. These predefined types can be completely redefined, removed or replaced. The best practice being to build-up a library from which all these data types would be reused.

Capella provides advanced editors for specifying simple data types. For example, it is possible to define [ min, max, default and null values], to specify whether a simple data type is discrete (countable) or not, etc.

We will use the simple example of a car to further illustrate data modeling constructs.

NumericType

Numeric Type is a kind of simple data type, representing numbers.

Numeric Types can be of Kind Float or Integer; their min and max Values define the range of the possible Values for the Numeric Type.

Let us create a first Numeric Type of Kind Integer called Mileage, for our car description.

PhysicalQuantity

Physical Quantity is a specific kind of Numeric Type. It represents a physical �dimension� and is associated to Unit (meter, gram, volt, etc.).

Unit

A Unit of measurement is a definite magnitude of a physical quantity, defined and adopted by convention and/or by law, that is used as a standard for measurement of the same physical quantity. Units are used in Physical Quantity data types and [ Numeric Values].

The speed of a car, for instance, can be expressed in terms of km/h (or mile/h, depending on the country).

The Mileage of a car is more precisely expressed in terms of kilometers or miles. If we wish to add this Unit concept, we need to use a Physical Quantity Type instead of a Numeric Type.

Speed can also be a Physical Quantity, with another Unit. We could even define two different Speed types, with different units�

Enumeration

An Enumeration is a simple data type whose possible values are enumerated in the model as Enumeration Literals.

For instance, when you buy a car, you can choose its color in a predefined set.

BooleanType

A Boolean Type is a kind of simple data type. A Boolean type defines two named values which hold the semantics of truth and falsehood.

StringType

A String Type is a kind of simple data type, representing a sequence of characters. A String defines a piece of text. The semantics of the string itself depends on its purpose; it can be a comment, computational language expression, OCL expression, etc.

In our example, the owner of the car could be a person, with a first name and a last name. The first name and the last name are of kind String Type. Hence we define a specific String Type named �Name�.

Complex Type

In Capella , simple types cannot own [ Properties]. So if we need structured data types, we have to create Classes, but then we have to specify that these classes are �[ primitive]�. These primitive classes play the role of complex types.

Primitive Classes can be used to type other Class Properties, but cannot be the source or target of [ associations]. Primitive means instances of the class have no identity in the context of the system.

Let us give an example. If we need a Date type containing three properties like year, month, and day, we have to create a �primitive� class.

A simple solution consists in creating three properties with the Integer type. We can further specify that Min and Max values for month are 1 and 12, and that Min and Max values for day are 1 and 31.

Two instances of the Date Class with the same property values cannot be distinguished ; A date does not have any intrinsic identity, contrary to a car or a person, it is a � primitive � class or complex type.

Class

A Class is a complex classifier.

The purpose of a Class is to specify a classification of objects and to specify the features that characterize the structure and behavior of those objects.

Classes have properties, typed by other Classes, [ Unions], [ Collections], data types, etc. Objects of a class must contain values for each property of that class, in accordance with the characteristics of the property, for example its type and multiplicity.

Classes are the Capella declination of the UML concept of �Class�. So, many possibilities given by the UML Class Diagram are available here: classes can be associated and generalized, etc.

Class Editor

Field

Description

Default

Name

The name of the current Element.

<generic name>

Summary

A short headline about the role of the current Element.

<blank>

Super

One or several classes the current Class inherits. An option in the preferences allows specifying whether multiple inheritance is possible or not.

<blank>

Realized Classes

One or several classes in the previous engineering phase (for example System Analysis if the current Class belongs to Logical Architecture) refined by the current Class.

<blank>

isFinal

Specifies whether the current Class can be specialized or not. A final Class cannot be specialized by other Classes.

False

isAbstract

Specifies whether the current Class is abstract or not. An abstract Class is a Class that cannot be instantiated; it is expected to be specialized by one or several concrete Classes.

False

isPrimitive

Primitive Classes specify complex data types that can be used to type Properties held by a class, but cannot be the source or target of associations. Primitive means instances of the class have no identity in the context of the system.

False

Property

Properties of a class can be held directly by the class itself or by the navigable [ role] of an [ association] from this class. When held by a class, a property is also called attribute.

Properties are constituent members of structured elements such as Classes and Unions.

A Property has mainly a name and a type. A property is complex or simple depending whether its type is complex (class or complex data type) or simple (simple data type).

Key

A Property (attribute or association role) can be part of key. It means that the values of this property enable to distinguish different instances of the Class.

For instance, assuming there are no homonyms, we could say that both properties (firstName + lastName) make the key for the class Person. Of course, weight, height or birthday, would not be valid keys. But this is highly domain-dependent.

Key properties are noted with a �&� prefix.

Note that a key is said to be composite when it is made of several parts or a unique complex part, whereas simple keys are specified by a unique simple property.

Let us give a simple example of an association role being part of a key: a Ground Antenna is both identified by its own antenna number and the Ground Station it is related to (Ground Antennas are numbered by: Ground Antenna 1, 2 3 � of Ground Station STA1).

Cardinality

By default, each instance of a Class will bear exactly one value for each Property of the Class: Min. Card = Max. Card = 1.

We can specify that a property is optional, by setting its Min. Card to �0� instead of �1�. We can also specify that a property may have several values by setting the Max. Card to more than 1.

In France, for instance, when a child is born and declared, the parents must give him/her at least one first name, but there is no official number limit. The order of declaration is important, and the first one is the official first name. Let us also specify an optional middle name �

The cardinality bounds are typically shown in the format:

<lower-bound> �..� <upper-bound>

where <lower-bound> is an integer and <upper-bound> is an unlimited natural number. The star character (*) is used as part of a cardinality specification to represent the unlimited (or infinite) upper bound.

Note that for a multi-valued property to be part of a key, it shall be ordered.

The usual practice is to allow only properties with [1..1] multiplicity as being part of a key

Other Property basic features

The following table synthetizes the available features of a property according to the different simple type kinds.

Boolean

Enumeration

String

Numeric

Phys. Quan.

Min / Max

No

No

No

Yes

Yes

Default Value

Yes

Yes

Yes

Yes

Yes

Null Value

Yes

Yes

Yes

Yes

Yes

Min. / Max. Length

No

No

Yes

No

No

These features, when specified for a property, overwrite those, if any, defined for the property�s type.

As a good practice, defining these features in types should be preferred to defining them in properties. When features are defined in types the model is clearer. A drawback of this practice is that it leads to defining a larger number of types.

Default Value

When an object is instantiated in a class, for every attribute of the class that has a specified default, if an initial value of the attribute is not specified explicitly for the instantiation, then the default value specification is evaluated to set the initial value of the attribute for the object [UML].

The default value can be overwritten in a subtype.

Example: Numeric Type 1 redefines to 9 the default value of Numeric Type 2 (45).

Null Value

If the null value is defined for a type, wherever a value of this type is expected, the null value shall be provided to actually specify �no value�. The null value of a type is the concrete (physical) value to specify �no value� from a logical point of view.

The null value can be overwritten in a subtype.

Min/Max

Minimum and maximum values for range.

If pertinent, Min. / Max. Inclusive properties indicate if min/max values are inclusive in the range.

Min. Length/Max. Length

Minimum and maximum values for String length.

Property ordering

Property ordering may be considered for data detailed definition.

Note that, with Capella , ordering can be changed inside the model explorer, but not directly from diagrams.

Operation

An operation is a behavioral feature of a class that specifies the name, type, parameters, and constraints for invoking an associated behavior.

An operation belonging to a class should not be confused with an [ operation] belonging to a component, available as an Exchange Item in the Communication Model.

From a system engineering perspective, unless specific needs, use of operations in classes is not recommended.

Abstract Class

An abstract Class is a class that cannot be instantiated; it is expected to be specialized by one or several concrete classes (subclasses).

Abstract class names are displayed in italics in diagrams (look at Vehicle in the following CDB).

In our example, let us speak also about motorbikes. Cars and motorbikes are �vehicles�. We can create an abstract Class �Vehicle� that will factorize all the common properties for cars and motorbikes.

isAbstract: Boolean. Default value is false.

Take care that all properties of the generalized class (super-class) must be meaningful for all the subclasses! If we wish to add the bicycles to our model, it would not be a good idea just to add a third subclass, as it would imply that bicycles have also registration numbers and mileage. A better model would be the following one:

isPrimitive

When a class is tagged �isPrimitive�, it becomes a [ Complex Type].

Primitive Classes can be used to type other Class Properties, but cannot be the source or target of [ associations]. Primitive means instances of the class have no identity in the context of the system.

Warning: as a consequence, converting a class to a primitive might delete all its associations. It depends on your Capella preferences.

Values

Values are instances of classes and data types and allow defining fixed data values. There are named values and anonymous values.

Only named values can be reused through value references to specify other model elements. In this case they have the semantics of a constant in the system and can be referenced to build other data values or to define:

An anonymous Data Value cannot be referenced.

Literal Numeric Value

Literals allow defining fixed Data Values.

Examples of Numeric Literals for a Numeric Type of Kind FLOAT:

In our example, we just wanted to express that the minimum mileage value is �0�.

Enumeration Literal

An Enumeration Literal is a user-defined possible [ Enumeration] instance.

We can specify the precise list of available colors for cars. Let us begin�

Each Enumeration literal can be associated optionally with an Domain value, enabling to treat them as an ordered set (next, previous). This Domain Value field should be consistent with the Domain Type declared in the owning Enumeration data type.

Literal Boolean Value

Literal Boolean values are used to define the names of true and false values of a Boolean type.

Examples of Boolean Literals:

A good practice is to have only one Boolean type in a model. If there is a need of defining other values (Yes/No, etc.), it is strongly recommended to create an Enumeration simple type owning two Enumeration literals, and then to associate each of the literals to either false of true value of the Boolean type.

Literal String Value

Literals allow defining fixed Data Values.

Examples of String Literals:

These String Literals can then be used in default and null values of properties typed by a String data type.

Association

An Association is a semantic relationship between two Classes (or Unions and Collections). �Association� represents a relationship shared among the instances of two classes.

An association is normally drawn as a solid line connecting two types, or a solid line connecting a single classifier to itself (the two ends are distinct).

Note: Distinction between �attribute� and �association� properties should be made upon the basis of the type of the element linked to the class:

As a consequence, it is neither possible to create an association towards a Datatype / primitive Class, neither possible to type a single Property with a non-primitive Class.

In our example, imagine we just need the last name for the owner of a car, assuming there are no homonyms, the following simple model would be sufficient.

But as soon as we need more information on the owner, the best is to add a Class Person, and create an association between Car and Person, as in the next figure.

Role

An association end is the connection between the line depicting an association and the box depicting the connected class. A name string may be placed near the end of the line to show the name of the association end. The name is optional and suppressible.

There can be several associations between two classes, each representing a specific relationship (with its own properties). For instance, let us assume that a car always has one and exactly one owner, whereas it can have zero or one driver at a time. The Person class plays two roles with respect to class Car: owner and driver roles. Conversely, a person can own several cars simultaneously, but cannot drive more than one car.

Cardinality

Cardinality is a definition of an interval of non-negative integers beginning with a lower bound and ending with a (possibly infinite) upper bound.

For a multivalued multiplicity (Max. Card > 1), this attribute specifies whether the values in an instantiation of this element are sequentially ordered. Default is false. See � [ isOrdered].

For a multivalued multiplicity (Max. Card > 1), this attributes specifies whether the values in an instantiation of this element are unique. Default is true. See � [ isUnique].

Typical cardinalities are:

A cardinality with zero as the lower bound and an unspecified upper bound may use the alternative notation containing a single star �*� instead of �0..*�. In Capella , as for Properties, the default is supposed to be �1..1�, and is not displayed.

If the lower bound is equal to the upper bound, then an alternate notation is to use the string containing just the upper bound. For example, �4� is semantically equivalent to �4..4� (exactly 4).

The lower and upper bounds for cardinality may be specified by [ Literal values] or [ References] (it is also true for attribute cardinalities).

For instance in our example, the Constellation contains both operational and spare satellites. To be more flexible, we do not want to fix the number of operational and spare satellites once and for all in the cardinality ranges. We prefer to refer to named constants or references, so that if they appear in multiple diagrams, we only have to change the unique definitions.

Notice the difference:

A good practice to name classes that are not collections is to always use singular. Do not forget that cardinalities are there to express multiplicity!

Take care also not to abuse of [0..*] or [*] cardinalities: they are never wrong but often too imprecise

Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.

An open arrowhead on the end of an association indicates the end is navigable. In the following example, the Person can access directly to his/her owned cars, and the Car can access to its owner.

Specially when a modeling objective is code generation, it is strongly advised to reduce the navigability of associations to only one direction to minimize coupling. In the following diagram, for instance each Car knows directly its owner, but a person cannot access directly to ownedCars. This does not mean that the system does not have the capability to access the cars owned by a person, but it will not be performed directly from the person side.

If the role is not navigable, its name is optional, and is not displayed on the diagram. Conversely, the role name must be filled in the navigable role side.

Note also that:

Name

It is also possible to give a name to the association itself, instead of or in addition to the role names. Take care: by default, the name of the association does not appear on the diagram! You have to deactivate the default filter called �association label�.

Take care that if you change the layout of the diagram, for instance if you put Car on the left and Person on the right, the verbs will read in the wrong direction! Very often, the reading direction of each verb is obvious from the domain knowledge, but it may not be the case. Two possibilities are available: either prefer the role names, or use additional symbols such as < or ^ (but you will have to modify them if you change again the layout).

And do not forget that navigability (arrows on associations) and direction of the verb naming the association are completely distinct notions !

Associations in Capella Project Explorer

Properties of a class (attributes or navigable roles) are shown in the same way under their owning class in Capella Project Explorer.

A first example is given by the next figure, where the class Car is shown in the Project explorer with 3 attributes and two navigable roles.

As soon as we reverse the navigability of the first association, one property disappears (owner: Person).

When an association is navigable in both directions, one property for each navigable role is visible under each class.

Remember that non navigable roles appear as properties of the association itself.

Take care also that if you ever change the name of a Class, the names of the roles pointing to it will not be changed automatically!

Aggregation, composition

When Aggregation Kind of a role is ASSOCIATION, the association is a simple association. For this role, the origin class has a reference to the target class which shall own or inherit a key.

�Aggregation� is a variant of the "has a" association relationship; aggregation is more specific than association. It is an association that represents a part-of relationship.

Take care: as this concept does not have a universally agreed semantics (it is a semantic variation point in UML), it is advised not to use it unless you define a clear semantics for your project.

�Composition� (or composite aggregation) is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the composition subgraph below that element.

Composition is represented by a black diamond on the origin end of the association.

An association with Aggregation Kind = AGGREGATION (shared association in UML) differs in notation from simple associations in adding a hollow diamond as a terminal adornment at the aggregate end of the association line. An association with Aggregation Kind = COMPOSITION has also a diamond at the aggregate end, but differs in having the diamond filled in.

In our example, we have expressed the fact that a car always contains four wheels and a boot. These elements are present when you buy the car; they belong to the product definition (EPBS). On the contrary, there may be luggage in the boot from time to time, but luggage does not belong to the product definition.

Take care not to create multiple compositions where the same Class is involved as a part. It is very often the symptom of a wrong analysis. At least, pay attention to the cardinality on the composite side: the same element cannot belong to several composites! For instance, the following diagram is correct when you read it from top to bottom. But when you read it from bottom to top, it expresses the false assertion that a Wheel belongs both to a Car and a Motorbike!

A better solution is to specifiy [0..1] cardinalities on the composite sides

An even better model is the following one (with the XOR constraint):

Refrain absolutely from circular compositions (or aggregations).

Note also that Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation.

Generalization

Where a generalization relates a specific class to a general class, each instance of the specific class is also an instance of the general class. Therefore, properties specified for instances of the general class are implicitly specified for instances of the specific class. Any constraint applying to instances of the general class also applies to instances of the specific class.

A Generalization is shown as a line with a hollow triangle as an arrowhead between the symbols representing the involved classes. The arrowhead points to the symbol representing the general class. The Generalization relationship is also shown in the Properties sheet under the topic �Super�, which indicates the super-class.

Mutual generalizations between classes A and B are impossible and Capella prevents to create the second generalization in the opposite direction. Moreover, Capella even detects circular generalizations and prevents them.

Package

Definition

A package is used to group elements, and provides a namespace for the grouped elements. A package may contain other packages. A package owns its members, with the implication that if a package is deleted from a model, so are its owned elements. In Capella , packages are shown as rectangles.

In our example, we have organized all the System Analysis Types into three packages:

It is highly recommended not to put all the types � flat � in the Data existing package. Inside Classes, and Basic Types, we could have created subpackages to better structure the Data Model. Usually classes and basic types are mixed in packages for the structuration in packages shall rely on business criteria and not on type kind (class vs datatype). A useful recommendation is to limit the number of datatypes and classes in a package to 20.

A package can contain Types, Exchange Items, but also Associations and diagrams.

Dependencies

Data Packages should display high cohesion and low coupling. It is very important to avoid:

Package dependencies can be deduced from crossing navigable associations or generalizations between types (this is why it is already important to restrict the navigability of associations to only one direction), and also from the fact that properties are typed by elements belonging to another package.

For instance, in the next figure, we see that Capella detects the dependency between packages, because an association exists between classes owned by these packages.

A very interesting feature of Capella is the ability to calculate and draw dependencies between packages based on associations and generalizations between owned Types.

On our example, Capella was able to calculate that Classes depends on Basic Types and Predefined Types (properties of classes are typed by Basic Types and Predefined Types), and that Basic Types depends on Predefined Types. In the Package Dependencies diagram, if we insert all packages, the following diagram is automatically displayed:

We can check easily that there are no mutual dependencies, nor circular ones.

CDB (Class Diagram Blank)

All definitions of Classes, Types and Exchange items are done in Capella through Class Diagrams. These CDB (Class Diagram Blank) are available at each Arcadia abstraction level.

Filters

There are several filters available in the CDB.

Only the �Hide Association Labels� filter is activated by default. We have given examples of this filter and the following one: �Hide Role Labels� in the [ Association Name �].

Hide Properties

This filter hides the properties inside classes. But it does not hide the literals inside the basic types.

Hide Operations

This filter hides the operations inside classes. Remember we strongly advise not to use operations inside classes.

Hide Associations

This filter hides the associations between classes, including aggregations and compositions.

Hide Generalizations

This filter hides the generalizations between classes.

Show Full Path

This filter shows the full path of owning packages.

Hide Derived Properties

This filter hides the [ derived] properties inside classes.

Toolbox

Insert / Remove Types

All Classes, Primitive Classes and Basic Types are managed through the same tool: Insert/Remove Types.

Communication Model

Main Communication Concepts

The following figure gives a summary of Exchange concepts throughout the Arcadia abstraction levels:

Why are additional concepts necessary? The reason is the purpose of each concept:

If only data model was used to structure context-dependent exchanged data, this could lead either to very complex data structures (trying to deal simultaneously with multiple uses), or very numerous, partially redundant data structures (thus compromising the understanding of semantic data definition).

Exchange Items can be defined in order to group references to a set of data, to be considered in a coherent manner for functional exchanges. Furthermore, some non-functional properties may need to be attached to this set of data: coherency of use in this context, simultaneousness of transport, same quality of service, periodicity� And here again, the need also exists to indicate that several exchanges should carry the same set of data.

Note that:

- An Exchange or port can implement many Exchange Items for complex communication;

- Data to be allocated to a port or exchange are in fact allocated to it through one or more Exchange items.

Exchange Item

An Exchange Item defines a communication media and a set of data

Exchange Items help in:

Field

Description

Default

Name

The name of the current Element.

<generic name>

Summary

A short headline about the role of the current Element.

<blank>

Exchange Mechanism

Data are exchanged between Functions or Components according to standard communication patterns. An Exchange Item therefore carries the communication mechanism specifying how its content is actually exchanged. Possible communication mechanisms for Exchange Items are: OPERATION, EVENT, FLOW, SHARED DATA. In the early stages of the engineering process, the communication mechanism applying to a given Exchange Item might not be known yet. In that case, UNSET can be used.

UNSET

Echange Item Elements

One or several references to elements from the Data Model (Data types, Classes, Unions, Collections, etc.). Adding references towards Data elements from this widget creates Exchange Item Elements and displays a dedicated editor allowing setting the properties of the newly created Exchange Item Element (name, type, cardinality, direction).

<blank>

Realized Exchange Items

One or several Exchange Items in the previous engineering phase refined by the current Exchange Item.

False

Event

Exchange Item with a communication mechanism set to EVENT.

Structured Data sent from one Component / Function and received by a unique receiver (unicast), a defined set of receivers (multicast) or an undefined set of receivers (broadcast).

It is possible to represent explicitly the Event in an IDB, along with Communication Links.

Using the Communication Link editor, it is possible to specify the SEND protocol. Here, BROADCAST is selected.

The Communication Link label on the Interface diagram is then updated.

Operation

Exchange Item with a communication mechanism set to OPERATION.

Piece of behavior with input and output parameters, executed by one Component / Function and requested by others. Operations can be synchronous or asynchronous.

It is possible to represent explicitly the Operation in an IDB, along with Communication Links.

Using the Communication Link editor, it is possible to specify the CALL protocol. Here, ASYNCHRONOUS is selected.

The Communication Link label on the Interface diagram is then updated.

Flow

Exchange Item with a communication mechanism set to FLOW.

Continuous or discrete Flow of information / material (fluid, electric power, calories, etc.) produced by a Component / Function and consumed by one or several others.

It is possible to represent explicitly the Flow in an IDB, along with Communication Links.

Using the Communication Link editor, it is not possible to specify the PRODUCE protocol, contrarily to the other kinds of Exchange Items.

Shared Data

The data referenced by the Exchange Item is:

It is possible to represent explicitly the Shared Data in an IDB, along with Communication Links.

Using the Communication Link editor, it is possible to specify the ACCESS protocol. Here, READ is selected.

The Shared Data can also be grouped in an Interface.

It is also possible to change the ACCESS protocol using the editor of Exchange Item Allocations. Here, ACCEPT is selected.

Exchange Item Element

Exchange Items are structured through Exchange Items Elements in the same way as classes are structured in Properties. These elements are in turn defined by classes, complex types and simple types.

An Exchange Item Element is either of Kind MEMBER or TYPE.

It has the following features:

When an Exchange Item has a communication mechanism of type OPERATION, its Exchange Item Elements are mandatorily of type MEMBER, and are used to define the parameters of this operation. It is also mandatory then to specify each parameter direction.

Naming Exchange Item Elements is mandatory when kind = MEMBER.

Note that for p11, isComposite must be true as Class1 does not have a key property, but p12 can be a reference (isComposite = False), as Class2 inherits its key from Class4.

Observe also that it is possible to restrain the Exchange Item Element to a subset of the Class (or data type) properties. In our example, parameter p 21 of Operation 2 could reference only property Class4::a21 through the �Referenced Properties� field.

When an Exchange Item has a communication mechanism of type EVENT, FLOW, or SHARED _DATA, its Exchange Item Elements are either of type MEMBER or TYPE,

If the Exchange Item Element is of Kind TYPE, the Exchange Item only owns this Exchange Item Element, and the structure of the Exchange Item is completely defined by the type of the Exchange Item Element, and its features: cardinality, �is composite�, �is ordered� and �is unique�.

Else, all its Exchange Item Elements are of type MEMBER, and each Exchange Item Element enables to define a structural property of the owning Exchange Item, in the same way as class [ properties] define structural properties of a class.

Interface

Interfaces are contracts specifying how components can interact with each other. Interfaces are defined by grouping Exchange Items.

Interfaces are implemented/provided or used/required by Components/ Components Ports. Each Component/ Component Port can implement - provide / use - require several Interfaces.

Interface building rules are:

Interface Definition Blank (IDB) diagram

An Interface Definition Blank (IDB) enables to create (/insert) Components, Ports, Interfaces, etc.

CEI and CDI diagrams

These two related diagrams are contextual diagrams, created from one specific Component (or from the System at System Analysis level).

The Contextual Component External Interfaces (CEI) diagram shows all the Interfaces of a Component ( / System) as well as all the relationship of these Interfaces with other Components / Actors.

The Contextual Component Detailed Interfaces (CDI) diagram shows all the Interfaces of a Component as well as their contained Exchange Items.

Interface Scenario (Vs. Functional Scenario and Exchange Scenario)

To illustrate the differences between the three different kinds of Scenarios, let us consider again the simple architecture represented by the following diagram:

A Functional Scenario enables to draw sequence messages representing Functional Exchanges between lifelines representing Functions.

It is nevertheless possible to show directly the conveyed Exchange Items instead of the Functional Exchanges on the diagram, by applying a specific filter.

An Exchange Interface Scenario enables to draw sequence messages representing Functional or Component Exchanges between lifelines representing Components. It is also possible to see the conveyed Exchange Items by applying the same filter.

An Interface Scenario enables to draw sequence messages representing directly Exchange Items between lifelines representing also Components.

Note that it is possible to create new Exchange Items on the fly, and even new Interfaces, instead of selecting existing ones.

A big difference between Scenario and Data Flow Blank diagrams is that you can specify duration constraints on scenarios, and also loops, alternatives or optional conditions with the �combined fragment� concept.

Note that it is also possible to display [ Shared Data] as Lifelines in Interface Scenarios, to explicitly show the READ / WRITE access to them.

The same is true for the [ Events].