SAP Cross-Connector Software Architecture

Lecturer:

Henry Muccini and Vittorio Cortellessa

Computer Science Department

University of L'Aquila - Italy

Course:

Ingegneria del Software II

academic year: 2004-2005

Course Web-site: [www.di.univaq.it/ingegneria2/]

Lecture 5:

Copyright Notice

»

The material in these slides may be freely reproduced and

distributed, partially or totally, as far as an explicit reference

or acknowledge to the material author is preserved.

Acknowledgment

»

This presentation comes from:

-

[TR 16/01] Luca Marcucci, Paola Inverardi, Henry Muccini.

Formal and Semi-formal descriptions of a Cross-Connector

Software Architecture. Internal Report 16/01, Universita'

dell'Aquila

General Context

»

Telecom Italia Network Architecture:

-

3 layers

:

>

urban

>

regional and

>

national telephone exchange

»

System behavior:

-

When a customer makes a call, his call is routed through a local

network.

-

If the call is

local

, then the customer is connected to the local number

STM-4/16 ADM ADM ADM ADM STM-1/4 ADM ADM ADM

ADM ADM_ADM SXC 4/1 SXC 4/1

Urban Level

SXA SXA STM-1/4 ADM ADM ADM

ADM ADM_ADM ADM ADM STM-4/16 ADM ADM ADM ADM

Regional level

STM-1/4 ADM ADM ADM ADM ADM

ADM ADM_ADM SXA

SXA

TELECOM ITALIA NETWORK ARCHITECTURE

WDM STM-4/16 ADM ADM ADM ADM SXA SXA WL WL STM-16 Ring

National Level

ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM WLWL ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM ADM STM-16 Ring

Simplified view

»

Telecom Italia Network

Architectural style

Urban Router

Regional Router

National Router

Urban R.

Urban R

Regional R.

Dynamics: phone call Irvine – San Francisco

Culver R

Irvine R.

S. F.

Call

Local?

No

Our Context

»

The SXA subsystem

»

Our aim:

-

The study of the SXA Cross Connector, in order to...

-

develop a formal or semi-formal architectural specification to realize

quantitative analysis

(explain)

>

The experimentation of

different formalisms

to describe this SA (UML, ADL,

Process Algebra)

>

The

elicitation and organization of the information

necessary to build a

performance model

STM-4/16 ADM ADM ADM ADM SXC 4/1 SXC 4/1 SXASXA STM-4/16 ADM ADM ADM ADM

Regional level

SXA SXA ADM ADM SXA SXA

National Level

What Siemens provided

»

A good

physical

(Hw) architectural description

»

An incomplete, only statical, description of the SXA

Software Architecture

-

Components and Connectors

-

Deployment Software components in Hw nodes

»

The system dynamics and configuration is described

only

at the

low-level,

using a SDL-like notation

What Siemens provided

»

How did they evaluate the system performance before?

-

They modify the code and evaluate its execution

time and resource consuming

»

How do they want to evaluate the system performance?

-

Modifying the architectural model and evaluating the architectural

changes

What Siemens provided

»

8 different manuals, each one of about 200 pages (at least

they documented the system)

»

The possibility to contact the people responsible of the

SXA development and documentation

SXA Cross-Connector (1)

»

The SXA is a cross-connector with a transmissive capacity

of 140 Mbit.

»

Its main behavior is to enable a

cross-connection between

networks nodes

»

One of its basic features is the possibility to

monitor traffic

for an automatic protection switching activation (

fault

management

) or for dynamic reconfiguration (e.g.,

work

balancing

)

(explain)

»

The SXAs are parts of the regional TIN layer and they

enable the setting up of mesh networks composed of

interconnected, different layers, ring networks.

»

In the available documentation, the SXA architecture is

described by three different configurations or views:

-

The Software configuration

:

it represents the

functional view

. The

software components are identified, and their behaviors are

described;

-

the

Hardware configuration: the system is represented by the

hardware devices

composing it;

-

the Deployment configuration: it represents a

mapping

between the

software components and the hardware devices

.

»

1. Software Configuration

»

2. Hardware Configuration

SUPER-USER

TERMINAL

SYSTEM FUNCTION

OSI

STACK

COMMAND

HANDLER

XCONN

DATABASE

MANAGER

NETWORK

MANAGER

1. SXA System – Software Configuration

Database

MIB

1.

Super-User Terminals

can locally or remotely be connected to the SXA

system to handle system services; they can

add or remove connections

and

manage the software and hardware

system configuration

. The terminals are

bi-directionally connected to the system by an OSI Stack;

2.

the

Command Handler

translates Users commands into

system function

calls

; it is also connected to a global database;

3.

The

user-to-system communication

is implemented by a complete OSI Stack

4.

the

MIB Global Database

stores the external requests and the component

software and hardware configuration;

The SXA Software Configuration (2)

5.

the

System Functions

represent the software components implementing the Users

requests. Each component has its own behavior:

-

CM

manage the system configuration,

-

EPS

manage the equipment protection resources,

-

FM

provides

fault detection

and alarm generation,

-

PM

evaluates the

performance

of transmission links,

-

LPS

handles the line protection switching,

-

TIM

manages the network

synchronization

,

-

DR

performs the

initializations

in the system during power-up and restart and

-

TM

organizes the execution of all the

tests

which are defined in the system.

-

XCONN

is the

core

of the system;

it manages the activities related to the routing, setting

up point-to-point and broadcast cross-connections.

SYSTEM FUNCTION

The SXA Software Configuration (3)

-

Terminology:

>

macro-components

-

the five components just shown

>

micro-components

-

their sub-components (i.e., each

macro-component is composed by several

micro-components).

Macro and Micro components

»

Macro Component

SSXC <<XCONN component>> 1..1 1..1 CXC <<XCONN component>>1..11..1 1..1 1..1 1..1 1..1 1..1 1..1 GXC <<XCONN component>> 1..1 1..1 1..2 1..1 1..2 1..1 1..1 1..1 1..1 XCONN <<SYSTEM FUNCTION>> <<SYSTEM FUNCTION>> XCONN

»

Micro Components

Refinement

CMDH LPS <<SYSTEM FUNCTION>>

…

2. SXA System – Hardware Configuration, v1

ES-CORE Protection

ES-CORE

Working

C-CORE

T-MUX

# 1

ET-MUX

# 1

T-MUX16

# 1

Hardware Configuration

In the hardware configuration the SXA system is described by

means of the hardware devices composing it; the distributed

system

elements (shelves) are:

»

the

T-MUX

,

ET-MUX

and

T-MUX16

contain the system ports and contain

also part of the cross-connect processing.

-

Depending on the switching capability, there are multiple instances of these

shelves: in the more complex case, there are 29 MUX, 15 EMUX and 7

T-MUX16;

»

the

C-CORE

contains the main controller;

»

the

ES-CORE

contains the central part of the cross-connect processing and

the system timing synchronization function;

»

The

ES-CORE

is duplicated (protection and working) for the hardware faults

management.

SXA System – Hardware Configuration, v2

ES-CORE Protection

ES-CORE Working

.

C-CORE

T-MUX

_ET-MUX

_T-MUX16

C-LAN

GLOBAL

SHELF

PERIPHERAL

SC-LAN

SC-LAN

Hardware Layers

»

All shelves are connected via an external lan (

C-LAN

).

»

In each shelf more processors can be located, connected by a local lan (

SC-LAN

);

»

the processors are organized in a hierarchical manner and are partitioned into

three levels: global, shelf

and peripheral.

»

Global processors

are located in the C-CORE; they are devoted to the system

management;

»

Shelf processors

are located in each shelf; they are devoted to the shelf

management;

»

Peripheral

are located in each shelf; they are devoted to specialized

functionalities.

SXA System – Hardware Configuration, v2 -

VIEWS

ES-CORE Protection

ES-CORE Working

.

Timing

8 ETMSU

PSCU

C-CORE

LAN HUB

2 TSU

_PSCU

ASU

Porte

Fisiche

DPS

TDU

T-MUX

PSCU

ASU

Porte Fisiche

DPS

TDU

ET-MUX

PSCU

TDU

ASU

Porte Fisiche

T-MUX16

C-LAN

2 TSU

_{2 TSU}

MSCU

MSCU

GLOBAL

SHELF

PERIPHERAL

SXA System – Hardware Configuration, v2 -

FLOW

ES-CORE Protection

ES-CORE Working

.

Timing

8 ETMSU

PSCU

C-CORE

LAN HUB

2 TSU

_PSCU

ASU

Porte

Fisiche

DPS

TDU

T-MUX

# 1

PSCU

ASU

Porte Fisiche

DPS

TDU

ET-MUX

# 1

PSCU

TDU

ASU

Porte Fisiche

T-MUX16

# 1

C-LAN

2 TSU

_{2 TSU}

MSCU

MSCU

GLOBAL

SHELF

PERIPHERAL

3. Deployment Configuration

»

In the deployment configuration each SXA macro-component is

decomposed in several micro-components;

»

each micro-component is implemented by a process running in global,

shelf or peripheral processors;

»

Each macro-component could be composed of several instances of its

micro-components.

Software and Hardware

SYSTEM FUNCTION

XCONN

ES-CORE

Protection

ES-CORE

Working

.

C-CORE

T-MUX # 1 ET-MUX # 1 T-MUX16 # 1

C-LAN

GLOBAL

SHELF

PERIPHE

RAL

SC-LAN

SC-LAN

???

For each component…

1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..1 XCONN1

XCONN

…

GLOBAL

SHELF

PERIPHE

RAL

XCONN2 XCONN3 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..1 XCONN1

XCONN

…

XCONN2 XCONN3

Components Deployment

GLOBAL

PERIPHERAL

ES-CORE

Protection

ES-CORE

Working

.

C-CORE

ET-MUX

# 1

C-LAN

MSCU

runs

XCONN1

SHELF

PSCU runs

XCONN2

runs

XCONN3

PSCU

runs

XCONN2

1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..1 XCONN1

XCONN

…

XCONN2 XCONN3

Summarizing

»

Software:

-

each component, is composed in sub-components

»

Hardware:

-

Three layers: global, shelf and peripheral

»

Deployment:

Our Research

»

Our aim:

-

The study of the SXA Cross Connector, in order to...

-

develop a formal or semi-formal architectural specification to

realize quantitative analysis

(explain)

»

What we did:

-

A Reverse Engineering approach to analyze the existent

documentation and produce an architectural description.

System Domain

Analysis

Domain Analysis of the

XCONN System Function

Architectural Description

Functional Partition

1.System Domain Analysis 2. Domain Analysis of XCONN 3.Architectural Description 4.Functional

System

Domain

Analysis

Meeting with the

developers

High-Level

Class and

Sequence

Diagram

(UML)

High-Level

Class and

Sequence

Diagram

(UML)

1. System Domain Analysis

High-Level

Components

Documentation

SXA Class Diagram (Macro-Component Level)

CM <<SYSTEM FUNCTION>> CMDH LPS <<SYSTEM FUNCTION>> EPS <<SYSTEM FUNCTION>> DATABASE MANAGER XCONN <<SYSTEM FUNCTION>> FM <<SYSTEM FUNCTION>>

Step1: encountered problems

»

Macro-components level description

is too abstract

for

quantitative analysis

»

Sequence diagrams are not enough informative

»

Solution:

-

Analyze only the SXA main component in detail: the XCONN

component

2. Domain Analysis of XCONN

Components

Detailed

Documentation

Domain

Analysis of

the XCONN

System

Function

Exchanged

messages list

Exchanged

messages list

Deployment

Diagram

(UML)

Deployment

Diagram

(UML)

Stereotyped class

diagram

(UML)

Stereotyped class

diagram

(UML)

Previous

Step

Results

1.System Domain Analysis 2. Domain Analysis of XCONN 3.Architectural Description 4.Functional Partition

PREVIOUS ARCHITECTURE

PSXC <<XCONN component>> <<XCONN component>> <<component>>1..11..1 BXC <<XCONN component>> SSXC <<XCONN component>> 1..* 1..1 1..* 1..1 TXC <<XCONN component>> STXC <<XCONN component>> 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..* 1..1 1..* 1..1 CM <<component>> 1..1 1..* 1..1 1..* FM <<component>> CXC <<XCONN component>>_{1..1 1..11..1 1..1} 1..1 1..1 1..1 1..1 1..1 1..* 1..1 1..* EPS <<component>> GXC <<XCONN component>> _1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..1 1..1 1..1 1..1 1..1 CMDH <<component>> 1..1 1..1 1..1 1..1 Element Manager <<component>> 1..1 1..1 1..1 1..1

XCONN

ALL

macro

components

UML Class Diagram – XCONN SYSTEM FUNCTION

PSXC <<XCONN component>> PTXC <<XCONN component>> LPS <<component>>1..11..1 BXC <<XCONN component>> SSXC <<XCONN component>> 1..* 1..1 1..* 1..1 TXC <<XCONN component>> STXC <<XCONN component>> 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..* 1..1 1..* 1..1 CM <<component>> 1..1 1..* 1..1 1..* FM <<component>> CXC <<XCONN component>>_{1..1 1..11..1 1..1} 1..1 1..1 1..1 1..1 1..1 1..* 1..1 1..* EPS <<component>> GXC <<XCONN component>> _1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..1 1..1 1..1 1..1 1..1 CMDH <<component>> 1..1 1..1 1..1 1..1 Element Manager <<component>> 1..1 1..1 1..1 1..1

macro

components

micro

components

macro

components

Step2: encountered problems

»

UML is not the best tool to analyze software architectures

»

We decided to use an ADL:

-

Darwin

for the topology

-

The

FSP

process algebra for the dynamic

»

XCONN micro-components and communication channels

(previously defined

using the UML Class Diagram) have been modeled as Darwin components and

connectors.

»

The FSP specification language has been used to describe the Darwin

components behavior. SDL code and diagrams have been used to produce the

FSP specification

3. ARCHITECTURAL DESCRIPTION

Architectural

Description

Components

Topological

Description

(DARWIN)

Components

Topological

Description

(DARWIN)

Behavioral

Description

(FSP)

Behavioral

Description

(FSP)

SDL Code and

Diagrams

Components

Detailed

Documentation

Previous Steps

Results

Message

Abstraction

Message

Abstraction

Previous results

modification

Previous results

1.System Domain Analysis 2. Domain Analysis of XCONN 3.Architectural Description 4.Functional Partition

SAXC Graphical Description

DARWIN TOPOLOGICAL DESCRIPTION

SAXC

cxc[0]

cxc[1]

bxc[1]

bxc[0]

SDL State

_{INPUT MESSAGES}

OUTPUT MESSAGES

range Active_Cxc = 0..1 range State = 0..16 range p_State= 0..1

GXC= GXC_INIT,

GXC_INIT = (gcm_state_require-> GXC_WAITING[0][...][...] ...),

GXC_WAITING[cxca:Active_Cxc][...][...][...][...]= (epg_matrix_state -> (gc_matrix_state[0][0] -> GXC_W_ACK_STATE[1][escore1][escore2][tmux1][tmux2] | gc_matrix_state[0][1] -> GXC_W_ACK_STATE[0][escore1][escore2][tmux1][tmux2] | tout -> GXC_WAITING[cxca][escore1][escore2][tmux1][tmux2]) |cmg_resource_state[nescore1:Statop][nescore2:Statop][ntmux1:Statop][ntmux2:Statop] -> gcm_ack -> (gc_matrix_state[0][0] -> gcstate_matrix[1][1] ->...

|...), GXC_W_ACK_STATE[cxca:Active_Cxc][...][...] ... = (cg_gxcack -> GXC_W_ACK_STATE[cxca][...][...] ... | cmg_resource_state[p: p_State]-> ... ...), ... a) b) c) d) e)

FSP Specification

Labeled Transition System generated from the

FSP Specification

Functional

Partition

Messagge

Sequence Chart

(MSC)

Messagge

Sequence Chart

(MSC)

Activity Diagram

(UML)

Activity Diagram

(UML)

SDL

Code and

Diagrams

4. FUNCTIONAL PARTITION

Previous

Steps

Results

1.System Domain Analysis 2. Domain Analysis of XCONN 3.Architectural Description 4.Functional

»

In the first step we manually generated some system scenarios. This

description was

too high level

for quantitative analysis

»

In the third step we used the available SDL documentation to write an FSP

specification of the XCONN component; in this case the

level of

abstraction was right

BUT

we were not able to generate the system model

due to the

model complexity

.

»

At this step, the idea is to

integrate

the

low level scenarios

produced in

step1 with XCONN internal interactions, described in the FSP spec

ð

two different levels of abstraction in the same model

Functional Partition

APPROACH CONCLUSIONS

Documentation lackness

Not well defined development process

Incoerence between low- and high-level documentation

Poor architectural description

• UML is not enough to describe the behavioral description

• Formal tools limitations

Lecture Conclusions

»

Software and Hardware Together

»

Too complex… way to abstract

-

Two level of abstraction

»

SA for quantitative

(performance) analysis…

-

why!

»

Architectural style…

-

it was not achieved

(picture)

1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..1 1..2 1..1 1..2 1..1 XCONN1

XCONN

…

XCONN2 XCONN3