Injbnnurion and So/iwar-e Technology 1995 37 (1) IS-22

Object-oriented development for telecommunication services

Panos Fitsilis INTRASOFT SA, 2 .4drianiou St, 11.5 25 Athens, Greece e-mail:fit~ilis@isoft.inrranet.gr

In this paper an integrated object-oriented methodology for the development of telecommunication services is presented. Methodology integration refers to the capability to support development approaches that have multiple alternative perspectives. The proposed methodology is composed of three different models: the object model, the task model, and the architectural model. Each of these models gives emphasis to different system features. The object model is based on Coad and Yourdon object-oriented methodology and describes primarily the functionality and the data manipulated by the system. Since telecommunication service development has special requirements, some new features have been added to the methodology in order to support complexity handling and control. The task model describes the way the control is enforced within the system. Finally, the architectural model gives the actual layout and the task distribution of the system.

Keyword\: development of telecommunication services, object-oriented methodologies

Object-oriented development is not very common in today’s

telecommunication industry. However, it is recognized

as having great potential for improving the quality and reliability of complex software.

Telecommunication systems are characterized by a com- mon feature-their complexit,y. This is manifested by the

large number of the providecl services. A typical service

consists of thousands of software objects that are running

on hundreds of hardware objects. All these objects are

interacting in a complex and almost unpredictable way. To develop new services as quickly as possible, telecommuni- cation software must be built with ways that are easy to understand and extend.

Object-orientation provides some key features necessary

for tackling such challenging problem domains. Among them some of the most important are: improve analyst and

problem domain expert interaction; increase the internal

consistency of analysis results; explicitly represent com-

monality; reuse analysis results and build specification resilient to change.

This paper presents an object-oriented technique for developing large, even very large, systems in an object- oriented fashion. This technique is based on Coad and

Panos Fitsilis IS also at the University of Patras, School of Engineering, Department of Computer Engineering and Informatics, 265 00 Patras, Greece

Yourdon object-oriented analysis and design methodologies which have been extended in order to support efficiently the

development of telecommunication services’-‘. These extensions aim primarily at handling complexity, task

modelling, architectural modelling, and model integration.

The whole methodology has been evaluated and used by

major European telecommunication service providers in the context of R2076-RACE project BOOST. BOOST (Broad-

band Object Oriented Service Technology) is studying the availability of object-oriented modelling and development

techniques that concern the service creation process.

Telecommunication system and object-oriented development methodologies

The most widely known method for describing the functional behaviour of telecommunication system is SDL (Specification

and Description Language). This is a standard language for the specification and description of systems. It has been

developed and standardized by CCITT’ (International

Telegraph and Telephone Consultative Committee). Although SDL has a broader application area, it is mainly known within the telecommunication field.

In SDL, the behaviour of a system is described by the combined behaviour of a number of processes in the system. Each process is an extended finite state machine that works autonomously and concurrently with other processes.

0950.5849195/$09.50 0 1995 Elsevier Science B.V. All rights reserved SSDI 09%5849(94)00435-g 15

Object-oriented development for telecommunication services: F Fitsilis

HwEGwEDNDoa

OBJECT MODEL

Objects State Transition diagram

Service

Charts

CLUSTER A

Objects State Transition diagram

\ r statements

Service Charts

CLUSTER El

TASK MODEL VARCHITECTURAL MODEL r I I

Figure 1 The integrated model

The object model

Object-oriented analysis (OOA)‘, consists of five major activities which must not be seen as sequential steps:

(I) Finding Class&Object.

(2) Identifying structures. (3) Identifying subjects.

(4) Defining attributes. (5) Defining services,

a ‘is N’ or ‘is a kind of relation between classes. Within

Generalization-Specialization structure inheritance applies, where more general attributes and services are defined in

the generalization class and are inherited by specialization class(es). A Generalization-Specialization structure may

form either a hierarchy, in which case there is single inheritance. or a lattice, in which case there is multiple

inheritance, since a specialization may have more than one

generalization.

The execution of each of these activities has as output the production of the correspondent layer. These activities

guide the analysts from high levels of abstraction (ex.

subjects, Class&Objects) to lower levels (ex. structures,

attributes, services).

A Whole-Part structure can be thought of as a ‘bus a’

structure between objects. In this kind of structure, an

amount or range indicating the number of parts that a whole

may have, and vice versa, can be specified.

A class i\ a description of one or more objects with a uniform set of attributes and services, including a description of how to create new objects in the class. An object is an

abstraction of something in a problem domain reflecting the

capabilities of the system to keep information about it and interact with it. ,4 Class&Object is a term meaning ‘the

~~lu.ss and the objects iti that class’.

In an OOA model, the number of classes is dependent on

the breadth and depth of the problem domain and the system requirements and may vary a lot. For large object

models, the concept of subject has been introduced to the OOA methodology. This concept allows the reader to

define the subjects of the system within the problem

domain. thus presenting the overall model from a very high perspective (higher than that presented by the Class&Object layer).

In OOA specific types of relations between objects are In OOA, each Class&Object is described in more detail described by tvro types of structures: Generalization- with attributes and services. Attributes describe the state of Specialization structure and Whole-Part structure. A the object, while services describe the specific bchaviour an Generalization-Specialization structure can be thought of as ob.ject is responsible to exhibit.

17

An attribute is some state information for which each object in the class has its own value. These values can be exclusively manipulated by the services of the object. Attributes and exclusive services on those attributes are

treated as an intrinsic whole. These values are accessed by another part of the system through the specification of a

message connection corresponding to the appropriate service.

A message connection is a mapping of one object to another object (or class) in which a ‘sender’ sends a message

to a ‘receiver’ to get some processing done. The required

processing is named in the sender’s services specification and is defined in the receiver’s services specification.

In OOA there is also the concept of instance connection that defines the required mappings between objects in order

to fulfil their responsibilities.

Each of the five layers of the object model mentioned at the beginning of the section, describes some of the OOA concepts presented above.

The subject layer describes the subjects of the object model and the Class&Object layer describes the Class&- Objects and the classes of the model. The structure layer describes the Generalization-Specialization and the Whole-

Part structures between Class&Objects, the attribute layer

describes the attributes of the Class&Objects and the instance connections between them, while the service layer

describes the services of the Class&Objects and the

message connections between them.

These layers are not completely separate. They can overlap, thus describing a part of or the whole object model

of the system under consideration.

In Object-oriented design (OOD) the following four major components have to be defined:

. problem domain component;

. human interaction component;

. task management component;

. data management component.

In OOD, the OOA results fit right into the problem domain

component. The analysis results are an integral part of OOD method. The analysis model is extended in order to

form the design model. Also, the task management com- ponent is not used in the proposed methodology; this is

because it is too general to be of use in the service creation

problem domain.

Extensions to the object model

Telecommunication systems are generally large and com- plex systems. In most of the cases they exhibit a dynamic behaviour with possibly distributed features. Two main

factors contribute to the complexity of telecommunication

systems. First, a telecommunication system provides both telecommunication and administrative services and a model must be able to represent these different views. Second, the structure of the telecommunication software imposes

several levels of abstraction. In order to handle this inherited complexity the concept

of clusters has been suggested. Each system is composed of a number of clusters; each cluster is constructed by using the syntax and the semantics introduced by Coad and Yourdon plus some new functionality which interface

18

clusters. Clusters arc modelling sub-systems that ha\c II very clear and specific interface with the other parts of the systems. They have been introduced in order to split the

complexity of a huge and entirely tlat model in a collection of sub-models. Usually, clusters are executed at the san~e physical processor or location. In order to provide <II~

interface between different clusters the cluster-interface objects have been introduced.

An object that belongs to a specific cluster is sending

messages to an object belonging to another cluster using

a cluster-interface object. It is also possible to have Generalization-Specialization relations using the cluster-

interface object as the generalized class. We have restricted

the cluster-interface object to be only generalized class because if the same Class&Object is at the same time Generalization and Specialization of some Class&Object. it

means that this object should belong to this cluster. Also a

Whole-Part structure may include cluster-interface objects as part objects. The reason for this restriction is l’or

managing the complexity of each cluster. Usually when we are building a system we are not interested in the internal

structure of the parts composing the systems. These two restrictions do not limit the expressive power of the method-

ology but provide a clear cut between clusters. The reason

for these restrictions is in order to focus our attention on the subject matter.

For the Whole-Part structure our concern is to have only

the parts of a whole in a single picture. Usually we arc not

interested for the sub-parts of a part. For example, when we are designing a computer we do not want to know the

parts of an integrated circuit we use.

Similarly, if this restriction is not applied, for a

Generalization-Specialization structure this means that a

cluster-interface object is a specialization and at the same time a generalization of some objects. In this case this

cluster-interface object should belong to the same cluster with the generalization and specialization objects. By

applying this restriction. a clear cut between clusters is

provided.

Large telecommunication systems exhibit a complex behaviour which surely cannot be described in a sequential

manner. In this type of system an external interrupt or event. not just a call, can initiate an operation. Modern

software development methodologies should he able to

model communicating processes that might not be in a

calling relationship with one another. Communication between objects is achieved by the ex-

ecution of a service. It is possible that an object requests the execution of a service to transfer control to the object that provides the service. In this cast. the flow of control is

transferred sequentially. After completion, control is returned to the object that requested the service execution. It is also possible that control is not transferable, in which

case the execution request is queued to the object which provides the service. The service provider object will decide whenever it will execute or reject the request, depending on its internal state or the constraints imposed on this object. In this case the control is transferred in parallel. There are three different types of parallel transfer of control: synchronous, clocked and asynchronous. In synchronous

Information and Sojiware Technology 1995 Volume 37 Number I

Object-oriented development for telecommunications senke~: P Fitsilis

transfer of control the sender object waits indefinitely until

the receiver object is ready to proceed. Clocked messages

are either sent at specific time intervals or the sender object

waits for the receiver object for a specific amount of time.

Finally, asynchronous messages are sent regardless of whether the receiver is expecting the message.

Objects communicate using messages. In order to accom- plish this communication each message carries a certain amount of information. We have borrowed the notations

used in structured design methodologies in order to describe more precisely the flow of information. For this reason

each message connection has been extended in order to

include the following:

. service name issues the message;

. service name receives the message;

. a set of data couples (input)..

. a set of reverse data couples (output);

. a set of control flags (input);

. a set of reverse control flags (output).

These data-passing notations apply to all kind of messages.

An exception is an abnormal termination of the execution of a service. The exception may be raised by a service in

response to a particular state (usually exceptional). The

object that requested the service must provide functionality

in order to handle the exception by propagating or by absorbing the exception. Exceptions are propagated using

a reverse control flag. The details of an exception are

described in the attribute definition part of the design. In Figure 2. an outline of the object model is given.

l’he task model

For certain applications, the introduction of the concept of

tasks simplifies the overall design and code. There are several reasons why such systems require multiple tasks.

Subject -

Class&Object

Whole-Part Structure

Class

Figure 2 The object model

O.mA

Some of them are: responsibility for control and data

acquisition; many users at the same time; communication

inside the system or with other systems; various hardware

architecture. In telecommunication systems most of the

above characteristics are present; therefore a number of different tasks are running concurrently in order to accom-

plish a specific behaviour. In order to define tasks we first need to define:

. the way tasks are activated or triggered;

. objects required for the execution of a task:

. the way of communication:

. the constraints under which a task is executed.

In order to handle complexity, tasks can be decomposed to:

. a number of sub-tasks;

. a number of objects.

Sub-tasks do not always define a new process but it is rather

a logical decomposition. At the upper level diagram only the main tasks performed by the system are presented.

While we are going to lower level diagrams, tasks are described in more details. in terms of other sub-tasks and

objects. In lower levels only objects appear because each

task is realized with objects. It is clear that the designer first

has to create the object model of the system.

The Class&Object diagram is a very static representation of the system: it just shows a collection of objects sending

messages from one to the other. State transition diagrams

also arc associated with a specific Class&Object, and for

this reason the timing and the sequence in which the things

happen are not shown. Task definition diagrams are able to present the timing as well as the sequence of execution within a system. Each arc connecting objects or sub-tasks is marked by a number indicating the order of execution.

Thus message 1 is executed before message 2 and so on. Task definition diagrams do not intend to show the flow of

Personnel 9 Pilot

Cluster It-&face Object

Instance Connection

Message Connection

I :

MESSAGEIYYPEZ

Asynchronous Message V

Simple or Synchronous Message ,.~__-_.~..-~a,~.~“_n . . . . _ __“@+.

Sender waits for N

4 ***$._ --“----se

Sender waits for N

DAIA-

Data Control

--@+ XI”I~..X-..-----..%-- l.l_.X=.., I

Exception Control Flag

ln,formarion and Sojiv~ure Technology I995 Volume 37 Number I 19

Object-oriented development for tc,lrcornmutritzltiorr serviws: P Fitsili.,

control or the flow of data within a system, but it is rather

a visualization showing what happens within a system and in which sequence. Usually these diagrams do not present in full detail, but they are used to present the overall picture

of the system. In the upper level diagram a set of dis- tinguished tasks are presented. These tasks are communi-

cating only with asynchronous messages or the get triggered

and start execution periodically. In the lower level, each

object is a sub-task and is executed in serial. Figure 3

presents an outline of task definition diagrams.

The architectural model

An architectural model is created to model the system’s

design, thus showing the configuration of physical modules. A system architecture model must take into account the

overall objectives of the system and how it is embedded in

the larger framework of a telecommunication network. Due to their size and complexity telecommunication systems

involve concurrency most of the time. Therefore, archi-

tectural models must be capable of showing the structure

of the system regardless of their internal hardware and software structure.

Many different architectural modelling methodologies

have been proposed. For example Booth’ has presented

process diagrams which map processes to physical resources.

This approach has the main disadvantage that it is a single layer diagram, which means that it is incapable of modelling

large and complex systems. Hartley and Pirbhai” have proposed an architectural modelling approach which is

complete, but it is intended to be used in parallel with a

powerful but structural ‘requirements capture’ methodology. According to this approach an architecture model is com- posed of architecture context diagram, architecture flow

diagrams and architecture interconnect diagrams.

Level 1

Task A2

In order to create an architectural model the tasks per-- formed by the system must be known. Usually each com- ponent of a large system is dedicated to a set of specific

tasks, therefore each task is allocated to an architectural component of the system. Tasks may appear in more than one architectural component. Each architectural component may be decomposed to a number of sub-components. Sim-

larly each task assigned to a component may be reassigned

to a sub-component or can be decomposed to a number

of sub-tasks which in turn may be assigned to a sub- component. Links between architectural components indicate

communication lines. In this hierarchy of diagrams, upper level diagrams represent logical components, while lower

level diagrams indicate physical components. In Figure 4 an example of architectural modelling diagrams

is presented. At level 0. the context diagram is presented. In the context diagram a general view of the system is

presented. At level 1, the sub-systems composing the whole

system are presented. These sub-systems are logical and usually do not represent physical devices. At level 3 all the

elements that are composing the local network 1 are pres-

ented. These elements are hardware devices that have a

specific set of tasks to perform. Summarizing, architecture diagrams attempt to handle

the complexity of large systems and at the same time map tasks to physical components, thus introducing two different

hierarchies: tasks and architecture.

A case study

In order to demonstrate the proposed methodology, a simple example from the telecommunication service creation

Level 0

Level 1

SW1 optical link

SW2

B_network_mng B_network_mng

Local Network1 Local Network2 __network_mng __network_mng conference_appl conference_appl

I ?

1 Workstation1 ethernet W

I L_network_mng link orkstation2 /

L_network_mng I ~ conference_mngr conference_clnt ~

hardwara devices

Figure 3 The task model Figure 4 The architectural model

20 Informution and Sojiware Technology 19% Volume 37 Number I

Object-oriented development for telecommunicution services: P Fitsilis

moblle subscriber /

mobile subscriber

Telecommunlcatlon network

\ normal subscrlber

Figure 5 Mobile telephone system configuration

domain is presented. The case study presented is the dev-

elopment of a mobile phone system. Figure 5 shows the configuration of this system. The mobile control system is

connected to a normal telephone network. The mobile

control system consists of a radio station and mobile phone switch. Also the mobile control provides both telecom-

munication and administrative services. The telecommuni-

cation services provided are call handling between mobile phones, as well as call handling between mobile phones and ordinary phones. Administrative services are new subscrip-

tions and subscription changes.

Whenever a user of the system wants to make a call, the

user is connected to a radio station. The radio station is

controlled by a mobile control system. A mobile control

system may control more than one radio station at a time. At this point the mobile control system determines whether the use of the ordinary telecommunication network is

needed in order to make the connection. The object model can be described with two clusters: the

cull handling cluster and the administrution cluster. In this application the object model is simplified and in each

cluster only the Class&Object structures are presented. In

Figure 6 the object model for cluster cull handling is presented.

Figure 7 shows the corresponding task model. In our

CLUSTER: call handling

,“___ _,,... ,, __” ,. ,,_ ,..~” _ Subject: Devices

Subject: ,....

Directory

Figure 6 The call handling cluster

dial-tone-on 4

go-offhook opt?”

- Subscriber A go-inactive *

Subscriber B go-onhook ) Coordinator cbse

Handling * Handling

select

mark-busy

2

go-active I+ Figure 7 A sample of the task model

21

simple model three different tasks have been identified:

Subscriber A handling, Coordinator and Subscriber B

handling. Each task receives a number of events which have as effects the triggering of some actions. For example,

whenever our system receives the event ‘go-ofiook’ then

the object ‘A-line’ sends the same message to object ‘A- subscriber call handler’, which in turn sends the message

‘mark-busy’ to ‘Subscriber’ object and then the message

‘dial-tone-on’ back to the ‘A-line’ object. In Figure 7 only

the top level tasks and the clarification of task ‘Subscriber A Handling’ are shown.

There is no doubt that, in the development of real telecommunication services, the whole model is sub- stantially larger, more complex and with many levels of

abstraction.

Conclusions

In this paper an integrated methodology for the develop-

ment of large complex systems has been proposed. Three

models have been developed giving different perspectives of the system under development in a consistent manner.

These models are: the object model which describes the

functionality and the data that the system provides; the task

model which describes the control within the system; and

the architectural model which describes the physical layout

of the system. The object model used here is based on the Coad and Yourdon methodology. This methodology has

also been extended with features that support the com-

plexity handling of telecommunication services development.

The main advantage of the proposed methodology is the

integration it provides between the different views of the system. The task model is based on the object model as

tasks are realized with objects. Also, the architectural model is connected with the task model, as each architec-

tural component has to execute some tasks. However, the proposed methodology is not complete:

many points have to be reconsidered and improved. Some of the topics under consideration are:

. a formal method for describing the functionality of the

services; . a way to simplify the interactions between the objects; . a method for describing the dynamic characteristic of a

Class&Object in the context of a task.

It is expected that the feedback from the extensive use of the proposed methodology within the telecommunication

industry will provide valuable rcmarka for improvemenr

Acknowledgements

The author wishes to thank Panayiotis Cheliotis and Melani Chryssoulaki for their help on the early stages of this work.

Also, I would like to thank Petros Kapasouris and Kostas Dervos for their comments on the final manuscript.

References

1 Coad, P and Yourdon, E Object-oriented una/yL~ (Second edn) Yourdon Press (1991)

2 Coad, P and Yourdon, E Object-oriented design (Second edn) Yourdon Press (1991)

3 CCITT Recommendation ZlOO ‘CCITT specification and description language (SDL) and annex a to the recommendation’ Technical Report blue book recommendation 2100, CCITT COM X-R17-E. CCITT (March 1992)

4 Dahle, H P, Lnfgren, M, Magnusson, B and Madsen, 0 L ‘Mjnlner: A highly efficient programming environment for industrial use’ Proc. of Sofware Tools (London, 1987)

5 Brinksma, E and Bolognesi, T ‘Introduction to the IS0 specification language LOTOS’ Computer Networks and ISDN Systems Vol 14, pp 25-59 (1987)

6 Jacobson, I ‘Object-orlented development in an industrial environment’ OOPSLA 87 Proceedings (October 1987)

7 Jacobson, I Object-oriented development software engineering Addison-Wesley (1992)

8 Booth, G Object-otiented design wth app/ic,ations Benjamin/Cummings ( 1993)

9 Shlaer, S and Mellor, S Object-oriented.qwem.~ ana/ysis Prentice-Hall (1988)

IO HOOD Working Group HOOD Reference Manual Issue 3.0 WME/89-173/JB, European Space Agency, Noordwijk. Netherlanda (September 1989)

11 HOOD Working Group HOOD User Manual Issue 3.0 WMEl89- 353/JB, European Space Agency, Noordwijk, Netherlands (December 1989)

12 Martin, J and Odell, J Object-oriented anaIy.sis and design Prentice- Hall (1992)

13 Zachman, J ‘A framework for information system architecture’ IBM System J. Vol 26 No 3 (1987)

14 Monarchi, D and Puhr. G ‘A research typology for object-oriented analysis and design’ Comm. of the ACM Vol 35 No 9 (September 1992)

15 RACE RI021 ‘ARISE project, state of the art study on object-oriented development’ R202l/BCM/RD1/DS/BI027/Bl (December 1991)

16 RACE R2049 ‘CASSIOPEIA project, initial statement of requirements on methods, techniques, and tools’ R049/GMDISEMiDSiP/002ibl (December 1992)

17 Fitsilis, P, Kontaxaki, S, Matinopoulos, G and Chatzistefanidia. S ORIENT User’s Guide INTRASOFT, Athens (1994)

18 Harmon, P ‘Object-oriented fourth generation language and CASE products’ CASE strategies, Special Report (1992)

19 Short, K ‘Methodology integration: evolution of information engineering’ Inf: and So@. Technol. (1991)

20 Hartley, D and Pirbhai, A Strategies for reul-rime sytem specificurwn Dorset House Publishing (1987)

22 Information and Sojiware Technolog 1995 Volume 37 Number I

Cooperation between processes is performed asynchronously by discrete messages known as ‘signals’. A process can also send and receive signals from the environment of the system. In order to handle complexity SDL uses the

concept of blocks, which is the main structuring concept. A system contains one or more blocks, interconnected with

each other and with the boundary of the system by

channels. A channel is a means of conveying signals. Also, a block can be partitioned into sub-blocks and channels.

Object-oriented extensions to SDL were introduced in 19874: they were later issued as part of the CCITT Recom- mendations in 1992. The underlying approach to object-

orientation in OSDL is based upon the ideas behind

SIMULA. The new elements added are generic parameters, specialization, virtual types and transitions.

LOTOS is an alternative development method within the telecommunication systems problem domain. LOTOS (Language of Temporal Ordering Specifications)5 is a

forma1 description technique generally applicable to distributed, concurrent information processing systems. It

is based on process algebra in which systems are modelled

as sets of interacting processes which exchange data with their environments.

Another, and very important, methodology widely used

within the telecommunications application domain, is the

methodology proposed by Ivar Jacobsor?,‘. This method-

ology has combined a well-proven technique for large system design called block design, with conceptual

modelling and object-oriented programming. According to Jacobson, a system is built by developing five different models. The first model, ‘the requirements model’, consists of ‘actors’ and ‘use cases’. An ‘actor’ models something

that will interact with the system, and a ‘use case’ specifies

a flow that a specific ‘actor’ invokes in the system. The

analysis mode1 is developed from the requirements model giving the objects structure; the design model refines the

analysis mode1 further in terms of blocks and takes into

consideration the current implementation environment; the implementation mode1 consist mainly of the source code

written to implement the blocks; and finally the testing

model is developed. There is also a great deal of current literature on object-

oriented systems development. A large number of method- ologies and methods have been proposed in order to

provide a way of thinking and working in the development of large object-oriented systems. Most of these approaches

have been advocated by academic papers and are not very

likely to have a big impact.

Among these methodologies, Object-oriented analysis’ and Object-oriented design2 by Coad and Yourdon; Object-

oriented design’ by Booth; Object-oriented systems analysis (OOSA)’ by Shlaer and Mellor; Hierarchical object-

oriented design (HOOD)“‘,“; Object-oriented analysis

and design” by Martin and Odell, are of the most

importance. There are six aspects of the problem spaces to which

system development methodologies are addressedk3. These aspects are: process, data, control, rules, location and people. To some extent, most methodologies address process and data; few address control, and still fewer address rules,

16

location and people. So, after extensive study and the application of the above evaluation criteria as well ax the criteria proposed by Monarchi and Puhr” some object- oriented methodologies have proved to be complete and

more suitable for the development of telecommunication systems. Among these methodologies is Coad and Yourdon’s

Object-oriented analysis and design (OOA/OOD) method- ology. It is widely accepted as one of the strongest methodologies as well as one of the most popular. Also

OOA/OOD is highly recommended by the RACE II Project Line”,“, that has investigated issues related with the

service engineering concept. The methodology is also

supported by a number of CASE tools”.“. Even though these methodologies’.-‘ are among the

strongest methodologies, they do not properly address aspects absolutely necessary for the development of

telecommunication services, such as complexity, control, rules, and location. In order to account for these defici-

encies, a number of extensions that add expressiveness and

strength to the methodology have been suggested. The proposed extensions address primary issues related with

complexity handling, control modelling and architectural

modelling. Special emphasis has been given to the

integration of the methodology. Methodology integration

enables different perspectives on system development to be

used in a consistent manner.

The integrated methodology for developing telecommunication services

As previously mentioned, an integrated methodology has to

give answers to the following questions’“:

Process-which is the system functionality?

Data-what data does the system manipulate and how

does the system store data in persistence storage? Control-when is it being done‘?

Rules-under which constraints does the system operate‘?

Location-how is functionality of the system distributed?

People-how do humans interact with the system?

The proposed methodology is composed of three different models supporting the above aspects. These models are:

l object model;

. task model;

. architectural model.

Figure 1 shows the whole integrated model. The object

mode1 describes the functionality provided by the system. In the object model the mechanism to process each instance of a telecommunication service is described.

Basically, the object model addresses the aspects of pro- cess, data, rules, people and partially aspects of control.

In the task model, the designer describes how the system receives events and manages software execution. The task mode1 primarily addresses the aspect of control and rules. Finally, in the architectural model, the physical layout of the actual system is described and the aspect of location is addressed.