Figure 22: Application Layer Metamodel
Note: This figure does not show all permitted relationships: every element in the language can have composition and aggregation relations with elements of the same type; furthermore, there are indirect relationships that can be derived as explained in Section 8.5.
The main structural concept for the application layer is the application component. This concept is used to model any structural entity in the application layer: not just (re-usable) software components that can be part of one or more applications, but also complete software applications, sub-applications, or information systems. Although very similar to the UML 2.0 component, our component concept strictly models the structural aspect of an application: its behavior is modeled by an explicit relationship to the behavioral concepts.
Also in application architecture, the inter-relationships of components are an essential ingredient. Therefore, we also introduce the concept of application collaboration here, defined as a collective of application components which perform application interactions. The concept is very similar to the collaboration as defined in the UML 2.0 standard [8], [12].
In the purely structural sense, an application interface is the (logical) channel through which the services of a component can be accessed. In a broader sense (as used in, among others, the UML 2.0 definition), an application interface defines some elementary behavioral characteristics: it defines the set of operations and events that are provided by the component, or those that are required from the environment. Thus, it is used to describe the functionality of a component. A distinction may be made between a provided interface and a required interface. The application interface concept can be used to model both application-to-application interfaces, which offer internal application services, and application-to business interfaces (and/or user interfaces), which offer external application services.
Also at the application layer, we distinguish the passive counterpart of the component, which we call a data object. This concept is used in the same way as data objects (or object types) in well-known data modeling approaches, most notably the “class” concept in UML class diagrams. A data object can be seen as a representation of a business object, as a counterpart of the representation concept in the business layer.
An application component is defined as a modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces.
An application component is a self-contained unit of functionality. As such, it is independently deployable, re-usable, and replaceable. An application component performs one or more application functions. It encapsulates its contents: its functionality is only accessible through a set of application interfaces. Co-operating application components are connected via application collaborations.
An application component may be assigned to one or more application functions, business processes, or business functions. An application component has (is composed of) one or more application interfaces, which exposes its functionality. Application interfaces of other application components may be used by an application component. The name of an application component should preferably be a noun.
Figure 23: Application Component Notation
Example
In the model below, a financial application is depicted as an application component consisting of two collaborating subcomponents for accounting and billing.
Example 16: Application Component
Application collaboration is defined as a (temporary) configuration of two or more components that co-operate to jointly perform application interactions.
An application collaboration specifies which components (have to) co-operate to perform some task. The collaborative behavior, including, for example, the communication pattern of these components, is modeled by an application interaction.
An application collaboration is a specialization of a component, and aggregates two or more (co-operating) application components. An application collaboration may be assigned to one or more application interactions or business interactions. An application interface may be used by an application collaboration, and an application collaboration may be composed of application interfaces. The name of an application collaboration should preferably be a noun.
Figure 24: Application Collaboration Notation
Example
In the model below, two components collaborate in transaction administration: an Accounting component and a Billing component. This collaboration performs the application interaction Administrate transactions.
Example 17: Application Collaboration
An application interface declares how a component can connect with its environment.
An application interface specifies how the functionality of a component can be accessed by other components (provided interface), or which functionality the component requires from its environment (required interface). An application interface exposes an application service to the environment. The same application service may be exposed through different interfaces.
In a sense, an application interface specifies a kind of contract that a component realizing this interface must fulfill. This may include parameters, protocols used, pre- and post-conditions, and data formats.
An application interface may be part of an application component through composition (not shown in the standard notation), which means that these interfaces are provided or required by that component, and can be used by other application components. An application interface can be assigned to application services or business services, which means that the interface exposes these services to the environment. The name of an application interface should preferably be a noun.
Figure 25: Application Interface Notation
Example
In the model below, an Accounting component is shown that provides an application interface for Transaction data exchange, and a Billing component that requires such an interface.
Example 18: Application Interface
A data object is defined as a coherent, self-contained piece of information suitable for automated processing.
An application function operates on a data object. A data object may be communicated via interactions and used or produced by application services. It should be a useful, self-contained piece of information with a clear meaning to the business, not just to the application level. Typical examples of data objects are a customer record, a client database, or an insurance claim.
A data object can be accessed by an application function, application interaction, or application service. A data object may realize a business object, and may be realized by an artifact. A data object may have association, specialization, aggregation, or composition relationships with other data objects. The name of a data object should preferably be a noun.
Figure 26: Data Object Notation
Example
In the model below, two application functions co-operate via an application service, in which a data object holding Transaction data is exchanged.
Example 19: Data Object
Behavior at the application layer can be described in a way that is very similar to business layer behavior. Also here, we make a distinction between the external behavior of application components in terms of application services, and the internal behavior of these components; i.e., application functions that realize these services.
An application service is an externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. The service concept provides a way to explicitly describe the functionality that components share with each other and the functionality that they make available to the environment. The concept fits well within the current developments in the area of web services. The functionality that an interactive computer program provides through a user interface is also modeled using an application service, exposed by an application-to-business interface representing the user interface. Internal application services are exposed through an application-to-application interface.
An application function describes the internal behavior of a component needed to realize one or more application services. In analogy with the business layer, a separate “application flow” concept is conceivable as the counterpart of a business process. Note that the internal behavior of a component should in most cases not be modeled in too much detail in an architectural description, because for the description of this behavior we may soon be confronted with detailed design issues.
An application interaction is the behavior of a collaboration of two or more application components. The UML 2.0 standard [8], [12] also includes the interaction concept. An application component is external behavior from the perspective of each of the participating components, but the behavior is internal to the collaboration as a whole.
An application function is defined as a representation of a coherent group of internal behavior of an application component.
An application function describes the internal behavior of a component; for the user of a component that performs an application function, this function is invisible. If its behavior is exposed externally, this is done through one or more services. An application function abstracts from the way it is implemented. Only the necessary behavior is specified.
An application function may realize application services. Application services of other application functions and infrastructure services may be used by an application function. An application function may access data objects. An application component may be assigned to an application function (which means that the application component performs the application function). The name of an application function should preferably be a verb ending with “-ing”; e.g., “accounting”.
Figure 27: Application Function Notation
Example
In the model below, the functionality of a Financial application is modeled as an application function consisting of two sub-functions.
Example 20: Application Function
Application interaction is defined as a unit of behavior performed by a collaboration of two or more components.
An application interaction describes the externally visible behavior that is performed by components that participate in an application collaboration. This may, for example, include the communication pattern between these components. An application interaction can also specify the externally visible behavior needed to realize an application service.
An application collaboration may be assigned to an application interaction. An application interaction may realize an application service. Application services and infrastructure services may be used by an application interaction. An application interaction may access data objects. The name of an application interaction should preferably be a verb.
Figure 28: Application Interaction Notation
Example
In the model below, an Accounting component and a Billing component of a financial system co-operate to compose an administrate transactions interaction. This is modeled as an application interaction assigned to the collaboration between the two components.
Example 21: Application Collaboration
An application service is defined as an externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment.
An application service exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces. An application service is realized by one or more application functions that are performed by the component. It may require, use, and produce data objects.
An application service should be meaningful from the point of view of the environment; it should provide a unit of functionality that is in itself useful to its users. It has a purpose, which states this utility to the environment. This means, for example, that if this environment includes business processes, application services should have business relevance.
A purpose may be associated with an application service. An application service may be used by business processes, business functions, business interactions, or application functions. An application function may realize an application service. An application interface may be assigned to an application service. An application service may access data objects. The name of an application service should preferably be a verb ending with “‑ing”; e.g., “transaction processing”. Also, a name explicitly containing the word “service” may be used.
Figure 29: Application Service Notation
Example
In the model below, a Transaction processing service is realized by the Accounting application function. This service is assigned to the Transaction data exchange interface and used by the Billing application function.
Example 22: Application Service
Table 2 gives an overview of the concepts at the application layer, with their definitions.
Table 2: Application Layer Concepts
|
Concept |
Definition |
Notation |
|
Application component |
A modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces. |
|
|
Application collaboration |
An application collaboration defines a (temporary) configuration of two or more components that co-operate to jointly perform application interactions. |
|
|
Application interface |
An application interface declares how a component can connect with its environment. |
|
|
Data object |
A coherent, self-contained piece of information suitable for automated processing. |
|
|
Application function |
A coherent group of internal behavior of a component. |
|
|
Application interaction |
A unit of behavior jointly performed by two or more collaborating components. |
|
|
Application service |
An externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. |
|
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C091.