U.S. patent application number 09/124479 was filed with the patent office on 2001-12-27 for mechanism for integration of management functionality in communications networks.
Invention is credited to BRAGG, NIGEL LAWRENCE, HAYBALL, CLIVE COLIN, ROSS, NIALL FORBES, TATTERSFIELD, PETER JAMIESON.
Application Number | 20010056481 09/124479 |
Document ID | / |
Family ID | 22415131 |
Filed Date | 2001-12-27 |
United States Patent
Application |
20010056481 |
Kind Code |
A1 |
HAYBALL, CLIVE COLIN ; et
al. |
December 27, 2001 |
MECHANISM FOR INTEGRATION OF MANAGEMENT FUNCTIONALITY IN
COMMUNICATIONS NETWORKS
Abstract
There is presented a method for integrating management
functionality in communications networks by virtue of a design
model for constructing a management information base in a
communications network management system. A unit of manageable
physical resources is represented in the management information
base by a management unit. The management unit comprises a
collection of managed objects representing actual physical and
logical resources in the communications network, the managed
objects arranged such that functionality provided by the physical
and logical resources is represented separately and independently
from the actual physical and logical resources themselves, in the
particular way in which those resources are implemented. A unit of
manageable functionality and resources is represented in the
management information base by a management unit. A management unit
comprises an Application Model, which represents functionality of
those resources, and an Implementation Model, which represents the
actual specific implementation of how that functionality is carried
out. The Application Model and Implementation Model are related to
each other by a set of associations, presented in the disclosure,
termed "realisation associations". A collection of realisation
associations which link an Application Model to an implementation
form a realisation model. Division and representation of physical
and logical resources in the management information base by the
management unit method may enable substitution of physical and
logical resources by different implementations of similar resource
components without requiring re-configuration of parts of the
management information base which represent the functionality
provided by those physical resources. Greater reuse of design and
development effort may be achieved by configuring the management
information base in the method disclosed, and easier maintenance
and replaceability of physical and logical components may be
achieved.
Inventors: |
HAYBALL, CLIVE COLIN;
(HERTFORDSHIRE, GB) ; BRAGG, NIGEL LAWRENCE;
(CAMBRIDGE, GB) ; ROSS, NIALL FORBES; (ESSEX,
GB) ; TATTERSFIELD, PETER JAMIESON; (ESSEX,
GB) |
Correspondence
Address: |
WILLIAM M. LEE, JR.
LEE, MANN, SMITH, MCWILLIAM, SWEENEY &
OLSON
P.O. BOX 2786
CHICAGO
IL
606902786
|
Family ID: |
22415131 |
Appl. No.: |
09/124479 |
Filed: |
July 29, 1998 |
Current U.S.
Class: |
709/223 ;
715/736 |
Current CPC
Class: |
Y10S 715/969 20130101;
H04L 41/024 20130101; H04L 41/00 20130101; H04L 41/0233
20130101 |
Class at
Publication: |
709/223 ;
345/736 |
International
Class: |
G06F 015/173; G09G
005/00 |
Claims
1. A network management system for managing a communications
network, said management system comprising: at least one processor;
and a data storage device, wherein functionality and resources of
said communications network are represented by managed objects, and
at least one association links classes of said managed objects
representing said functionality with classes of said managed
objects representing said resources.
2. The network management system according to claim 1, wherein said
associations are contained within at least one realisation
model.
3. The network management system according to claim 2, wherein said
realisation model comprises at least one realised by
association.
4. A method of creating a network management system for managing a
communications network wherein functionality and resources of said
communications network are represented by managed objects, said
method comprising the step of: creating at least one association
linking classes of said management objects representing said
network functionality with classes of said managed objects
representing said network resources.
5. The network management system according to claim 1, wherein said
classes and said associations are represented by means of object
oriented modeling.
6. A design method for creating a management system for managing a
plurality of physical and logical resources, said design method
comprising the steps of: identifying a unit of said resources to be
managed as a whole; at least one function is carried our by said
managed unit; for each of said managed units, representing said
functions by a "black box" representation in which said
functionality is represented as a set of managed objects,
independently of the specific physical resources which provide said
functionality; for each said "black box" managed object
representation of functionality, representing physical and logical
resources which implement said functionality by at least one "white
box" managed object representation; and associating said "black
box" managed object representations with their corresponding "white
box" representations by means of a plurality of associations.
7. The method as claimed in claim 6, wherein a plurality of said
"black box" representations are collectively associated with a
corresponding plurality of said "white box" managed object
representations, by a plurality of corresponding said
associations.
8. In a management system for managing a plurality of physical and
logical resources co-operating to provide communications
functionality, said management system comprising a data processing
means and a data storage means, a method of representing said
physical resources by a plurality of managed object models
comprising: a management unit object model, said management unit
object model comprising a model of "black box" managed objects
representing a functionality provided by said resources
independently of implementation of said functionality; a plurality
of "white box" managed objects, said "white box" managed objects
representing implementation of said functionality by said plurality
of physical resources; and a plurality of associations, said
associations connecting a plurality of endpoints and capabilities
of said "black box" managed objects with a corresponding set of end
points and capabilities of said "white box" managed objects.
9. The method as claimed in claim 8, wherein a said "black box"
managed object comprises a said endpoint.
10. The method as claimed in claim 8 wherein a said endpoint
comprises a managed object representing a physical endpoint.
11. The method as claimed in claim 8, wherein a said endpoint
comprises a managed object representing a logical endpoint.
12. The method as claimed in claim 8, wherein a said capability
comprises a managed object representing a behavior which represents
transformation of data between at least one endpoint and at least
one said "black box" managed object.
13. The method as claimed in claim 8, wherein a said capability
comprises a managed object representing a cross-connection between
first and second physical or logical endpoints.
14. The method as claimed in claim 8, wherein a said capability
comprises a managed object representing an interworking function
between first and second physical or logical endpoints.
15. The method as claimed in claim 8, wherein a said "black box"
managed object comprises a behavior object, said behavior object
representing interconnections between said physical resources.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to network management and
particularly, although not exclusively, to a method of
implementation of a management system.
BACKGROUND TO THE INVENTION
[0002] The advent of broadband networks' technologies such as ATM
and SDH is causing network operators and suppliers to re-think the
way in which telecomms systems are constructed and managed.
Monolithic network elements such as tandem switches are now being
replaced or augmented by a new generation of systems which comprise
loosely coupled elements distributed across a broadband
infrastructure. Furthermore, the services offered by such systems
need not map precisely onto a set of dedicated elements, as the
various elements can now share their resources across services in a
flexible manner.
[0003] This decoupling of services from elements and resources
presents new management challenges. Services offered by such
systems must be managed, as they are the primary instrument of
revenue generation for network operators. Equipment and resources
must also be managed in order to support services effectively.
Additionally, management of services needs to be coupled with
management of equipment and resources in order to automate those
management processes, such as flow-through provisioning and service
impact analysis, which contribute to efficient, cost-effective
operations.
[0004] These new systems have the following characteristics which
impact upon their manageability.
[0005] Systems and services are composed from logical resources
(e.g. resilient processing platforms, diversely routed connections)
which are themselves constructed out of physical components and
assemblies of components. Integrated management requires
manipulation of the relationships between components and resources
within each service context.
[0006] Systems are Quality-of-Service (QoS) users of a Virtual
Private Network (VPN) overlay onto the underlying broadband
network. Details of the broadband network should be hidden from
these systems in all but exceptional circumstances.
[0007] Equipment types are heterogeneous, multi-technology and
potentially multi-vendor. Because these systems incorporate novel
and proprietary approaches to the provision of services, there are
usually no standard information models to support management at the
levels of equipment and logical resources.
[0008] Services are complex and need to be managed separately from
the logical and physical resources out of which they are
constructed.
[0009] Speed-to-market pragmatics demand reuse of resource
management functionality across different systems and services
wherever possible.
[0010] Prior art inventions have addressed this problem from
several perspectives. Blau, Eneroth and Carlsund (WO 95/34974)
proposed creating "black-box" and "white-box" models on an
interface between an operations support network and a managed
system, with a hierarchical composition of models based on the ITU
"managed element" concept. Hayball, Bragg and Tattersfield in U.S.
Ser. No. 08/921,649 and U.S. Ser. No. 08/921,225 the contents of
which are incorporated herein by reference, have proposed a design
method and management system architecture which separates
management of equipment from management of application and allows
potentially many different interface "views" to be supported. These
inventions address the desired structure of management systems
(internally) and interfaces (externally), but do not provide a
consistent, comprehensive means to link the models and/or
interfaces together in order to support truly integrated systems
management.
SUMMARY OF THE INVENTION
[0011] This invention introduces a concept of a "realised-by"
association to extend the ITU TMN framework to support integrated
management. The invention is targeted towards integrated management
of systems and services constructed from distributed elements
(hereafter known as "the network" ). It is therefore applicable to
several levels of the TMN hierarchy (network element, element
management, network management and potentially service management).
The invention is also equally applicable to the way in which data
and functionality is structured within a managed system and to the
way in which management functionality is exported across a
management interface, such as Q3 interface, to an Operations
Support System (OSS) or other user.
[0012] Aspects of the present invention combine with the teaching
of U.S. Ser. No. 08/921,649 and U.S. Ser. No. 08/921,225 to form an
overall network modeling method, with an object of raising of the
semantic level at which a network is managed in away that is
compatible with existing standards. The network modeling method
systematically groups low-level Managed Object classes found in a
Management Information Base (MIB) schema of a typical network
management into higher-level units of modeling. These higher level
models represent the network to the management system and are the
means by which the management system applies commands to the
network.
[0013] According to a first aspect of the present invention there
is provided a network management system for managing a
communications network, said management system comprising:
[0014] at least one processor; and
[0015] a data storage device,
[0016] wherein functionality and resources of said communications
network are represented by managed objects, and at least one
association links classes of said managed objects representing said
functionality with classes of said managed objects representing
said resources.
[0017] The processor and data storage device cooperate for
management of said communications network by storing said managed
objects and by performing operations on said managed objects, which
are replicated by corresponding operations carried out on physical
resources such as network elements and components represented by
said managed objects.
[0018] A plurality of said associations may be contained within a
realisation model.
[0019] The realisation model preferably comprises at least one
realised by association.
[0020] Preferably, the associations comprise pointer attributes of
classes of said managed objects representing said network
functionality and said network resources.
[0021] According to a second aspect of the present invention, there
is provided a method of creating a network management system for
managing a communications network wherein functionality and
resources of said communications network are represented by managed
objects, said method comprising the step of:
[0022] creating at least one association linking classes of said
management objects representing said network functionality with
classes of said managed objects representing said network
resources.
[0023] Preferably said classes and said associations are
represented by means of object oriented modeling.
[0024] According to a third aspect of the present invention there
is provided a design method for creating a management system for
managing a plurality of physical and logical resources, said design
method comprising the steps of:
[0025] identifying a unit of said resources to be managed as a
whole;
[0026] for each of a plurality of functions carried out by said
managed unit, representing said function by a "black box"
representation in which said functionality is represented as a set
of managed objects, independently of the specific physical
resources which provide said functionality;
[0027] for each said "black box" managed object representation of
functionality, representing physical and logical resources which
implement said functionality by at least one "white box" managed
object representation; and
[0028] associating said "black box" managed object representations
with their corresponding "white box" representations by means of a
plurality of associations.
[0029] Suitably, a plurality of said "black box" representations
are collectively associated with a corresponding plurality of said
"white box" managed object representations, by a plurality of
corresponding said associations.
[0030] According to a fourth aspect of the present invention there
is provided a management system for managing a plurality of
physical and logical resources co-operating to provide
communications functionality, said management system comprising a
data processing means and a data storage means, a method of
representing said physical resources by a plurality of managed
object models comprising:
[0031] a management unit object model, said management unit object
model comprising a model of "black box" managed objects
representing a functionality provided by said resources
independently of implementation of said functionality;
[0032] a plurality of "white box" managed objects, said "white box"
managed objects representing implementation of said functionality
by said plurality of physical resources; and
[0033] a plurality of associations, said associations connecting a
plurality of endpoints and capabilities of said "black box" managed
objects with a corresponding set of end points and capabilities of
said "white box" managed objects.
[0034] A said association comprises an asymmetric relationship.
[0035] A said endpoint may comprise a managed object representing a
physical endpoint.
[0036] A said endpoint may comprise managed object representing a
logical endpoint.
[0037] A said capability may comprise a managed object representing
a behavior which represents transformation of data between at least
one endpoint and at least one said "black box" managed object.
[0038] A said capability may comprise a managed object representing
a cross- connection between first and second physical or logical
endpoints.
[0039] A said capability may comprise a managed object representing
an interworking function between first and second physical or
logical endpoints.
[0040] A said "black box" managed object may comprise a behavior
object, said behavior object representing interconnections between
said physical resources
BRIEF DESCRIPTION OF THE DRAWINGS
[0041] For a better understanding of the invention and to show how
the same may be carried into effect, there will now be described by
way of example only, specific embodiments, methods and processes
according to the present invention with reference to the
accompanying drawings in which:
[0042] FIG. 1 illustrates schematically an association between a
specification object and an implementation object representation
part of a management information base for a communications
network;
[0043] FIG. 2 illustrates schematically a Management Unit Model
representing in a management information base a unit of manageable
physical and/or logical resources in a physical network;
[0044] FIG. 3 illustrates schematically a "black box" Application
Model representation of a cross-connect device providing conversion
of 64 k voice channels between a time division multiplex regime and
an asynchronous transfer mode regime;
[0045] FIG. 4 illustrates schematically a "white box"
Implementation Model which represents actual physical and/or
logical resources for carrying out the functionality represented by
the "black box" representation of FIG. 3 herein;
[0046] FIG. 5 illustrates schematically a model of managed objects
linking the "black box" representation of FIG. 3 with the "white
box" representation of FIG. 4, by means of a plurality of
associations which realise individual components of the "black box"
representation by their corresponding individual components in the
"white box" representation;
[0047] FIG. 6 illustrates schematically an example of a managed
object representation of a "Y" joint used to couple a single E1
interface into two separate powered termination units for a logical
adaptor apparatus;
[0048] FIG. 7 illustrates schematically a management model of a
unit of physical/logical resources comprising a logical adaptor,
implemented by a physical adaptor, and illustrating a plurality of
realised by associations linking managed objects representing the
logical adaptor functionality with the physical implementation
provided by the physical adaptor;
[0049] FIG. 8 illustrates schematically how a logical adaptor which
is physically realised by a logical line card in an ATM switch by a
protected ATM link and a plurality of unprotected ATM links is
represented by managed objects in a managed object model, which may
be used for construction of a management information base of a
communications network;
[0050] FIG. 9 illustrates schematically a fragment of the
management object model of FIG. 8 which corresponds to the
protected link functionality;
[0051] FIG. 10 illustrates schematically a Management Unit Model
for the distribution and replication of software applications
across a set of processors;
[0052] FIG. 11 illustrates schematically an example of a particular
case of distribution and replication;
[0053] FIG. 12 illustrates schematically how a "black box" object
representing a cross-connect function is implemented in terms of a
"white box" cross-connect object and a "white box" link object, by
means of realisation association, and how a "black box" object
representing a link is implemented by a "white box" implementation
object of a link and a "white box" Implementation Model of a
cross-connect, the "black box" and "white box" representations
being connected by means of "realised by" associations according to
specific implementations of the present invention;
[0054] FIG. 13 illustrates schematically a representation of an ATM
virtual circuit connection linking first and second end systems by
first and second sub-networks;
[0055] FIG. 14 illustrates schematically a generic management
object model corresponding to the virtual circuit connection of
FIG. 13 herein;
[0056] FIG. 15 illustrates schematically a representation of a data
table and its realisation in terms of a set of data tables;
[0057] FIG. 16 illustrates schematically a simplified Management
Unit Model diagram:
[0058] FIG. 17 illustrates schematically a simplified general
Management Unit Model diagram;
[0059] FIG. 18 illustrates schematically a general Application
Model diagram; and
[0060] FIG. 19 illustrates schematically a virtual circuit
connection trail being realised by two virtual circuit links and a
virtual circuit cross-connect according to a specific method of the
present invention.
DETAILED DESCRIPTION OF THE BEST MODE FOR CARRYING OUT THE
INVENTION
[0061] There will now be described by way of example the best mode
contemplated by the inventors for carrying out the invention. In
the following description numerous specific details are set forth
in order to provide a thorough understanding of the present
invention. It will be apparent however, to one skilled in the art,
that the present invention may be practiced without limitation to
these specific details. In other instances, well known methods and
structures have not been described in detail so as not to
unnecessarily obscure the present invention.
[0062] Referring to FIG. 1 herein, there is illustrated
schematically an association, hereinafter termed a "realised by"
association, represented using Unified Modeling Language (UML)
notation. UML notation was devised by Booch, Rumbaugh and Jacobson
and is known to those skilled in the art (see for example "UML
Distilled" by Martin Fowler, published by Addison Wesley 1997). It
will be appreciated by a person skilled in the art that whilst UML
notation is used herein for description of specific methods and
processes according to the present invention, the underlying
methods, processes and apparatus according to the invention are
independent of the languages and notations used to describe their
specific implementation. Other semantically equivalent
object-oriented (OO) notations can be used.
[0063] The "realised by" construct comprises a specification object
101, one or more implementation objects 102, and an association 103
connecting the specification object and the implementation
objects.
[0064] That is to say, a set of underlying physical resources
comprising a physical communications network perform a defined
functionality. The managed functionality is described in a
management information base by the specification object 101. The
actual managed physical and logical resources implementing the
functionality are described and represented in the management
information base by data in terms of one or more implementation
objects 102. Each implementation object 101 helps realise the
specification object 102 by providing data and behavior describing
the actual managed physical and logical resources through which the
managed functionality described by the specification object 101 is
actually implemented. The realised by association represents that a
certain unit of functionality is implemented by specific physical
and logical resources within a network, the functionality
represented by the specification object and the physical/logical
resources specified by the implementation object, by associating
the specification object with the implementation object, the
realised by association represents the actual realisation of
functionality by physical and logical components in the
network.
[0065] Within a management information base of the management
system of the communications network, a plurality of realised by
associations are collectively grouped to form a Realisation Model.
Referring to FIG. 2 herein, in the specific implementation herein,
a taxonomy of models and their relationships has been developed,
which forms a plan for an overall construction of a management
information base. Referring to FIG. 2, a Management Unit Model 200
comprises an Architecture Model 201 or an Equipment Model 202. The
Architecture Model 201 comprises an Application Model 203, an
Implementation Model 204, and linking the Application Model and
Implementation Model a Realisation
[0066] Model 205. The Equipment Model 202 comprises a second
Application Model 206, an external Implementation Model 207, and
linking the second Application Model and external Implementation
Model, a second Realisation Model 208.
[0067] An Architecture Model is composed of a plurality of a lower
level models, whereas an Equipment Model communicates directly with
actual physical managed equipment or with an external management
system. An Architecture Model contains an Application Model which
is realised by an Implementation Model, whereas an Equipment Model
contains an Application Model which is realised by external managed
resources. Architecture Models exist wholly within the modeling
system described herein. An Equipment Model exists at the boundary
between the modeling system described herein and the resources
these models help to manage.
[0068] The Application and Implementation Models comprise
assemblies of specific specification and implementation classes
respectively. These concepts are disclosed in prior disclosures
U.S. Ser. No. 08/921,649 and U.S. Ser. No. 08/921,225, the contents
of which are incorporated herein by reference.
[0069] Realisation Models comprise assemblies of specific "realised
by" associations. The concept of a Realisation Model is presented
in this disclosure in further detail by way of examples
hereinafter.
[0070] A Management Unit Model is built from an Application Model,
an Implementation Model and a Realisation Model. The concepts of a
Management Unit Model and its specializations are also presented
herein.
[0071] Whereas prior art management information base schema merely
capture the state of managed objects and how they are connected,
the methods and implementations presented herein capture and
organize the information of how high-level (more abstract)
capabilities of a network are realised in terms of lower-level
(more specific) ones. The Realisation Model provides a basis for
the modeling of how managed capabilities of individual system
elements combine to form more abstract managed capabilities.
[0072] The "realised by" association enables a simple, consistent
approach to integrated management of distributed, multi-component
telecommunications systems and may provide users of a managed
system with the ability to see and manage system entities at a
variety of levels, both physical and logical, with mappings between
levels to ensure that the managed system functionality can support
a close fit to the needs of individual operational practices. This
may result in significant reduction in operational costs.
[0073] Additional benefits arise from the organization of "realised
by" associations into Realisation Models, and of Application,
Implementation and Realisation Models into Management Unit Models
as follows:
[0074] Firstly, flow-through provisioning often requires observing
constraints between several "realised by" associations. The
Realisation Model provides the unit for managing such constraints,
and the similar constraints that occur in other network management
functions handled on a flow-through basis, either downward from
Application Model to Implementation Model or upward as in service
impact analysis.
[0075] Secondly, an ability to construct different Management Unit
Models containing a same top-level Application Model supports
resilience in the face of changes in the kinds of network
elements.
[0076] Thirdly, the Realisation Models' reflection of how the
network elements support each other assists in distributing network
management functionality compatibly with the distribution of the
network itself.
[0077] Specific implementations according to the invention may be
explained at two levels as follows:
[0078] a Managed Object level of network description
[0079] a model level of network description (hereinafter called the
Management Unit level).
[0080] The management unit level organizes the managed object-level
classes and relationships into models. Each model is a
configuration of managed object-level classes and relationships
representing some manageable unit of network functionality. Each
model corresponds to one of the kinds defined by the method. The
method requires several kinds of model. All models are expressed
herein in UML, a known standard object oriented modeling
notation.
[0081] The next section of this description presents the managed
object-level "realised by" association and illustrates it by
example in the context of various models. The section following
presents management unit-level Realisation and Management Unit
Models.
[0082] The "Realised By" Association (Managed Object Level)
[0083] The examples which follow illustrate the best mode
contemplated by the inventors for deploying the "realised by"
association mechanism. They show how this management construct can
be applied consistently to a variety of management situations,
including application-to-equipment mappings, equipment, line and
software protection, communications layer mappings and data table
mappings.
[0084] The best way to implement the "realised by" association is
by means of pointer attributes. The specification object implements
functionality which uses the "realised by" pointer(s) to access
implementation objects pertinent to the job in hand. Conversely,
each implementation object contains pointer attributes to the one
or more specification objects it realises; it implements
functionality which uses these pointers to convey information to
its specification objects concerning its ability to provide the
quality of service desired by these specifications. In general, the
specification-to-implementation pointers support flow-through
provisioning and the implementation-to-specification pointers
support service impact analysis.
[0085] Other options are open to the implementor, e.g. by means of
a separate "realised by" managed object providing an explicit
representation of the association or by using inheritance to
realise the implementation objects as specializations of their
specifications.
EXAMPLE 1
Application-to-Equipment Mapping
[0086] FIG. 3 provides a protocol model of a cross connect
application, which converts 64 K voice channels between TDM (as
DS0s on an E1 interface) and ATM (as AAL1 VCCs). Individual DSO
cross-connections are controlled using Q.2931 signaling from some
external system. ATM physical interfaces are 1+1 protected to
provide resilience against single failures such as fiber
breaks.
[0087] FIG. 4 provides a protocol model of a system architecture
which realises the application from FIG. 3 herein. The system
comprises three logical components, being: an Adaptor 401, which
converts between TDM and ATM;
[0088] an ATM Switch 402, which provides external ATM interfaces
and cross-connects between ATM VCCs; a Controller 403, which
processes Q.2931 signaling messages and instructs the Adaptor and
ATM Switch to make or break individual TDM-to-ATM connections.
[0089] FIG. 4 also shows how these logical components are linked
together internal to the system to support the desired
functionality.
[0090] Referring to FIG. 5 herein, there is illustrated a
Management Unit Model (depicted using UML notation) which uses
"realised by" associations to indicate how the application as shown
in FIG. 3 herein is realised by the logical components and
interfaces of the system architecture shown in FIG. 4 herein. Note
that this model has been deliberately simplified to highlight the
specific use of the "realised by" association pertinent to this
example. It is indicated in FIG. 5 which of the objects fall within
the AM and which within the IM.
[0091] The composite object model depicted in FIG. 5 herein has the
following features:
[0092] It is composed out of two separate object models--one for
the TDM-ATM application and one for the TDM-ATM system which
realises the application. These two object models are linked
together using the "realised by" associations.
[0093] Each managed object has a single parent via a containment
relationship.
[0094] The objects TDM-ATM Application and TDM-ATM System form
separate containment sub-trees. For alignment with TMN object
structures, these are sub-types of Managed Element and are
contained under a single parent. (The parent is not shown in FIG. 5
herein.)
EXAMPLE 2
Equipment Protection
[0095] Telecoms systems equipment is often replicated in order to
enhance overall system reliability and to maintain a high level of
service availability in the event of equipment failure. Equipment
protection is almost inevitably inter-related with communications
protection (see example 3 below).
[0096] A variety of protection regimes have been devised to address
equipment protection, e.g. load-sharing, active-standby, with 1+1
through to 1:N resiliency. These regimes are fundamentally similar
from the perspective of the functionality they offer, with subtle
differences in the way they are realised.
[0097] The "realised by" association can be used to model various
forms of equipment protection, including 1+1 and 1:N. The Logical
Adaptor shown in FIG. 4 herein provides an example of 1+1
protection.
[0098] A common approach to equipment protection on E1 interfaces
is to use a "Y" joint to couple a single E1 interface into two
separate, independently powered termination units. FIG. 6 herein
illustrates how this would work for the Logical Adaptor.
[0099] The "realised by" association provides the means to model
the Logical Adaptor and (physical) Adaptor separately and to link
them together. The resultant management model is as depicted in
FIG. 7 herein.
[0100] The equipment protection model of FIG. 7 has the following
features.
[0101] The control link between each pair of Adaptor objects 700,
701 has been omitted--this link is hard-wired and therefore cannot
be managed.
[0102] Similarly, the "Y" joint itself cannot be managed and
therefore does not appear in the model.
[0103] The Logical Adaptor object 700 supports the provisioning and
management of adaptor functionality irrespective of the way in
which it has been realised by protected equipment.
[0104] The Adaptor object 701 supports provisioning and management
of individual physical Adaptor units.
[0105] The "realised by" associations between Adaptor and Port
objects support flow-through provisioning, whereby changes at the
logical Adaptor model level are mapped to changes on the individual
physical units. Conversely, problems encountered at the physical
level can be mapped back to their (potential) impact at the logical
level.
[0106] As before, each managed object has a single parent via
containment.
EXAMPLE 3
Link Protection
[0107] Telecoms systems often provide levels of resilience for
inter-equipment communications, e.g. through path protection,
diverse routing or by load-sharing across a set of physical links,
to ensure that a level of service can be maintained in the event of
link failure. Regardless of how resilience is achieved, a single
logical connection exists between two end-points at some level of
abstraction. From a management modeling perspective, this logical
connection is "realised by" a specific protection scheme.
[0108] The TDM-ATM system again provides a pertinent example in the
form of a 1+1 protected link between each logical adaptor and the
logical ATM switch. FIG. 8 herein shows how a protected link is
composed out of two unprotected links.
[0109] FIG. 9 herein illustrates the management object model
fragment which corresponds to the protected link functionality.
[0110] In FIG. 9 herein, the "realised by" associations between
equipment and ports have been omitted to avoid clutter. The
protected ATM link object can be used to manage the ATM link at the
logical level, e.g. to provide overall link reliability measures.
The unprotected ATM link object can be used to manage individual
physical links, e.g. to measure bit error rates. The principle
illustrated in the example can be applied to more complex
situations in similar fashion, e.g. where the individual links are
replaced by diversely routed transmission paths--a diversity
constraint would be added between the two individual paths.
[0111] The line card objects are contained within ATM switch. The
ATM link objects are contained directly within TDM-ATM system (not
shown explicitly in FIGS. 5 and 9 ).
EXAMPLE 4
Software Protection
[0112] Telecoms systems need to provide protection against
processor, communications and/or software failures. This is
normally achieved by replicating software applications across
multiple compute platforms.
[0113] A flexible scheme is obtained by addressing each application
as a logical entity, without the calling software having to know
the protection status of the application. Each application instance
must have control paths to its associates, to ensure integrity of
operation. A typical protocol model is depicted in FIG. 10
herein.
[0114] FIG. 11 provides the generic object model fragment which
supports the software protection scenario with reference to FIG. 10
herein.
[0115] In FIG. 11 herein, logical processor 1100 refers to an
abstract processing engine which provides the resiliency mechanisms
to support software protection. Processor 1101 is a physical
realisation, i.e. one of processor #1 through Processor #3. Logical
software load 1102 represents a protected software load,
irrespective of which processors it runs on. Software load 1103 is
a physical realisation running on a specific processor. The model
as provided constrains each logical and physical processor to have
a single software load. Logical application 1104 represents a
protected software application, irrespective of which processors it
runs on (and hence within which software load it is contained).
Application 1105 is a physical realisation, i.e. a specific
instance of an application running as part of the software load on
a specific physical processor.
[0116] The model supports management at both the logical and
physical levels. For example, software upgrades can be coordinated
at the logical level, but individual software loads and problem
reporting are handled at the physical level.
EXAMPLE 5
Decomposition of Links and Cross-Connections
[0117] Communications within and between telecoms systems are
normally constructed from a set of protocol layers, each such layer
providing a set of communications services for the layer above.
End-to-end connections within a given protocol layer are
constructed out of individual links (between pieces of equipment)
and cross-connections (within equipment).
[0118] The "realised by" association provides a natural means to
model how connections are constructed within each communications
layer. Furthermore, the end-to-end connections within a given layer
can then be used, via containment, to support the individual links
within the layer above (a consistent way to model this latter
aspect of communications management is furnished within ITU-T
recommendation G.805).
[0119] Two basic patterns are illustrated with reference to FIG. 12
herein (note that arrows have been used to indicate the direction
of the "realised by" association).
[0120] An abstract cross-connect 1200 represents a cross-connection
which spans either an application or a composite equipment element
(such as a system or sub-system). When the cross-connection is
expanded out, it becomes "realised by" an interleaved series of N
cross-connects 1201 and N-1 links 1202.
[0121] Similarly, when an abstract link 1203 is expanded out, it
becomes "realised by" an interleaved series of N links 1204 and N-1
cross-connects 1205.
[0122] (The notation used in FIG. 12 herein obviates the need to
represent each individual link or cross-connection in the expansion
as a separate object. See "Arbitrarily Folded Models" later in this
document for further details). An example is provided by ATM, where
the virtual circuit (VC) layer sits above the virtual path (VP)
layer.
[0123] Referring to FIG. 13 herein, there is illustrated an example
of an ATM VC connection (VCC) running across two abstract ATM
sub-networks. It introduces some additional concepts, namely:
Virtual Path Link (VPL); Virtual Path Connection (VPC); Virtual
Circuit Link (VCL), Cross-Connection (X-C).
[0124] The elements of FIG. 13 comprise the following:
[0125] A VCC 1300 links first and second end systems 1301, 1302.
The VCC is "realised by" two VCLs and a VCL X-C.
[0126] A number of VCLs 1303, 1304 are contained in a VPC (this is
where adaptation between layers occurs). A VPC links two ATM
systems (end systems, cross-connects or sub-networks). A VPC is
"realised by" a single VPL or by a set of VPLs concatenated using
VPL X-Cs.
[0127] A number of VPLs 1305, 1306 are contained within each
physical ATM path between ATM systems.
[0128] Referring to FIG. 14 herein, there is illustrated
schematically a generic management object model which corresponds
to these definitions. The object model of FIG. 14 shows how the
containment association is used to join together the VC and VP
communication layers and how the "realised by" association is used
to depict the construction of each layer connection from its
constituent links and cross-connections.
[0129] Features of the object model of FIG. 14 include the
following:
[0130] Arrows have been added to the "realised by" associations to
indicate the direction of the associations.
[0131] The "realised by" association between VCC CTP and VCL CTP is
a consequence of VCC decomposition. However not every VCL CTP is
associated with a VCC CTP. The VCL CTP at the End System realises a
VCC CTP, but the VCL CTP at the other end of the VCL does not (the
latter merely provides the inter-connection point with the VCL X-C.
The same situation applies in the VP Layer with respect to the VPC
CTP and VPL CTP objects. Thus the VCL and VPL CTPs can play
differing roles in the VP Layer and VC Layer Implementation
Models--some terminating "realised by" associations, some not. This
is an example of the modeling flexibility offered by the "realised
by" association.
[0132] The managed objects in the model are aligned with the ATM
Forum recommendations for ATM element and network management.
However the model in the specific implementation of the best mode
herein adds associations between the network and element management
layers which may be used to supported integrated management of ATM
networks and systems.
[0133] The containment associations which cross layer boundaries
correspond to adaptation functions, as described in ITU-T
recommendation G.805.
[0134] VCCs and VPCs may be constructed from arbitrary numbers of
Links (N), together with N-1 cross-connections. The values N and
N-1 thus provide numeric constraints.
[0135] CTP objects are contained either directly within an
Application object (for logical CTPs) or within the equipment
object which supports them (for physical CTPs). Cross-connection
objects are contained either within an application object (logical)
or within a fabric object (physical). Link objects are contained
either within a corresponding layer network (logical) or within the
composite equipment object which supports them (physical). Thus,
once again all managed objects have a single parent via containment
to be used for naming, navigation, etc.
EXAMPLE 6
Data Tables
[0136] Flow-through provisioning of telecoms systems involves
converting single user input to potentially many tables which must
be data-filled within the managed equipment.
[0137] The "realised by" association allows individual managed
objects representing user-provisioned data tables to be mapped to
many corresponding managed objects representing tables on
individual equipment components. Referring to FIG. 15 herein there
is illustrated a general template for managed object models to
accomplish these mappings.
[0138] In FIG. 15, X-Y data table 1500 represents managed data that
provides an association between two entities X and Y. This data
table is "realised by" a set of data tables on separate components,
each of which contributes to some aspect of the X-to-Y
association.
[0139] Realisation in Models (Management Unit Level)
[0140] This section presents the model taxonomy, ending with the
realisation model and the interactions between its modeling
construct and those of the other models. An appendix describes the
principal classes appearing in the models, ending with the
"realised by" association class.
[0141] The simplified management unit diagram of FIG. 16 herein
emphasizes that capabilities are relationships. Owing to the
limitations of UML notation, it can only do this while implying
that a single capability can never connect more than a pair of
endpoints. It similarly omits broadcast links. (The specialization
of endpoint within the Implementation Model is solely to show the
disjoint roles it plays. The constraints between relationships are
described in the text.)
[0142] The more general Management Unit Model shown in FIG. 17
herein allows both capabilities and links that connect more than
two endpoints, but at the cost of de-emphasizing their role as
relationships.
[0143] The kinds of model used in the specific methods and
embodiments presented herein are as follows: The Application Model
and Implementation Model concepts were introduced in prior
disclosures U.S. Ser. No. 08/921,649 and U.S. Ser. No. 08/921,225
and are described again here for clarity, as the other Models make
use of them.
[0144] Model
[0145] A model contains a set of classes and relationships,
expressed in UML notation with mathematical annotations. The
relationships impose constraints on whether an instance can exist
without another instance related to it and how many instances can
be related to another. The mathematical annotations may add
constraints on closed loops of relations. An instance of a model is
a set of instances of these classes and relationships that respects
these constraints.
[0146] To instantiate a model means to instantiate each of its
classes so as to create such a set of instances without reference
to any existing instances.
[0147] To modify a model instance means to modify one model
instance into another by deleting some of its classes' instances
and/or instantiating others.
[0148] For example, a demand for flow-through provisioning of a new
set of capabilities may be specified by performing either of these
operations on the appropriate high-level model.
[0149] Application Model
[0150] An Application Model is the external interface of a
management unit; it is the black-box view of the management unit.
An Application Model contains: an application root class being a
single class to name the model and act as a root for the
composition and naming hierarchy within the model; one or more
endpoints (ports and/or CTPs) to provide an interface to that
management unit (an Application Model does not have to have
endpoints, although almost all do. Closed world models are
possible); and a set of capabilities (e.g. cross-connections,
translations, inter-working functions, etc.) spanning these
endpoints.
[0151] An Application Model rarely contains links to its endpoints,
but links can appear in Application Models for "network"
applications (for example, the Application Model for SS7 contains a
Signaling Link class).
[0152] Implementation Model
[0153] An Implementation Model is the internal realisation of a
management unit; it is the "white-box" view of the management unit.
An Implementation Model consists of configurations of either
(classes in) lower-level Application Models or of classes (agents)
that interface to the network elements without further mediation
within the modeling method. In addition to the application,
endpoint and capability classes it acquires from subordinate
Application Models, it contains link classes connecting some of the
endpoints.
[0154] Management Unit Model
[0155] A Management Unit Model, comprises an Application Model plus
an Implementation Model plus a set of "realised by" associations
showing how the endpoints and capabilities of the Application Model
are realised by the endpoints and capabilities of the
Implementation Model. A management unit is a unit of granularity of
a modeled network, so is distinguished for use in managing the
network.
[0156] An Application Model may figure in many different management
units, being realised differently in each. Likewise, an
Implementation Model may figure in more than one management unit,
realizing a different subset of its overall functionality within
each. Only the realisation model of "realised by" associations
between its Application Model and Implementation Model classes is
unique to the management unit.
[0157] Equipment Model
[0158] An Equipment Model is a management unit whose Implementation
Model interfaces to some device or function external to the
modeling context. This is a defined aspect of an management unit;
it is not computed. The same Application Model may be associated
with an externally-realised Implementation Model in one (Equipment
Model) management unit and with an Implementation Model containing
subordinate Application Models in another (Architecture Model)
management unit.
[0159] Architecture Model
[0160] An Architecture Model (ArM) comprises a management unit
whose Implementation Model is composed of a configuration of
Application Models. An Architecture Model's Implementation Model
consists of subordinate Application Models of other management
units, configured such that:
[0161] some of the subordinate Application Models endpoints are
linked to each other
[0162] the remaining unlinked endpoints realise the endpoints of
the management unit's Application Model
[0163] the network of linked capabilities between those endpoints
realises the capabilities of the management unit's Application
Model.
[0164] A given set of (compatible) management units thus defines an
ordered realisation network of models, from top-level Architecture
Models through intermediate level ones to bottom-level Equipment
Models. This network is partially ordered closed.
[0165] Realisation Model
[0166] The realisation model connects a management unit's
Application Model to its Implementation Model. It enforces the
constraints (in mathematical terms, the commutativity rules) that
arise between "realised by" associations in an realisation model
due to relationships between the classes they relate. Such
constraints are valuable in promoting clean designs and allowing
automated reasoning about models.
[0167] Two relations R and S commute if R.degree. S necessarily
equals S.degree. R. They anti-commute if R.degree. S necessarily
does not equal S.degree. R. A relation, or sequence of relations,
between members of the same class is reflexive if R(x,x) always
holds and irreflexive if R(x,x) never holds. These terms are a
subset of a range of mathematical annotations on relations,
involute (i.e. between members of same class) relations and
closures of relations that are useful (sometimes essential)
additions to the UML notation when defining model types such as
those described in this section.
[0168] Classes in models are related by composition, connection and
realisation relationships. Connection and composition were
introduced in U.S. Ser. Nos. 08/921,649 and 08/921,225 and so will
be described here only as necessary to explain their effect on the
Realisation Model.
[0169] Composition does not cross model boundaries, except that
model root classes contain other models' root classes as their
model contains those models (i.e. model containment equals root
class containment); otherwise composition is limited to classes
that are either both within an Application Model or both within an
Implementation Model and outside its subordinate Application
Models.
[0170] Connections are either Links or Capabilities.
[0171] The "realised by" association respects the type system of
the method: applications realise applications, endpoints realise
endpoints and connections realise connections.
[0172] An endpoint that is unlinked in a management unit's
Implementation Model may realise an endpoint in that management
unit's Application Model one-for-one (only).
[0173] A sequence or network of linked capabilities in a management
unit's Implementation Model, each linked to the next via one of its
endpoints, defines an overall capability between the unlinked
endpoints of the capabilities terminating the sequence. This
overall capability may satisfy one required by the management
unit's Application Model. A realised capability has "realised by"
associations to each of its realizing capabilities and links.
[0174] If an Application Model's endpoints and capabilities realise
another Application Model's endpoints and capabilities then that
Application Model's root class realises the other Application
Model's root class.
[0175] Capability connection and realisation commute: if a
capability is realised in an management unit then its endpoints
must also be realised in that management unit, and vice versa. (The
same applies to links appearing in the management unit's
Application Model.)
[0176] (Implementation model link connection and realisation also
commute but in a different way. Links connect endpoints in two
different subordinate Application Models of an Implementation
Model. Either or both Application Models of a link may be replaced
by their realizing Implementation Models; the link's endpoints are
replaced by their realisers and the link connects them. Hence,
although only shown on the Implementation Model containing the top-
level endpoints of each side of the link, a link implicitly
connects the entire realisation hierarchy of each of their
endpoints.)
[0177] Realisation and composition also commute.
[0178] If an endpoint contains another, the realiser of the first
must contain the realiser of the second.
[0179] If a capability contains another and each is realised by an
arrangement of capabilities and links, then the elements of the
first sequence in each subordinate Application Model within the
realizing Implementation Model contain those of the second and the
links between them contain each other similarly.
[0180] In both cases, indirect composition is permitted on the
realizing side.
[0181] Arbitrarily Folded Models
[0182] Models with a fixed number of folds are disclosed in U.S.
Ser. No. 08/921,649 and U.S. Ser. No. 08/921,225. The idea
generalizes to models with arbitrary numbers of folds. Just as one
end of a relationship in UML can be annotated either with a given
integer or so as to mean `any number`, so an assemblage of folded
Application Models and links within an Implementation Model can be
annotated either to indicate some particular number of folds
intended or to indicate that the folded model can be unfolded
arbitrarily often and represents all unfolded models that can be so
obtained.
[0183] Example 5 in the "realised by" association section above
(abstract cross-connect or link) shows how realisation can make use
of models with arbitrary numbers of folds. The arbitrarily folded
Implementation Model of an abstract cross-connection's management
unit can be unfolded into an Implementation Model that contains any
number N of cross-connects and N-1 of links. Similarly, the
abstract link's Implementation Model can be unfolded into an
[0184] Implementation Model that contains any number N of links and
N-1 of cross-connects.
[0185] Contraction Rules
[0186] It often happens that particular assemblages of classes
within models are fixed (e.g. by standards) and so may be replaced
by a single class without loss of meaning (the equivalent full
assemblage being held in some library of model fragments). In such
cases, a variety of meaning-preserving contraction rules may be
used to simplify model representations.
[0187] For example, where an endpoint's protocol, reliability or
other attributes mean that it necessarily contains a fixed set of
other endpoints, a contraction rule governs how to replace the
composition assembly with the single container endpoint while
preserving model constraints.
[0188] When a bi-directional endpoint in an Application Model is
composed of two uni-directional endpoints, each of which is
realised by an appropriate Implementation Model endpoint, a
contracted model will just show the bi- directional endpoint being
realised by the two Implementation Model endpoints.
[0189] A similar case arises in Example 2 above. In strict detail,
the model should show the protected ATM and E1 ports being each
composed of two unprotected ports (whose activity states the
protected ports manage), with each unprotected port being realised
by a single Implementation Model port. In FIG. 7, the endpoint
composition contraction rule is used to omit this decomposition and
show two unprotected Implementation Model ports directly realizing
one protected Application Model port.
[0190] In both cases, the apparent contradiction with the
one-for-one endpoint realisation rule can be resolved by the
contraction rule.
[0191] Appendix A: Principal managed object-level Classes
[0192] Most managed object-level classes that appear in the above
models belong to one of the following kinds.
[0193] A general Application Model diagram is illustrated in FIG.
18 herein.
[0194] Application
[0195] Every Application Model contains an application root class.
This acts as the root of the model's containment tree and as a name
slot to identify the Application Model being defined. In principle,
every application class can be the root of an Application Model. In
practice, complex Application Models can contain subordinate
application classes contained within the root class.
[0196] An Implementation Model has an Implementation root class and
a Management Unit Model has an management unit root class,
performing the same roles. In those models as the application root
class in its Application Model. The implementation root class can
contain application root classes and/or individual managed object
classes. Management unit root classes are usually not shown but
left implicit when drawing management unit diagrams.
[0197] Implementation Model root classes are sometimes not
shown.
[0198] Endpoint
[0199] Endpoints appear in Application Models only. Endpoints
terminate Connections. An endpoint has an internal-to-Application
Model role as the class on which a capability may terminate and a
(normally) external-to-Application Model role as the class on which
a link may terminate. Endpoints act as interface classes between an
Application Model and classes of other models with which it
combines within an Implementation Model or management unit.
[0200] Endpoint specializes to port (physical endpoint) and
termination point (logical endpoint). Common subclasses of
termination point are trail and (in the telecoms standards sense,
to be distinguished from our more general usage of the word)
connection.
[0201] Behavior
[0202] The properties of the (real or virtual) device or function
represented by an Application Model are captured in behaviors.
There are capability, innate and fabric behaviors. Behaviors only
appear in Application Models.
[0203] Capability
[0204] A capability comprises a behavior which represents the
transformation of data between a number (typically two) of
endpoints within an Application Model. Hence, in principle, a
capability connects endpoints of different type and/or location
and/or capacity. The capability is said to span the endpoints.
[0205] A capability is an exportable behavior; one that can
directly contribute to realizing a higher-level capability when its
Application Model is part of the Implementation Model of a
higher-level management unit. Its exportability comes from the
nature of its endpoints; they must all be either joined to others
via links in the higher-level management unit's Implementation
Model, or themselves realise endpoints of the higher-level
management unit's Application Model.
[0206] Typical subclasses of capability are cross-connections
(between identical endpoint types) and interworking functions
(between dissimilar endpoint types).
[0207] Fabric
[0208] Fabric classes provide capabilities. They may have
relationships to endpoints but are not themselves relationships
between endpoints; their function is to provide capabilities that
connect subsets of their endpoints. For example, a DSO fabric
capability might span two sets of 32 DSO TPs and be able to provide
up to 32 DSO cross-connect capabilities, each spanning two DSO TPs,
one from each set.
[0209] Fabrics track the total numbers or other resource limits of
the subordinate behaviors, record limits to the endpoints between
which they can be provided and serve as a configuration placeholder
for the capability to provide these capabilities, independent of
the lafter's actual presence.
[0210] The existence of a parametrized class of capabilities
(parametrized by the endpoints they connect as in the example above
or otherwise) within an Application Model implies the existence of
a fabric capability to provide them. Hence it may not be necessary
to represent a fabric class explicitly in a given model.
[0211] Innate
[0212] Innate behaviors support others directly and internally to
an Application Model, without the mediation of endpoints. Examples
include fault behaviors, performance monitoring objects and log
records.
[0213] Link
[0214] A link is normally a standard one-one binary relationship
(broadcast links are one-to-many): each link connects precisely one
endpoint to precisely one is other; each endpoint can be linked to
precisely one other endpoint. As only a link can appear in an in an
Implementation Model outside any subordinate Application Model, it
is always a link that connects the endpoints of different
Application Models.
[0215] Irreducible Link
[0216] This term concerns the interconnection of two objects by a
relationship that is not manageable (sometimes purely conceptual in
nature--e.g. a link might record that a plug is in a socket; there
is no real object connecting the plug to the socket) or whose
network management behavior is too trivial to be worth modeling as
an management unit.
[0217] (For example, in a model being used for fault management, an
irreducible link should have no non-trivial failure behavior
independent of the management units owning the objects that it
connects; it is either there or it is not.)
[0218] The endpoints of irreducible links are necessarily of the
same type if bi-directional and of conjugate types if
uni-directional (e.g. they must both be bi-directional SDH ports or
one must transmit SDH, the other receive it).
[0219] Reducible Link
[0220] A link may not have trivial network management behavior in a
fundamental sense. It may simply be a manageable connection that
did not need to be modeled further in a given context or epoch.
Such a link is said to be reducible (and has non-trivial network
management behavior).
[0221] Realised_by
[0222] This class, at the managed object level, has been defined in
detail above.
[0223] The "realised by" association is the only class that can
exist in an management unit outside of its Application Model and
Implementation Model. It lives in the management unit's realisation
model. Realisation is an asymmetric relationship: if A realises B
then B cannot realise A.
[0224] The endpoint or capability "realised by" association holds
data on how much of the realizing capability's or endpoint's
bandwidth, slots or other capacity measure is being provided to the
realised capability or endpoint.
[0225] Appendix B: Examples of Realisation Relationships in
Code
[0226] The "realised by" relationship is first used in analysis and
high-level design. It helps the analyst separate modeling the
abstract functionality that a system will offer from modeling how
these functions will be realised by the systems components. As the
analysis and design in general influence the code that is finally
produced, so the realisation relationships within these models can
be found in the resulting code.
[0227] This appendix gives three simple examples of what a
"realised by" relationship may look like in code. All the examples
are written in Smalitalk in the context of an ATM switch element
manager.
[0228] FIG. 19 herein illustrates schematically a VCC trail being
realised by two VC links and a VC cross-connect. The trail contains
a number of DSO links.
[0229] Termination points are realised compatibly: DSO CTPs are
contained within VCC TPs which are realised by VCL TPs. Demand for
DSOs will create demand for VCC trails. Any VCC trail thus demanded
will attempt to provision itself by demanding all its realisation
links.
[0230] Realisation mapped to the standard Object-Oriented
interface-implementation relationship
[0231] The most minimal way of implementing a "realised by"
relationship is as the 15 relationship between the interface and
implementation of a single object. If object A is "realised by"
object B in the design then the implementation is a single object C
whose interface represents A and whose implementation represents B.
If, in the analysis model, A can be commanded to do X, which it
achieves by asking B to do Y, where B then invokes Z, then in the
implementation the single object C is commanded to do X and
responds by invoking Z.
[0232] For example, suppose, in the above model, we implement the
aggregation VCC TP "realised by" VCL TP as a single object. Then
provisioning it might be done as follows.
1 VCTP class>>provisionEndFor: aVCC in: aVPTP "Create
combined TP object for both trail and its end link" {circumflex
over ( )}(self new) containedBy: aVPTP; vccTrail: aVCC; *** vcLink:
(aVCC realisedBySet) first; .... (other setup commands) ...;
yourself.
[0233] In this example, the *** line achieves an effect that in the
model above would be triggered by the "realised by" relationship
between a VCC TP and the VCL TP that it, on being provisioned,
would automatically create. Having chosen to combine the two
classes, we must hardwire this relationship into the relationship
between the top-level provisioning method and its
implementation.
[0234] Realisation implemented directly.
[0235] The simplest way of implementing a "realised by"
relationship is as a relationship in the code. This can be done
specifically (specific classes implement their own realisation
relationships to those that realise them on a case by case basis)
or generically (a high-level class implements the "realised by"
relationship, with all its semantic meaning; specific classes
inherit from it).
[0236] In the first case, the provisioning of a VCC Trail might be
as follows.
2 VCCTrail class>>provisionOver: aCrossConnectFabric from:
aVCCTP to: anotherVCCTP "Provision VCC Trail object end-end over
one cross-connect" .vertline. aVCLinkXC .vertline. aVCLinkXC:=
aCrossConnectFabric provisionVCLXConnect. {circumflex over (
)}(self new) realisedByXC: aVCLinkXC; realisedByLinkA: (VCLink
provision From: (aVCCTP realisedBy) to: aVCLinkXC);
realisedByLinkZ: (VCLink provisionFrom: aVCLinkXC to: (anotherVCCTP
realisedBy); .... (other setup commands) ... ; yourself. or, in a
slightly more general form, VCCTrail class>>provisionOver:
aVPlevelNetwork from: aVCCTP to: anotherVCCTP "Provision VCC Trail
object end-end over a VP level network" {circumflex over ( )}(self
new) realisedBySet: aVPlevelNetwork findVPlevelRouteFrom: (aVCCTP
realisedBy) to: (anotherVCCTP realisedBy); .... (other setup
commands) ... ; yourself.
[0237] Realisation implemented generically.
[0238] In the above, the model has guided the coding but it has
done so specifically, not generically. The abstract semantic
meaning of "realised by" appears in the style of coding the
specific relationships. A more generic approach, in which we
implement the semantics of "realised by" as code, is shown
below.
3 VCCTrail class>>provisionOver: aVPNetwork from: aVCCTP to:
anotherVCCTP "Provision VCC Trail object end-end over a VP level
network" .vertline. aVCLinkXC .vertline. aVPlevelRoute:=
{circumflex over ( )}(self new) realisedBySet: aVPNetwork
findVPlevelRouteFrom: (aVCCTP realisedBy) to: (anotherVCCTP
realisedBy); .... (other setup commands) ... ; yourself.
* * * * *