A Recap from Part 11…
The Business, Application and Technology Layers are broken down into three types of concepts: Passive Structure, Behavior, and Active Structure. Passive structure elements are written to and read from by Active structure elements. Behavior elements describe the transaction between the Active and Passive structure elements as well as between Active structure elements.
Examples of Passive structure elements are contracts, data objects and products. Actors, roles, collaboration, and others represent active structure elements. Functions, processes, and events are some of the elements that represent behavior structure elements.
The following series of articles will cover Application Layer concepts. The Application Layer supports the business layer with application services, which are realized by (software) applications.
Application Layer Structural Concepts and Relationships
Application Component – a modular, deployable, and replaceable part of a software system that encapsulates its behavior and data and exposes these through a set of interfaces.
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, the ArchiMate component concept strictly models the structural aspect of an application: its behavior is modeled by an explicit relationship to the behavioral concepts.
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, has one or more application interfaces, which expose its functionality, and application interfaces of other application components may be used by an application component.
An application collaboration specifies which components 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 typically models a logical or temporary collaboration of application components, and does not exist as a separate entity in the enterprise.
An application collaboration:
- is a specialization of a component
- aggregates two or more (co-‐operating) application components
- is an active structure element that may be assigned to one or more application interactions or business interactions
An application interface may be used by an application collaboration.
An application collaboration may be composed of application interfaces.
Application interface – a point of access where an application service is made available to a user or another application component.
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.
An application interface may be part of an application component through composition, which means that these interfaces are provided or required by that component, and can be used by other application components.
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 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.
Next week’s article will cover Application Behavior concepts.
This blog includes extracts of the ArchiMate 2.0 Specification, Copyright © 2009-2012 The Open Group. ArchiMate® is a registered trademark of The Open Group. For the original material please refer to this page.