Advanced Telecommunication

Networks
Software Methodologies for
Converged Networks and Services

CONTENT
1. Development of Software Methodologies for ICT
2. Software Processes in the NGN Framework
3. High-level Analysis and Design Methods
4. Enterprise and Business Modelling Notation
5. Object and Data Definition Languages
6. Dynamic Modelling Notations
7. Component and Interface Notations
8. Distributed Systems
9. Creating a Unified Framework

Development of Software Methodologies for ICT

In the telecommunications domain
Specification and Description Language (SDL) for defining
processes and interactions with other processes and
Message sequence chart (MSC) for defining the flow of
messages in the various sequences of successful and unsuccessful
operation of distributed processes.

In the Internet methodology is essentially the definition of

protocols, supporting services and management information.
In the information technology area
Unified Modelling Language (UML) providing a number of
notations based on object-oriented concepts for expressing different
views of any software system and gives the designer flexibility to
emphasise views for different purposes.
3

Development of Software Methodologies for ICT

An organisation of software concerns in complex ICT systems

Software Processes in the NGN Framework

Frameworks and architectures
provide set of concepts, principles and rules that guide analysis and
design of complex systems
support learning about and understanding such systems.
Methodology separating implementation detail from the analysis and
design process
agreed notations that are frequently rooted in a modelling approach
implementation concerns such as programming languages,
operating systems and communications protocols arise.
Information representation and automation tools.

Software Processes in the NGN Framework

Software systems become more complex and analysis, specification,

description and design methods become important.
The previously distinct software engineering paradigms of
telecommunications and information technology must converge.
The complexity of the underlying network facilities must be hidden
from the applications developer.

Software Processes in the NGN Framework

Functional entities - communicating finite state machines

Functional entities in NGN Framework are locus of software processes

7

Software Processes in the NGN Framework

The external view of a functional entity is in the form of a protocol or
interface specification. Each protocol or interface is intended for use in a
specific environment.

Essentials of the specification and use of a communications protocol 8

Software Processes in the NGN Framework

Physical entities are described by the functional entities they host. A
physical entity may however contain an element that performs physical
operations on user data or streams, for example a switching matrix, a
media gateway, a digit receiver, a tone and announcement generator or
a forwarding engine in a router.
Physical processing entities are described by an information model, that
is structured data that represents the element and its operational state.
The information model is often implemented as a management
information base (MIB).
The RM-ODP contemplates a different type of interface, the stream
interface to show that an entity is a source or sink of user data. The
stream interface has a number of properties, for example a network
address, port number, media carried and the required quality of service.
9

Software Processes in the NGN Framework

A model is a description of an entity or system that is sufficiently
detailed for the purpose at hand.
This representation has static and dynamic facets.
System dynamics usually follow a state transition type of process.
ICT systems are partitioned into layers and domains capturing related
functionality in functional entities and using reference points to
describe their interaction. A reference point gives a degree of
abstraction.

10

Software Processes in the NGN Framework

Classification of methods used for describing protocols, processes and

objects in an ICT system
11

High-level Analysis and Design Methods

Future ICT systems support services and applications that may rely on
complex logic, allow access to content and exploit network connectivity
and messaging.
Analysis, modelling and design methods must therefore support highlevel as well as detailed design.
Two such methods are the Reference Model of Open Distributed
Processing (RM-ODP) and the Model Driven Architecture (MDA).
RM-ODP provides a formal basis for the fundamental concepts
and architecture of distributed systems.
MDA seeks to support the portability,interoperability and reusability of
software, emphasises modelling and is linked to notations that allow the
system designer to apply the MDA methodology.
12

High-level Analysis and Design Methods

THE REFERENCE MODEL OF OPEN DISTRIBUTED PROCESSING

Characteristics of an object defined in RM-ODP

13

High-level Analysis and Design Methods

THE REFERENCE MODEL OF OPEN DISTRIBUTED PROCESSING
Distribution is more than locating the constituent software objects of a
system on separate computing nodes but includes the enabling
communication support mechanisms.
Portability is a property of an object that, by virtue of the compliance of
its interfaces to an agreed specification, allows it to be applied in
different configurations.
Interoperability is the ability of objects that are implemented using
different technologies to interact to meet specified objectives.
Reusability is the property of an already implemented software object
that allows it to be used as part of a new object or system without
redesign.

14

High-level Analysis and Design Methods

THE REFERENCE MODEL OF OPEN DISTRIBUTED PROCESSING
Access transparency enables an object to invoke the services of
another where the objects use different data representation and
invocation mechanisms. Interworking between differently implemented
objects is supported.
Location transparency frees an invoking object from the need to
know the location of an invoked object when identifying and binding to
interfaces: naming information is sufficient to invoke the services of an
object.
Relocation transparency allows an invoking object to continue to
invoke an interface to which it is bound when that interface has been
relocated.
Migration transparency enables a system to change the location of
an object without compromising the ability of an invoking object to
access its services. Load balancing and reduced latency are thus
achieved.
15

High-level Analysis and Design Methods

THE REFERENCE MODEL OF OPEN DISTRIBUTED PROCESSING
Replication transparency: allows an invoking object to invoke an
interface that has been replicated without knowledge of the details of
the replicated interfaces. The object of replication is to enhance
performance and availability.
Failure transparency enables an object to continue operating if other
interacting objects and even itself fail and have to be recovered. This
property supports fault tolerance.
Persistence transparency frees an object from dealing with the
deactivation and reactivation of other objects (or itself) to give the
effect of persistence when the system cannot ensure continuity.
Transaction transparency frees an invoking object from the need to
coordination of activities among interacting objects to achieve
consistency.

16

High-level Analysis and Design Methods

THE REFERENCE MODEL OF OPEN DISTRIBUTED PROCESSING

RM-ODP Viewpoints giving different but consistent views on the

same system
17

High-level Analysis and Design Methods

THE REFERENCE MODEL OF OPEN DISTRIBUTED PROCESSING
Enterprise viewpoint is essentially a requirements analysis,
focusing on the purpose, scope and policies for that system without
regard to how the requirements are met.
Information viewpoint focuses on the semantics of information and
information processing.
Computational viewpoint enables distribution through functional
decomposition of the system into objects which interact at
interfaces.
Engineering viewpoint focuses on the mechanisms and functions
required to support interaction between distributed objects in the
system.
Technology viewpoint focuses on the choice of technology in the
system.
18

High-level Analysis and Design Methods

THE REFERENCE MODEL OF OPEN DISTRIBUTED PROCESSING

Process for distributed application analysis and design based

on RM-ODP

19

High-level Analysis and Design Methods

MODEL DRIVEN ARCHITECTURE
The computing environment is characterized by languages and
operating systems.
The communications environment is characterized by transport
protocols and supporting mechanisms.
The concept of a platform captures considerations of
implementation languages, operating systems, communications
protocols or distribution support such as CORBA.
The platform is a set of defined interfaces to the infrastructure
underlying a computing application and their patterns of use.

20

High-level Analysis and Design Methods

MODEL DRIVEN ARCHITECTURE
The description model-driven emphasises the intention that the
lifecycle of a software product should be supported by models.
Types of models are defined through three MDA viewpoints.
The computationally independent viewpoint focuses on the
requirements on a system and its environment without regard to how
the system will be structured and implemented.
The platform independent viewpoint is a way of describing a system
that concentrates on the operation of the system without considering
the implementation platform. The system could be implemented on
different platforms.
The platform specific viewpoint is a way of viewing a system that
adds platform specific considerations to the platform independent
view of the system.
21

High-level Analysis and Design Methods

MODEL DRIVEN ARCHITECTURE
The computationally independent model is essentially a
requirements analysis considering the system and its environment
and has similar objectives to the RM-ODP enterprise viewpoint. The
MDA does not specify how the requirements analysis should be
done.
The platform independent model of the system is expressed in
technology neutral or platform independent terms. The objective is to
permit implementations on different platforms. Development of the
PIM involves identifying the objects that make up the system and the
way that they interact to perform processing. These objects must
then be packaged into components with interfaces.
The platform specific model is concerned with implementation
issues similar to the concerns of the engineering and technology
viewpoints of the RM-ODP. The RM-ODP engineering viewpoint is
concerned with support for a distributed processing environment and
defines a generic platform in MDA terms.

22

High-level Analysis and Design Methods

SDL AND MSC

System, block and process level organisation in SDL

23

High-level Analysis and Design Methods

SDL AND MSC

Association setup logic for the

SCTP protocol expressed in SDL

24

High-level Analysis and Design Methods

SDL AND MSC

Comparison of three system design methods: RM-ODP, MDA and

SDL (with MSC for checking the output)
25

High-level Analysis and Design Methods

(a) Generalisation of RM-ODP and MDA processes for distributed

system design.
(b) Process with constraints placed by software architecture or
standard.
26

High-level Analysis and Design Methods

Generalised analysis, modelling and design system based on

RM-ODP and MDA with tools useful at various stages

27

High-level Analysis and Design Methods

28

High-level Analysis and Design Methods

Relationship between SDL standard and system instance specification

29

Enterprise and Business Modelling Notation

RM-ODP Enterprise Language
The system is viewed as a community of enterprise objects.
Enterprise objects are things that play roles in the system.
Enterprise objects that have a single authority in common may be
classified as belonging to a domain.
Domains may share resources in an agreed way. Such a community of
domains constitutes a federation.

30

Enterprise and Business Modelling Notation

A use case diagram showing the external actors and use cases for the
User Access Control System

31

Enterprise and Business Modelling Notation

Structure of UML standards and resulting development process for

classes

32

Object and Data Definition Languages

Example of class definition in the PIMEV stage for the User Access
33
Control System

Object and Data Definition Languages

ABSTRACT SYNTAX NOTATION ONE

Abstract Syntax Notation One definition approach to

(a) Object definition and (b) transfer of object instances
34

Object and Data Definition Languages

ABSTRACT SYNTAX NOTATION ONE

Examples of ASN.1 descriptions of data structures

35

Object and Data Definition Languages

ABSTRACT SYNTAX NOTATION ONE

36

Object and Data Definition Languages

ABSTRACT SYNTAX NOTATION ONE

Part of the object identifier tree in ASN.1

37

Object and Data Definition Languages

INTERFACE DEFINITION LANGUAGE

Processes for achieving interoperability of differently

implemented objects based on IDL
38

Object and Data Definition Languages

INTERFACE DEFINITION LANGUAGE

39

Protocols
Several important telecommunications protocols were defined
before object-orientation became the dominant paradigm for
protocol definition, for example Q.931, ISUP and MAP. Each
protocols targets a specific environment.
The software system analysis and design methodology results in
components representing co-located objects that are accessible
through defined interfaces. Each interface contains a number of
method calls. Each method call specifies in general the operation
to be performed, the parameters, the return value and exceptions.
These method calls represent the application-to-application
interaction. The method calls play the same role as application
layer protocol operations.

40

Protocols
A number of IETF protocols that are important in the convergence
process use a common approach to defining the protocol messages.
These protocols include the Simple Mail Transfer Protocol (SMTP), the
Hypertext Transfer Protocol (HTTP), the Session Initiation Protocol
(SIP) for controlling multimedia sessions and two protocols (PINT and
SPIRITS) for facilitating interworking between Internet clients and IN
Service Control Points.
All protocols are defined in a human-readable, common text format
and are known as text-based protocols.

41

Protocols

Example of an IETF text-based

protocol: transfer of an e-mail
message using SMTP

42

Protocols

43

Protocols

44

Protocols

Relationship between XML standard, application domain data

type definition and data instance specification

45

Protocols

XML Document Type Definition (left)

and sample document (right)

46

Protocols
The number of XML applications is substantial. Four examples typify
the application of XML in specific contexts:
Internet Protocol Data Record (IPDR): definition of document
formats for accounting and billing information for a variety of ICT
services.
VoiceXML: definition of data and scripts for control of interactive
voice response units.
Web Services Definition Language (WSDL): a way of describing
Web services that allows potential users to establish the suitability of
the services for their needs.
The OMG Meta Object Facility (MOF): a basic definition of the
constructs in UML.
47

Protocols

Relationship between XML, SOAP and HTTP

48

Protocols

Communication (robustness) diagram for the User Access

Control System
49

Dynamic Modelling Notations

Message sequence chart for a user access control system

50

Dynamic Modelling Notations

Message sequence chart for setup logic for the SCTP protocol
expressed in ITU-T convention

51

Dynamic Modelling Notations

UFM information sequence chart for setup logic for the SCTP
protocol
52

Dynamic Modelling Notations

System definition process using SDL and MSCs

53

Dynamic Modelling Notations

UML sequence diagram for setup logic for the SCTP protocol

54

Dynamic Modelling Notations

Four methods of describing state-transition processes

55

Dynamic Modelling Notations

Connection View State notation for describing connections in IN

56
Capability Set 2. State names are shown in italics

Component and Interface Notations

The PIMCV reflects the logical packaging of the software system that
emerges from the PIMIV.
Functionality is gathered in components. Requests or method calls are
gathered in interfaces.
A component is a unit that must be deployed on a single computing
node. Reference points may be created at which conformance with
definitions can be verified.
The component-level description of the system is, in the absence of
constraints, platform independent.

57

Component and Interface Notations

Three notations for depicting components and interfaces

58

Component and Interface Notations

An example of how the interfaces on an object are defined and how

this object depends on interfaces belonging to other objects

59

Distributed Systems
Computer networking introduced the need to deal with the distributed
nature of computing through the Open Systems Interconnection (OSI)
approach.
While this initiative was concerned initially with managing the
complexity of communications protocols through a layered reference
model, there was also a strong emphasis on openness.
An open system presents a standard interface that allows different
implementations of the communicating systems to work together.
The concept of openness has been extended to software as well.
Definition of applications programming interfaces is a means of
partitioning a software system into one part that provides services to
another part. The standard way of invoking services is defined as
software interfaces with defined method calls, relying on
accompanying data definitions.
60

Distributed Systems
NETWORK PROTOCOL-BASED DISTRIBUTED SYSTEMS
Dynamic Host Configuration Protocol (DHCP)
Domain Name Service (DNS).

REMOTE METHOD INVOCATION

A process of invoking a method on a remote computer when the object
implementation and platforms are in the same language but not
necessarily running on the same platforms on client and server sides
The most common instance is the Java
language with its Java Remote Method Invocation (RMI) technique.

61

Distributed Systems
WEB SERVICES MODEL
Web services are conceived as a way of achieving application-toapplication interaction intended primarily for electronic business (ebusiness) but finds widespread use.
The emphasis is on sharing functionality and data across computing
platforms in application-to-application interactions.
Web services represents a form of distributed computing in which
functionality that already exists can be made available for use by other
programs.

62

Distributed Systems

Representation of Web services as a triangular relationship

63

Distributed Systems
Common Object Request broker Architecture - CORBA

Essential elements in CORBA support for object interactions.

Examples of protocols and messages are shown in brackets

64

CREATING a UNIFIED FRAMEWORK

The integrated approach to the analysis, design and implementation of
complex ICT software systems:
As an organising principle, the RM-ODP viewpoints and the Model
Driven Architecture provide a process with up to five stages, as
necessary in each project. We have identified these phases by
combinations of RM-ODM and MDA viewpoints as: CIMEV, PIMIV,
PIMCV, PSMEV and PSMTV.
The most appropriate notations drawn from the many available should
be used to support analysis and design.

65