Technical Overview
IN-Lab report 93/2
Trygve Reenskaug, Taskon
Raymond Nilsen, NTR
27 July
1993 Taskon
Carl Petter
Swensson,
Per Wold, Taskon
Abstract.
IN-Lab2 is a software laboratory set up for small-scale experiments with the design and
construction of Intelligent Networks. This report gives a technical overview of the support
value chain for a highly simplified version of a point-to-point telephone commnuication
example. The report acts as an introduction to the detailed reports of each level in the
support value chain.
Client: TF
Client reference: IN-Lab Report 93/2
Taskon reference: Draft
File: D:\work.t12\ooram.t12\oo-pres.t12\1993\931206-in-lab2.t12\in2-document.rm4
Last update: 25 August 1993 at: 18:27
Print generated: 1 Juni 1998 at: 17:18
Taskon, Gaustadalléen 21, N-0371 Oslo 3 Norway.
TASKON
Work Environments
Tel. + (47) 22 95 86 31 Telefax: + (47) 22 60 44 27
25 August 1993 at: 18:27
Report overview
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 1
25 August 1993 at: 18:27
Introduction
Chapter 1
Introduction
Norwegian Telecom Research and Taskon are currently carrying out a joint project on the
industrial creation of Intelligent Network Services (IN). The project builds on the IN technology
proposed by the EURESCOM project EUP103 which is reported to this conference in a paper by
Raymond Nilsen et al, and on the Taskon OOram object oriented methodology which is
described in this paper and in [Ree92], [EAnd92], [JAnd91].
The construction and deployment of IN services is going to be a very large operation. There will
be a large and expanding number of available services, the total system complexity will be
staggering, and many organizations employing people in different capacities will be involved in
its creation and operation.
A laboratory for the small scale experiments with the creation and invocation of Intelligent
Network Services has been created and tested on a concrete example. The purpose of the
laboratory, called InLab2, is to explore and demonstrate the applicability of the OOram
methodology to the IN industry.
The scope of InLab2 is the complete IN creation life cycle. It is supported by a comprehensive
set of tools for system specification on different abstraction levels, including the specification for
monitored execution. The purpose of a design environment such as InLab2 are as follows:
1. Thinking aid. A good environment helps the designer consider the whole without getting lost
in details, and to isolate specific parts for detailed consideration.
2. Internal consistency. A good environment provides a seamless model of the design, ensuring
that all aspects of the specification can be made consistent. This does not mean that the
environment enforces consistency at all times. The designer must be allowed to explore new
ideas, polishing them and making them consistent with the rest of the specification at his
leisure.
3. External consistency. The designer's ultimate goal is to satisfy some perceived need. A
correct answer to the wrong question is as useless as an incorrect answer to the right
question. Prototyping based on executable specifications is an invaluable aid for checking
that the design satisfies the external goals.
4. Documentation. The designer needs to communicate the basic ideas, the details, and the
rationale for his solution to other people. We have found that automatically generated reports
are invaluable for providing the exact details of the solution. But such reports cannot
completely replace the personal, well written exposition which highlights important aspects
of the solution and discusses the reasons for the particular choices that have been made.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 2
25 August 1993 at: 18:27
Introduction
The present set of reports provides the complete documentation of an example system,
challenging the reader to consider item 4?? above. InLab2 itself is created to help designers
explore their ideas for IN services, and incidentally also to test items 1?? through 3?? above.
A first separation of IN into two distinct domains has been suggested in [Bugge91], this is
illustrated in figure 1
Service Domain
Switching Domain
Figure 1. The intelligent network
In an intelligent network, functions in the service domain use functions offered from the switching domain. The idea
of separation is built upon the client-server principle, that is, the service domain is a client of the switching domain,
which is a server of the connectivity in the telecommunications network.
The Switching Domain encapsulates all the problems associated with the rapid switching and
transmission of large masses of user data and hides the differences between different switch
implementations, providing a universal interface to the Service Domain.
The Service Domain encapsulates all the problems associated with the great variety of services to
be provided. It can be thought of as a distributed system being supported by its own
communication facility for signalling. Some of the services provided will be completely
implemented in the Service Domain, while others will be used to control the Switching Domain
in a more or less sophisticated manner.
The communication examples given in this document are based on designs created by the
Norwegian Telecom Research, but they have been modified and simplified so they do not reflect
the current NTR solutions to the same problems. The software description and production
facilities described are based on the facilities developed and used by Taskon, but a number of
detailed issues have been omitted in the interest of clarity.
Chapter 2 gives an overview of our support value chain for the creation and invocation of
Intelligent Network Services in general and our example telephone service in particular. Chapter
3 digresses into a description of some parts of the Ooram methodology which have not been
described elsewhere. The remaining chapters give an overview of the individual layers of our
support value chain. In Appendix 2, we give the detailed reports from two monitored test
executions of our system: The first is for the installation of a User's services, and the second is
the establishment of a telephone connection.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 3
25 August 1993 at: 18:27
A reference model for the creation and invocation of services
Chapter 2
A reference model for the creation and invocation of services
In this chapter we will endeavor to define a reference model for the creation and invocation of
Intelligent Network Services in a number of abstract layers, and we will identify the
responsibility of the personnel managing each layer. The guiding principle will be that while the
qualifications of the personnel on the different layers will be different, the individual
qualification requirements shall be realistic in terms of a large and distributed organization.
Before going into any detail on each of the abstraction layers, we will discuss some general
principles:
1. Development process
-
Our development process is iterative, evolutionary and object-oriented. It is aimed at supporting
continuous development of software systems on a large scale. The methodology is divided into
distinct methods which are used to support work on the different abstraction layers.
2. Product
-
The product delivered by one abstraction layer constitutes the libraries and production facilities
employed on the layer above it. The goal is to help each abstraction layer achieve maximum
effectiveness through suitable production tools and through maximizing reuse of specifications,
designs and code.
-
Each abstraction layer has its own kind of product, and therefore its own life cycle model.
-
The life cycles of a product and the modules that constitute this product are interdependent.
3. Organization
-
The principle guiding the definition of each abstraction layer is that the competence required of
the people performing the operation on a particular layer shall be defined and realistic.
-
The total IN operation may in the future be performed by many different organizations. The
abstraction layers are defined in such a way that they support a possible division of authority and
responsibility between different organizations.
An important principle in our architecture is that we assume the operators to be hostile, be it by
intent or by ignorance. The production facilities for any layer must therefore be secure: It must
be physically impossible for the operator on any given layer to threaten the integrity of the layer
below it. A corollary to this is that the production facilities for a certain layer must be complete:
The facilities must permit the personnel to perform all permissible changes to the total Service
Domain system and no more. Since procedures and methods are used at the discretion of the
personnel, security and completeness must be implemented in the tool portion of the production
facilities.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 4
25 August 1993 at: 18:27
2.1
A reference model for the creation and invocation of services
The generic support layer
We will separate the Service Domain into a number of support layers. Each layer will be
characterized by the operations belonging to that layer: The responsibility of its personnel to
produce certain deliverables to its client, and the authority to make certain changes to the Service
Domain system. The actors will utilize certain production facilities; these facilities will include
procedure guidelines breaking down the total work into manageable tasks, methods to be
employed in the performance of these tasks, and computer based tools that facilitate the effective
performance of the tasks.
Deliverables from
LayerN
Operations on
ayer
LN
Production facilities
Layer
for N
Figure 2. A support layer is completely isolated from the layer below it.
We will now give a generic specification of the competence required of a person who is to
operate on a given layer. (This specification must of course be augmented by the special
requirements associated with any given concrete layer).
1. The deliverables from a given abstraction layer are the production facilities for the layer
above it. The personnel must therefore understand the qualifications and requirements of
their client, who is the personnel on the layer above. The personnel should also be motivated
to satisfy all aspects of these requirements, the success criterion is customer satisfaction.
2. The personnel must understand and be well trained in the use of the available production
facilities: The operations, the methods and the use of the tools.
2.2
A possible Support Value Chain
Our first choice of abstract layers is derived from the actors in the IN service life cycle given in
[Vestli, Nilsen 92]. They are illustrated in the figure below:
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 5
25 August 1993 at: 18:27
A reference model for the creation and invocation of services
User Layer
Subscriber Layer
Service
Domain
Service Provider Layer
Service Creator Layer
Service Constituent Creator L
Switching
Domain
Network Provider Layer
Figure 3. Basic abstraction layers
The layers are illustrated in figure 3??, and are described from top to bottom in the following:
1. User layer. The user is the party who wants to use available services, and who is responsible
for the selection and invocation of a service. The production facilities will consist of various
user manuals together with suitable tools (user interfaces). The nature of the tools will
depend on the kind of terminal equipment used. If the equipment is a touch-tone telephone,
the user interface to the tools will consist of various combination of key presses. If the
equipment is a personal computer, the user interface is likely to be a direct manipulation
Graphical User Interface (GUI).
2. Subscriber layer. The Subscriber is the party who purchases a set of services on behalf of
one or more users, who pays for them, and who is responsible for making services available
for his or her users. The Subscriber is responsible for the activation and deactivation of
services. Different sets of services may be made available to different (groups of) users, and
the services may be customized according to individual user needs. The production facilities
will consist of various instruction manuals together with suitable tools, which are likely to be
direct manipulation Graphical User Interfaces (GUI).
In some cases, the User and the Subscriber will be played by one and the same person. This
does not change the abstract architecture, but merely means that the same person plays two
roles and therefore utilizes the production facilities of two layers.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 6
25 August 1993 at: 18:27
A reference model for the creation and invocation of services
3. Service Provider layer. The Service Provider is a party who has a license for installing
telecommunications service software in the telecommunications network, and who is
responsible for installation and deinstallation of services. The Service Provider receives
requests for creating a service from a subscriber or can initiate the creation of services
himself, in which case the service Provider also acts as a Subscriber. The Service Provider
can be a network operator, a network equipment vendor or in general an independent
software vendor. The Service Provider personnel must be fully conversant with the services
they offer, and must know why and how to tailor them to satisfy special needs. It is important
to note that a Service Provider will in general not know all possible services, a given
Subscriber may acquire services from many different Service Providers.
4. Service Creator layer. The Service Creator is a party who has a license for producing
telecommunications service software to be made available to the Service Provider for
installation in the telecommunications network. In general, services can be intended for
being subscribed to by many Subscribers, or services can be tailored to one particular
Subscriber. The Service Creator can be a network operator, a network equipment vendor or
in general an independent software vendor. The Service Creator must understand the general
needs of the market within the domain of his services, but the immediate client is the Service
Provider. The Service Creator must understand the nature and functionality of the available
Service Constituents and how to combine them into complete Services.
5. Service Constituent Creator layer. The Service Constituent Creator is a party that has a
license for producing building blocks which are configured into complete services. The
Service Constituent layer has been split into several sub-layers, the functionality of Service
Constituents on one layer utilizing the functionality of Service Constituents on the sub-layers
below it. The Service Constituent layer is the highest layer where we expect to find
programming in the traditional sense of the word. The challenge is to create a programming
environment which guarantees the integrity of the system on the layers below it, and general
frameworks for the facilities to be provided on all levels above it. This can for example be
achieved by making lower-layer functionality available through carefully guarded interfaces,
in addition to requiring all modules to pass extensive validation test suites.
6. Network Provider layer. The Service Domain builds on the functionality of the Switching
Domain as shown in figure 1. The deliverables of the Network Provider are encapsulated in
the production facilities of the bottom layer of the Service Constituent Creator.
Note that there will be more Users than Subscribers, many more Subscribers than Service
Providers, many more Service Providers than Service Creators, more Service Creators than
Service Constituent Creators, and many more Service Constituent Creators than Network
Providers. Knowledge about end users should be pushed as far to the top of the hierarchy as
possible, since there are many different categories of Users. Knowledge about systems
programming and switching should be pushed as far down as possible, since skilled systems
programmers and communication experts is a scarce resource.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 7
25 August 1993 at: 18:27
2.3
A reference model for the creation and invocation of services
Organizational issues
Organizational ownership adds another dimension to the layers of figure 3??. The Network
Provider Layer and the lower sub-layers of the Service Constituent Layer will presumably be
owned and controlled by a communication provider such as a PTT; other sub-layers of the
Service Constituent Layer and the Service Creator layer may be owned by various software
houses or different departments of a PTT; the Service Provider layer may be supplied by various
retailers of IN services; users on the User layer will usually belong to the same organization as
the Subscriber. In all cases, the production facilities available to a particular actor will be the
subset of all facilities available to that layer subject to some kind of licensing agreement created
by administrative action.
Similar administrative action may be employed within an organization to limit the facilities
available to a particular group or individual.
2.4
Example Support Value Chain
Seen from a User, a Service appears as something concrete which may be bought and used. Seen
from the IN system, a service is rather intangible, it is realized as a number of interacting objects.
Some of these objects are specific to the Service, while others are shared with other Services. It
is the purpose of the different abstraction layers to manage the specification, design,
implementation, instantiation and invocation of these objects in a safe and controlled manner.
The general Support Value Chain of figure 3?? has been filled in with details from our concrete
example as shown in figure4??. We will describe each layer and the example information entities
on each layer before we go into details about the nature and contents of the entities.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 8
25 August 1993 at: 18:27
A reference model for the creation and invocation of services
IN Service
Layers
Service
Information Entities
User and Subscriber
Layers
Actors
Subscriber
and End User
Service Objects
Service Provider
Layer
Service Specification
Contract
Dealer
Service Creator
Layer
Conceptual Schema
Service vendo
User SM
Calling SM
Service Constituent
Creation Layers
Called SM
Service
Programmer
AbstrConn SM
Invocation SM
Network Provider
Layer
Network SM
Administration
programmer
Switch controll
programmer
Figure 4. IN-Lab2 support value chain.
The arrows denote the using relationships between the modules. Notice that the User SM does not export to the
Conceptual Schema, this means that the User objects are here a fixed part of the programs and not subject to
configuration.
The User and Subscriber Layers have been merged, because we do not provide any special
Subscriber functionality in our example. The Service Constituent Creator Layer has been subdivided to demonstrate that some Service Constituents will be built from more basic Service
Constituents. The information entities shown in figure 4?? are as follows:
1. User and Subscriber Layers. The Subscriber is the party who purchases a set of services on
behalf of one or more users, and is responsible for making the services available to his or her
users. The work of the Subscriber involves selecting a desired service and making a copy of
the relevant objects available to the User. Some of the service parameters may be bound as
part of this process. The User is the party who wants to use available services, and who is
responsible for the selection and invocation of a service. The invocation leads to creating a
copy of the relevant master objects, installing them in the Invocation environment, and
executing the service. All remaining parameters must be bound by the User as part of the
service invocation process.
-
Service Objects are a set of master objects unique to a particular User and stored in a data base
for that user. Service invocation consists of installing and invoking a copy of a service master.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 9
25 August 1993 at: 18:27
A reference model for the creation and invocation of services
2. Service Provider Layer. The Service Provider is a party who has a license for installing
telecommunications service software in the telecommunications network. The work of the
Service Provider involves creating concrete object structures which implement certain
desirable services, and making these object structures available to the Subscriber. Some of
the service parameters may be bound as part of this process. The deliverable from the Service
provider is contractual document defining a set of services, together with a master instance of
interconnected objects which define the particular set of services available to a given User.
Some of the free parameters are bound as part of the instantiation process.
-
Service Specification Contract. This is a structured document which may be traversed to
instantiate and install User objects together with their master service objects, and which may be
printed to provide a record of the installation on paper.
3. Service Creator Layer. The Service Creator is a party who has a license for producing
telecommunications service software to be made available for installation in the
telecommunications network. Service Constituents are generally made reusable, so that their
objects may be configured in many different ways to create different services. The Service
Creator defines a grammar, called an OOram Conceptual Model, which specifies which
objects may be involved in a certain (family of) services, how they are to be structured, and
possibly specializes their names to suit the mental model of the Service Provider. Some of
the service parameters may be bound as part of this process.
-
Conceptual Schema. This is a grammar which controls the creation of the Service Specification
Contract. It specifies all permissible object structures which may be instantiated in the Contract.
(The general principles are described in [Nordh89]).
4. Service Constituent Creation Layer. The Service Constituent Creator is a party who has a
license for producing building blocks which may be configured into complete services, and
who specifies new units of functionality in the form of role models. Access to the Switching
Domain is done through synthesis by importing the relevant Network Provider exported
models. A SC role model is then implemented, and the result may be made available to other
SCs by exporting a suitably constrained role model. The result may also be made available to
the Service Creator layer in the form of configurable object specifications, which define the
Service Constituent building blocks. They are exported to the Service Creator layer in the
form of an OOram Abstract Type Model, which define all possible ways that the Service
Constituents may be configured into complete services.
-
Service Programmer sub-layer
-
User SM. Module defining the interaction between the a general User object and the different
Service objects. (Details in report 93/8).
-
Called SM. Module defining the a Service Constituent for the Called end of a telephone
service. (Details in report 93/7).
-
Calling SM. Module defining the a Service Constituent for the Calling end of a telephone
service. (Details in report 93/6).
-
AbstrConn SM. Module defining the interaction between the Calling and the Called ends of a
telephone service. (Details in report 93/5).
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 10
25 August 1993 at: 18:27
-
A reference model for the creation and invocation of services
Administration programmer sub-layer
-
Invocation SM. Module defining the invocation environment for all services. (Details in
report 93/4).
5. Network Provider Layer. The Network Provider layer represents the actual switches in a
unified, implementation-independent manner. It makes its functionality available to the SC
Creator as OOram Client-Server models in the form of a number of exported role models
together with the corresponding implementation (classes).
-
Network SM. Module defining the functionality of the Switching Domain as it is seen from the
Service Domain. (Details in report 93/3).
The nature of the deliverables are summarized in the figure below.
User layer
Subscriber layer
Service Provider layer
Service Creator layer
Master structures of objects
Master structures of objects
Generic model
Abstract Data Type meta model
Service Constituent sub-layer
Frameworks with implemented superc
Service Constituent sub-layer
Client-Server models with implemente
Network Provider layer
Figure 5. The names of the deliverables used on each layer are shown in figure 5?? below.
2.5
Actors, Equipment and Name Spaces
A telecommunications network consists of interconnected equipment of different types which is
used by a variety of different actors. In this report, we will simplify matters and only look at a a
few essential entities.
In the following, we will be using the following name spaces:
1. subscriberID (subscrID). A Subscriber is an actor who enters into a contract with the service
provider to provide a specified set of services. The Subscriber is also the unit appropriate for
charging and billing. The Subscriber will be a real or legal person.
2. userID (usrID). A user is an actor which is using the network services without being part of
the network. A User object is an object in the user's terminal which represents the user in the
context of service invocation.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 11
25 August 1993 at: 18:27
A reference model for the creation and invocation of services
3. accessPointID (apID). An Access Point is a point in the switching network where a Terminal
may be connected. An accessPointID corresponds to the identity of a wire end point in the
permanent telephone system or a communication channel in the mobile telephone service.
Note that a common telephone terminal will usually be associated with three identifiers: A
userID which identifies it in the Service Domain, an accessPointID which identifies its
connection point in the Switching Domain, and a subscriberID which identifies the contracting
party.
A terminal which is used to manage network services, but which does not itself use such
services, will not need a accessPointID.
A terminal which is only used for communication, but which is not used for accessing the
Service Domain, will only need an accessPointID.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 12
25 August 1993 at: 18:27
Some extensions to the basic OOram product
Chapter 3
Some extensions to the basic OOram product
We assume that the notions of plain role models and their synthesis is known to the reader. We
refer to [Ree92] for further details about these notions.
NOTE: The definitions given in this section are tentative and need to be honed in the light of
future experience.
The following concepts not mentioned in [Ree92] are used in IN-Lab2:
1. OOram Type Specifications are role models with associated executable specifications. Their
roles are called Object types. An Object Type is the specification for a class (implemented in
Smalltalk-80).
2. Immutable roles are roles which may not be modified in any way in an importing model.
3. Environment roles are roles which send one or more stimulus messages.
4. An OOram Module is an encapsulation of one or more role models.
5. An OOram Export Model is a role model which is visible outside an OOram module. Export
Models are the only models visible outside the OOram Modules so that they may be
imported into other OOram Modules.
3.1
Notation and other conventions used in IN-Lab2
In IN-Lab2, symbol names of roles and role models follow the following conventions. The
corresponding notation is shown in figure 6??.
1. Plain role models are given the suffix RM, e.g. SW2ConnRM.
2. Type Specification models are given the suffix SPC, e.g. SW2ConnSPC.
3. Export models intended for synthesis into other models are given the suffix EXP, e.g.
TelA2UserEXP.
4. Export models specifying grammar types for the Conceptual Schema are given the suffix
CSC, e.g. TelA2SrvCSC.
5. Role symbol names are prefixed with the role model symbol name without suffix.
Executeable classes are named according to the following conventions:
1. An abstract class is generated for each object type, its name is the symbol name of the type
followed by a zero, e.g. TelA2Srvc0.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 13
25 August 1993 at: 18:27
Some extensions to the basic OOram product
2. A concrete class is generated for each object type as a subclass of the abstract, its name is the
symbol name of the type followed by a one, e.g. TelA2Srvc1.
Plain
Plain role
Immut
Immutable role
(Cannot be modified in import model)
Envir
Environment role
(Has stimuli)
Type
Object Type
(Has or will have class)
Immut
Envir
Immutable environment role
Immut
Type
Immutable object type
Envir
Type
Object type in environment
Immut
Env
Type
Immutable object type in environment.
(Meaningless, environment roles M
be extended by importer to explain
Figure 6. Notation for the different kinds of roles.
The correspondence between roles of different kinds and classes are as follows:
1. An Object Type is implemented as an abstract class with a concrete subclass. The abstract
class is generated automatically, all messages to be understood by the class are implemented
as self subclassResponsibility methods. The concrete class is implemented by a programmer.
2. An Object Type can at most import one other Object Type, the class will be subclass of the
imported type's class. (This restriction is caused by the single inheritance property of
Smalltalk, Eiffel, C++, etc)
3. Environment types may be implemented for testing purposes, but their class is not subclassed
in importing models. (Environment meaning that the role specifies additional behavior of an
object which is described elsewhere). Immutable environment types are therefore
meaningless.
4. The automatically generated implementations of Immutable Object Types ensure that they
cannot be subclassed.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 14
25 August 1993 at: 18:27
3.2
Some extensions to the basic OOram product
The OOram Module
The OOram Module is an encapsulation of role models and object specifications. The OOram
Module supports programming-in-the-large: The Module exports one or more carefully designed
models and hides all design and implementation details.
The OOram Module may import models from other modules and synthesize them into the
module's own role models. Object Specifications specify classes which may be implemented.
Simplified views of a selected set of these role models and specifications are exported to be used
in other models as illustrated in the figure below.
Import Models
Role Models
Object SpecificationsExport Models
Figure 7. The OOram Module.
An Export Model is a role model which is designed to be reused through synthesis into another
role model, and it may implemented as a set of classes designed to be subclassed in a controlled
manner.
An Export Model may consist of the following parts:
1. An OOram Role Model describing its functionality.
2. A coordinated set of classes which implement the model for executable specifications
(optional).
3. Rules for the import of the model, blocking the subclassing of some classes and restricting
the modifications permitted in the subclasses of others. The rules shall be designed to ensure
the static and dynamic integrity of the Constituent. Many different rules can be
contemplated, they should preferably be automatically enforceable or checkable (optional).
The export models are of the following kinds:
1. Mechanisms (suffix EXP). Role models defining archetypical objects and their interaction
without object type specification.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 15
25 August 1993 at: 18:27
Some extensions to the basic OOram product
2. Client-Servers (suffix EXP). Role models defining the interface to pre-programmed server
objects. The model specifies one or more server roles, which are implemented and not
intended for subclassing. It also defines one or more client roles, which are to be synthesized
into the corresponding roles in the importing modules, but which do not provide superclass
specifications.
3. Frameworks (Suffix EXP). Implemented role models defining abstract classes which are
designed to be subclassed. The functionality of the framework is imported into another
module by synthesizing its roles into corresponding roles in the importing role model. These
roles are intended to be modified in the importing models, the corresponding classes will be
subclasses of the framework classes.
4. Configuration Service Constituents (suffix CSC). Views on implemented object
specifications with exactly two roles: a root role and a leaf role. A CSC model specifies a
configuration type: Given an object playing the root role, one or more objects playing the
leaf role may be configured to be a root role collaborator. The configuration types are used to
control the creation of OOram Conceptual Models.
3.3
Work process considerations
Programming a small system like the current example in an incremental programming
environment like Smalltalk-80 would be relatively simple. Using exploratory programming
techniques, a satisfactory set of classes and methods would evolve naturally.
The situation is radically different when we add the rigorous of a systematic design
methodology. We now have a model of the program with a number of different and overlapping
views, all these views must be made consistent in all their details. The roles models prescribe
permissible message sends, these must be consistent with the messages actually sent by the
programs. Role models build on other role models through synthesis. If a role model is changed,
the importing role models must be updated accordingly. Tools can be provided to check and help
the programmer in the updating tasks, but there hard work is still involved and it is easy to get
lost in all the petty details.
Consider the current example. The programs consist of only 38 classes and 300 methods, about
half are created and updated automatically from the object type specifications. The total program
file is 2500 lines and 100 kBytes. This small program is specified in 6 OOram modules, there are
28 role models including 14 export models. The design and documentation is divided into 8 files
totalling 1.300 kBytes, 13 times the bare programs. We seem to remember having seen a report
that it takes three times as long to create a designed and documented program compared to just
writing it. Given the compactness and productivity of Smalltalk programming, this number
seems to be on the low side. (A corresponding program written in C would probably be at least
five times our number of lines).
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 16
25 August 1993 at: 18:27
Some extensions to the basic OOram product
The good news are that the discipline, modularity and precision provided by a good analysis and
design methodology makes it easier for us to scale to real-sized projects. The structure imposed
on the design gives other people a chance to understand what we have done and why we did it.
Quality checks can be applied at different levels of abstraction by independent auditors. The
logical descriptions makes it possible to apply automated tools to check that the programs
actually conform to the designer's intentions.
We offer the following advice for good working habits:
1. The architecture as it is embodied in the choice of modules and their exported functionality is
very important. The hassle involved in system updates is immensely reduced if one can get
the architecture right.
2. Keep it mean and lean. The models exported from the modules should be simple, easy to
understand and easy to apply.
3. Exploratory design and implementation of modules is a powerful method which yields good
results in a short period of time. But keep the architecture stable, exported models should be
changed infrequently and only after careful consideration.
4. Keep modules and role models brief and sketchy until the architecture all naming
conventions are stable.
5. more???
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 17
25 August 1993 at: 18:27
The combined User and Subscriber Layers
Chapter 4
The combined User and Subscriber Layers
The work of the Subscriber involves selecting a desired service and making a copy of the
relevant objects available to the User. Some of the service parameters may be bound as part of
this process. The User is the party who wants to use available services, and who is responsible
for the selection and invocation of a service. The invocation leads to creating a copy of the
relevant master objects, installing them in the Invocation environment, and executing the service.
All remaining parameters must be bound by the User as part of the service invocation process.
The deliverable to the User from the Service Provider is the required set of Services installed in
the User's data base.
<<<??CePe: Do you want to include a description of demo user interface here??>>>
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 18
25 August 1993 at: 18:27
The Service Provider Layer
Chapter 5
The Service Provider Layer
The work of the Service Provider involves creating concrete object structures which implement
certain desirable services, and making these object structures available to the Subscriber. Some
of the service parameters may be bound as part of this process. The deliverable from the Service
provider is contractual document defining a set of services, together with a master instance of
interconnected objects which define the particular set of services available to a given User. Some
of the free parameters are bound as part of the instantiation process. An appropriate medium for
this information is a Service Contract Document, which may be printed (and signed), and which
may be executed to cause the installation of the Subscriber, Users and their services in the
Service Domain.
The tool for creating this document is an intelligent editor which permits the Service Provider to
create any and all permissible Subscriber, User and Service specifications, and which
automatically prevents the creation of illegal combinations. (We strongly believe this is better
than an editor which permits anything and then hits its user with an error message if something is
wrong).
The deliverable from the Service Creator to the Service Provider is a Conceptual Model which
controls the insertions in the Contract Document Editor.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 19
25 August 1993 at: 18:27
The Service Provider Layer
Figure 8. Editor for specifying the Contract Document.
The object oriented tree structure tool shown in figure 8?? is in two parts: The left margin gives
a graphical representation of the structure, where the rectangular symbols represent the kind of
element shown to the right, and the small, black triangles represent insertion points, indicating
where the user may insert additional elements. Each insertion point only permits the insertion of
new elements which are appropriate at that point in the structure. The tool supports multi-media,
in the sense that it presents low-level phenomena such as texts, graphics and tables, as well as
high-level phenomena such as IN Services and Access Point Selectors. The appropriate editor for
the elements is automatically activated when the user points inside one of the information
elements in the right part of the tool. The tool permits selective zooming, the ellipsis after an
element symbol indicates that the element presentation has been collapsed into a one-liner.
In the above example, we show our editor when the Service Provider is defining the Tel-B
service. The specification says that the network Access Points with IDs 222, 333, 444 are to be
selected in a round robin fashion Monday through Friday between 08:00 and 16:00. The hidden
call forward selector specifies that all day Saturday and Sunday, incoming calls are to be
forwarded to the User with userID 5601. In all other cases, the call is to be received in the default
Access Point with accessPointID 222.
A node selection box appears when the Service Provider selects one of the insertion points. An
example is shown in figure 9?? below, it is the box appearing at the insertion point just above
"Call Forward Specification" in the above figure.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 20
25 August 1993 at: 18:27
The Service Provider Layer
Figure 9. Example of contract node insertion box.
The Service Provider may select a text node from the clipboard, or one of an AP-Selector or CF-Selector. The
Service Provider has changed his mind about the insertion, and pressed the Cancel-button.
5.1
Service Specification and Contract Document - Example
The printed result of the above contract example is shown on the following two pages. A real
contract document would contain more legal jumble and possibly a tailored user's manual, but
we have omitted such embellishments in this simple example.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 21
25 August 1993 at: 18:27
The Service Provider Layer
Contract document
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 22
25 August 1993 at: 18:27
The Service Provider Layer
Contract document
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 23
25 August 1993 at: 18:27
The Service Creator Layer
Chapter 6
The Service Creator Layer
The Service Creator is a party who has a license for producing telecommunications service
software to be made available for installation in the telecommunications network. Service
Constituents are generally made reusable, so that their objects may be configured in many
different ways to create different services. The Service Creator defines a kind of grammar, called
an OOram Conceptual Model, which specifies which objects may be involved in a certain
(family of) services, how they are to be structured, and possibly specializes their names to suit
the mental model of the Service Provider. Some of the service parameters may be bound as part
of this process. A simplified form of the model controlling our example application is shown in
figure 10?? below.
Figure 10. OOram Conceptual Model editor showing our example model.
This Conceptual Model says that a document consists of Texts, SubscriberData, and Users. A
User part consists of Texts, User-Data, and one or more services. The services offered here are
Tel-A and Tel-B, each is specified with describing Texts and certain attributes (Tel-A-Data and
Tel-B-Data). Tel-B-Data may optionally be modified with one or more Access Point Selectors
(AP-Selector) and/or Call Forward Selectors (CF-Selector).
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 24
25 August 1993 at: 18:27
The Service Creator Layer
Information about object type (Service Constituent), cardinality and initial values are associated
with each of these schema elements. There must for example be exactly one SubscrData in a
document, and one User-Data for each User. There can be at most one of each service, but any
number of Texts, AP-Selectors and CF-Selectors. The permissible sequence of elements is
specified in an extended form of the diagram (not shown here).
The Service Creator uses a special tool to define the available services. This tool permits the
construction of any schema supported by the available Service Constituents. Figure 10?? above
shows the appearance of the tool on the workstation screen. Implicit insertion points exist above,
below and to the right of all symbols, permitting the Service Creator to insert additional objects
to be made available to the Service Provider.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 25
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Chapter 7
The Service Constituent Creator Layer
This is the layer for actual programming of service functionality. The Service Constituent
Creator is a party who has a license for producing building blocks which may be configured into
complete services, and who specifies new units of functionality in the form of role models.
Access to the Switching Domain is done through synthesis by importing the relevant export
models from the Network Provider Layer. A Service Constituent (SC) role model is then
implemented, and the result made available to other SCs by exporting a suitably constrained role
models.
The deliverables from a Service Constituent Creator to the Service Creator is an OOram Abstract
Type Model, which define all possible ways that the Service Constituents may be configured into
complete services.
The deliverables from a Service Constituent Creator to another Service Constituent Creator are
OOram Export Models which may be imported into the other Service Constituent Creators
modules.
7.1
Abstract Type Model
An OOram Abstract Type specifies an object with the required properties of its collaborators.
There are 7 different Abstract Types in our example Conceptual Schema in figure 10??.
1. TextType is a general type, it specifies an object that can act as a node in a tree structure and
which has a text attribute. document, Text, User, Tel-A and Tel-B are applications of this
object type.
2. SubscrDataType is the special type of the SubscrData insertion.
3. UserDataType is the special type of the UserData insertion.
4. TelAType is the special type of the Tel-A-Data insertion.
5. TelBType is the special type of the Tel-B-Data insertion.
6. APAllocatorType is the special type of the AP-Selector insertion.
7. CFType is the special type of the CF-Selector insertion.
Composition Service Constituents, which are defined as export models with a CSC name suffix
in the Calling SM and Called SM modules, specify the properties of the OOram Abstract Types
as shown in figure 11??
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 26
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Export from Calling Telephone Serv
defining that
TelA2Srvc is a service that
can be connected under an Invocat
Analyzer.
Inv2
Analzr
TelA2
Srvc
TheTel-A-Type must be defined so tha
its instances can play
TelA2Srvc
the
role.
Export from Called Telephone Ser
defining that
TelB2 Srvc is a service tha
can be connected under an Invoca
Analyzer.
Inv2
Analzr
TelB2
Srcv
TheTel-B-Type must be defined so t
its instances can play
TelB2Srvc
the
role.
Export from Called Telephone Se
defining that
Tel2SelSrv is a selector th
can be connected under a B servi
TelB2
Srcv
Tel2
SelSrv
Both the
APAllocatorType and the
CFType
must be defined so that their insta
can play the
TelB2SelSrv role.
Figure 11. Composition Service Constituent types.
We use a simple syntax which we hope is self-explanatory for defining the abstract types. Notice
that there are two types for the TelB2SelSrv role. Their external properties are identical, but their
detailed functionality differ in that one selects an Access Point while the other selects a Call
Forward UserID.
type: TextType
subtypeOf: Object
role ... roleModel ... module ... " Role Model not provided in this example "
downNodes (Object).
type: SubscrDataType
subtypeOf: Object
role: ... roleModel: ... module: ... " Role Model not provided in this example "
downNodes: ().
type: UserDataType
subtypeOf: Object
role: nil roleModel: nil module: nil " Role Model not provided in this example "
downNodes: (Object)
" Not quite right, is it ?? "
type: TelAType
subtypeOf: Object
role: TelA2Srvc roleModel: TelA2SrvCSC module: TeleA2
downNodes: ().
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 27
25 August 1993 at: 18:27
The Service Constituent Creator Layer
type: TelBType
subtypeOf: Object
role: TelB2Srvc roleModel: TelB2SrvCSC module: TeleB2
downNodes: (APAllocatorType CFType)
type: APAllocatorType
role: TelB2SelSrv roleModel: TelB2SrvCSC module: TeleB2
subtypeOf: Object
downNodes: ().
type: CFType
role: TelB2SelSrv roleModel: TelB2SrvCSC module: TeleB2
subtypeOf: Object
downNodes: ().
The particular services assigned to a User are instantiated and installed through the structured
document called the Service Contract described in the previous section.
The 9 classes of these programs have been hand coded in InLab2. Automated aids for the
generation of these programs are for further study.
7.2
Service Constituent Export Models
A summary description of the models exported from the Service Constituent Provider sub-layers
are given in the following sub-sections.
7.2.1
Called Telephone module export models summary
TelB2 User-Service Interaction EXP (TelB2UserEXP) {Export Model}
Report including the following selections automatically generated 28 July 1993: Export
Models; Area of Concern stimuli; Role list diagram; Scenarios explanation
Area of Concern
Defines the interaction between the User object and the CalledTelephone service.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 28
25 August 1993 at: 18:27
The Service Constituent Creator Layer
The Roles
TelB2
Srcv
TelB2
User
Called Telephone Service CSC (TelB2SrvcCSC) {Export Model}
Report including the following selections automatically generated 28 July 1993: Export
Models; Area of Concern stimuli; Role list diagram; Scenarios explanation
Area of Concern
This model is a type specification for the called end of a telephone connection service.
The Roles
Inv2
Analzr
TelB2
Srcv
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 29
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Called Telephone selector CSC (TelB2SelCSC) {Export Model}
Report including the following selections automatically generated 28 July 1993: Export
Models; Area of Concern stimuli; Role list diagram; Scenarios explanation
Area of Concern
This model is a type specification for the called end of a telephone connection service.
The Roles
TelB2
Srcv
Tel2
SelSrv
7.2.2
Calling Telephone module export models summary
Connecting telephone Service Configuration Service Constituent (TelA2SrvCSC) {Export
Model}
Report including the following selections automatically generated 28 July 1993: Export
Models; Area of Concern stimuli; Role list diagram; Scenarios explanation
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 30
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Area of Concern
This model is a type specification for the calling end of a telephone connection service.
The Roles
Inv2
Analzr
TelA2
Srvc
TelA2 User-Service Interaction EXP (TelA2UserEXP) {Export Model}
Report including the following selections automatically generated 28 July 1993: Export
Models; Area of Concern stimuli; Role list diagram; Scenarios explanation
Area of Concern
Defines the interaction between the User object and the Calling Telephone service.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 31
25 August 1993 at: 18:27
The Service Constituent Creator Layer
The Roles
TelA2
User
7.2.3
TelA2
Srvc
Abstract Telephone Service export summary
Abstract Telephone Interaction EXP (Abstr2IntEXP) {Export Model}
Report including the following selections automatically generated 28 July 1993: Export Models
Area of Concern - stimuli Role list - diagram Scenarios - explanation
Area of Concern
This role model covers the interaction between the services of two users (A and B). Both the Aand B-services are capable of handling real time telephony calls. Service A handles telephony
calls in a way that suits A, service B handles calls in a way that suits user B. In this role model
service A is capable of generating new outgoing calls, while service B handles incoming calls.
The stimulus messages of this role model is a request by service B for context information from
service A. This message is typically the first message sent from service B after it has been
created and started. It is assumed that service B initially knows little about the state of service A
and the type of call A wants to make, just that service A is capable of generating calls.
This role model does not cover a complete protocol between service A and service B, just
messages that are relevant for the TINA demo. It is also expected that this role model can be split
into different role models covering different aspects of service interaction, e.g. charging,
connection setup, security, etc. For the sake of simplicity and due to our relatively simple
services we merge this into one role model at this stage.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 32
25 August 1993 at: 18:27
The Service Constituent Creator Layer
The Roles
Abstr2
AServ
Abstr2
BServ
Interaction Scenarios
Tel2
AServ
Tel2
BServ
releaseFromA
releaseFromB
Figure 12. Release connection from A {Scenario}
This MSC shows how a connection is released with the initiative coming from the calling side.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 33
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Tel2
AServ
Tel2
BServ
open
provideContext
call:qoc:
userBWaiting:
createLeg:direction:qoc:toConnPt:
Figure 13. Establish connection {Scenario}
This Message Sequence Chart shows the typical message sequence for the successful establishment of a telephone
connection.
Tel2
AServ
Tel2
BServ
releaseFromB
releaseFromA
Figure 14. Copy of Release connection from A (Release connection from B) {Scenario}
This MSC shows how a connection is released with the initiative coming from the called side.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 34
25 August 1993 at: 18:27
7.2.4
The Service Constituent Creator Layer
Service Installation and Invocation export models summary
Inv2InvocationMCH (Inv2InvMCH) {Export Model}
Report including the following selections automatically generated 28 July 1993: Export Models
Area of Concern - stimuli Role list - diagram Scenarios - explanation
Area of Concern
This mechanism is for service invocation in an intelligent network. It conveys the principles for
how to process a particular client's request for execution of a particular service.
The Roles
Inv
Mngr
Inv2
Analzr
Inv2
Client
Technical Overview IN-Lab report 93/2
Inv2
Serv
©Taskon 1998. Page 35
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Interaction Scenarios
Inv
Client
Inv
Mngr
Inv
Analzr
Inv
Serv
invocReq:
Figure 15. Invocation rejection 1 {Scenario}
This scenario exemplifies the earliest possible rejection of an invocation request. The returned value is false.
Inv
Client
Inv
Mngr
Inv
Analzr
Inv
Serv
invocReq:
servicesFor:
obeysProtocol:
getService:for:
obeysProtocol:
setUp:client:analyzer:invocator:
Figure 16. SelectAndOpenService {Scenario}
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 36
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Inv
Client
Inv
Mngr
Inv
Analzr
Inv
Serv
invocReq:
clientIdRequest
Figure 17. Invocation success 1 {Scenario}
This scenario shows the basic standard expected message flow during perfect execution of the invocation phase.
Inv2InvocationFW (Inv2InvFW) {Export Model}
The role model is identical to Inv2InvocationMCH, but the roles define suitable classes to be
subclassed by the importer.
Inv2InstallationEXP (Inv2InstallEXP) {Export Model}
Report including the following selections automatically generated 28 July 1993: Export Models
Area of Concern - stimuli Role list - diagram Scenarios - explanation
Area of Concern
The Service role represents the target application for the client. This is the software defining
some client's telecommunications service.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 37
25 August 1993 at: 18:27
The Service Constituent Creator Layer
The Roles
Inv
Mngr
Inv
Analzr
Inv
Installer
Inv
User
Inv
Serv
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 38
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Interaction Scenarios
Inv
Installer
Inv
Analzr
installService:
Figure 18. Service installation {Scenario}
Installing a service in an InvocationAnalyzer.
Inv
Client
Inv
Mngr
Inv
Analzr
Inv
Serv
invocReq:
Figure 19. Invocation rejection 1 {Scenario}
This scenario exemplifies the earliest possible rejection of an invocation request. The returned value is false.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 39
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Inv
Client
Inv
Mngr
Inv
Analzr
Inv
Serv
invocReq:
servicesFor:
obeysProtocol:
getService:for:
obeysProtocol:
setUp:client:analyzer:invocator:
Figure 20. SelectAndOpenService {Scenario}
Inv
Installer
Inv
Analzr
removeService:
Figure 21. Service removal {Scenario}
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 40
25 August 1993 at: 18:27
The Service Constituent Creator Layer
Inv
Client
Inv
Mngr
Inv
Analzr
Inv
Serv
invocReq:
clientIdRequest
Figure 22. Invocation success 1 {Scenario}
This scenario shows the basic standard expected message flow during perfect execution of the invocation phase.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 41
25 August 1993 at: 18:27
The Network Layer
Chapter 8
The Network Layer
In our context, the main responsibility of the Network Provider is to provide basic switching and
communication services to the IN services. A first separation of IN into a Switching Domain and
a Service Domain has been suggested in [Bugge91] as shown in figure 1??. A network
implementation which could support this layer is discussed in [Hand93].
The Switching Domain encapsulates all the problems associated with the rapid switching and
transmission of large masses of user data and hides the differences between switch
implementations, providing a universal interface to the Service Domain.
The Service Domain encapsulates all the problems associated with the great variety of services to
be provided. It can be thought of as a distributed system being supported by a communication
facility for signalling. Some of the services provided will be completely implemented in the
Service Domain, while others will be used to control the Switching Domain in a more or less
sophisticated manner.
The Network Layer exports two client-server models as described in the following sub-sections:
8.1
8.1.1
Network export models summary
Network Connection Model (Netw2ConnEXP) {Export Model}
Report automatically generated 24 July 1993
Area of Concern
The ConnectionControl is primarily responsible for the provision of communication paths
between two or more addressable entities in the network (end user, service provider, etc). The
ConnectionControl offers two different types of communication path:
1. Unidirectional communication path
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 42
25 August 1993 at: 18:27
The Network Layer
2. Bidirectional communication path.
These communication paths can be built up by service primitives on the attributes: Legs and
ConnectionPoints, to provide a large variety of connection configurations. But some restrictions
are put on the possible combinations:
1. The parts of a communication path must all be unidirectional or bidirectional.
2. For the unidirectional case, at most one source (addressable entity) can be connected at a time
(no restriction on number of connected sinks), i.e. effectively supporting point-to-multipoint
configuration.
3. For the bidirectional case, at most two addressable entities may be connected at a time, i.e.
effectively supporting point-to-point configurations.
The objects of this role model are abstract, in the sense that they are responsible for the isolation
of the Client from the ATM specific network technology.
The Roles
Netw2
Conn
Client
Netw2
Conn
Leg
Netw2
Conn
Point
1. Net2Connection Client (Netw2ConnClient) {Type}. The service instance,
Netw2ConnClient, views the network as a virtual switch object and represents a user of the
Connection Control.
2. Netw2Connection Leg (Netw2ConnLeg) {Type}. This role represents a communication
path from a connection point towards an addressable entity in the network (e.g. an end user
terminal). A Leg is always associated with a ConnectionPoint. Leg is responsible for storing
the information characterizing the leg.
3. Netw2Connection Point (Netw2ConnPoint) {Type}. This role represents an interconnection
or logical bridge allowing information to flow between legs.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 43
25 August 1993 at: 18:27
The Network Layer
Interaction Scenarios
Netw2
Conn
Client
Netw2
Conn
Point
Netw2
Conn
Leg
openCPFor:type:responseLevel:
createLeg:direction:to:qoc:
modifyQoc:
modifyDirection:
freeLeg
freeCp
Figure 23. Rudimentary create and free sequence. {Scenario}
8.1.2
Network Access Manager EXP (Netw2MngrEXP) {Export Model}
Report automatically generated 24 July 1993
Area of Concern
This role model describes the main access point to the Switching Domain. Its purpose is to
provide the client with the available Switching Domain services. It combines the functionality of
a general switch manager and some socket types.
The ConnectionControl is primarily responsible for the provision of communication paths
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 44
25 August 1993 at: 18:27
The Network Layer
between two or more addressable entities in the network (end user, service provider, etc). The
ConnectionControl offers two different types of communication path:
1. Unidirectional communication path
2. Bidirectional communication path.
These communication paths can be built up by service primitives on the attributes: Legs and
ConnectionPoints, to provide a large variety of connection configurations. But some restrictions
are put on the possible combinations:
1. The parts of a communication path must all be unidirectional or bidirectional.
2. For the unidirectional case, at most one source (addressable entity) can be connected at a time
(no restriction on number of connected sinks), i.e. effectively supporting point-to-multipoint
configuration.
3. For the bidirectional case, at most two addressable entities may be connected at a time, i.e.
effectively supporting point-to-point configurations.
The objects of this role model are abstract, in the sense that they are responsible for the isolation
of the Client from the ATM specific network technology.
The Roles
Netw2
Mngr
Client
Netw2
Mngr
1. Network Manager Client (Netw2MngrClient) {Type}. Any Service Domain object which
has access to the Switching Domain services.
2. Network Access Manager (Netw2Mngr) {Type}. This object is a main access point to the
Switching domain, giving access to the specialized Switching Domain services.
The service client views the network as a virtual switch object and represents a user of the
Connection Control.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 45
25 August 1993 at: 18:27
References
Appendix 1
References
[Bugge91] Bugge B. et al. Methods and tools for service creation in an intelligent network, initial
document. Kjeller, Norwegian Telecom Research, 1991 (Research Doc. No. 34/91)
[Chambers] Chambers's Encyclopædia, Gerorge Newnes Ltd 1955, vol X p. 663a.
[EAndRee92] Egil P. Andersen, Trygve Reenskaug: System Design by Composing Structures of
Interacting Objects. ECOOP '92, Utrecht, Holland.
[Etzioni64] Amitai Etzioni: Modern Organizations. Prentice-Hall 1964. pp 53-54
[GCOlsen92] Grete Christina Olsen: Object oriented data bases and role models. MSc thesis, Dept. of
Informastics, University of Oslo, 1992. (In Norwegian).
[Hand93] Tom Handegård, Bengt G. Jensen, Kirsti A. Løvnes: IN control of broadband Networks. The
Forth Telecommunications Information Networking Architecture Workshop, L'Aquila, Italy. (TINA-93)
[Harel87] David Harel: Statecharts: A Visual Formalism for Complex Systems. Science of Computer
Programming, 8:231-274, Elsevier 1987.
[JAndRee91] Jørn Andersen, Trygve Reenskaug: Operations on sets in an OODB. OOPS Messenger, 2,4
(October 1991)
[Nordh89] Else Nordhagen: Generic Object Oriented Systems. Proceedings of Tools 89, Paris November
1989 (pp. 131,140)
[Ree73] Trygve M. H. Reenskaug: Prokon/Plan - A Modelling Tool for Project Planning and Control.
IFIP Conference, North-Holland 1977.
[Ree92] Trygve Reenskaug, Egil P. Andersen, Arne Jørgen Berre, Anne Hurlen, Anton Landmark, Odd
Arild Lehne, Else Nordhagen, Eirik Næss-Ulseth, Gro Oftedal, Anne Lise Skaar, Pål Stenslet: OORASS:
Seamless Support for the Creation and Maintenance of Object Oriented Systems. Journal of Object
Oriented Programming, October 1992, pp 27-41.
[Vestli, Nilsen 92] Vestli, Nilsen: The Intelligent Network Service Life Cycle. Telektronikk 2.92
(Norwegian Telecom Research, P.b. 83, 2007-Kjeller, Norway)
Anne Lise Skaar: Objektorienterte produktmodeller i DAK-system. Institute of Informatics, University of
Oslo, 1982
Else Nordhagen: Blaise, syntaksorientert programredigering av Pascal tekst i et Smalltalk system. MSc
thesis, Institute of Informatics, University of Oslo, 1982
Jørn Andersen, Trygve Reenskaug: Operations on sets in an OODB. OOPS Messenger, 2, 4 (Oct. 1991)
pp. 26-39.
Pål Stenslet: Spørresystem basert på Smalltalk. MSc thesis, Institute of Informatics, University of Oslo,
1982
Rebecca J. Wirfs-Brock, Ralph E. Johnson: Surveying current research in object-oriented design.
Communications of the ACM, 33, 9 (September 1990) pp 113 ff.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 46
25 August 1993 at: 18:27
References
T. M. H. Reenskaug: "User-Oriented Descriptions of Smalltalk Systems". Byte, 6, 8 (August 1981)
pp148-166 and G. E. Peterson: Tutorial: Object-Oriented Computing, Volume 1: Concepts. The
Computer Society of IEEE 1987, pp75-81.
T. Reenskaug, E. Næss-Ulseth: "Tender/One - An Environment for Tender Preparation". Ninth
International Cost Engineering Congress, Oslo 1986.
Trygve Reenskaug, Anne Lise Skaar: An Environment for Literate Smalltalk Programming. Sigplan
Notices 24 10 (Oct 89) OOPSLA 89 pp 337-345
Trygve Reenskaug: Administrative Control in the Shipyard. ICCAS Conference, Tokyo 1973.
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 47
25 August 1993 at: 18:27
Monitored executions
Appendix 2
Monitored executions
App 2.1
Inv2Install1 fileIn {Role Model}
Report including the following selections automatically generated 21 July 1993: Role Models Area of Concern stimuli Role list - diagram Scenarios Message Sets
App 2.1.1
Area of Concern
App 2.1.2
The Roles
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 48
25 August 1993 at: 18:27
Inv2
Mngr
#101
Monitored executions
Term2
User
#107
17
TelB2
Srcv
#110
5
27
14
28
18
Inv2
Install
#106
2
Term2
User
#102
8
Inv2
Analzr
#103
26
25
22
10
TelA2
Srvc
#109
9
11
Tel2
SelSrv
#105
App 2.1.3
Inv2
Analzr
#108
TelB2
Srcv
#104
12
Tel2
SelSrv
#106
Interaction Scenarios
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 49
App 2.1.4
Inv2
Mngr
#101
Technical Overview IN-Lab report 93/2
userID
initializeFrom:
servicesOfKind:
servicesOfKind:
initializeFrom:
servicesOfKind:
servicesOfKind:
invocReq:
addUser:analyzer:
userID
userID:subscrID:manager:user:
userID:manager:analyzer:
invocReq:
initializeFrom:
servicesOfKind:
servicesOfKind:
invocReq:
addUser:analyzer:
userID:subscrID:manager:user:
userID:manager:analyzer:
invocReq:
Inv2
Install
#106
Term2
User
#102
kind
Inv2
Analzr
#103
initializeFrom:
initializeFrom:
TelB2
Srcv
#104
Tel2
SelSrv
#105
Tel2
SelSrv
#106
Term2
User
#107
kind
kind
kind
kind
Inv2
Analzr
#108
TelA2
Srvc
#109
TelB2
Srcv
#110
25 August 1993 at: 18:27
Monitored executions
Figure 24. Inv2Install1 fileIn {Scenario}
Message Sets
©Taskon 1998. Page 50
25 August 1993 at: 18:27
1.
2.
3.
4.
5.
Monitored executions
Inv2Install#106 {Role}
- 18 {Port}
- executed {Contract}
- invocReq: {Message}
- addUser:analyzer: {Message}
- 2 {Port}
- executed {Contract}
- userID:manager:analyzer: {Message}
- 8 {Port}
- executed {Contract}
- userID:subscrID:manager:user: {Message}
- servicesOfKind: {Message}
- 10 {Port}
- executed {Contract}
- initializeFrom: {Message}
- 14 {Port}
- executed {Contract}
- userID:manager:analyzer: {Message}
- 25 {Port}
- executed {Contract}
- userID:subscrID:manager:user: {Message}
- servicesOfKind: {Message}
22
{Port}
- executed {Contract}
- initializeFrom: {Message}
28
{Port}
- executed {Contract}
- initializeFrom: {Message}
Inv2Mngr#101 {Role}
- 5 {Port}
- executed {Contract}
- userID {Message}
17
{Port}
- executed {Contract}
- userID {Message}
Inv2Analzr#103 {Role}
- 9 {Port}
- executed {Contract}
- kind {Message}
TelB2Srcv#104 {Role}
- 11 {Port}
- executed {Contract}
- initializeFrom: {Message}
- 12 {Port}
- executed {Contract}
- initializeFrom: {Message}
Inv2Analzr#108 {Role}
- 26 {Port}
- executed {Contract}
- kind {Message}
- 27 {Port}
- executed {Contract}
- kind {Message}
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 51
25 August 1993 at: 18:27
App 2.1.5
Monitored executions
Inv2Install1 fileIn trace file
Inv2Install1 fileIn
TASKON/OOram INLab Monitored Execution. on 21 July 1993 at 9:59:28 pm
version e03-t11.im1
Inv2Install#106 -> Inv2Mngr#101 invocReq: ('5602')
>> nil
Inv2Install#106 -> Term2User#102 userID:manager:analyzer: ('5602' Inv2Mngr#101 Inv2Analzr#103)
>> Term2User#102
Inv2Install#106 -> Inv2Analzr#103 userID:subscrID:manager:user: ('5602' '56' Inv2Mngr#101 Term2User#102)
>> Inv2Analzr#103
Inv2Install#106 -> Inv2Mngr#101 addUser:analyzer: (Term2User#102 Inv2Analzr#103)
>> Inv2Mngr#101
)-- Inv2Mngr#101 -> Term2User#102 userID )
>> '5602'
Inv2Install#106 -> Inv2Mngr#101 invocReq: ('5602')
Inv2Install#106 -> Inv2Analzr#103 servicesOfKind: (#TelB)
>> RMSOrderedCollection ()
)-- nil -> Inv2Analzr#103 installService: (TelB2Srcv#104)
>> Inv2Analzr#103
Inv2Install#106 -> Inv2Analzr#103 servicesOfKind: (#TelB)
>> RMSOrderedCollection (TelB2Srcv#104 )
Inv2Analzr#103 -> TelB2Srcv#104 kind )
>> #TelB
)-- Inv2Install#106 -> TelB2Srcv#104 initializeFrom: (RMSDictionary ('apID'->222 'serviceKind'->'TelB' 'title'->'Connection called
party specification' 'selectors'->RMSOrderedCollection (RMSDictionary ('kind'->#APSelector 'weekdays'->RMSOrderedCollection
(#Monday #Tuesday #Wednesday #Thursday #Friday ) 'apCondition'->#roundRobin 'endTime'->'16:00' 'startTime'->'08:00' 'apIDs'>RMSOrderedCollection (222 333 444 ) ) RMSDictionary ('kind'->#CallForward 'weekdays'->RMSOrderedCollection (#Saturday
#Sunday ) 'apCondition'->#roundRobin 'endTime'->'24:00' 'userIDs'->RMSOrderedCollection (5601 ) 'startTime'->'00:00' ) ) ))
>> TelB2Srcv#104
)-- TelB2Srcv#104 -> Tel2SelSrv#105 initializeFrom: (RMSDictionary ('kind'->#APSelector 'weekdays'->RMSOrderedCollection
(#Monday #Tuesday #Wednesday #Thursday #Friday ) 'apCondition'->#roundRobin 'endTime'->'16:00' 'startTime'->'08:00' 'apIDs'>RMSOrderedCollection (222 333 444 ) ))
>> Tel2SelSrv#105
)-- TelB2Srcv#104 -> Tel2SelSrv#106 initializeFrom: (RMSDictionary ('kind'->#CallForward 'weekdays'->RMSOrderedCollection
(#Saturday #Sunday ) 'apCondition'->#roundRobin 'endTime'->'24:00' 'userIDs'->RMSOrderedCollection (5601 ) 'startTime'->'00:00'
))
>> Tel2SelSrv#106
Inv2Install#106 -> Inv2Mngr#101 invocReq: ('5601')
>> nil
Inv2Install#106 -> Term2User#107 userID:manager:analyzer: ('5601' Inv2Mngr#101 Inv2Analzr#108)
>> Term2User#107
Inv2Install#106 -> Inv2Analzr#108 userID:subscrID:manager:user: ('5601' '56' Inv2Mngr#101 Term2User#107)
>> Inv2Analzr#108
Inv2Install#106 -> Inv2Mngr#101 addUser:analyzer: (Term2User#107 Inv2Analzr#108)
>> Inv2Mngr#101
)-- Inv2Mngr#101 -> Term2User#107 userID )
>> '5601'
Inv2Install#106 -> Inv2Mngr#101 invocReq: ('5601')
Inv2Install#106 -> Inv2Analzr#108 servicesOfKind: (#TelA)
>> RMSOrderedCollection ()
)-- nil -> Inv2Analzr#108 installService: (TelA2Srvc#109)
>> Inv2Analzr#108
Inv2Install#106 -> Inv2Analzr#108 servicesOfKind: (#TelA)
>> RMSOrderedCollection (TelA2Srvc#109 )
Inv2Analzr#108 -> TelA2Srvc#109 kind )
>> #TelA
)-- Inv2Install#106 -> TelA2Srvc#109 initializeFrom: (RMSDictionary ('apID'->111 'serviceKind'->'TelA' 'title'->'Plain Old Telephone
calling party specification' ))
>> TelA2Srvc#109
Inv2Install#106 -> Inv2Analzr#108 servicesOfKind: (#TelB)
>> RMSOrderedCollection ()
Inv2Analzr#108 -> TelA2Srvc#109 kind )
>> #TelA
)-- nil -> Inv2Analzr#108 installService: (TelB2Srcv#110)
>> Inv2Analzr#108
Inv2Install#106 -> Inv2Analzr#108 servicesOfKind: (#TelB)
>> RMSOrderedCollection (TelB2Srcv#110 )
Inv2Analzr#108 -> TelA2Srvc#109 kind )
>> #TelA
Inv2Analzr#108 -> TelB2Srcv#110 kind )
>> #TelB
)-- Inv2Install#106 -> TelB2Srcv#110 initializeFrom: (RMSDictionary ('apID'->111 'serviceKind'->'TelB' 'title'->'Plain Old Telephone
called party specification' 'selectors'->RMSOrderedCollection () ))
>> TelB2Srcv#110
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 52
25 August 1993 at: 18:27
App 2.2
Monitored executions
Inv2Install1 example4Connect: '5601' to: 5602 {Role Model}
Report including the following selections automatically generated 22 July 1993: Role Models Area of Concern stimuli Role list - diagram Scenarios Message Sets
App 2.2.1
Area of Concern
App 2.2.2
The Roles
TelB2
Srcv
#110
TelB2
Srcv
#104
Inv2
Mngr
#101
13
TelA2
Srvc
#109
18
5
3
9
Inv2
Analzr
#108
4
Inv2
Analzr
#103
14
6
10
1
Term2
User
#107
17
8
7
11
TelA2
Srvc
#10903
TelB2
Srcv
26 #10403
23
21
19
Netw2
ConnPoint
#118
24
22 27
Tel2
SelSrv
#105
25
Tel2
SelSrv
#106
20
Netw2
MngrServer
#111
Technical Overview IN-Lab report 93/2
Netw2
ConnLeg
#119
Netw2
ConnLeg
#120
©Taskon 1998. Page 53
TelA2
Srvc
#109
Technical Overview IN-Lab report 93/2
userReq:
user
potsConnect:from:to:qoc:
setUp:client:analyzer:invocator:
kind
protocol
kind
Inv2
Analzr
#108
TelB2
Srcv
#110
Inv2
Mngr
#101
userReq:
createLeg:direction:qoc:toConnPt:
createLeg:direction:to:qoc:
createCp:with:for:
call:qoc:
open
getService:for:
invocReq:
TelA2
Srvc
#10903
TelB2
Srcv
#104
user
setUp:client:analyzer:invocator:
protocol
kind
Inv2
Analzr
#103
createLeg:direction:to:qoc:
selectRequest
Netw2
ConnPoint
#118
Netw2
ConnLeg
#119
connPt:client:direction:to:qo
connPt:client:direction:to:qo
openCPFor:type:responseLevel:
Netw2
MngrServer
#111
selectRequest
TelB2
Srcv
#10403
App 2.2.3
obeysProtocol:
getService:for:
Term2
User
#107
25 August 1993 at: 18:27
Monitored executions
Interaction Scenarios
©Taskon 1998. Page 54
Monitored executions
qoc:
qoc:
Tel2
SelSrv
#105
Tel2
SelSrv
#106
Netw2
ConnLeg
#120
25 August 1993 at: 18:27
Figure 25. Inv2Install1 example4Connect: '5601' to: 5602 {Scenario}
App 2.2.4
1.
2.
Message Sets
Term2User#107 {Role}
- 1 {Port}
- executed {Contract}
- getService:for: {Message}
- 7 {Port}
- executed {Contract}
- potsConnect:from:to:qoc: {Message}
Inv2Analzr#108 {Role}
- 4 {Port}
- executed {Contract}
- obeysProtocol: {Message}
- 3 {Port}
- executed {Contract}
- kind {Message}
- protocol {Message}
- 5 {Port}
- executed {Contract}
- kind {Message}
- 6 {Port}
- executed {Contract}
- setUp:client:analyzer:invocator: {Message}
9
{Port}
- executed {Contract}
- userReq: {Message}
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 55
25 August 1993 at: 18:27
3.
4.
5.
6.
Monitored executions
TelA2Srvc#10903 {Role}
- 8 {Port}
- executed {Contract}
- user {Message}
- 10 {Port}
- executed {Contract}
- invocReq: {Message}
- 11 {Port}
- executed {Contract}
- getService:for: {Message}
- 23 {Port}
- executed {Contract}
- open {Message}
- call:qoc: {Message}
- createLeg:direction:qoc:toConnPt: {Message}
- 19 {Port}
- executed {Contract}
- createCp:with:for: {Message}
- 21 {Port}
- executed {Contract}
- createLeg:direction:to:qoc: {Message}
Inv2Analzr#103 {Role}
- 13 {Port}
- executed {Contract}
- kind {Message}
- protocol {Message}
- 14 {Port}
- executed {Contract}
- setUp:client:analyzer:invocator: {Message}
- 18 {Port}
- executed {Contract}
- userReq: {Message}
TelB2Srcv#10403 {Role}
- 17 {Port}
- executed {Contract}
- user {Message}
- 24 {Port}
- executed {Contract}
- selectRequest {Message}
- 25 {Port}
- executed {Contract}
- selectRequest {Message}
- 26 {Port}
- executed {Contract}
- createLeg:direction:to:qoc: {Message}
Netw2MngrServer#111 {Role}
- 20 {Port}
- executed {Contract}
- openCPFor:type:responseLevel: {Message}
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 56
25 August 1993 at: 18:27
7.
Monitored executions
Netw2ConnPoint#118 {Role}
- 22 {Port}
- executed {Contract}
- connPt:client:direction:to:qoc: {Message}
- 27 {Port}
- executed {Contract}
- connPt:client:direction:to:qoc: {Message}
App 2.2.5
Inv2Install1 example4Connect: '5601' to: 5602 trace file
Inv2Install1 example4Connect: '5601' to: 5602
TASKON/OOram INLab Monitored Execution. on 22 July 1993 at 7:54:18 am
version e03-t11.im1
Term2User#107 -> Inv2Analzr#108 getService:for: (#TelA Term2User#107)
Inv2Analzr#108 -> TelA2Srvc#109 kind )
>> #TelA
Inv2Analzr#108 -> TelA2Srvc#109 protocol )
>> #TelA
Inv2Analzr#108 -> Term2User#107 obeysProtocol: (#TelA)
>> true
Inv2Analzr#108 -> TelB2Srcv#110 kind )
>> #TelB
Inv2Analzr#108 -> TelA2Srvc#10903 setUp:client:analyzer:invocator: (#() Term2User#107 Inv2Analzr#108 Inv2Mngr#101)
>> TelA2Srvc#10903
)-- Term2User#107 -> TelA2Srvc#10903 potsConnect:from:to:qoc: (#Duplex Term2User#107 '5602' 2400)
>> TelA2Srvc#10903
TelA2Srvc#10903 -> Inv2Analzr#108 user )
)-- Inv2Analzr#108 -> Inv2Mngr#101 userReq: ('5601')
)-- TelA2Srvc#10903 -> Inv2Mngr#101 invocReq: ('5602')
)-- TelA2Srvc#10903 -> Inv2Analzr#103 getService:for: (#TelB {TelA2Srvc#10903})
Inv2Analzr#103 -> TelB2Srcv#104 kind )
>> #TelB
Inv2Analzr#103 -> TelB2Srcv#104 protocol )
>> #TelB
Inv2Analzr#103 -> TelB2Srcv#10403 setUp:client:analyzer:invocator: (#() {TelA2Srvc#10903} Inv2Analzr#103 Inv2Mngr#101)
>> TelB2Srcv#10403
)-- TelA2Srvc#10903 -> TelB2Srcv#10403 open )
>> TelB2Srcv#10403
)-- TelA2Srvc#10903 -> TelB2Srcv#10403 call:qoc: (#Duplex 2400)
>> TelB2Srcv#10403
TelB2Srcv#10403 -> Inv2Analzr#103 user )
)-- Inv2Analzr#103 -> Inv2Mngr#101 userReq: ('5602')
TelA2Srvc#10903 -> Netw2MngrServer#111 createCp:with:for: (#Duplex #OnlyNack TelA2Srvc#109)
Netw2MngrServer#111 -> Netw2ConnPoint#118 openCPFor:type:responseLevel: (TelA2Srvc#109 #Duplex #OnlyNack)
>> Netw2ConnPoint#118
)-- TelA2Srvc#10903 -> Netw2ConnPoint#118 createLeg:direction:to:qoc: (#Duplex #None 111 2400)
Netw2ConnPoint#118 -> Netw2ConnLeg#119 connPt:client:direction:to:qoc: ({Netw2ConnPoint#118} TelA2Srvc#109 #None 111
2400)
>> Netw2ConnLeg#119
)-- TelA2Srvc#10903 -> TelB2Srcv#10403 createLeg:direction:qoc:toConnPt: (#Duplex #None 2400 Netw2ConnPoint#118)
TelB2Srcv#10403 -> Tel2SelSrv#105 selectRequest )
>> false
TelB2Srcv#10403 -> Tel2SelSrv#106 selectRequest )
>> false
TRACE-Tel2SelSrv#106-selection not implemented
TRACE-TelB2Srcv#10403-#('default' 222 )
)-- TelB2Srcv#10403 -> Netw2ConnPoint#118 createLeg:direction:to:qoc: (#Duplex #None 222 2400)
Netw2ConnPoint#118 -> Netw2ConnLeg#120 connPt:client:direction:to:qoc: ({Netw2ConnPoint#118} TelA2Srvc#109 #None 222
2400)
>> Netw2ConnLeg#120
TRACE-TelA2Srvc#10903-commenceCommunication
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 57
25 August 1993 at: 18:27
Taskon standard QualityCheck of the IN2 implementation
Appendix 3
Taskon standard QualityCheck of the IN2 implementation
App 3.1
Error reports
This section describes errors which should be corrected as soon as possible.
Taskon Smalltalk program Quality report automatically generated 24 July 1993 from image e03t12.im1
None
App 3.2
General information
This section is for the information and enlightentment of the responsible programmer.
Taskon Smalltalk program Quality report automatically generated 24 July 1993 from image e03t12.im1
Check Class Comments
Inv2Analzr1 has no comment
Inv2Client1 has no comment
Inv2Serv1 has no comment
Netw2ConnClient1 has no comment
Netw2ConnLeg1 has no comment
Netw2ConnPoint1 has no comment
Netw2MngrClient1 has no comment
Netw2MngrServer1 has no comment
RMSAllocator1 has no comment
RMSCallForward1 has no comment
RMSSection1 has no comment
RMSServiceContract1 has no comment
RMSSubscrInstall1 has no comment
RMSTeleA1 has no comment
RMSTeleB1 has no comment
RMSText1 has no comment
RMSUserInstall1 has no comment
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 58
25 August 1993 at: 18:27
Taskon standard QualityCheck of the IN2 implementation
TelA2Srvc1 has no comment
TelB2Srcv1 has no comment
Term2User1 has no comment
Check for inst.vars. not referenced
Inv2Install0 does not reference the following instance variables:
analyzer
invocManager
service
user
Netw2ConnClient0 does not reference the following instance variables:
connectionPoint
legs
Netw2MngrClient0 does not reference the following instance variable:
netwManager
Netw2MngrServer0 does not reference the following instance variables:
connectionPoint
legs
TelB2Srcv0 does not reference the following instance variables:
connectionPoint
legs
Check for classes being referenced.
RMSTeleA1 does not seem to be referenced neither by name nor by class
RMSTeleB1 does not seem to be referenced neither by name nor by class
Comment: This is OK, the classes are referenced through the Conceptual Model.
Check for methods implemented but not sent
Inv2Install1 class implements the following unsent messages:
countProgramSizeInLab example2: example4Connect:to: fileOutINLabTo:
Term2User1 implements the following unsent messages:
example4ConnectTo:
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 59
25 August 1993 at: 18:27
Taskon standard QualityCheck of the IN2 implementation
Check Method history
62 Taskon-modified methods
62 dated changes
1 dated changes on most frequently changed method.
1.0 dated changes per method.
Report Program Size
38 classes. 315 methods. 1115 lines.
O.K.
Check that changeParameterAssociations and tmInitialize is implemented
Check tmInitialize and formats
Check for Undeclared references
Check for sent but not implemented
Check for obsolete classes.
Method consistency check
Check for unimplemented subclassResponsibility
Check for references to outdated classes.
Check changed-update conversion.
Check unused class variables.
Check empty methods.
Check that method sources exist
Technical Overview IN-Lab report 93/2
©Taskon 1998. Page 60
TABLE OF CONTENTS
Chapter 1
Introduction
2
Chapter 2
A reference model for the creation and invocation of
services
4
2.1
The generic support layer
5
2.2
A possible Support Value Chain
5
2.3
Organizational issues
8
2.4
Example Support Value Chain
8
2.5
Actors, Equipment and Name Spaces
11
Some extensions to the basic OOram product
13
3.1
Notation and other conventions used in IN-Lab2
13
3.2
The OOram Module
15
3.3
Work process considerations
16
Chapter 4
The combined User and Subscriber Layers
18
Chapter 5
The Service Provider Layer
19
Service Specification and Contract Document - Example
21
Chapter 6
The Service Creator Layer
24
Chapter 7
The Service Constituent Creator Layer
26
7.1
Abstract Type Model
26
7.2
7.2.1
7.2.2
7.2.3
7.2.4
Service Constituent Export Models
Called Telephone module export models summary
Calling Telephone module export models summary
Abstract Telephone Service export summary
Service Installation and Invocation export models summary
28
28
30
32
35
The Network Layer
42
Network export models summary
Network Connection Model (Netw2ConnEXP) {Export Model}
Network Access Manager EXP (Netw2MngrEXP) {Export Model}
42
42
44
Chapter 3
5.1
Chapter 8
8.1
8.1.1
8.1.2
Technical Overview IN-Lab report 93/2
<i>
Appendix 1
References
46
Appendix 2
Monitored executions
48
App 2.1
App 2.1.1
App 2.1.2
App 2.1.3
App 2.1.4
App 2.1.5
Inv2Install1 fileIn {Role Model}
Area of Concern
The Roles
Interaction Scenarios
Message Sets
Inv2Install1 fileIn trace file
48
48
48
49
50
52
App 2.2
App 2.2.1
App 2.2.2
App 2.2.3
App 2.2.4
App 2.2.5
Inv2Install1 example4Connect: '5601' to: 5602 {Role Model}
Area of Concern
The Roles
Interaction Scenarios
Message Sets
Inv2Install1 example4Connect: '5601' to: 5602 trace file
53
53
53
54
55
57
Taskon standard QualityCheck of the IN2
implementation
58
App 3.1
Error reports
58
App 3.2
General information
58
Appendix 3
Technical Overview IN-Lab report 93/2 <ii>