Wireless Future - Telenor

148
Each viewpoint constitutes a self-contained
specification of the system from a particular perspective.
In addition, certain mappings between
the viewpoints need to be established for the
integrity of the overall system to be maintained.
Because the target application is a model for
management, only the system aspects subject to
management, i.e. the management requirements,
need to be represented in the model. The management
requirements are expressed in terms of
actions with associated policies (enforcements
or restrictions). This is done in the Enterprise
Viewpoint and implies that the requirements
become an integrated part of the model itself.
Another, equally important implication is that
the Enterprise Viewpoint becomes a repository
for management requirements, i.e. the management
specification per se.
2.1 The Enterprise Viewpoint
When compared with the original version of the
RM-ODP framework, most of the changes pertain
to the Enterprise Viewpoint. A finer granularity
in the modelling approach is allowed,
namely that of the network resource types
defined in G.805. All the modelling constructs
in the other viewpoints are provided with unique
labels for backwards traceability to the functional
requirements in the Enterprise Viewpoint.
This is a fundamental mechanism for the support
of conformance testing of implementations and
also for requirement assessment during the specification
phase.
As previously mentioned, functional requirements
are modelled as actions invoked by a
caller role 3) and carried out by a provider role.
In this context, an object is an entity that can be
distinguished from other entities, has a separate
existence and is described in terms of actions,
policies and relationships with these other entities.
Actions are enforced or restricted by action
policies, that is – Permissions or Obligations
respectively – to provide additional level of
detail to the management specification. The
caller has no knowledge of how the action is
implemented. He only knows the action signature,
i.e. the action name and the action policies.
Actions naturally belonging together are
grouped into functional units called Communities.
Actions may also be combined in ordered
series, Activities, to realize more comprehensive
functionality. The provider may decide whether
the full action sequence or an abstracted view in
terms of a single high-level action is to be exposed
to the caller. It is possible to create new
communities by combining existing ones, by
adding new functionality or deleting parts of the
existing functionality. By taking advantage of
existing actions when defining new communities,
substantial reuse of specification and possibly
implementation may be achieved. Policies
may also be defined on the community- and the
activity levels.
For usage outside the context of its initial definition,
the functionality provided by a community
may be expressed through the Service Contract,
essentially a listing of the functional contents.
When making models on the Service Management
level, the service contract may be used to
define the technical part of the Service Level
Agreement (SLA), the Service Level Specification
(SLS).
In addition to capturing the functional requirements
the Enterprise Viewpoint also serves as
the road map towards the other viewpoints.
Actions in the Enterprise Viewpoint map to
interface operations in the Computational Viewpoint.
The client and provider roles map to computational
objects. Enterprise actions are normally
concerned with the manipulation (create,
delete, associate, etc.) of G.805 network resources
such as trails, access groups, link connections,
etc. Network resources map to objects,
attributes or relationships in the Information
Viewpoint.
When passing from the less formal architectural
description of network resources in G.805 to a
formal network model, additional element behaviour
needs to be settled. Rec. G.852.2 [8]
does that for the elements in G.805 and also provides
definitions for some important elements
currently missing in G.805.
An extract from the Enterprise Viewpoint specification
for trail management showing the community
policy, role, action and service contract
definitions for trail termination point creation is
shown below.
COMMUNITY trail management (tm)
COMMUNITY_POLICY
OBLIGATION signalId
“Each resource in the community shall have the
same signal identification”. 4)
ROLE
tm_caller
“This role reflects the client of the actions
defined within this community. One and only
one caller role occurrence must exist in the
community.”
3) In RM-ODP, a role is a fraction of the behaviour of an object, in this case an Enterprise object.
4) This is the same as requiring each resource to be part of the same layer network domain (LND).
Telektronikk 1.2001