home

yoga

drawings &
paintings

software
development

the human
matrix

info



software development

projects

taxonomy

design
patterns

propositional
signs

vim

gallery

tree of knowledge
of good and bad


Software Design Patterns

Copyright © Heinz Prantner 2007

created: December 13 2007
last updated: December 13 2007

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

Table of Contents

(§1.3.3) Design Patterns

(I) Telecommunication System

(1) Intent

Specify the generic software layout of a telecommunication system independent of the services provided or the services beeing used, indpendent of the technology and protocols involved and independent of the location in the network.

(2) Also Known As

(3) Motivation

Telcommunication Systems on one hand are defined and designed by the technology and protocols involved, the services being provided or used and the location in the network. On the other hand there are several topics in common, independent of the influences listed above. This design model shall address the generic aspects of a telecommunication system.

(4) Applicability

Use this pattern when designing a system and

(5) Structure

Platform

(6) Participants

System Manager

The system may be distributed or a single platform system, it consits of one or more platforms, connected devices, external users and interfaces to other systems. The system manager is responsible for the following tasks:

Platform Manager

A platform boundary can be a process, a board, or a application. A platform is a subdivision of a system and builds the components of a distributed system. In other words, a distributed system consists of multiple platforms. Usually a platform is a single process or a application. The platform manager is responsible for the following tasks:

Data Manager

Telecommunication systems deal and interact with external users, connected devices, interfaces to other systems, peer systems and services, all of whitch come with their configuration and state data. The data manager is useful to share these informations between components within the system and to take care for persitent storage. The data manager is responsibe for the follwing tasks:

Statistics Manager

Statistics are a very powerful instrument for bug tracking, load and stress testing, throughput and performance evaluation. Statistic measurements can be turnd on and off, may be pulled or pushed, need to be collected and presented in an appropriate manner and format.

Event Manager

Events inform the user about important state changes of the system, the devices, connections, services, peers. Events have a name, parameters and may have a priority.

Log Manager

Events and more detailed information on the system changes can be logged to a file or to a output stream.

Configuration Manager

The Configuration Manager, also known as Layer Manager, Stack Manager, is responsible to configure and setup the protocol stack components according to data given in persitent storage or on user command request. Bottom Up configuration of the protocol stack is preferrable.

Command Manager

The system may be operated via a console driven command language interface (CLI), or man machine interface (MMI), a graphical user interface (GUI), a remote management information base (MIB) with SNMP commands, a local binary application interface (API), a modem AT command interface, and the like. The Command Manager should provide for various interfaces and multiple users and process and distribute the commands within the system.

Connection Manager

The Connection Manager builds the abstraction layer to the various signalling and data connections by hiding the specific interfaces to the lower layers and drivers and providing a generic interface for connections to the users for

Protocol Stack Engine

Application

(7) Collaborations

A distributed system may use the Platform layout for each participant with different build and run-time options and configurations, e.g. Active / Standby. So each platform may have all or a subset of the system components given in the model.

(8) Consequences

It is impossible to think of a telecommunication system without any data (configuration and volatile state information) and according data handling associated to it. It is possible though, to implement such a system without a dedicated data management. As a consequence, any new feature where data exchange between components is involved, the data handling has to be designed and negotiated from scratch with unforseeable problems at interfae alignment attached to it. A well defined data management allows for introduction of new features in a controlled and smooth manner. The same applies for other topics such as events, statistics, commands, log, etc.

(9) Implementation
(10) Sample Code

Sample C++ code for Platform.h:

#include "system/system/SystemManager.h"
#include "system/platform/PlatformManager.h"
#include "system/configuration/ConfigurationManager.h"
#include "system/connection/ConnectionManager.h"
#include "system/event/EventManager.h"
#include "system/log/LogManager.h"
#include "system/data/DataManager.h"
#include "system/statistics/StatisticsManager.h"
#include "system/command/CommandManager.h"

class Platform
{

	SystemManager        *sysman;
	PlatformManager      *pfmman;
	ConfigurationManager *cnfman;
	ConnectionManager    *conman;
	EventManager         *evtman;
	LogManager           *logman;
	DataManager          *datman;
	StatisticsManager    *staman;
	CommandManager       *cmdman;
	
public:
	
	Platform();
	~Platform();
	void init();
	bool run();
	void shutdown();
	
};

Sample C++ code for Platform.cpp:

#include <iostream>

#include "Platform.h"

Platform::Platform()
{
	std::cout << "Platform::++() " << '\n';
}

Platform::~Platform()
{
	std::cout << "Platform::--() " << '\n';
	delete sysman;
	delete pfmman;
	delete cnfman;
	delete conman;
	delete evtman;
	delete logman;
	delete datman;
	delete staman;
	delete cmdman;
}

void Platform::init()
{
	std::cout << "Platform::init() " << '\n';
	sysman = new SystemManager();
	sysman->init();
	pfmman = new PlatformManager();
	pfmman->init();
	cnfman = new ConfigurationManager();
	cnfman->init();
	conman = new ConnectionManager();
	conman->init();
	evtman = new EventManager();
	evtman->init();
	logman = new LogManager();
	logman->init();
	datman = new DataManager();
	datman->init();
	staman = new StatisticsManager();
	staman->init();
	cmdman = new CommandManager();
	cmdman->init();
}

bool Platform::run()
{
	std::cout << "Platform::run() " << '\n';
	sysman->start();
	pfmman->start();
	cnfman->start();
	conman->start();
	evtman->start();
	logman->start();
	datman->start();
	staman->start();
	cmdman->start();
	while (pfmman->run());
	return false;
}

void Platform::shutdown()
{
	std::cout << "Platform::shutdown() " << '\n';
	sysman->shutdown();
	pfmman->shutdown();
	cnfman->shutdown();
	conman->shutdown();
	evtman->shutdown();
	logman->shutdown();
	datman->shutdown();
	staman->shutdown();
	cmdman->shutdown();
}

(11) Known Uses
(12) Related Patterns

(II) Protocol Stack Component Facade

(1) Intent

Define a protocol stack component architecture facade with protocol independent ports which fits into the generic telecommunication system layout.

(2) Also Known As
(3) Motivation

Finding the right granularity in an abstraction is not easy to achive. If the granularity is to small then we are no longer generic, if the granularity is too big then the abstraction may be too vague. This facade pattern is refining the interface of a component processes primitives by breaking down the intreface into different generic categories.

(12) Related Patterns

(III) Managed Object

(IV) Grammar Model

(V) Organism Model

(VI) Component Task

(VII) Substate

(IX) Poll & Voting Machine

end of document