3.2.2.2 Information Attribute: Link
Directionality (example)
DEFINITION
“The link directionality attribute character-
izes the ability of the associated resource to
carry traffic in one, two or undefined direc-
tion.”
STATE
undefined
“There is no indication on the ability of
the resource to carry the signal in one or
two directions.”
unidirectional
“The resource is able to carry the signal
in only one direction from A_end to
Z_end.”
bidirectional
“The resource is able to carry the signal
in two directions.”
3.2.2.3 Information Relationship:
Topological Link is Supported
by Trail (example)
This relationship type is related to the following
enterprise entity:
<COMMUNITY:tem,ROLE:topological
link,PROPERTY:adaptation_relation>,
<COMMUNITY:tem,ROLE:trail,PROPERTY:
adaptation_relation>
DEFINITION
“The topologicalLinkIsSupportedByTrail
relationship class describes the relationship
that exists between topologicalLinks of a
given layer network (known as the client
layer network) and the trail that supports
them in a server layer network.”
ROLE
clientTL
“Played by instances of the<topologi-
calLink> information object type or
subtype.”
serverTrail
“Played by an instance of the
information object type or subtype.”
INVARIANT
inv_serverTrailRoleCardinality
“One and only one instance of the role
serverTrailmust participate in the rela-
tionship.”
inv_clientTLRoleCardinality
“At least one instance of the clientTL
must participate in the relationship.”
inv_directionality
“If the information object playing the
role serverTrailis bidirectional, then the
information objects playing the role
clientTLmust be bidirectional.”
inv_signalIdentification
“In a given relationship instance of topo-
logicalLinkEndSupportedByNetwork-
TTP, the information object playing the
role servertrailmust have a different signalIden-
tification value than the information object play-
ing the role clientTLas defined in Recommenda-
tion G.805 (compliant values are technologies
dependent and defined in the corresponding
Recommendations, e.g. G.783 for SDH).”Potential relationships are not inherited in a sub-
class specification. Mandatory relationships are,
however, inherited.3.2.3 The Computational Viewpoint
The Computational Viewpointdescribes the
functional decomposition into structures suitable
for distribution. The dynamic behaviour of the
system is described in terms of interactions be-
tween Computational Objectsthat support Com-
putational Interfaces, and Dynamic Invariants
(dynamic constraints) on the objects and their
interfaces. For each interface, a set of Computa-
tional Operationsis defined.Each operation is invoked providing a number of
input parameters and upon successful execution,
a number of output parameters are returned.
Each parameter has a name, type specifier and
a value assigned. Every parameter is mapped to
the corresponding element in the Information
Viewpoint in the Parameter Matching clause.The computational objects may have Opera-
tionaland Notification Interfaces. For each suc-
cessful operation, a report operation notifying
relevant external recipients is generated.The invariant state of a system before and after
the execution of an operation is specified by
defining the state of the relationships and
attributes supported in the form of a set of Pre-
and Post Conditions. This is part of the “Design
by contract” methodology described in [OOsw].
Whenever an invariant is violated, a specific
exception is raised. For each exception, an
explanatory text as well as a type specifier are
provided.The operations are mapped to the corresponding
actions in the Enterprise Viewpoint.Operational interfaces are specified in terms of
Operation Signaturesand associated Behaviour.
The operations are described in a communica-Figure 10 The topological link
is supported by trail
topologicalLink relationshipTrail