Technology Interface : Archimate

A technology interface specifies how the technology services of a node can be accessed by other nodes. A technology interface exposes a technology service to the environment. The same service may be exposed through different interfaces.

In a sense, a technology interface specifies a kind of contract that a component realizing this interface must fulfill. This may include, for example, parameters, protocols used, pre- and post conditions, and data formats.

A technology interface may be part of a node through composition (not shown in the standard notation), which means that these interfaces are provided by that node, and can serve other nodes. A technology interface can be assigned to a technology service, to expose that service to the environment.
The name of a technology interface should preferably be a noun.

Technology Process : ArchiMate

A technology process describes internal behavior of a node; for the user of that node, this process is invisible. If its behavior is exposed externally, this is done through one or more technology services. A technology process abstracts from the way it is implemented. Only the necessary behavior is specified. It can use technology objects as input and use or transform these to produce other technology objects as output.

A technology process may realize technology services. Other technology services may serve (be used by) a technology process. A technology process may access technology objects. A node may be assigned to a technology process, which means that this node performs the process. The name of a technology process should clearly identify a series of technology behaviors; e.g., “System boot sequence” or “Replicate database”.

Technology Service : ArchiMate

A technology service exposes the functionality of a node to its environment. This functionality is accessed through one or more technology interfaces. It may require, use, and produce artifacts.
A technology service should be meaningful from the point of view of the environment; it should provide a unit of behavior that is, in itself, useful to its users, such as application components and nodes.
Typical technology services may, for example, include messaging, storage, naming, and directory services. It may access artifacts; e.g., a file containing a message.
A technology service may serve application components or nodes. A technology service is realized by a technology function or process. A technology service is exposed by a node by assigning technology interfaces to it. A technology service may access artifacts. A technology service may consist of sub-services.
The name of a technology service should preferably be a verb ending with “ing”; e.g., “messaging”. Also, a name explicitly containing the word “service” may be used.

Term

The denomination of a concept used by a party such as a person, a role or an organization unit.

Test Case

A specification of some test scenario that tests a specified aspect of an item.

Test Requirement

A component that holds summary information about what to a subsystem for.

Text Annotation

The Text Annotation template in QualiWare permits the user to add an object where any amount of text can be included on the diagram to support what is going on with one Activity, or other BPMN based template. The Text field on the Text Annotation tab in the Object Editor is where the text is entered and upon saving and closing the object editor, the text will appear on the diagram within the Text Annotation object. The Text Annotation is then linked to the applicable Activity or other object using the Association symbol/connector.

Association

A relationship between two classes.

In the Unified Modeling Language (UML), there are five different types of relationships: association, aggregation, composition, dependency, and inheritance.

Association is a semantically weak relationship (a semantic dependency) between otherwise unrelated objects. An association is a ‘using’ relationship between two or more objects in which the objects have their own lifetime and there is no owner.

As an example, imagine the relationship between a doctor and a patient. A doctor can be associated with multiple patients. At the same time, one patient can visit multiple doctors for treatment or consultation. Each of these objects has its own life cycle and there is no ‘owner’ or parent. The objects that are part of the association relationship can be created and destroyed independently.

In UML an association relationship can be represented as one-to-one, one-to-many, or many-to-many (also known as cardinality).

Assignment

Assigns a value to variables for the process.