HOPEX Aquila EN

FRAMEWORKS - HOPEX DoDAF V2 > Service Viewpoint Models > SvcV-2 Service Resource Flow Description

SvcV-2 Service Resource Flow Description

SvcV-2 Description

Purpose of SvcV-2

Detailed Description

SVcV-2 HOPEX Implementation

Services Hierarchy

Service Point Fulfillment

Functionality Dependencies

SvcV-2 Description

Purpose of SvcV-2

SvcV-2

SvcV-2 Service Resource Flow Description

A description of Resource Flows exchanged between services.

The SvcV-2 Service Resource Flow Description model describes Resource Flows exchanged between Services. Service definition includes, among other things, the definition of interfaces, and connecting the interfaces to service definition components.

Detailed Description

See the DoDAF web site: SvcV-2: Service Resource Flow Description.

SVcV-2 HOPEX Implementation

Services Hierarchy

This is a hierarchical description of services (functionalities, technical functionalities, hardware functionalities).

A functionality is a service required by an organization in order to perform its work. This functionality is generally necessary within an activity in order to execute a specific operation. If it is a software functionality, it can be provided by a system.

Service Point Fulfillment

An editor enables you to specify how services are fulfilled.

In this tile you only see the functionalities which have been selected in SVcV-1.

The Information Service Catalog provides a central source of information on the Information services delivered by the service provider organization. It provides the list of reference functionalities and their recommended implementation.

Here you can specify:

• which system(s) fulfill(s) a functionality (Realizer Agent column).

Only the objects/systems which have been selected in SVcV-1 appear here. For more information see Populating service catalogs and specify functionality fulfillment.

• through which exchange contract the functionality is realized (Service Port column).

The Service port is an exchange contract specified in the application structure diagram. For more information see SV1- Defining Systems.

Functionality Dependencies

This list displays functionality dependencies, together with the dependent and desired application effects.

A functionality dependency is a relationship which asserts that a functionality is dependent on another (required functionality), in the context of a Functionality Building Block (owner), with respect to its desired effect.

Functionality dependencies naming

You cannot change the name of a functionality dependency. The name is built as follows:

[Name of the dependent functionality] -> [Name of the required functionality]

Desired Effect

A desired application effect is the effect (or applicative outcome) desired by a functionality.

It can be required by another functionality through a functionality dependency.