Nato Architecture Framework (NAF) - 4.5 - NATO Meta Model - NSOV
Alternative notations。
- In practice a lot of organization uses other notations for modellign services
- At the moment the most popular is SoaML
- As to the metamodel to make it operative, it is common to use Modaf Metamodel instead of NAF (as v3.1 does anyway)
NATO Service-Oriented Views (NSOV)
NSOV-1 Service taxonomy。
NSOV-1 is a service taxonomy, describing a specialisation hierarchy of services (note these are classes of services, rather than the service implementations). There is no prescribed representation for this view, other than the ability to show multiple inheritances. The view may optionally show properties (e.g. service availability) and constraints on those properties, though this is covered in detail in NSOV-2.
Nato Architecture Framework (NAF) - 3.4 - NATO Service-Oriented View#NSOV-1.2C_Service_Taxonomy
NSOV-2 Service definitions。
The NSOV-2 view specifies the properties of services and defines the interface of the service explicitly. NMM supports specific stereotypes to manage interfaces, ports as well as asynchronous messages and synchronous operations handling as part of the service interface. It should be noted that only one interface of a service may be exposed to the surrounding environment and that this is the interface that can be accessed by a service consumer.
Nato Architecture Framework (NAF) - 3.4 - NATO Service-Oriented View#NSOV-2.2C_Service_Definitions
NSOV-3 Service orchestration。
This view specifies how services can be combined and sequenced to provide a ‘higher level’ service. Note that there might be several instances (products) of this view since there are generally several different possible service combinations. The view is best presented by means of a UML composite structure diagram but other possibilities also exist. It should be noted that no decision concerning implementation of the service is actually made in this view – i.e. the orchestration is a requirement specification rather than a design. In fact, none of the service subviews describe the implementation of the services - this is covered in the NSV-12 view.
Nato Architecture Framework (NAF) - 3.4 - NATO Service-Oriented View#NSOV-4.2C_Service_Orchestration
NSOV-4 Service to operational activities mapping。
This view shows how operational activities can be supported by various services, i.e. within a given scenario, certain defined operational activities within nodes defined as part of NOV-2 can be supported by a given set of services.
NSOV-5 Service state transition, activity and event-trace descriptions。
This view enables the description of a service by means of a state-diagram, an activity model or by an event-trace description. In order to fully define the sequencing of messages and operations that form part of the service interface, event-trace descriptions are useful. In order to fully define the handling that takes place in a service due to possible different internal states, a state description is also useful. For all of these descriptions standard UML entities provide the best means of representation.
Nato Architecture Framework (NAF) - 3.4 - NATO Service-Oriented View#NSOV-5.2C_Service_Behaviour
NSOV metamodel diagrams。
NSOV-2 Service definitions
NSOV-3 Service orchestration。
NSOV-4 Services to operational activities mapping。
NSOV-5 Service state transition, activity and event-trace descriptions。
NSOV metamodel glossary。
| Element | Definition |
|---|---|
| AsynchronousMessage | A signal which is transmitted irregularly with respect to time.
Note: An asynchronous message is not guaranteed to arrive in a specific time following a request. |
| MessageHandler | An aspect of a <<ServiceInterfaceDefinition>> which receives incoming <<AsynchronousMessage>>s. |
| Service | A type of delivered functionality, specified independently of the capabilities that provide it.
Note: A service may or may not have a physical effect on its environment. OASIS Definition: A service is a mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. |
| ServiceAimsToAchieve | Asserts that a <<Service>> is intended to deliver a <<Capability>>.
Note: multiple instantiations of this element may be required, as it is likely that more than one service is required to achieve a capability. |
| ServiceAttribute | A property of <<Service>>.
Example: availability |
| ServiceComposition | An assertion that a <<Service>> (parentService) calls upon another <<Service>> (childService) in order to deliver its stated functionality. |
| ServiceConnectorEnd | One of two ends of a <<ServiceNeedline>>. |
| ServiceConsumer | A UML::Actor representing an unknown service user. |
| ServiceFunction | A type of activity describing the functionality of a service. |
| ServiceGeneralisation | An assertion that one <<Service>> class is a specialisation of another. |
| ServiceInteractionSpecification | A model representing how a set of <<Service>> classes interacts with one another. |
| ServiceInterface | The mechanism by which a <<Service>> communicates.
Note: a <<ServiceInterface>> specifies the <<ServiceInterfaceDefinition>> provided and required by the <<Service>>. |
| ServiceInterfaceDefinition | The specification of a provided or required communication method exposed by a <<ServiceInterface>>. |
| ServiceInterfaceOperation | A function or procedure which enables programmatic communication with a <<Service>> via a <<ServiceInterface>>. |
| ServiceInterfaceParameter | A constant or variable passed into or out of a <<ServiceInterface>> as part of the execution of a <<ServiceInterfaceOperation>>. |
| ServiceInterfaceSchema | An assertion that a <<PhysicalDataModel>> defines the data structure used by a <<ServiceInterface>> when communicating with a <<Service>> or client. |
| ServiceLevel | A value specification for a set of <<ServiceAttribute>>s indicating the level to which a <<CapabilityConfiguration>> delivers a <<Service>>.
Example: A <<ServiceAttribute>> ‘availability’ may be defined against a <<Service>>. A given <<CapabilityConfiguration>> could have a corresponding <<ServiceLevel>> - e.g. ‘90%’. |
| ServiceLifeLine | A part of a <<ServiceInteractionSpecification>> denoting the role of a <<ServiceInterface>>. |
| ServiceNeedline | An assertion that two <<Service>>s need to communicate when assembled together under another <<Service>> |
| ServiceParameterType | Either a UML::DataType or a <<ServiceInterfaceParameter>>. [ABSTRACT] |
| ServicePolicy | A constraint governing one or more <<Service>>s. |
| ServiceProvision | An assertion that a <<CapabilityConfiguration>> delivers a <<Service>> to a specified <<ServiceLevel>>. |
| ServiceStateMachine | A model representing the changes of state which are possible for a <<Service>>. |
| ServiceSupportsActivity | An assertion that a <<Service>> in some way contributes or assists in the execution of an <<OperationalActivity>>. |
