DE102004062791A1 - Method for production of system components for telecommunications and internet services involves displaying preceding characteristics by inventive quality - Google Patents

Abstract

Method for production of system components for telecommunications and internet services involves displaying preceding characteristics by inventive quality. An independent claim is also included for system component for telecommunications and internet services with preceding characteristics displayed by inventive quality.

Description

1.1 Starting situation and motivation

The complete networking

The technical progress of the last decades has made the worldwide use of telecommunication services a matter of course. In Germany alone, an average of 874 million minutes of telephone calls were made in 2002 per day. With the spread of the Internet, it has also become possible to retrieve digital information from around the world in fractions of a second. Communication and information play a key role in both the private and economic sectors. Terms such as the change to the "information society" [BHP + 00] are an expression of the social changes that accompany them.

This Information trend is in particular due to the increasing networking driven. The development of worldwide telephone networks and the rapid dissemination Mobile networks have every place in the world connected to the global communications network connected. Satellite networks allow telephoning to the most remote corners of the earth. Computers and switching equipment enable automates the spontaneous establishment of communication links between any places at any time. Not only people, but also machines and computers are communicating in ascending order Dimensions with each other. The continuing unabated increase in worldwide networking is taking place now in the "small" place More and ever smaller devices and communication units are transmitted through transmission networks to the worldwide Communication connected - the "meshes" of the network will be always finer knotted.

The economic significance of the service

In recent years, however, it has become clear that with the ever-closer "networking" of the network - with the increase in connectivity - the economic success of communications providers has not increased to the same extent - with the technical advancement, in particular the continuous digitization of almost all media In the past few decades, the technical burden of transferring data has steadily declined, and the increasing frequency of transporting data and the competition from the growing number of vendors are reducing the economic benefits that can be achieved For the user, in turn, the value of the transmission of a bit less in the transmission is itself, but results much more from the value, the di e has related information for him. Currently, the sending of a short message (SMS) in the mobile network costs about as much as conducting a one-minute telephone conversation in the same network , However, since about 600 times as many bits are needed for the transmission of the telephone call, the user pays for a bit of SMS about 600 times as much as for a bit of the telephone call. Odlyzko [Od101] points out that such price differences in communications services are not new or unusual, pointing out that in the US postal service in 1832, newspapers accounted for 95% of the transported weight, but only 15% of revenue contributed.

The declining income through pure information transport lead to an increasing service orientation the communications provider to provide innovative and attractive services new sources of revenue tap to be able to [ALM + 01]. Technical transmission parameters move play in the background and the services offered to the user the main role [Jes01]. Customers are interested in the use a service and not for the underlying technology [BHP + 00].

Increasing complexity of services

Services in communication networks are often offered across network boundaries and combine various media and functionalities. With the convergence of the various communication networks - called "convergence of the networks" - the concept of service has become more and more separated from the network: While in the past telephone service and telephone network were inseparable units, it is now possible to diversify While the telephone network as an Integrated Services Digital Network (ISDN) offers videoconferencing, faxing and data services a wide variety of services. The convergence of the networks leads to a multiplication of the possible services [MMO + 98].

The Deregulation of the telecommunications market has been increasing rapidly Number of providers of telecommunications services. The regulatory authority for telecommunications and Post recorded in January 2003 for Germany 2100 providers [Reg03]. The services offered range from network operation to integrated value-added services, such as video conferencing. Demand for more complex, individualized telecommunications services has increased enormously in recent years [ZH99]. The provider diversity leads strong competitive pressure that is forcing providers to their offered service portfolio continuously to the current demand adapt.

Of the increasing share of software in the field of communication networks has an important impact on the way the service is developed. The greater flexibility of a software solution Compared with a hardware system increases the flexibility of the overall system with regard to the possible Services that can be provided with this system. Furthermore, a change or extension of the system in much less time, so that new services in shorter Time can be introduced into the network. The increase in possibilities However, this is accompanied by an increase in complexity. modern Communication systems are highly complex, distributed software systems, where a lot of system components have to play together, to provide the required overall functionality [Ebe96].

The Increase in technical diversity and complexity on the one hand and the economic one on the other On the other hand, in ever shorter terms Time to offer new services has the process of service development a new significance [Sie01]. The way of development of these services and the technical systems providing them in the context of an independent Discipline - the "service Engineering "- examined and further developed. It has compared to the communication networks a very young past [ZH99]. Your job is to appropriate methods, techniques and tools for the development of information and provide communication services.

Deficits of service development methods

at the products to be developed in the context of service development As described above it is largely software. The service development is therefore in many cases exposed to the typical problems of software development. To An investigation by the Standish Group [SGI99] was completed in 1998 only about a quarter (26%) of all software development projects are successful completed. About half Although projects (46%) were completed, they were not full successful. This group includes projects that are not in the planned Time or at the planned cost could be performed or at which not all desired Properties of the software could be realized. In more than a quarter (28%) of started software development projects the work was discontinued before the project became a degree could be brought.

Also if this investigation does not focus on service-specific development projects limited, shows they are the principal problematic, the service development subject. Between the strict formality of a program code on the one hand and the more intuitive-creative mode of creation on the other hand there is a contrast that leads to a high susceptibility to errors of the development process. The real development goal is immaterial and therefore difficult tangible. The complexity of the target system is due to the high degree of dependencies very tall and complicates the previous estimation the development effort.

When Main deficit especially of the service development becomes too long lasting Development time seen in the field of telecommunications often three to five Years is [Eti95]. Due to the insufficient methods for verification and to test the services developed within existing tools can the correct functionality of service despite long and extensive test phases not always be ensured [KHEB99]. The developed service corresponds often not the original one Customized, because the requirements are described as inaccurate and incomplete.

One stringent methodological procedure in the development process is so far only in beginnings recognizable, and often there are no predetermined development methods [Ebe97]. Existing development methods are rarely used on the adapted to service-specific concerns and can change the development process only insufficient support.

The deployed development environments for services are many on a specific type of service limits or restricts the Providing the service to a specific execution platform type or a network technology. In the context of the open telecommunications market However, generic development environments are needed that are universal for one Variety of services, platforms and networks can be used [KT97]. The necessary flexibility of the development process becomes inadequate from existing processes supported.

New Methods and approaches to service development a shortening development time while increasing the complexity of services enable. For this purpose, a systematic and targeted approach is necessary where a clear approach guides the developer and the Development work is supported by suitable tools.

1.2 Objective and Approach work

The This paper presents a new process for the development of information and Communication Services (I & K Services) in front. The goal of this process is to enable the efficient development of any I & C services and helping to overcome the aforementioned shortcomings. Therefor is tailored to the specific characteristics of I & C services Development process, however, the variety of possible Services and the usable implementation platforms.

The The development process presented in this work offers models and description languages specific to the properties from I & K services are adjusted. It contains Concepts, language elements and rules that are simple and efficient To enable the description and development of I & C services. Generic templates and building blocks can for the be specialized in concrete use. Through the chosen abstraction levels and the reuse of building blocks can add complexity to service development be reduced.

One important principle in the development of the present process was the formality the models and description languages used. Formal definitions The description languages used provide the internal consistency the individual development results safely. By mapping rules Between the results of different stages of development, the work carried out in the steps of the development process be verified. This will ensure that the developed Actually that originally has specified behavior. Tedious test phases can thereby greatly shortened become. The formality The description languages used also allow a support of the development process through software tools. By the high achievable degree of automation of development and possibility to verify the development outcome can be a drastic shortening the duration of development the existing procedures.

One great Problem of service development is the difficulty of understandable and unique specification of the desired service. The desired behavior a service can only be inadequate expressed with texts and images become. In particular that from atypical uses and occurring error cases resulting service behavior is neglected at the beginning of the development. Of the therefore often does not correspond to the original service Ideas of the client. For this problem is a early Presentation of the planned service using models or prototypes helpful. By simulating the model or testing a model Prototype of the planned service may be the behavior of the service be validated together with the client. The in the specification phase formal service modeling used in the present method allows a simulation of the specified service behavior. hereby can be early ensured in the development process together with the client be that needs the customer were correctly recorded and actually the desired Service is developed.

In general, a wide variety of platforms can be used to implement a service. The presented development process should therefore not be tied to a particular platform. To support different technical execution platforms, the process must be easily and flexibly adaptable to the specific development process for a particular target platform be. An important principle in the development of the present method was the strict separation between the specification of the desired service and the subsequent implementation of this specification as part of an implementation. This separation allows implementation of a once specified service on different execution platforms. Due to the clear delimitation of the specification, it can be used unchanged for different implementations. A procedure for implementing service specifications on an existing, component-based execution platform is presented in this paper. Procedures for implementing services on other platform types can be developed as needed.

Around the manageability of the developed method in practice too demonstrating two prototypical software tools were created. The first of these tools allows the creation, verification and simulation of the service specification. The graphical representation and the use of prefabricated building blocks facilitate the creation of a specification considerably. The second tool allows the implementation of a service specified by the procedure on the existing, component-based execution platform. Here can the correct implementation of the specification is largely verified become. The prototype platform used consists of components, For example, sending an email or building a Enable telephone connection.

1.3 Structure of the work

In Chapter 2 of the work will begin first defines the concept of information and communication service (I & K service). The presentation of some examples of such services clarifies the term used in this work. For working out the requirements for the development of I & C services, will follow analyzed the environment of these services. This concerns in particular the technical systems used to provide such services; by a big one heterogeneity Marked are. However, also economic conditions have an impact on service development and therefore become considered.

The The focus of Chapter 3 is the consideration of development processes in general. Based on a model for development processes a measure of the complexity of this Processes presented. Subsequently be based on this measure basic concepts illustrating the complexity of the development process decisively influence, worked out. They represent the success-critical Factors for the design of development processes. The analysis of these Success factors related to the service-specific requirements from chapter 2 to compile a catalog of criteria for the evaluation of development processes for I & K services.

In Chapter 4 introduces a number of existing development processes and with the list of criteria in Chapter 3 regarding their suitability for development from I & K services rated. The investigated methods come from the field telecommunications, general software development and out various research projects for service development. The chapter includes with a summary of the results found.

chapter 5 gives an overview of that I & K services development process presented in this paper. The used abstraction levels and description languages are presented. This is on the selected Procedure for definition and notation of the models used and description languages. The chosen approach to service development is divided into a specification phase and an implementation phase, their individual steps at a glance being represented.

content Chapter 6 is the detailed explanation of the specification phase. Their goal is to create an implementation-independent model a planned service. The elements used in these models and their relationship to each other are presented. For the notation created service models becomes an XML-based description language presented.

chapter Figure 7 looks at a procedure for implementing created service specifications on a component-based service platform. This is a Model of the chosen Implementation based on existing platform components. Due to the presented, formal consistency rules, the fulfillment of the Specification requirements. The individual steps of the procedure will be detailed Example explained.

The work concludes with a summary and an outlook. First, the fulfillment of the discussed in Chapter 3 through the proposed development process. Subsequently, possible extensions and applications of the method for different areas are outlined.

2 Characterization of Information and communication services

The present work presents a new method of development of Information and communication services. To the described To be able to classify and evaluate procedures, first the existing Environment and the underlying conditions of the process explained. This chapter begins with the delimitation and definition the term used by the information and communication service (I & K-service). The following list of some examples illustrates the scope the definition used.

The other sections of this chapter describe the environment in which the I & K service is created and provided. To this end, the actors involved and their interfaces to each other. A role model serves to classify the presented aspects. In addition to the properties the technical systems and platforms used to provide services economic conditions are taken into account, as far as they affect the way of service development to have.

Out the features presented and the discussed environment of I & C services worked out the specific requirements at the end of this chapter, dedicated to the development of I & K services put.

2.1 Delineation of the concept of service

Of the Term "service" is in different Contexts and partially different meanings used. A generally valid Definition of this term does not exist. The term service must rather for the appropriate purpose and the environment of use appropriately defined become. The following are first different service terms, especially in the field of Telecommunications presented. Building on this, the Concept of "Information and Communication Service "(I & K Service), as used in the present work.

2.1.1 Terms

In the general language meaning, a service represents the offer of a service provider to a service user to perform a particular task. For the telecommunications environment, the telecommunications service is defined as defined by the International Telecommunication Union (ITU) as the offer of a government or recognized operator its customers to fulfill a (specific) telecommunication requirement:
That is offered by an Administration or ROA (Recognized Operating Agency) to its customers in order to satisfy a (specific) telecommunication requirement. "[ITU93a, ITU98]

The in this definition still existing imprint by the state monopolization The telecommunication networks can easily enter the free market be extended. The above and similarly broad definitions (eg [TIN + 97b]) emphasize the universal character of the ministry, However, there are only a few statements about the specific properties a telecommunications service. This is a more detailed Consideration of the constituent properties of the telecommunication service necessary.

Constituent properties a telecommunications service

The fundamental commonality of all telecommunications services is the spatial independence of service usage. Providers and users of a telecommunications service do not need to be in the same location. Rather, the use of the service in a variety of places is possible. To bridge the spatial distance access and use of the service done by means of transmission networks. The actual content of the telecommunication service (the task to be fulfilled) consists in the transport of non-material things (information). The provision and / or processing of this information can also be part of the service. The transport of material goods (eg a letter) can not be the content of a telecommunications service. Although telecommunications services can transport material things trigger (eg transport of a book ordered), the transport process itself is not part of the telecommunications service.

Multimedia Services

By the increasing skills the transmission networks The variety of media used in services has greatly increased. services can not only the medium common in telecommunications but also a variety of other media, such as images and text. The increasing digitization of all media enables processing and the transport of different media through uniform technical Systems.

at the simultaneous use of different media under one Service, this service is referred to as multimedia. Partially It is assumed here that at least one of the used media around a time-continuous medium (eg language, Music, video) acts [Mül96]. With such services are in particular (temporal) dependencies between the media and dynamic changes in the media used (Addition, omission or quality changes a medium) [Kel98]. For The present work aims to use a wide variety of media not restricted in a service become. Therefore, the term used in this work closes multimedia services. However, there are also services without considered continuous-time medium or with only a single medium.

at Multimedia services should be taken into account that the media used vary depending on the purpose quality requirements be put. For example, the users of a videoconferencing service often very different claims to the picture and sound quality the transmission. Multimedia services need therefore different quality gradations support the media used.

invention a need

Of the Motivation to use a particular service is a concrete one desire of the service user. Regarding the to be fulfilled needs is a further distinction of the character of service possible. These it is the need to obtain a specific information, the used Service can be referred to as an information service. communication services On the other hand, they are characterized by the need for real-time (temporally not significantly delayed) Communication between multiple service users. Also any Combination of needs both types is possible and is therefore intended below by the term information and Communication service (short I & K service) summarized become. In particular, he extends the concept of telecommunications service especially around the internet Types of information retrieval and transmission services.

Services on different levels

Of the Service concept can also be differentiated according to different levels become. In the field of telecommunications, network services are generally used ( "Support services "," Bearer services ") as the lowest Defined level. They describe the pure transmission and connection services that a communication network to disposal provides. In the ISDN telephone network this is for example a 64 kbit / s Channel between two endpoints. These are application-independent services of the network, which is a purely technical functionality of the network and directly accessible to the end user.

On the basis of the network services are provided to the end user by means of terminals and the functionalities and user interfaces implemented in them Teleservices available [ITU93a]. examples for Teleservices based on the telephone network are voice telephony, video telephony and fax. As the I & K service defined above meets the satisfaction an end user's need directed, it is assigned to the teleservices and closes pure Network services.

easy Teleservices become frequent referred to as basic services provided by service features ("Service features" or "Supplementary services ") can be. These service features are not standalone services as they are can exist only in combination with a basic service. So For example, the service feature "Callback on busy" can be used as an extension the basic service "telephone call". Such a distinction of the service functions in basic service and service feature is not performed in the present work.

in the Connection of telecommunication services is also common the term value-added service ("Value added service ") to find. These are usually about the pure telephone service understood beyond the services that the processing or storage of language or data. Also a through a special one Type of tariff pricing service is partly called value-added service designated. A precise demarcation is only with regard to one certain service group possible and pushes an added value for the service user associated with the considered services out. The above term of I & K service should the possible functionality not restrict the service and close hence the use of such capabilities one.

Service application

A The delimitation of the I & C concept of service used in this work from the concept of "application" is not carried out, as a clear demarcation of service and application does not seem possible. In general, the use of a service under a specific Context called application. One and the same I & K service can in this understanding are used in different applications and there are different Serve purposes. So the service "phone conversation" in different Applications (eg order hotline or telephone counseling). A clear demarcation between I & K service and application is not possible in some cases. So For example, a "call center" on the one hand as the Application of a special telecommunications service, on the other hand, from the point of view of the call center Telefonseelsorge the used I & K service Therefore, a differentiation of the service from the application must be made out of perspective. She is for the others Work not necessary. Instead, it is assumed below that I & K services also part of a parent I & K-service ("Application").

2.1.2 Definition of the information and communication service

From the described features and properties, the necessary conditions for the existence of an information and communication service (I & K service) can be determined. The service term used in this work considers the service from the point of view of the participants and abstracts from all details of the technical realization of this service. From the point of view of the participants, the service therefore appears like a black box in which they can not look into it ( 1 ). The interface between subscriber and service is the terminal used by the subscriber.

• • Weitgehende räumliche Unabhängigkeit der Dienstnutzung.
• • Inhalt des Dienstes ist die Übertragung (und eventuell auch Verarbeitung) von Information.
• • Das Dienstangebot ist an einen Endnutzer gerichtet.
• • Ziel des Dienstes ist die Befriedigung eines Informations- oder Kommunikationsbedürfnisses des Nutzers.
• • Die Erbringung des Dienstes wird durch technische Systeme (Übertragungsnetze, etc.) bewerkstelligt.

The other necessary features of this I & C service can be summarized as follows:

• • Extensive spatial independence of service usage.
• • Content of the service is the transfer (and eventually processing) of information.
• • The service offer is addressed to an end user.
• • The purpose of the service is the satisfaction of a need for information or communication of the user.
• • The service is provided by technical systems (transmission networks, etc.).

Of the Term of the I & K service contains no restriction the functionality the service, the media used in the service or the number of participants. The above conditions define the one used in this work Concept of information and communication service. If in the this work is spoken by a service, then it is, Unless otherwise stated, the concept of the term defined above I & K-service meant.

2.1.3 Examples of I & C services

Examples for I & K services the presented definition can be found in many areas. A comprehensive listing can not. The following is the variation of the possible I & C services by the exemplary Introducing some typical examples from different areas to be shown. A list of conceivable scenarios can be found for example, in [HKS97], which also includes some of the following service examples is taken.

Unified messaging

The term "unified messaging" includes services that enable a universal exchange of messages between two participants.The sending participant, who wants to send a message to the recipient, can choose from a variety of communication options offered telephone, e-mail or fax (see 2 ).

ever according to medium of the message (language, text, etc.) and in the respective Usage environment available standing accessibility can the receiver choose different communication channels to retrieve the message. The "Unified Messaging "service If necessary, it takes a corresponding conversion of the message before, so that the receiver For example, you can have a text message read aloud on the phone.

Extended telephone services

• • Rufnummernübersetzung und Routing: Hierbei wird der Zielanschluss eines Anrufwunsches nicht durch die vom initiierenden Teilnehmer gewählte Rufnummer bestimmt, sondern abhängig von bestimmten Kriterien auf verschiedene Zielanschlüsse umgesetzt. Die jeweiligen Kriterien, nach denen die Zielansteuerung gewählt wird, können hierbei sehr unterschiedlich sein. So können die Tageszeit, der Ursprungsort, Quoten, Eingaben des Anrufers oder die Erreichbarkeit der potentiellen Zielanschlüsse die Wahl des jeweiligen Anrufziels beeinflussen [Sie01].
• • "Calling Card" Diest: Hier kann der Kunde von einem beliebigen Telefonanschluss aus Gespräche auf eigene Rechnung führen. Hierzu ruft er eine gebührenfreie Rufnummer des Dienstanbieters an und authentifiziert sich mit Hilfe einer ihm zugewiesenen Kartennummer und einer persönlichen Identifikationsnummer (PIN). Nach erfolgreicher Authentifizierung kann der Kunde durch Angabe der Zielrufnummer die gewünschte Telefonverbindung aufbauen. Die Abrechnung der anfallenden Gesprächskosten geschieht entweder durch eine separate Abrechnung oder durch Vorausbezahlen eines gewissen Gesprächsguthabens durch den Kunden. Der Dienst kann durch die Möglichkeit zur Speicherung von Kurzwahlnummern erweitert werden.
• • Konferenzdienste: Zur gemeinsamen Kommunikation zwischen mehreren Teilnehmern existiert eine Reihe von Konferenzdiensten. Die Art der Konferenzen kann hierbei von reinen Sprachkonferenzen am Telefon, eventuell erweitert um eine Videofunktion, bis hin zur gemeinsamen Benutzung von zusätzlichen Applikationen reichen [HKS97, RLL+94]. Unterschiedliche Sprach- oder Bildkodierformate der verwendeten Teilnehmerendgeräte werden in Konvertierungseinheiten angepasst. Die Rechte, Teilnehmer zur Konferenz hinzuzunehmen oder wieder zu entlassen, können unterschiedlich verteilt sein. Die Art und Weise der Bilddarstellung bei den einzelnen Konferenzteilnehmern (alle Teilnehmer gleichzeitig oder nur den jeweils aktiven Sprecher) kann oft vom Teilnehmer individuell variiert werden.

Service orientation in the area of the telephone network, in particular on the basis of the technology of the "intelligent network" [Sie01], has led to a large variety of extended telephone services, for example:

• • Number translation and routing: Here, the destination port of a call request is not determined by the number dialed by the initiating subscriber, but implemented depending on certain criteria to different destination connections. The respective criteria according to which the target control is selected, can be very different. Thus, the time of day, the place of origin, quotas, inputs of the caller or the accessibility of the potential destination connections can influence the choice of the respective call destination [Sie01].
• • "Calling Card" Diest: Here the customer can make calls on his own account from any telephone connection. For this purpose, he calls a toll-free number of the service provider and authenticates with the help of a card number assigned to him and a personal identification number (PIN). After successful authentication, the customer can establish the desired telephone connection by specifying the destination number. The billing of the incurred call costs is done either by a separate billing or by prepayment of a certain call credit by the customer. The service can be extended by the possibility of storing speed dial numbers.
• • Conference Services: There are a number of conference services available for communication between multiple participants. The type of conferences can range from pure voice conferences on the telephone, possibly extended to a video function, to the joint use of additional applications [HKS97, RLL + 94]. Different voice or picture coding formats of the subscriber terminals used are adapted in conversion units. The rights to add or dismiss participants to the conference can be distributed differently. The way in which the images are displayed at the individual conference participants (all participants at the same time or only the respective active speaker) can often be varied individually by the participant.

Multimedia games

In the field of entertainment is currently offered a variety of multimedia games. Many of these games combine different interaction channels to the user, such as voice calls, SMS, web pages and WAP. The content of the games can be very diverse. These include quizzes, adventure games, thrillers or community games such as raising virtual fish and trading these fish with other players. As an example of such a game here is the game "Ivan" singled out (see 3 ), which is offered by several providers. In this game, the player must find out the whereabouts of a criminal named Ivan. For this purpose he receives some SMS and phone calls with hints. If the player thinks he has guessed the place where Ivan is staying, he sends his solution by SMS to the provider.

remote maintenance

As mentioned in the beginning, the proportion of services with non-human participants is increasing strong. So can machines and devices increasingly through remote maintenance services also over size Distances are administered. Electricity meters can be used at regular intervals the current meter reading to the utility company. Enable new vending machines it, the stock of drinks from remotely interrogate. disorders in the system such machines automatically to the service personnel [HKS97].

Multimedia Mobile Tele Information Service (MMMTIS)

This service is an example, which in the Bavarian research association Soft Ware Engineering (FORSOFT) was developed in subproject C2 "Software Engineering for Communication Systems" [Ebe96] and described in [KSS01] The aim of the service is to enable a mobile subscriber (such as a motorist) access to information services known from the Internet (please refer 4 ). These services may provide, for example, traffic announcements, news or tourist information. In this case, the subscriber should be able to individually retrieve information pages from a specific pool of available pages at his receiving device, similar to the videotext. The transmission of the pages to the subscriber takes place here by embedding the information in the data stream of digital terrestrial television (DVB-T) [SEK + 99, SK99, KSE00, SKZ02]. If the subscriber wants to retrieve information pages which are not present in the current stock, the system can be extended by a return channel for requesting individual pages [RKS01]. This return channel is realized via a mobile network.

Also the transmission Further data can be realized on the basis of such a platform become. This data could for example, individual pieces of music represent an entertainment program from which the receiving device an individual Program for the participant is created [Sti01].

Location-dependent information services

in the In the area of mobile telephony, more and more location-dependent information services are offered ("Location Based Services ") These services may require the user to request information have their current whereabouts included. Such information is for example the way to the nearest gas station or a selection of nearby restaurants. Also a current, Location-based weather forecast is conceivable in the future [AB02]. The information can either presented in text form or graphically as a map become.

Home Shopping / click-to-talk

With the help of home shopping services, it is possible for a customer to purchase goods from home. The goods are viewed and selected in a virtual catalog on the screen of a PC. Such catalogs are usually offered on the basis of WWW pages over the Internet. If the customer has further questions that can not be answered with the information in the catalog, some companies offer that he can set up a telephone connection to a consultant at the push of a button. For the voice connection, either a standby telephone can be used on the customer side, or a voice connection can be established via the Internet with the help of the PC. Such telephone connection options at the push of a button are referred to as "click-to-talk" or "click-to-dial" service and are offered in particular by retail companies on the Internet (cf. 5 ).

The described service can be extended by additional functions. So it is the customer in the in 5 shown variant possible to select a delay of the call by selecting a later call time. Further, in some variants of the service, the customer advisor may interactively influence the catalog information presented to the customer and assist the customer, for example, in completing an order form.

Even though the functionality The described "click-to-talk" service is very simple is satisfied all of the criteria defined in the previous section I & K service. He linked by the request by pressing a button and then built telephone conversation different media. For the requirement and also for the following telephone conversation can to implement such a service a number of different Network technologies are used. Because of these properties this service is for the explanation of the proposed development process in this work at many Jobs taken as an example.

2.2 The environment of provision from I & K services

After the presentation and definition of the I & C service, we will now look at the environment in which such services are provided. In the context of the provision of services, a specific lifecycle of services can be identified. Here, the two types of service type and service instance of the service term are distinguished. In order to be able to classify the subsequent detailed consideration of the technical and economic framework conditions for the provision and development of I & C services, an overview of the rough structure of the service-providing companies and the associated value-added chain is necessary. A role model developed therefrom divides the following technical and economic analysis.

2.2.1 The service life cycle

When considering the life cycle of I & C services, two different manifestations of the concept of service are distinguished. These are described by the terms service type and service instance. Their relationship is evident in the lifecycle of services, which in 6 is shown schematically.

The The emergence of a new service begins with the three phases of brainstorming, Specification and development. In these phases are starting from the idea the necessary structures, functions and data to execution of the new service. The totality of these phases created results defines the service behavior and the way this behavior behaves on the execution platform is realized. They do not describe a single concrete one Use of the service, but lay the framework of all possible versions of this service. The frame defined thereby becomes below referred to as service type (see also [Sie01]).

The Installing this service type on the execution platform allows the actual use of the service. In many cases, the use of a Service a contractual relationship ahead. To the possibility of use to open, must be the service type first be subscribed by a customer. Once installed service type can be subscribed to by a large number of customers. in this connection can possibly different parameters or prices for different ones Customers are agreed. The original service type can do this be varied within specified limits.

By the procedure described so far are the conditions for use of the service. This is until this time but not yet claimed. The actual use a subscribed service type begins with the call of the service by the user. Hereby the execution platform is based on the Data of the service type a concrete instance of the requested service generated. This service instance contains the special data of the currently used service. From one service type can simultaneously or a plurality of service instances exist in succession. While a service instance in this case the concrete unit of a currently running Describes the service type as the superset of the service Functions and data common to all instances of this service describe.

With the termination of a service instance becomes this from the execution platform away. By the termination the service can be the contractual relationship between the customer and the provider disbanded and the possibility to stop using the service. Will the service type be from Provider no longer needed, so it can be removed by uninstalling the execution platform become.

2.2.2 The structure of I & K service industry

I & K services become offered by different companies. The specific corporate structure This industry has changed significantly in recent years. It influences the way of delivery and development from I & K services and forms the framework for the subsequent one detailed consideration of the technical and economic aspects the service development.

At the beginning of the spread of communication networks, service and network were inseparable. Telegraphy, telephony and television were provided as separate services by independent networks, whose technical characteristics fully corresponded to the service to be provided by them. The technical separation of the various networks has led to the emergence of clearly distinct industries (eg telecommunications and broadcasting). Within these industries, providers have mostly covered the entire value chain from network operation to customer support (see 7 Left).

The widespread digitization of all transmission technologies has enabled the technical interconnection of networks, facilitating the exchange of information disseminated through the networks and the provision of cross-network services. The convergence of networks that has been driven forward in this way has far-reaching effects on the business models of the companies behind them. For example, by linking the networks and services, the originally coexisting providers have grown into a common, comprehensive industry within which clear boundaries can no longer be drawn [ZPS + 01]. This common industry is also referred to as "TIME" (Telecommunication, Infor mation, media and entertainment / education).

The increasing share of software in the networks, and in particular in the systems required for service provision, has also led in recent years to a far-reaching separation of services from network technologies [Sti02b]. For example, a significant proportion of telecommunications services are data services, while radio and television programs are increasingly being distributed over data networks such as the Internet [Ebe01]. The originally strong connection between network and service could thus be lifted. The emergence of specialized suppliers, which only cover a certain part of the value chain, has led to a fragmentation of the value chain (see 7 right). It enables companies to take over individual sub-functions of I & C service provision without having to cover the entire value chain. Services are therefore increasingly provided by networks of cooperating companies, each with specific tasks [BBH01].

In such an enterprise network must be provided for the provision of the Services necessary tasks are clearly structured and distributed. To investigate this task structure will be the necessary actions as part of the service provision below by a role model shown.

2.2.3 Role Model of service delivery

For the realization of a service, a number of different actors are necessary. Each of these actors has a certain influence on the service providing system and has to fulfill specific tasks. Since even with different services many tasks occur repeatedly in the same or similar form, they can be divided into roles to be performed in the context of service provision. As a result, a rough structuring of the necessary tasks for the provision of services is achieved (see also [KSS01], page 62 ff.). 8th shows a model of the roles required for service provision and the points of contact (interfaces) between them. These interfaces include both technical and non-technical interfaces, such as contractual relationships.

For a given service, each of these roles can be taken over by different companies. However, a company can also have multiple roles at the same time or take on different roles in different services. The aforementioned separation of service and network makes it possible to assume the role of the I & C service operator without having to be the operator of the network infrastructure used. The business model of such an independent service provider (also known as "3 ^rd party service provider") consists of the use of network and basic services of other providers, in order to offer their own, extended services [Sti02b] for the use of these network and basic services I & C service providers and providers of network and basic services have to rely on a common (especially technical) interface ( 8th , Interface ➀). In many cases, the service provider requires external content (eg stock quotes, news, etc.) for its services from content providers. Also for the transfer of these contents a suitable interface (➁) must be defined. In many cases, standardized media formats can be used.

The Offer the I & K services does not have to be done by the operator himself, but can by independent Provider (also called "agent") done. The interface (➂) between these two roles becomes through contractual agreements on quantities to be accepted and Prices formed. Customer of a service provider is the contractor, who buys (subscribes) a service. He does not have to be at the same time also be the actual user of the service. For example becomes a "click-to-talk" service purchased from a company such as Fleurop (Service) Customers, the buyers the flowers, used (the service users).

The interface (➃) of the service user is the terminal used by him, which is connected to a particular access network. The access network operator offers the user universal access to the I & C services and generally receives remuneration from the service user. For the use of an I & C service, it is irrelevant from the point of view of the service customer whether the operation of the network infrastructure and the service platforms is performed by one or several companies. For problems that occur when using the I & C service, he usually can not distinguish in which area of responsibility these problems fall. The point of contact for the use of the I & C service is therefore first the service provider ("1 ^st level customer care"), who has to pass on technical problems to the service provider ("2 ^nd level customer care") who, if necessary, with his "suppliers". - the network / basic service providers or content providers.

With the development of a new I & K service the operator can hire an external service developer. The interface (➄) is determined on the one hand by the type and how the properties and capabilities of the developing Service and on the other by the service provider used platform on which the developed service then expire should.

The role model from the View of service development

For the development of an I & K service especially the in 8th gray marked roles of the service developer and the service operator crucial. However, their requirements for the development process are decisively influenced by the interfaces ➀ - vorstehend described above. The previously not mentioned interfaces between different network operators and the network service providers can be neglected from the point of view of the I & K service development, as from the point of view of the service provider these are purely internal interfaces. Since the service provider does not have a direct interface to the service customer in this role model, requirements from the contractual relationship between service customer and service provider can only affect the development process via the interface ➂ between service provider and service provider.

in the Following are the roles of I & K service providers and I & K service developers and the described interfaces (➀ - ➄) the requirements for development processes of I & C services. Here are both technical and economic aspects consider.

2.3 Technical aspects the service provision

First, the technical aspects of service delivery arising from the technical platforms and systems used to provide the services will be examined. On the one hand, this concerns the network technologies used by the network operators. The offered network services are connected to a suitable interface (interface ➀ in 8th ) for use by the service provider. In turn, to service the desired service functionality, the service provider provides appropriate systems. The specific characteristics of these control systems are to be taken into account by the service developer and thus define the interface ➄ in 8th ,

by virtue of of rapid technological progress in the areas considered will be in the following analyzes in addition to the existing ones Systems and technologies also taken into account expected future developments.

2.3.1 Heterogeneity of networks

The technological developments have become a variety of communication networks with different skills and properties. Primary Fixed networks and mobile networks can be distinguished. For the stationary telecommunications sector has the digital telephone network "ISDN" (Integrated Services Digital Network) [Boc97] widely enforced. There are also a number of Technologies for Data networks, such as the DSL technologies (Digital Subscriber Line), Ethernet, SDH (Synchronous Digital Hierarchy), FDDI (Fiber Distributed Data Interface) or ATM (Asynchronous Transfer Mode).

For the wireless Communication with mobile devices There is a multitude of radio networks. GSM (Global System for Mobile Communication) [EVB01] and in the future UMTS (Universal Mobile Telecommunication System) are the best known Representatives of mobile telecommunication networks in Europe. they offer in addition to the telephone and short message service (SMS) also a Series of basic services for data transmission such as GPRS (General Packet Radio Service) and HSCSD (High Speed Circuit Switched Data). A variety of other radio network technologies allows data transmission with higher Bandwidths, but often only for lower ranges. As an example, here are WirelessLAN and Blue To call Tooth.

to Dissemination of broadband television and radio programs exists another group of networks. Stationary fixed networks, such as the cable television network, are used by radio-based networks, such as DAB (Digital Audio Broadcasting) and DVB (Digital Video Broadcasting), added. Through digitization these broadcasting distribution networks and their broadband communication options they are increasingly becoming synonymous for other information services [SEK + 99, SK99]. The combination This distribution network with bidirectional networks also allows offering interactive services over these networks [KSE00, RKS01].

The presented diversity of the existing network infrastructure and the existing introduction trend Other network technologies designed for specific needs mean that there is no reason to expect a decline in network diversity in the future either. The previous attempts to standardize the network infrastructure based on a continuous network technology (for example, ATM and B-ISDN) must be regarded as a failure in retrospect. It has been found that the requirements of the various communication services, such as necessary bandwidth and allowed delay, are so diverse that they can only be met inadequately by a uniform network technology. In the development of services, therefore, a large number of different networks will have to be considered in the future as well.

The However, network infrastructure diversity is not just different Network technologies determined. Driven by deregulation Telecommunications market today are usually several networks one certain network technology from different suppliers. For a high Customer reachability need Services therefore often over Networks of different providers can be used. An I & C service provider must therefore be with a variety of network service providers work together.

2.3.2 Open network interfaces

For the use of the networks by external service providers, the networks must offer suitable interfaces which enable the use of the network and basic services by external service providers (interface ➀ in 8th ). They are a prerequisite for the transparent use of different networks by a central control body [KBS + 01].

• • Internet-Protokolle (IP/TCP): Ziel der Entwicklung des aus dem Internet bekannten Protokolls „IP" [Pos81a] war ein einheitliches Verfahren zur Übertragung von Daten über unterschiedliche Netztechnologien. Es ermöglicht die Nutzung eines standardisierten Übertragungsdienstes an einer einheitlichen Schnittstelle und verbirgt die spezifischen Eigenheiten der hierbei genutzten Übertragungsnetze. Eine Reihe hierauf aufbauender Transportprotokolle wie TCP [Pos81b] und UDP [Pos80] und weitere anwendungsspezifischere Protokolle, wie HTTP [FGM+99] und FTP[PR85], ergänzen das Internet-Protokoll IP und haben eine weitreichende Verbreitung gefunden. Die hohe Präsenz dieser Protokolle erlaubt die universelle Nutzung der hierdurch angebotenen Netz- und Basisdienste. Anwendungsprogramme, die spezifische I&K-Dienste anbieten, können auf die an diesen Schnittstellen angebotenen Netz- und Basisdienste zugreifen, ohne die Art und Weise der technischen Umsetzung dieser Dienste in den jeweiligen Netzen berücksichtigen zu müssen (9). Die vorgenannten Protokolle entstammen aus dem Bereich der Computernetze. Ein Defizit dieser Schnittstellen ist die sehr begrenzte Eignung für realzeitige Kommunikation. Erst die Ergänzung durch weitere Protokolle, wie RTP [SCFJ03] und RSVP [BZB+97], oder die zukünftigen Varianten dieser Protokolle, wie IPv6 [DH98], werden dieses Defizit beheben können.
• • PSTN/ Internet Interworking (PINT): In der „Internet Engineering Task Force" (IETF) wurde in einer Arbeitsgruppe eine offene Schnittstelle zur Zusammenarbeit von Telefonnetz und Internet standardisiert [PC00]. Diese Schnittstelle ermöglicht die Nutzung von Telefonnetzen und deren Diensten aus dem Internet heraus. Das genutzte Protokoll basiert auf dem „Session Initiation Protocol" (SIP) der IETF. Über ein derartiges PINT-Gateway können Dienste wie der in Abschnitt 2.1.3 beschriebene Click-to-talk – Dienst realisiert werden. Ein Anstoßen von Internet-Diensten über das Telefonnetz wird derzeit von der IETF unter dem Namen SPIRITS („Services in the PSTN Requesting InTernet Services") diskutiert [GFL+03].
• • Open Service Access (OSA): Die 1998 als Industriekonsortium von fünf Gründungsunternehmen ins Leben gerufene „Parlay Group" arbeitet an der Spezifikation einer standardisierten, offenen Netzschnittstelle. Ziel ist es, externen Dienstanbietern die Netzdienste verschiedener Netze an einer sicheren, einheitlichen und abrechenbaren Schnittstelle zur Verfügung zu stellen [MK03]. Erweitert um mehrere Arbeitsgruppen hat die Parlay Group mittlerweile gemeinsam mit dem „European Telecommunica tions Standards Institute" (ETSI) die Version 4.1 der OSA-Schnittstelle spezifiziert [ETSI03]. Um die verschiedenen Netzdienste nutzbar zu machen, werden diese hierzu in „Service Capability Features" (SCF) eingeteilt. Sie umfassen beispielsweise den Aufbau einer Verbindung oder die Übermittlung einer Textnachricht. Über standardisierte Schnittstellen können externe Dienstanbieter auf die Funktionen der SCF-Bausteine zugreifen. Ein Framework ist für das Auffinden der verschiedenen SCFs und die Verwaltung der Nutzer und ihrer Rechte zuständig.
• • Java APIs for Integrated Networks (JAIN: Die JAIN-Initiative von Sun Microsystems fasst eine Vielzahl von APIs zur Steuerung von Netzen zusammen. Hierzu werden vorhandene APIs von Telefon- und Datennetzen in ein Java-Framework zusammengefasst [KTG00]. Zu den in JAIN integrierten Schnittstellen zählen SIP, H.323, SS#7, INAP und andere [BG00]. Das Framework stellt die unterschiedlichen Schnittstellen als Java-Komponenten zur Verfügung und erlaubt die flexible Nutzung der Netzfunktionen durch Dienste, die in einer Java-Programmierumgebung entwickelt wurden. Eine Implementierung der Parlay/OSA Schnittstelle und weiter unterstützende Funktionen zur Dienstausführung sind Bestandteil von JAIN.
• • Multimedia Home Platform (MHP): MHP definiert eine universelle Schnittstelle zwischen interaktiven Diensten und den multimedialen Endgeräten, auf denen diese Dienste ablaufen [ETSI01]. Der Einsatzzweck dieser Schnittstelle liegt im digitalen Fernsehen (DVB). Sie soll die endgeräteunabhängige Entwicklung von Diensten ermöglichen, die dann auf verschiedenen Teilnehmerendgeräten (Fernseher, Multimedia-PC, etc.) ablaufen können. Diese offene Programmierschnittstelle erlaubt die Ausführung beliebiger Anwendungsprogramme auf zukünftigen Endgeräten und ermöglicht die Nutzung des Fernsehverteilnetzes für neue Dienste [Ebe03].

Such interfaces have recently been developed for many types of networks. The cooperative network infrastructure resulting from this development is often referred to as "Next Generation Networks" (NGN) [ALM + 01] In the following some selected interfaces are presented which have an important influence on the development of the future network infrastructure and thus on the development of the network infrastructure Services will be:

• • Internet Protocols (IP / TCP): The aim of developing the Internet-aware protocol "IP" [Pos81a] was a unified process for the transmission of data across different network technologies, allowing the use of a standardized transmission service on a common interface and concealing A number of transport protocols based thereon, such as TCP [Pos81b] and UDP [Pos80], and further application-specific protocols, such as HTTP [FGM + 99] and FTP [PR85], supplement the Internet Protocol IP and have a The high level of presence of these protocols allows the universal use of the network and basic services offered by them.Application programs offering specific I & C services can access the network and basic services offered at these interfaces, without the technicalities involved Implementation of these services in the respec networks ( 9 ). The aforementioned protocols come from the field of computer networks. A deficit of these interfaces is the very limited suitability for real-time communication. Only the addition of additional protocols, such as RTP [SCFJ03] and RSVP [BZB + 97], or the future variants of these protocols, such as IPv6 [DH98], will be able to remedy this deficit.
• • PSTN / Internet Interworking (PINT): In the "Internet Engineering Task Force" (IETF), a working group has standardized an open interface for the cooperation between the telephone network and the Internet [PC00], which makes it possible to use telephone networks and their services The protocol used is based on the Session Initiation Protocol (SIP) of the IETF. Such a PINT gateway can be used to implement services such as the click-to-talk service described in Section 2.1.3. Internet services initiation over the telephone network is currently being discussed by the IETF under the name of SPIRITS ("Services in the PSTN Requesting InTernet Services") [GFL + 03].
• • Open Service Access (OSA): The "Parlay Group", founded in 1998 as an industrial consortium of five founding companies, is working on the specification of a standardized, open network interface with the aim of enabling external service providers the network services of different networks in a secure, consistent and billable interface In addition to several working groups, the Parlay Group has now specified version 4.1 of the OSA interface together with the "European Telecommunications Standards Institute" (ETSI) [ETSI03]. In order to make use of the various network services, these are classified in "Service Capability Features" (SCF), for example, the establishment of a connection or the transmission of a text message.On standardized interfaces, external service providers can access the functions of the SCF modules. A framework is responsible for locating the various SCFs and managing the users and their rights.
• • Java APIs for Integrated Networks (JAIN: Sun Microsystems' JAIN initiative brings together a variety of network-controlling APIs by merging existing telephone and data network APIs into a Java framework [KTG00] counting integrated interfaces SIP, H.323, SS # 7, INAP and others [BG00]. The framework provides the various interfaces as Java components and allows the flexible use of network functions by services developed in a Java programming environment. An implementation of the Parlay / OSA interface and further supportive functions for service execution are part of JAIN.
• Multimedia Home Platform (MHP): MHP defines a universal interface between interactive services and the multimedia devices running these services [ETSI01]. The purpose of this interface is in digital television (DVB). It is intended to enable the terminal-independent development of services that can then run on different subscriber terminals (TV, multimedia PC, etc.). This open programming interface allows the execution of arbitrary application programs on future devices and allows the use of the TV distribution network for new services [Ebe03].

2.3.3 Architectures for cross-network Control of services

The Flow control of the functionality an I & K service is the task of a service control [Kel02a]. She initiates the necessary establishment and dismantling of the communication relations between the participants. As part of the service flow, the service control in this case handle the interaction of the participant with the flow logic. Further tasks of a service control are the authentication and authorization of the participants who want to use the service. To personalize the services must be the management of subscriber profiles allows become. Also, the resulting in the context of service usage billing is an important task of service control.

In the original one service-specific networks, such as the analog telephone network, was the Service control is an integral part of the network infrastructure. With the separation of network and service, however, had to take new forms be developed by service controls. Network interfaces like allow the ones described above the use of network services of different networks for the provision cross-network I & C services. To control such services must be appropriate cross-network Service controls are developed.

A main task of these service controls is to enable the use of various networks transparently through the desired services [KSM02]. They rely on the in 8th shown interface ➀ on. The content offered as part of a service is often sourced from external content providers. These contents are offered in specific, often standardized formats. These formats must be defined by the service controls through suitable interfaces (interface ➁ in 8th ).

in the Following are some architectures for controlling cross-network Services presented as an example.

The "Telecommunications Information Networking Architecture "(TINA)

to flexible service provision by a variety of service providers on a shared heterogeneous network infrastructure, the network and basic services fast and universally more complex I & K Services can be combined. For this, the services offered by the networks are considered as components defined as part of a component model flexibly to complex I & C services can be. A component is an independent building block, which has a certain functionality encapsulates and interfaces them for use by other components offering. End-user services are provided by a network of components each realized a particular partial functionality of the service fulfill.

Such a component model for controlling I & K services offers, for example, the "Telecommunications Information Networking Architecture" (TINA) [BHG00] In this component model (see 10 ), the individual functionalities of the network nodes are mapped in "Computational Objects".

The communication of these objects with each other is realized by means of a Distributed Processing Environment (DPE) The DPE enables the transparent communication of the different objects with each other, without the objects having to know about their distribution on the different network nodes ("Computational Interface"), the objects offer their services within the component model. Communication links that exchange user data over the network connections between the network nodes are sent by the components via "Stream Inter faces "into the working environment.

On TINA defines this component model in the "Service Architecture "[TIN + 97a] concrete components for the provision of a service can be used. So The expiration of a service instance is through a "Service Session Manager" (SSM) component carried out. However, TINA does not specify how the respective service logic works to realize. For the functional distinction of the necessary signaling processes distinguished three "sessions" in the course of the service Access of the subscriber, selection and start of a service to the "Access Session "summarized. All at the service execution involved interactions fall into the "service session" Coordination of network services to fulfill the desired Communication relations between the service participants forms the "Communication Session".

by virtue of of the distributed component model may be in a TINA environment Services at the same time from different concrete service controls Tobe offered. Each provider can do this a suitable procedure choose, On the other hand, it does not get much help from the concepts offered by TINA. Despite the support of the TINA project through a variety of telecommunications companies has become due the wide scope and high complexity of the work the TINA architecture in real networks so far can not enforce. Many individual concepts (eg the session concept) are however from other works been taken up.

The SAMSON architecture

A detailed architecture for controlling services in heterogeneous Networks named "SAMSON" can be found in [Kel02a]. It relies on open interfaces of networks like the one in section 2.3.2 and provides an example of future cross-network Service controls.

Core of the SAMSON architecture (see 11 ) is a central control unit ("service control"). This central service control communicates via an internal signaling with the open interfaces of the networks for establishing the desired communication relationships between the subscribers of a service. All data belonging to an active service instance, such as the profiles of the subscribers and the currently switched communication connections, are recorded in the service control in a service graph. In the course of mapping a provided in the service general communication relationship between two service participants on specific operations in the connected networks for switching a connection of the service graph is gradually enriched with additional information and thus detailed so far, to a mapping to the concrete network elements is possible [Kel01]. In this case, in an adaptation level, the network-specific interfaces provided by the network service providers in the domain of the service provider are converted to a uniform interface with the aid of adapter units. These adapters allow the addition and use of new networks, without having to make changes in the central service control. To describe the desired quality parameters for the communication relationships of a service own quality classes are defined. Services must therefore be developed specifically adapted to this service control.

Web services

in the The area of the Internet has distributed architectures to provide enforced by services. The flat, little hierarchical structure the internet is for centrally organized service controls poorly suited. The control the services on the Internet is therefore usually divided into different Components, such as terminals and central servers.

Under The term "web services" becomes a component architecture whose goal is the utilization of individual service modules to the manifold Use in internet services based on this is [Jec03]. she is currently in several standards by the World Wide Web Consortium elaborated. Communication with the various service modules is handled on the basis of a protocol called "Simple Object Access Protocol" (SOAP) [Mit03]. Which functionalities the block offers this at its interface, can with the XML-based Web Services Definition Language "(WSDL) [CGMW03]. This allows the classification of the offered service and the indication of the possible call and response messages with their parameters.

The main application of this technology is the provision of individual information services on the Internet, which can be integrated as components in more complex applications. Such service For example, building blocks can offer the lookup of a postal code or the calculation of a package postage.

to Description of the offered interface builds WSDL on a stateless Connection protocol on which the service block no interdependencies managed between successive service requests. For reference For example, a postcode does not care about previous requests to the service module. The typical use of a Webservices therefore consists of a call and usually exactly one Reply.

The However, individual network services of a communication network must often complex states manage. Construction, change and degradation of a communication link, for example, not in Any order take place. To interact with a network service Therefore, usually more complex protocols are necessary, the multiple Handle interactions as part of a single service request can. A description of the interfaces of a communication network Therefore, with the WSDL offers only limited information about the Options, how this interface can be used. Also, SOAP is despite his name is not object-oriented and knows, for example, none Life cycle for Objects [Vin02].

A Comprehensive use of web services concepts to deliver more complex I & K-service is therefore unlikely. Because of their wide distribution in the area of the internet and the increasing fusion of internet and telecommunications networks, however, the integration of web service building blocks in future Architectures for I & K services an important Role-play.

ASP.NET

The widespread use of the Internet has many forms of use guided. In addition to simply retrieving static information pages increasingly complex applications based on the "World Wide Web "realized, such as interactive catalogs and ordering systems, or completing Bank transactions. The user can use these systems through his web browser serve. triggered through inputs and interactions of the user generates the system dynamically the necessary HTML pages. Such systems will be as "Web Applications " and need extensive processing systems to interact with the user and dynamically providing the transmitted information pages. The connection to external data processing systems for the provision and further processing of the information is necessary.

A technology used to create such web applications is the "ASP.NET" system offered by Microsoft [AFH + 02, WHKT02, Lor02]. In an object-oriented environment, ready-made classes for the Development of the desired Application can be used. For example, these classes offer opportunities for the management of service users and their system usage rights, as well as Interfaces for the connection of external systems. Another focus is the interaction of the user with the system. Own classes can be in any programming language can be created. extensive Software tools and development environments support the Developer in the creation and management of applications. ASP.NET is in particular for the development of web applications has been designed. One use for telecommunications services is not intended, could however, through the diverse connectivity will be realized.

2.3.4 Service Flow Logic Descriptions

to Control the flow of an I & C service through a service control must the flow logic of this service in a for understand the service control Form expressed become. Many service architectures, such as TINA, leave the implementation of the actual process control to the service operator, which therefore also has to select the form of the process description. On the other hand, there are many approaches to defining standardized ones Process descriptions. Some of these are procedural description languages linked to concrete service architectures. In some cases but also architec ture-crossing Process descriptions designed to use a service on different service controls.

In order to an automated processing of the service flow is possible The service process description must be in a well-defined form to be created. At the same time, this form should be the broad Variety of possible Services are not too restrictive. In the following some example descriptions are presented:

SIB-Graph of the Smart Network

With the term "intelligent Net "becomes one Extension of the telephone network to provide more complex, user-oriented Services based on telecommunications infrastructure [Sie01]. In this architecture, the control of the service flow in the context of a telephone connection to a central control authority ("Service Control Point "- SCP) become. In this SCP can various functions are applied to the service-initiating telephone connection become. These functions include, for example, forwarding the call to another destination, playing an announcement or the acceptance of subscriber signaling over the Telephone keypad. The course of such a service consists in sequential calls to the necessary function modules. This one Function blocks universally used in different services can be will they be "service Independent Building Blocks "(SIBs) called [ITU97b]. These blocks represent the basic functions later Service execution platform like answering a call, playing an announcement or recognizing DTMF tones.

The description of a service flow logic is done by specifying a directed graph whose nodes are the respective function blocks used (see 12 ). Depending on the result of the called block, the further processing of the service can be continued in different branches of the graph. In addition to specifying the function block to be used, a number of parameters of this block are usually also defined for the nodes of the graph. These parameters indicate, for example, which announcement a play module is to output to the caller. The notation of the service flow logic is done in a platform-specific format, which can be processed by the respective target platform.

at the building blocks of the SIB graph are functional building blocks the one specific function, for example the auditioning of a Announcement, represent. If several connections exist in one service at the same time, then created an association of the connections to the functions of the graph become. Also the simultaneous execution of several functions can not be described in the SIB graph. For these reasons is this technique for I & K services with several simultaneously active connections only limited use.

XML-based process descriptions

• • Call Processing Language (CPL): Die „Call Processing Language" ist eine Skriptsprache, um die Behandlung von internetbasierten Telefonanrufen zu steuern. Die folgenden Ausführungen beziehen sich auf den derzeit in der IETF diskutierten Vorschlag [LWS03], von dem eine baldige Verabschiedung als Standard (RFC) erwartet wird. Mit der CPL kann für einen Teilnehmer eines internetbasierten Telefonsystems spezifiziert werden, wie ein- oder ausgehende Anrufe vom System behandelt werden sollen. Mögliche Aktionen sind hierbei das Abblocken oder Umleiten eines Anrufes mit Bezug auf Bedingungen, wie „Anschluss belegt", „Tageszeit" oder „Ursprung". Ein derartiges Skript ermöglicht es dem Teilnehmer beispielsweise zu spezifizieren, dass eingehende Anrufe während der Bürozeiten an seinen Büroanschluss und zu anderen Zeiten an seinen Privatanschluss geleitet werden sollen. Des Weiteren könnte der Teilnehmer angeben, dass im Falle eines belegten Zielanschlusses der Anruf auf eine Mailbox weitergeleitet werden soll. 13 zeigt eine einfaches Beispiel für ein CPL-Skript, welches alle eingehenden Anrufe für den Teilnehmer auf einen anderen Anschluss umleitet. Da die CPL insbesondere für die Spezifikation von Diensten durch den Teilnehmer gedacht ist und diese Dienste dann auf einem zentralen Server ablaufen, ist der Funktionsumfang der CPL aus Sicherheitsgründen stark eingeschränkt. Komplexe Dienste mit mehreren Verbindungen können nicht realisiert werden.
• • VoiceXML: Für die Beschreibung komplexer Dialoge eines Nutzers mit einem telefonbasierten Informationssystem wird derzeit vom World Wide Web Consortium (W3C) die „Voice Extensible Markup Language" (VoiceXML) standardisiert [MBC+03]. Sie ermöglicht die Ablaufbeschreibung von Sprachdialogen, mit denen ein Nutzer mit Hilfe eines Telefons interaktiv Informationen wie Wettervorhersagen oder Börsenkurse abfragen kann. Diese Dialoge können dabei aus aufgenommenen oder synthetisierten Sprachansagen, dem Aufnehmen oder Erkennen von gesprochenen Benutzereingaben oder der Interaktion des Nutzers über die Tasten des Telefons bestehen. Auch das Weiterverbinden des Teilnehmers an einen anderen Anschluss ist möglich. Aufgrund des festgelegten Funktionsumfangs eignet sich die VoiceXML nicht zur Beschreibung von komplexeren Diensten, die über die beschriebenen Telefondialoge hinaus gehen.
• • CCXML: Für das Beschreiben komplexer telefonbasierter Dienstabläufe wird vom W3C derzeit die CCXML („Voice Browser Call Control") entwickelt [Aub03]. Mit dieser Beschreibungssprache können Dienstabläufe auf Basis eines Telefonsystems beschrieben werden, die Dialoge, Mehrpunktverbindungen und Konferenzschaltungen beinhalten können. Zur Beschreibung enthaltener Telefondialoge kann wiederum die VoiceXML genutzt werden. Die Beschreibung des Dienstablaufs basiert auf einem asynchronen Zustandsautomaten, der auf auftretende Ereignisse (z. B. einen eingehenden Telefonanruf) mit dem Ausführen von definierten Aktionen reagiert. Komplexe Funktionsabläufe können durch die objektorientierte Struktur beschrieben werden, der Dienst muss sich jedoch auf die Funktionalitäten des Telefonsystems beschränken. Weitere Netzdienste, wie das Versenden einer Email, können nicht hinzugefügt werden.

In addition to graphical service descriptions, there are also a number of textual process descriptions. For non-proprietary formats intended for cross-service use, a widely accepted and easy-to-use description format must be found. In order to establish such a format for flowcharts, the use of the Extensible Markup Language XML [BPSM00] has proven to be advantageous [BJ02] In the following, three XML-based process descriptions are presented by way of example.

• • Call Processing Language (CPL): The Call Processing Language is a scripting language used to manage the handling of Internet-based telephone calls The following remarks refer to the proposal currently under discussion in the IETF [LWS03], which is expected to be adopted soon CPL allows a subscriber of an Internet-based telephone system to specify how incoming or outgoing calls are handled by the system, such as blocking or rerouting a call with respect to conditions such as "connection occupied "," time of day "or" origin ". For example, such a script allows the subscriber to specify that incoming calls should be routed to his office line during office hours and to his private line at other times. Furthermore, the subscriber could indicate that in the case of a busy destination connection the call should be forwarded to a mailbox. 13 shows a simple example of a CPL script that redirects all incoming calls for the subscriber to another port. Since the CPL is intended in particular for the specification of services by the subscriber and these services then run on a central server, the functionality of the CPL is severely restricted for security reasons. Complex services with multiple connections can not be realized.
• • VoiceXML: The World Wide Web Consortium (W3C) standardizes the "Voice Extensible Markup Language" (VoiceXML) for the description of complex user dialogues with a telephone-based information system [MBC + 03] a user can interactively retrieve information such as weather forecasts or stock quotes using a telephone, which can be from recorded or synthesized voice prompts, recording or recognizing spoken user input, or user interaction over the keys on the phone. Also the further connection of the participant to another connection is possible. Due to the set scope of functions, VoiceXML is not suitable for describing more complex services that go beyond the described telephone dialogues.
• • CCXML: The W3C is currently developing CCXML ("Voice Browser Call Control") for describing complex telephone-based service operations [Aub03], which can be used to describe service processes based on a telephone system that may include dialogs, multipoint connections, and conferencing The description of the service flow is based on an asynchronous state machine that responds to occurring events (eg an incoming telephone call) with the execution of defined actions.Complex functional sequences can be described by the object-oriented structure However, the service must be limited to the functionality of the telephone system, and additional network services, such as sending an email, can not be added.

SAMSON service flow logic SPL

For the above described SAMSON architecture became a more flexible flow logic selected. To describe the dynamic behavior of a service in SAMSON operations (see Table 2.1) defined with which changes at the current service instance. With these operations can Participants or connections are added, modified or deleted. The picture of the changes in the abstract description of the service instance on concrete actions in the connected networks, as described above, task the service control in collaboration with the network adapters.

to Description of the flow logic of a service become the triggering conditions and the sequence of operations initiated by them. For the Notation of service logic suggests the author in [Kel02a] is an XML-based description language called "Session Programming Language "(SLP). However, the concrete definition of this SLP is defined only structurally and deposited with a fragmentary DTD.

Tabelle 2.1: Operationen auf die Dienstbeschreibung in SAMSON (aus [Kel02a])

Table 2.1: Operations on the service description in SAMSON (from [Kel02a])

2.3.5 Commissioning new services

For the operator a service control plays in addition to ensuring the trouble-free Operating the currently installed services especially the Smooth broadening of the service offer plays an important role. The addition new services, ie the installation of a new service type the execution platform, however, it carries some risks.

"Feature Interaction"

The Introduce new services or service functionality into an existing system with existing services often too unexpected and unwanted Interactions between the services. As a provider or participant can combine multiple services, there is a risk that the overall behavior the services do not correspond to the expected sum of individual behaviors. Cause for this are dependencies and interactions of the services with each other in the development the individual services were not sufficiently taken into account. This originally made In the telecommunications sector, the problem is called a "feature Interaction ". examples for Such interactions in telecommunication services can be found in [ITU97a].

With the variety of networks and media used and the deregulation of the market, the problem of undesirable interactions between I & C services becomes far more complex and complex [KSM00]. These interactions can be due to all phases of the development process as well as the later operation of the services. For example, inaccurately specified requirements as well as incorrect implementations or poor documentation of service behavior can trigger unwanted behavior. Problem - based interactions can therefore be their cause in all areas of the 8th have shown role model. When developing and commissioning new services, appropriate measures must be taken to prevent unwanted interactions in the overall system.

2.4 Economic Aspects the service provision

Next The technical aspects also have economic aspects a strong influence on the way of delivery and Development of I & K services. For one Service provider is in addition to the technical feasibility in particular the economic success of the service is the most important decision criterion for the Development of a new service. For the economic success is a corresponding demand potential on the service user side necessary. Needs and wishes the potential users therefore play an important role in the context the service provision. For The economic success of a service is beyond the question of pricing of paramount importance. These Factors are analyzed below and their implications for delivery and development of I & K services.

2.4.1 The service user

The decision to use a particular service or not is generally made by the service user. The user and his view of the service are therefore important framework conditions that must be taken into account when developing a service (interface ➃ in 8th ). In the following, the relevant aspects of the service user and his view of the service are considered.

Increasing mobility

By the individualization of society decreases the mobility of the participants strong to [BHP + 00]. The increasing proliferation of mobile and the ubiquitous possible access to I & K services through the use of the mobile phone leads to a increasing intensity of use the services. Participants are accustomed to providing their services to everyone Time and place to use [Sie01]. This mobility does not close only the physical mobility of the participant, but also the possibility of one and the same Service over different access channels to use. For example, in the office, querying emails can be done via the PC over and over on the way a mobile device. The service must adapt to the respective capabilities of the terminal can. These skills in particular concern the type and quality of input and output options of the terminal.

Also the current environment - the variable Context - in the participant during the use of service can have an important impact on the Interaction and the needs of Participants should be considered by the service. For example, a context-sensitive service switches for queries the emails from a text representation to an audio output if the subscriber leads a vehicle when polling.

Benutzerfreunddichkeit

The Wide use of a variety of services requires a high degree of usability the services. Can a user the functionality or the operation of a Service does not understand simply and quickly, so he becomes the service not use. Due to the spatial Distance between service provider and service user is an explanation of Service or a demonstration the use usually not possible. For a successful one Service, therefore, good user interfaces are essential.

personalization

However, users of a service are not all the same. The needs they have and the demands they place on the services are often very different. Often a consistent service can not satisfy all users equally. In order not for every user one in Having to develop a personal service and since the users usually know their needs and requirements best, it is advantageous if a uniform service can be customized by the users. This individual configuration of the service is called personalization.

2.4.2 Marketing of I & K Services

Already during the development of a service the later marketing possibilities must be considered. In addition to the technical feasibility of the service, the issue of economy plays a paramount role in the development of new services. This requires close cooperation between service providers and service providers (interface ➂ in 8th ). Determining the functionality of the service and the early estimation of economic success are major challenges.

Selective prototype development

by virtue of The multiplicity of influencing factors can be the later economic To predict the success of a service is difficult. The estimation of profitability is usually only possible through acceptance tests on selected customers. For this is a fast prototype development of the planned service necessary, the later Behavior of the service must authentically mimic. As part of the through the acceptance tests with the users collected experiences Often a repeated modification of the planned service is necessary. The basis of a new prototype can often be already existing services form. The development of new, profitable services is often based on trying out a variety of development opportunities existing services. This iterative approach to service development must be supported by the development process.

pricing

Drawing I & K services characterized by a number of properties that are important Influence on the possibilities their marketing. While the structure of the infrastructure needed to provide the services associated with high investment, fall for the concrete execution of one Service instance generally only low variable cost to [SV99]. The built-up capacity Furthermore, it can not be stored, but must be used consistently over time because the unused capacity expires [SS00]. These characteristics mean that an I & C service provider must strive to its existing capacities preferably largely to capacity.

The from him for The use of the services requested prices can only be limited to the orient directly by the use of costs, as these largely negligible are [Sti02c]. The prices must Rather, they are geared to the willingness of customers to pay. The determination of the concrete willingness to pay of the customers is in many cases associated with high difficulties, since the service user with the Use of an I & K service very different Can pursue purposes [Sti02b]. So can a phone conversation both serve the entertainment, as well as to be used for the execution of important banking transactions.

Especially in standard services, which are equally of a variety offered by providers is for a service provider the Differentiation from competition through different service characteristics only possible with difficulty. This is partly because the use of a service with different properties for the user is unfamiliar and the rapid dissemination of the service thereby precludes an obstacle. Furthermore, new ones Service features that have proven successful in the market often within the shortest possible time Time to be copied by the competitors. Due to the limited possibilities for product differentiation, pricing will therefore become one central element for the marketing of I & K services.

There are a number of choices available to the service provider to determine appropriate pricing. A more detailed treatment of the pricing options can be found in [Sti02c]. First, a selection of partial services of a service to be priced is to be made. Thus, not only the actual service user, but also a third party for the use of the service pay. In addition to the actual use of the service, the customer contacts arising during use can also be used to generate advertising fees. In addition, the usage data resulting from a large number of uses can often be disposed of after appropriate processing (eg as user profiles). In [Sti02c] it could be shown that at the services offered on the internet In recent years, there has been a significant broadening of the sources of income used. Many suppliers used not only the product revenues but also the customer contacts and the collected information as sources of revenue.

For the selected sources of revenue have to in the next Step concrete pricing models are set. It can be a Variety of parameters can be varied. In addition to usage-independent fees ("basic charge") can itself variable fees based on the number of uses, the length of time, the used quantity o. Ä. orientate.

There the customer's willingness to pay varies greatly price differentiation as a means of achieving optimal revenues. in this connection The provider tries the same service to different customers to sell at different prices [Wir00]. The goal here is to offer each customer the service at a price that reflects the respective The customer's willingness to pay as much as possible. Next the problem, the respective willingness to pay the customer Furthermore, it is necessary to ensure that a Customer only in each case the intended offer and not perceived that for another customer with a lower willingness to pay thought cheaper Offer.

The Assignment of offer and customer can either from the provider or by the customer himself. A selection of customers through the provider, for example, at the customer's place or one certain status (eg student, retiree, etc.). However, the selection of the right offer can also be transferred to the customer become. Here the offerer offers different variants of a in principle the same service and leaves the choice of the respective Offer to the customer [SS00]. The different service variants form Here, the different willingness to pay customers with Help different preferences the customer. So dispose For example, business customers often have one higher Willingness to pay as a private customer, but often provide others Requirements for the respective service. A service provider can offer service variants with different scope of services here (eg usable bandwidth, maximum number of stored calls on an answering machine, etc.) and these with different prices Mistake.

The Formation of variants happens in many cases, however, only by offering different pricing models for a service. Here can the Customer then for example between a tariff with low basic fee and high user fees or a tariff with a high base fee and low user charges choose.

The above show the importance of the pricing decision for the economic Success of an I & K service on. The customer benefit associated with the use of the service must be always be taken into account in the development of the service. For a successful one Marketing must be in many cases a flexible variant formation of a service be possible. The fast adaptation of pricing models and creating a variety of individual ones Tariffs for different user groups must be possible.

2.4.3 Introduction of new ones services

Of the Economic success of a service can be very much in many cases change quickly. Services that are still in high demand today may be enough already tomorrow due to changed environmental conditions the new customer needs no more. Service providers are therefore often a quick modification or expanding their service offer. This results in a high pressure on the development process to shorten the Development times.

Short service life cycles

The Development and commissioning of a new network generation is taking place usually in periods of a few years to decades. Once installed network technology must be in operation for many years for the investment to pay off. The change and updating an existing network technology are with a high effort connected, since the actual mains operation also during the Modification of the infrastructure without downtime maintained must become. When changing of network components there is a risk that in operation in the new Components occurring errors to strong disturbances in the entire network operation to lead. Also subject to the technical platforms for service control in principle this change resistance and have long migration cycles.

The resulting from this long change and innovation cycles of networks and platforms are in one sharp contrast to the often very short lifecycles of I & K services. by virtue of of competitive pressure new services are often developed and introduced within a few weeks. amendments to the existing services partly in even shorter Time mastered become. For special events, such as trade fairs or sporting events Services developed after the event no longer are needed and only a few days in use. The development a new service must therefore be possible without making any changes at the network infrastructure or control platforms necessary are. These must from the perspective of service development with their skills and characteristics as existing, immutable Components are accepted.

specification of the desired service

If the service is created by an external service developer, then the interface between service provider and service developer (interface ➄ in 8th Such a document defining the service to be developed shall contain all the information about the desired behavior of the service, the characteristics which the service must or may not have, and all conditions, In addition to their role as a "specification sheet" to form a contractual agreement on the service to be developed, such a specification is also an important tool for communication between the marketing department and the organization Development planning of a service provider [Sie01]. Also in dealing with the client of a service development such a specification is helpful. It is the basis for discussion to determine the planned behavior of the future service.

2.5 Requirements for the Development of I & K services

• • Anforderungen der Dienstfunktionalitäten:
• • Unterstützung der Funktionsvielfalt: Die dem Dienst zugrunde liegenden Bedürfnisse können sehr unterschiedlich sein. Der Entwicklungsprozess darf die mögliche Dienstvielfalt nicht einschränken.
• • Ermöglichung multiedialer Dienste: Die Nutzung unterschiedlicher Medien und einer Vielzahl von Kommunikationsverbindungen im Dienstablauf muss möglich sein.
• • Beschreibung von Qualitätsabstufungen: Für die einzelnen Kommunikationsverbindungen des Dienstes und die genutzten Medien sind verschiedene Abstufungsmöglichkeiten der Qualität möglich. Hierzu sind geeignete Parameter zur Beschreibung der notwendigen oder wünschenswerten Qualitätsstufen der genutzten Medien notwendig.
• • Anforderungen der technischen Plattformen:
• • Berücksichtigung bestehender Netzschnittstellen: Für die Neuentwicklung eines Dienstes ist im Allgemeinen eine Änderung der Netzinfrastruktur nicht möglich. Der neu entwickelte Dienst muss über die bestehenden offenen Netzschnittstellen abgewickelt werden können.
• • Unterstützung der Netzvielfalt: Ein und derselbe Dienst kann oftmals über eine Vielzahl unterschiedlicher Netze genutzt werden. Der Entwicklungsprozess muss daher die Umsetzung des Dienstes auf unterschiedlichen Netzen ermöglichen.
• • Anbingung an externe Systeme: Viele Dienste müssen mit externen Systemen (z. B. Datenbanken, Lokalisierungssystemen, etc.) zusammenarbeiten. Informationsinhalte für Dienste werden häufig von externen Anbietern bereitgestellt. Der Entwicklungsprozess muss die hierzu notwendigen Schnittstellen berücksichtigen.
• • Unterstützung verschiedener Dienststeuerungen: Für die spätere Ausführung des Dienstes können unterschiedliche Architekturen und Plattformen eingesetzt werden. Die plattformspezifischen Eigenschaften (Datenformate, Art der Dienstlogik, etc.) der Dienststeuerung müssen in der Entwicklung berücksichtigt werden.
• • Berücksichtigung bestehender Dienste: Die Installation eines neuen Diensttyps soll die bestehenden Dienste möglichst nicht beeinträchtigen. Der Entwicklungsprozess muss unerwünschte Interaktionen zwischen den Diensten möglichst weitgehend vermeiden.
• • Anforderungen durch die Dienstnutzer:
• • Einbeziehung von Personalisierungsmöglichkeiten: Damit der Nutzer den Dienst an seine persönlichen Bedürfnisse anpassen kann, müssen Möglichkeiten zur späteren Konfiguration des Dienstes in der Entwicklung vorgesehen werden.
• • Unterstützung der Endgerätevielfalt: Die genutzten Endgeräte unterscheiden sich hinsichtlich ihrer Fähigkeiten und Eigenschaften stark. Bei der Entwicklung des Dienstes kann nicht von der späteren Nutzung eines bestimmten Endgeräts ausgegangen werden. Die exakten Fähigkeiten und Eigenschaften der später genutzten Endgeräte sind oftmals während des Entwicklungsprozesses noch nicht bekannt.
• • Berücksichtigung unterschiedlicher Nutzungskontexte: Die spätere Nutzung des Dienstes sollte weitgehend unter unterschiedlichen Bedingungen möglich sein (Zuhause, im Auto, etc.). Die Dienstentwicklung muss hierzu unterschiedliche Zugangsarten und Bedienschnittstellen (Tastatureingaben, Spracheingaben, etc.) innerhalb eines Dienstes unterstützen.
• • Anforderungen der Dienstanbieter:
• • Ermöglichung einer unabhängigen Dienstentwicklung: Die Entwicklung neuer Dienste auf der Basis bekannter Schnittstellen sollte durch externe Dienstentwickler möglich sein. Eine eindeutige und vollständige Spezifikation des Verhaltens und der Eigenschaften des gewünschten Dienstes im Rahmen des Entwicklungsprozesses ist hierzu notwendig.
• • Unterstützung schneller Prototypenentwicklung: Prototypen neuer Dienste müssen schnell erstellt werden können, damit die Akzeptanz der Dienste getestet werden kann. Erfolgreiche Prototypen müssen schnell in reale Implementierungen umgesetzt werden können.
• • Erleichterung der Änderung bestehender Dienste: Die Abänderung oder Weiterentwicklung bestehender Dienste muss ohne die Notwendigkeit einer strukturellen Neuentwicklung möglich sein. Die Möglichkeit zur späteren Bildung von Dienstvarianten sollte schon frühzeitig im Entwicklungsprozess berücksichtigt werden.
• • Unterstützung einer flexiblen Tarifierung: Die Tarifmodelle der entwickelten Dienste müssen eine flexible Bepreisung ermöglichen. Die der Bepreisung zugrunde liegenden Parameter der Dienstnutzung müssen auch nach Abschluss der Entwicklung noch geändert werden können, damit beispielsweise auch nachträglich eine zeitabhängige Tarifierung eines Dienstes eingeführt werden kann.

The previous sections have defined the concept of I & C service and presented the current and expected future environment of these services. As mentioned at the outset, the term I & K service covers a very broad scope, so that not all I & C services equally meet the features presented. The service-specific requirements for the development of I & C services resulting from the presented scope of the I & C services and the discussed basic conditions of service provision can be summarized as follows:

• • Requirements of the service functionalities:
• • Functional diversity support: The needs underlying the service can vary greatly. The development process must not restrict the possible variety of services.
• • Enabling multi-service services: The use of different media and a variety of communication links in the service flow must be possible.
• • Description of quality gradings: For the individual communication links of the service and the media used, different quality grading options are possible. For this purpose, suitable parameters for describing the necessary or desirable quality levels of the media used are necessary.
• • Requirements of the technical platforms:
• • Consideration of existing network interfaces: For the new development of a service, it is generally not possible to change the network infrastructure. The newly developed service must be able to be handled via the existing open network interfaces.
• • Network diversity support: One and the same service can often be used across a variety of different networks. The development process must therefore enable the service to be implemented on different networks.
• • Attachment to external systems: Many services must work with external systems (eg databases, localization systems, etc.). Information content for services is often provided by external providers. The development process must take into account the necessary interfaces.
• • Support for various service controls: Different architectures and platforms can be used to later run the service. The platform-specific properties (data formats, type of service logic, etc.) of the service control must be taken into account in the development.
• • Consideration of existing services: The installation of a new service type should not affect the existing services as far as possible. The development process must avoid as much as possible unwanted interactions between the services.
• • Requirements by service users:
• • Incorporation of personalization options: allowing the user to personalize the service Needs to be adapted, possibilities for later configuration of the service in the development must be provided.
• • Support of terminal diversity: The terminals used differ greatly in terms of their capabilities and characteristics. The development of the service can not be based on the subsequent use of a particular terminal. The exact capabilities and characteristics of the later used terminals are often not known during the development process.
• • Consideration of different contexts of use: The later use of the service should be largely possible under different conditions (home, in the car, etc.). The service development must support different access types and user interfaces (keystrokes, voice inputs, etc.) within a service.
• • Requirements of service providers:
• • Enable Independent Service Development: The development of new services based on known interfaces should be possible through external service developers. A clear and complete specification of the behavior and characteristics of the desired service as part of the development process is necessary.
• • Rapid prototyping support: prototypes of new services need to be created quickly to test acceptance of the services. Successful prototypes need to be translated quickly into real implementations.
• • Facilitate the modification of existing services: the modification or further development of existing services must be possible without the need for structural redevelopment. The possibility for the later formation of service variants should be considered early in the development process.
• • Support for flexible pricing: the tariff models of the services developed must allow flexible pricing. The parameters of service usage on which the pricing is based must also be able to be changed after completion of the development, so that, for example, a time-dependent tariff classification of a service can also be subsequently introduced.

The The above listing characterizes the specific requirements dedicated to the development of I & K services put. They are the starting point for the following considerations the development processes. An efficient and effective Development process for I & K services must support and consider the requirements mentioned.

3 success factors of development process

To considering the specific characteristics that characterize I & C services, and the demands of the development of I & C services, Now the development process is examined. First, task and content of development processes in general. Then be on a model-based consideration of the development process the Factors worked out for the success of such a process are crucial. The observation of these success factors from the point of view of the previous one The specific requirements of the I & C services outlined in the section allow the Establishment of a catalog of criteria for the evaluation of I & C service development processes.

3.1 Task of a development process

The The task of a development process is to create a structural Frame for those necessary for the development of the target be executed To form actions. He describes for this the procedure of the to be executed development activities and the results to be created. The development process thus represents an outline, based on the complex development project in smaller, manageable Sections can be divided (see also [BEP + 00] to the software development process).

As far as the I & C service is concerned, the development process aims to create a new type of service. The once developed service type can then be activated ("instantiated") as part of the service usage for a large number of customers (see Section 2.2.1) .The creation of these service instances on the basis of the developed service type is the task of the execution platform used The development of a new service is always the development of a new type of service, and there is an idea at the beginning of a new service development, to transform this initially very vague idea into an implementation of a new type of service To carry out concretization steps, which together form the development process (see 14 ).

The starting point for new ideas can be a variety of different influences. The creative process of brainstorming can hardly be pressed into a defined framework. Impulses for new ideas are found in the entire complex environment of service development. As mentioned, the services currently in use often provide clues to new service ideas. The services developed, therefore, have the effect of finding new ideas, so that the development process in an as in 14 shown loop runs.

The The result of service development is the finished service type. He includes the installation of the service on the execution platform necessary programs, database structures, user interfaces, documentation and other necessary data and documents.

3.2 Terms of the development process

• • Artefakt: Als Artefakt wird im Folgenden ein im Rahmen des Entwicklungsprozesses genutztes, substantiiertes und abgeschlossenes Ergebnis bezeichnet. Es kann in textueller oder grafischer Form niedergelegt sein.
• • (Beschreibungs-)Sprache: Jedes Artefakt, welches im Rahmen einer Entwicklung geschaffen wird, muss auf einer festgelegten Begriffsbasis gefasst sein, um für eine weitere Verarbeitung zugänglich zu sein. Erst das gemeinsame Verständnis über eine einer Beschreibung zugrunde liegende Sprache gibt dieser Beschreibung einen Sinn. Der Begriff „Sprache" umfasst hierbei alle möglichen eingesetzten Notationsformen, die beispielsweise textueller oder grafischer Natur sein können.
• • Methode: Eine Methode beschreibt allgemein ein systematisches, zielgerichtetes Vorgehen, um einen bestimmten Zweck zu erreichen [Fri95]. Im Rahmen eines Entwicklungsprozesses umfasst dies alle eingesetzten Vorgehensweisen zur Erreichung des Entwicklungszieles. Methoden sind hierbei die Mittel, um die verschiedenen Artefakte im Rahmen des Entwicklungsprozesses zu bearbeiten, um so zu neuen Artefakten zu gelangen. Sie geben Hinweis und Anleitung, wie die einzelnen Modellierungssprachen im Entwicklungsprozess eingesetzt und verarbeitet werden [Bro96].
• • Vorgehensmodell: Ein komplexer Entwicklungsprozess beinhaltet meist den Einsatz einer Vielzahl unterschiedlicher Sprachen und Methoden. Die Koordinierung der verschiedenen Aktivitäten zum Einsatz der Sprachen und Methoden ist Aufgabe eines Vorgehensmodells. Dieses legt hierbei Art, Umfang und Reihenfolge des Sprach- und Methodeneinsatzes fest [And03].

In the context of the development process as a methodical procedure for concretizing an idea to a goal implementation, a number of fundamental concepts can be distinguished, which are of decisive importance for the further consideration of the development process:

• • Artifact: The following is an artifact used in the development process, substantiated and concluded result. It can be laid down in textual or graphic form.
• • (Descriptive) language: Any artifact created as part of a development must be written on a defined conceptual basis in order to be accessible for further processing. Only the common understanding of a language underlying a description makes sense of this description. The term "language" encompasses all possible types of notation that may be textual or graphical, for example.
• • Method: A method generally describes a systematic, goal-oriented approach to achieve a specific purpose [Fri95]. As part of a development process, this includes all procedures used to achieve the development goal. Methods are the means to process the various artifacts as part of the development process in order to arrive at new artefacts. They provide guidance and guidance on how the individual modeling languages are used and processed in the development process [Bro96].
• • Process model: A complex development process usually involves the use of a multitude of different languages and methods. The coordination of the various activities for the use of languages and methods is the task of a procedure model. This specifies the type, scope and sequence of language and method usage [And03].

3.3 Model of a development process

Of the Success or failure of a development is determined by a number of Factors influenced. For a closer examination of the factors influencing success Development process is referred to below in terms of Koomen [Koo85] a general model for set up a development process.

As in 14 The development process aims at the structured transfer of an idea into a concrete realization. Due to the complexity of the system to be developed, this implementation can generally not be carried out in an elementary step. Rather, the development process consists of the sequence of a multitude of successive steps (often called "phases") 15 shown represent.

starting point a step n is the result of the previous step n-1. Each result of a step consists of two elements. On the one hand contains The result is a set of requirements that are to be developed System be made. These requirements are usually just informal described with text or drawings. Part of the requirements Often it is not recorded in writing, but only implicitly in the external environment the system development included. The second component of the result A development step is the one developed up to this point System. It is generally in a formal, explicit language specified and contains for example, program code or block diagrams.

As part of a development step, the result of the previous step (output n-1), as in 15 shown. into a new result (output n) of step n. This new result (output n) then forms the starting point (input n + 1) for the subsequent development step n + 1.

• • Auswahl der diesen Schritt beeinflussenden Anforderungen
• • Entwicklung des neuen Systems aus dem bisher bestehenden System und den ausgewählten Anforderungen
• • Eventuell Umformulierung der verbleibenden Anforderungen (beispielsweise Konkretisierung im Hinblick auf das bisher entwickelte System)

At the beginning of the development process, the entry of the first step consists of request only requirements. At the end of the development process, on the other hand, a completely developed system should be available. For this purpose, the following tasks must be fulfilled in each step (see also [Koo85]):

• • Selection of requirements affecting this step
• • Development of the new system from the existing system and the selected requirements
• • possibly reformulation of the remaining requirements (eg concretisation with regard to the system developed so far)

in the Within the framework of a step, therefore, part of the requirements for Further development / refinement of the system used. The output result a step therefore provides a detail of the corresponding input result this step dar.

at the implementation This refinement, the developer must, as Koomen shows the result to add a certain amount of information. This is the information the an outsider, the output of a development step can, if he the Knows input of this step. So this added information provides the creative part of the development process, where the developer the remaining scope for him to create something new.

The presented model of successive development steps makes no statement about that chronological sequence of these steps. They are rather than structural To see steps of the process. During development, these can Steps not only sequential but also iterative in loops be processed. Also the backward turned Process is possible in the case of an existing system through gradual abstraction an ever more abstract model is created.

3.3.1 Entropy of the development process

und wird in der Einheit bit angegeben. Hierbei ist p_i die Wahrscheinlichkeit, dass das Ereignis i aller n möglichen Ereignisse eintritt. Die Entropie ist ein Maß für die Menge an Information, die ein Betrachter gewinnt, wenn man ihm das Ergebnis des eingetretenen Ereignisses mitteilt. Um diesen Wert wird dabei die Unsicherheit des Betrachters durch die Kenntnis des eingetretenen Ereignisses verringert.As Koomen shows, a certain amount of information has to be recreated on the way from the original requirements to the finished system. In order to "measure" this set of information, he proposes the concept of entropy developed by Shannon, which calculates the entropy H as the information content of an event x

and is specified in the unit bit. Here, p _{i is} the probability that the event i of all n possible events occurs. The entropy is a measure of the amount of information that a viewer wins when you tell him the result of the occurred event. In this case, the uncertainty of the viewer is reduced by this knowledge by the knowledge of the occurred event.

It can be shown that the entropy decreases when the set of possible events is reduced by one event and the probability of the event taken is distributed among the remaining events. Also, the entropy can be reduced if the distribution of the probabilities is different from the equal distribution. This is the case, for example, if, with two probabilities p ₁ <p _2, the greater probability p _{2 is increased} at the expense of the smaller probability p ₁ .

In terms of the development process, n indicates the number of implementations that can be a result of the development process under consideration. The probability that the implementation i will be developed with this development process is described by p _i . The entropy H is the amount of information that a viewer who knows the initial conditions of development fully gains by learning which of the possible n results of the development has actually been realized.

The Entropy H is the set of as part of the development process newly generated information. It is therefore a measure of the complexity of the considered Development process. Can the entropy of a development process this is tantamount to simplification development work, ie a reduction of the development effort.

3.4 Success factors of development processes

With the presented model of the development process and the developed concept of entropy as a measure of the amount of information to be generated, some general considerations can now be made structuring of the development process. Here are a number of factors that are crucial for the desired success of the development process - the rapid and error-free development of the desired item. They are referred to below as success factors.

3.4.1 Choice of abstraction levels

The each level of the development process provide one each certain abstraction of the entire system. They represent a description of the relevant with regard to this level of abstraction Properties of the system. For this system description can Different languages at every level of the development process be used. At a level n, therefore, the system is made the definition of the languages used and in those languages written descriptions. The determination of the used abstraction levels and the languages used at each level is central Part of the development process.

As Koomen shows can be created by the developers overall Information and thus the entropy of the process by the appropriate Choice of abstraction levels and languages can be significantly reduced. So can System-level redundancy at a higher level through reuse solved by building blocks easier become as on the lower levels of abstraction. The use of a such block on a higher Level reduces the number of possible implementations, because the building block is at the lower levels in all job sites each realized in the same way. Are in one Implementation, for example, two databases necessary and can a database realized by three different technologies This results in nine (3 · 3) implementation options. However, at a higher level Abstraction level for both databases are the same building block used so at the lower level for the realization of this database module only once from the three technologies select so that the number of possible Implementations reduced to three.

Next exploiting the redundancies of a system provides the right one Choice of levels of abstraction, however, further benefits. So can by abstracting the one to be processed by the developer on one level Information is broken down into smaller, delimited parts. This facilitates the capture and processing of the information and is especially important as humans only with a degree in complexity can handle. After the evaluation of several different experiments For example, Miller puts a number of about 7 elements as the maximum amount of information manageable by the human brain at the same time near [Mil67]. If this limit is exceeded in the experiments mentioned, so the error rate rises sharply. The abstraction levels of the development process have to therefore chosen be that complexity at any level does not exceed a certain level.

3.4.2 Suitable description languages

• • Fehlende Struktur: Eine durchgängige und von außen erkennbare Strukturierung ist nicht gegeben.
• • Mehrdeutigkeiten: Begriffe und Formulierungen können von verschiedenen Lesern unterschiedlich gedeutet werden.
• • Unvollständigkeit: Einer nichtformalen Beschreibung ist auf den ersten Blick nicht anzusehen, ob sie Lücken enthält.
• • Übermäßige Länge: Informelle Beschreibungen sind nicht auf das rein notwendige reduziert. Sie enthalten oft überflüssige Angaben und Wiederholungen.

The central component of the result of a development step is the system developed at this level. This system must be recorded in a suitable language. A non-formal description is associated with certain disadvantages and problems [Bro96]. These include, in particular:

• • Missing structure: A consistent and externally recognizable structuring is not given.
• • Ambiguities: terms and phrases may be interpreted differently by different readers.
• • Incompleteness: A non-formal description is at first sight unclear if it contains gaps.
• • Excessive length: Informal descriptions are not reduced to the purely necessary. They often contain unnecessary information and repetitions.

For these reasons, non-formal descriptions are poorly suited for describing system components in the development process. Formal Description Techniques (FDTs) are based on a strictly defined syntax and can largely avoid the problems mentioned, and a description developed on the basis of these languages allows the correct structure, syntax, and completeness to be checked using the formal definition The uniqueness of a description is also the aim of the formal description languages ("formal semantics"), although different interpretations of a described system by different readers can not always be excluded. Another important advantage of the formal description languages is their ease accessibility for automated processing, since, due to the formal definition, the reading-in and processing of such a description by computer programs is made possible. Insofar as people also have to work with the formal descriptions in the development process, it is important to have a clearly readable and comprehensible representation. In particular, graphic representations can serve well here.

in the Unlike non-formal descriptions is a formal description language limited to specified areas of application. A language can be here support certain views of a system (for example, in terms of temporal behavior) or for a particular type of system be suitable. Thus a high usability for a certain abstraction level given the development process, must be the chosen language can express the system properties relevant in this level. Furthermore should be possible prefabricated building blocks the preparation of the respective description as far as possible facilitate. Such building blocks can in the context of service development, for example, subscribers, terminals or communication channels represent. Such building blocks can be the total to be developed Reduce amount of information as they implement certain implementations exclude or at least the probability of certain types of implementations considerably increase.

3.4.3 Procedure model

task A process model is the individual steps of a development process in a structured framework. It must therefore specify which abstraction levels are chosen and which description languages are used at these levels. Appropriate methods need a smooth transition between the levels.

Also the timing of the different development steps is determined in a procedure model. A purely sequential Sequence of steps will not be the development of I & C services in most cases meet future changes the requirements or the environment is difficult to take into account can be. Rather, an iterative procedure will usually be necessary, which Setbacks in the development process allows. Doing so ensures that the consistency of the results between the different levels. This can then be ensured if by formal rules the correct relationship between the results of two levels can be verified. Techniques and procedures that provide such a secured, property-preserving Transformation of artifacts become formal methods called [BEP + 00].

3.4.4 Automation

Even though the development process substantially on the creative work of the Is dependent on humans In the context of the development often also many simple structured works accomplished become. As far as such work is taken in formal rules can, offers an automation of this work. To do this mostly computer programs used (see "Computer Aided Software Engineering" - CASE) Way, the human developer of simple, but time-consuming Working, such as the graphical representation of a system model or the calculation of specific properties of the developed system, be relieved and its work performance strengthened the creative part of the Devote to the development process. However, it has to be considered that the use of the automated tools by the developer associated with a certain amount of operating effort, the productivity of the developer in turn decreases [Koo85]. This operating effort must be through reduced human-machine interfaces as much as possible become. The means for this are, for example, graphic user interfaces call. Also need the abilities and the necessary input information of the tool to the respective Purpose to be adapted. Well suited (software) tools have a very important influence on the success of a development process.

Of the Automation of the process, however, have certain limitations because a complete Automation of the process would mean that as part of the development process no decisions have to be taken by developers anymore. The Entropy of this process would be therefore zero, since the result of the automated process is perfect de is predetermined by terminology. The creative part of the creative process, where something over that what is existing up to that point can be created however, they are not cast in algorithms and therefore must continue be done by people.

3.4.5 Limits in the Reduction of development time

Also an optimal choice of abstraction levels, description languages and tools can be the amount of information to be generated in the development process not arbitrarily reduce. This would only be the case if through the requirements and the given development process the final implementation is well established in every detail and therefore In the development process no longer independent decisions are meeting. By the generally given in the development process choices However, there are usually a variety of possible implementations as Result of the development. With the different possible Implementations and their occurrence probabilities can the entropy - and so that the minimum amount of information to be created - one Development project.

Considered man, that human information only with a certain maximum Can generate rate, this results in a given Number of developers a certain minimum duration necessary for the implementation of the Development process is necessary. If you try, the rate of Increasing the information production of a developer increases the risk of mistakes strong. Should the duration of a development process nevertheless shortened become two approaches for this purpose.

To the One can be tempted to sum the total in the development process Information to be generated - the Entropy H - through To reduce modification of the process. This can, as shown above, possibly by inserting be reached further abstraction levels, if appropriate Redundancies exist in the development process. Also the choice of one better adapted description language or providing appropriate Blocks can reduce the amount of information to be generated.

When another possibility To reduce the development time, it makes sense to count the number to increase the persons entrusted with the development herewith to increase the rate of generated information. in this connection however, it is necessary to consider whether the design of the development process is split up several developers allowed. Only as long as such partitioning the development possible is the total duration can be reduced.

As Brooks [Bro95] for Software development is increasing with the addition of more Developers of the necessary coordination effort with each other. This Voting effort increases particularly strongly, if between the individual partial results of the developers a high Number of dependencies consists. This coordination effort reduces the information rate of all developers and may be the most unfavorable Cause case that the total duration of development by adding more Developer rises and does not sink.

3.4.6 Summary the success factors of development processes

• • Geeignete Abstraktionsebenen: Durch die geeignete Wahl von Abstraktionsebenen können Redundanzen im Entwicklungsprozess ausgenutzt werden und die Komplexität des einzelnen Entwicklungsschrittes reduziert werden.
• • Angepasste Modelle und Sprachen: Für einen spezifischen Entwicklungsprozess müssen an das Entwicklungsobjekt angepasste Modelle und Sprachen zur Verfügung gestellt werden.
• • Formalität der Beschreibungssprachen und Transformationsmethoden: Eine formale Definition der eingesetzten Beschreibungssprachen und der zur Transformation der Ergebnisse in einem Entwicklungsschritt eingesetzten Methoden erlauben die Verfikation der einzelnen Entwicklungsschritte.
• • Definiertes Vorgehensmodell: Die Reihenfolge und die Art und Weise des Einsatzes der ausgewählten Modelle, Sprachen und Methoden wird durch ein explizit definiertes Vorgehensmodell strukturiert.
• • Werkzeugunterstützung: Eine Unterstützung des Entwicklungsprozesses durch geeignete Werkzeuge entlastet die Entwickler von automatisierbaren Aufgaben. Die Fehlerhäufigkeit und die Entwicklungsdauer können hierdurch reduziert werden.

By analyzing the presented model of a development process, the following factors can be summarized that must be fulfilled by a successful development process:

• • Suitable levels of abstraction: The appropriate choice of abstraction levels can exploit redundancies in the development process and reduce the complexity of the individual development step.
• • Custom models and languages: Models and languages adapted to the development object must be made available for a specific development process.
• • Formality of description languages and transformation methods: A formal definition of the description languages used and the methods used to transform the results in a development step allow the individual development steps to be validated.
• • Defined procedure model: The order and the way of using the selected models, languages and methods is structured by an explicitly defined procedural model.
• • Tool support: Supporting the development process with suitable tools relieves the developers of automatable tasks. The error frequency and the development time can be reduced thereby.

3.5 Picture of the special Requirements of the I & C services on the success factors

The Factors determining success are generally valid for each type from development process. They let themselves by the consideration of the service-specific requirements from section 2.5 for development processes from I & K services concrete. The success criteria will be included following for the analysis and evaluation of existing service development procedures used.

3.5.1 Suitable abstraction levels

starting point the service development process is the idea for a new service. At the start The development process must translate this idea into a clear and accurate one Specification of the desired Service and its characteristics. In the further course In the development process, this specification should be on or may be mapped to several different platforms. Also the conversion to different networks and the context-dependent use various communication channels should be supported become.

Around one possible enable extensive reuse of the specification have to the platform-specific implementations of the platform-independent specification be clearly separated. The development process must therefore be in the Abstraction levels a clear distinction between the specification of desired Service properties and implementation of the service on the Provide different platforms. In the models of the specification levels allowed to There are no implementation-specific details.

These Clear separation of the specification is also necessary for independent service development a service specified by the service provider from an external Service developer is implemented. Here, the description of the desired Service behavior of the while the implementation of the service on a particular platform developed artifacts are separated.

3.5.2 Custom models and languages

The description languages used for the specification and implementation of the service have to be adapted to the specific purpose. For the specification have to appropriate language elements are made available to the specific characteristics of the desired I & C service simply and clearly express can. Prefabricated language modules, for example for the service subscribers and facilitate the different types of communication relationships the preparation of the specification description. The description the existing communication relations between the Participants must support different quality gradings. In the specification must the quatlity parameters here at the for the functionality the service necessary conditions (for example, "intelligibility") and may Description does not require any specific implementations (for example "ISDN telephony").

The in the context of the implementation of the specified service on one chosen Platform-deployed description languages must conform to the platform-specific Orient properties. Due to the large differences of the used Platforms is the use of a fixed descriptive language not helpful. To enable a flexible selection of the target platform, The development process must be fast and easy to the platform-specific Details can be customized. Models and description languages for the different types of development Artifacts in their respective format have to be added easily and flexibly can. Platform-specific structures must be in the chosen language elements express to let.

3.5.3 Formality of the description languages and transformation methods

To enable independent service development by external developers, the service specification created must be clear and concise and meaningful. Ambiguities in the specification lead to the interface between service operators and service developers (cf. 8th , Interface ➄) for multiple queries or for the implementation of an undesired service. In order to make the descriptions clear, the description languages used must be sufficiently well defined. A formal verification of syntax and internal consistency of created descriptions should be possible.

Also in the case of the mappings of a development result into the following result in the course of a development step, a formal definition of the consistency conditions to be observed is the prerequisite for verification of the development step. Such verifiable consistency rules are particularly necessary to allow for subsequent changes to a developed service and to support an iterative approach to service development. In particular, such an iterative approach must ensure that the changes and extensions made at one level do not lead to inconsistencies in the other levels. The created on one level Changes or extensions must be able to be transferred to the other levels as simply and safely as possible. The support of this iterative approach is also necessary for a substantial reusability of already existing development results in subsequent service developments.

3.5.4 Defined procedure model

The individual activities of the development process be structured by a goal-oriented process model. This Process model should in particular the usually iterative approach support the service development. The rapid realization of prototypes and the possibility for the gradual refinement of the service specification are to this Key criteria. For the latter Extension or modification of an existing service allows the support an iterative approach that is a big part of the previous development outcome can be reused.

Also if in a development process a chain of different Description languages and tools is used, so the Development process a consistent and enable a uniform process. The procedural model should include the entire development process from the brainstorming to the respective target platform consistently cover the deployable service type. Media breaks between The individual development steps must be avoided.

3.5.5 Tool support

For the fast and safe development is the support of the process by appropriate Software tools of critical importance. This is how stated above in particular the formal definition of the used description languages necessary. The concrete development of software tools, however, depends Furthermore, it depends on how far a concrete process and the used in the industry.

aim The present work is not a decision-making tool for a company for the Selection of an existing process model to offer, but the Further development of future Service development processes in the context of scientific research to advance. Therefore, in the following work in the analysis and assessment of existing development processes, the formality as a prerequisite for the implementation examined in software tools, the concrete availability However, such tools are not rated.

3.5.6 Evaluation criteria for I & K service development processes

• • Separation: Klare Trennung von Spezifikation und Implementierung in den Abstraktionsebenen
• • I&K-Dienstspezifität: An die Eigenschaften der I&K-Dienste angepasste Modelle und Beschreibungssprachen
• • Formalität: Formale Fundierung der genutzten Beschreibungssprachen
• • Erweiterbarkeit: Flexible Unterstützung von neuen Umsetzungsplattformen
• • Iterativität: Passendes Vorgehensmodell zur schnellen Entwicklung von Prototypen und zur nachträglichen Modifikation von Diensten
• • Durchgängigkeit: Abdeckung des ganzen Prozesses von der Ideenfindung bis zur Implementierung ohne Medienbrüche

By considering the overall success factors of development processes (Section 3.4.6) with respect to the specific requirements that I & C services place on development (Section 2.5), this work has developed a set of criteria that are crucial to the success of a development process are crucial for I & K services. These criteria allow evaluation of development processes in terms of their suitability for the development of I & C services. The evaluation criteria developed in this work can be summarized as follows:

• • Separation: Clear separation of specification and implementation in the abstraction levels
• • I & K Service Specificity: Models and description languages adapted to the characteristics of the I & C services
• • Formality: Formal foundation of the used description languages
• • Extensibility: Flexible support of new implementation platforms
• • Iterativity: Appropriate procedure model for the rapid development of prototypes and for the subsequent modification of services
• • Consistency: Coverage of the entire process from brainstorming to implementation without media discontinuity

The The evaluation criteria presented below are used in the analysis and evaluation of existing development processes. You can do that Advantages and shortcomings of the individual procedures with regard to service development detect. From this you can subsequently Requirements for an improved service development process be derived.

4 discussion and evaluation of existing service development procedures

After the derivation of the criteria for a successful development process for I & K services will be In this chapter, existing methods and methods for service development are explained and evaluated with regard to the established criteria. The investigated methods come from different areas and therefore have different starting points. Besides the development of telecommunication services, due to the high influence of software development on the development of I & C services, methods and methods from general software development are included. A large number of research projects have also dealt with processes for the cross-network development of services.

As explained in the previous chapter, The central starting point of service development is the idea for one new service. This can be both an idea for a completely new one Service as well for the modification or further development of an existing service be. The methods used for brainstorming therefore play a role in the service development process an important role. They are the actual development process upstream and usually clearly separated from this. But she does Starting point of development, the following begins Consideration of existing methods and methods with explanation some typical methods for brainstorming.

All presented methods and methods and their specific properties each time according to the criteria set out in section 3.5.6 analyzed and evaluated. It should be noted that it is not in all cases to complete Development processes, but also methods and procedures are presented, which only certain aspects of service development cover.

4.1 Methods of brainstorming

aim Brainstorming in the context of I & K service development is finding new, more profitable service ideas. The finding process This requires both creative and analytical approaches unite with each other. So he should find the one hand on the one hand new ideas also on possibly completely new business areas support. For this purpose, he must, in particular, stimulate creative and as far as possible unrestricted thinking. On the other hand, you have to however, accurate analysis evaluates and compares the found ones Enable ideas concrete recommendations for further implementation of the Ideas can be given. A detailed Consideration of the process of brainstorming and evaluation during development from I & K services can be found in [Sti02b]. Below are some methods and A method for finding and evaluating new service ideas explained.

4.1.1 Methods of Idea Generation

aim brainstorming is the generation of a sufficient number good quality service ideas. The ideas developed should be the full range of possible Cover application fields. Even if at the end of the brainstorming process usually only a small number of service ideas are selected for a realization can, is for the phase of idea generation the variety and amount of proposals important.

in the General the idea generation can be divided into two phases. First, a "divergent Phase ", which is the Development of a big one and diverse Idea collection serves. In a subsequent "convergent phase" is by selection and combination of ideas a limited number of promising service ideas Developed.

divergent phase

The Ideas developed during this phase should cover the entire range potential Cover application fields. Every generated idea can be the Germ cell of a later successful service development. Passed in this phase Areas are also for lost the further course of brainstorming. The creative process Idea generation should therefore not be restricted be restricted to certain areas. Aim of the methods used Rather, it is necessary to broaden the view of new fields of application be.

Key location the generation of ideas for Services are on the one hand the requirements of the market and on the other hand technological developments. Both areas have to processed with appropriate methods and the necessary expertise become. In addition to the own coworkers also existing ones can in particular and potential customers involved in the process of generating ideas become.

• • Brainstorming: In einer Gruppe von 5 bis 10 Personen werden freie und spontane Gedanken und Ideen gesammelt, die von einem Moderator aufgeschrieben werden. Kritik, Selektion oder Diskussion der Vorschläge ist nicht erlaubt. Ziel ist eine große Menge an Ideen und das Aufdecken neuer Innovationsfelder.
• • Assoziationsketten: Für ein gegebenes Suchfeld werden die zentralen Problemaspekte herausgegriffen. Durch Assoziation werden zu jedem einzelnen Problemaspekt neuartige Ideenanstöße und Lösungsvorschläge gebildet.
• • Customer Tool-Kits: Einzelne Dienstbausteine können von Kunden im Rahmen eines Baukastens durch Zusammenfügen zu neuen Dienstideen kombiniert werden. Hierbei steht die spielerische Entwicklung neuer Ideen durch die neuartige Kombination der Bausteine im Vordergrund.

In particular, creative techniques are used as methods in this phase. It is possible to differentiate between two types of methods in a rough classification. The methods often referred to as "creativity techniques in the narrow sense" are aimed at the intuitive process of undirected generation of ideas [Sch99].

• • Brainstorming: In a group of 5 to 10 people free and spontaneous thoughts and ideas are collected, which are written down by a moderator. Criticism, selection or discussion of the proposals is not allowed. The goal is a large amount of ideas and the uncovering of new fields of innovation.
• • Association chains: For a given search field, the central problem aspects are selected. Through association, new ideas and suggestions for solutions are formed for each individual aspect of the problem.
• • Customer Tool Kits: Individual service modules can be combined by customers in a modular system by combining them to form new service ideas. Here, the playful development of new ideas through the novel combination of building blocks is in the foreground.

• • Morphologischer Kasten: Bestehende Dienste werden anhand ihrer spezifischen Merkmale analysiert. Ein Merkmal könnte das genutzte Endgerät sein. Für alle Dienste werden die jeweiligen Ausprägungen der Merkmale bestimmt (beispielsweise „Telefon", „Fernseher", „PC") und in eine Matrix eingetragen (siehe 16). Anschließend können durch das Auswählen neuer Ausprägungskombinationen Ansatzpunkte für neue Dienstideen gewonnen werden. Auch können bei den einzelnen Merkmalen neue, bisher nicht vorhandene Ausprägungen gesucht werden. Dienste können mit ihren Ausprägungen als ein Pfad in die Matrix eingezeichnet werden.
• • Lead-User Workshops: Kunden, die sich durch intensive oder innovative Nutzung der bestehenden Dienste auszeichnen, werden zu einem gemeinsamen Treffen eingeladen. Im Rahmen einer Diskussion werden Probleme bei der derzeitigen Dienstnutzung sowie Anregungen und Wünsche für neue Eigenschaften und Anwendungsfälle gesammelt.

The creativity techniques for developing new, undirected ideas are complemented by analytical methods, in which new ideas are developed through deduction and development from what already exists. Examples of such methods are:

• • Morphological box: Existing services are analyzed according to their specific characteristics. One feature could be the used terminal. For all services, the respective characteristics are determined (for example "telephone", "TV", "PC") and entered in a matrix (see 16 ). Subsequently, by selecting new combination of characteristics starting points for new service ideas can be obtained. It is also possible to search for new, previously non-existent characteristics in the individual features. Services can be drawn with their characteristics as a path into the matrix.
• • Lead-User Workshops: Customers who distinguish themselves through intensive or innovative use of existing services are invited to a joint meeting. As part of a discussion, problems with current service usage as well as suggestions and wishes for new features and use cases are collected.

convergent phase

In The preceding phase has been a great variety of possible Generated service ideas. From this variety must in the following phase a limited number possible promising and well-designed project proposals developed become. This phase is characterized by an analytical approach in which through compaction and selection the number of ideas gradually is reduced. There are two approaches to this. To the one are the ideas and suggestions on similarities and similarities to investigate. By comparing and rating weaker or redundant proposals can be sorted out. As a further course of action should be tried, different To combine ideas with each other to get the benefits of different approaches to unite in a service idea. In particular, technology-driven proposals be combined with ideas from the environment of marketing.

• • Szenarienbeschreibung: Ausgewählte Abläufe des geplanten Dienstes werden in konkreten Szenarien dargestellt. Durch die Verallgemeinerung dieser Szenarien können sogenannte „Use Cases" [Coc01] erstellt werden, die jeweils das Interaktionsmuster eines Akteurs mit dem System beschreiben.
• • Zielgruppe: Beschreibung der potentiellen Kunden, die mit diesem Dienst angesprochen werden sollen. Eine Einteilung in unterschiedliche Gruppen mit der Erläuterung der spezifischen Wünsche und Anforderungen dieser Kunden ist empfehlenswert.
• • Realisierungskonzept: Ein erstes grobes Realisierungskonzept beschreibt die zur Umsetzung des Dienstes notwendigen Grundfunktionen. Es kann insbesondere um ein Modell der vom Kunden gesehenen Benutzungsoberfläche des Dienstes ergänzt werden.

The result of the convergent phase consists of concrete project proposals for the realization of selected service ideas. For this, the ideas in hand must be elaborated and detailed in the course of the phase. The elaborated project proposals must be detailed and described in detail in such a way that an in-depth evaluation of the market economic opportunities and the expenditure of the technical realization is possible. For a comparability of the different proposals, attention must be paid to a uniform type of documentation. The following documentation elements are available for this [Sti02b]:

• • Scenario description: Selected processes of the planned service are presented in concrete scenarios. By generalizing these scenarios, so-called "use cases" [Coc01] can be created, each of which describes the interaction pattern of an actor with the system.
• • Target group: description of the potential customers to be contacted with this service. A division into different groups with the explanation of the specific wishes and requirements of these customers is recommended.
• • Implementation concept: A first rough implementation concept describes the basic functions required to implement the service. In particular, it can be supplemented with a model of the user interface of the service seen by the customer.

4.1.2 Evaluation and selection the service ideas

in the Follow-up to the development of project proposals for the development of new services must now make an entrepreneurial decision on the implementation of proposed projects. Here it is decided which of the project proposals carried out and within what time frame the implementation will take place should. The key decision criterion here is the long term expected economic success of each service. In addition to the appraisal the revenue generated by the services and the operation expenses incurred are also responsible for the development of each Service's necessary resources to consider.

The Way of evaluating service ideas and the design of the Process of decision-making is for the subsequent development the services and therefore does not continue in this work considered. Full Explanations of the cited Decision process and evaluation of service ideas can [Sti02b] be removed.

4.2 Development Processes from the field of telecommunications

services are an essential part of telecommunication networks. In the early one Years of telephone networks, these networks were only to provide a single service - the Telephony - developed. Service development was therefore an integral part of network development. Only with the increasing opening the telephone networks for a greater variety of services could become an independent Training service development. As stated in the introduction in section 1.1, has with the increasing economic relevance of the services the Service development has a new meaning. Stand-alone methods and processes have emerged. In considering this Methods will be examined below in particular in how far an extension over the telephone network based services on I & K services seems possible with these methods.

4.2.1 Development of Services in the telephone network

For the development of services in the conventional Telephone network strikes the International Telecommunication Union (ITU) in some of their Recommendations a framework process. This process is primarily for development of services for a digital telephone network according to the ISDN standard thought, can however also transferred to other telephone networks become. Recommendation I.130 [ITU88] provides an overview of this Development process. It is a sequential process which consists of three phases, which are divided into further sub-steps become.

Phase 1: service description from the perspective of the user

• • Schritt 1 (Informelle Beschreibung): Im ersten Schritt wird der Dienst in Prosa beschrieben. Die Empfehlung I.210 [ITU93c] gibt im Anhang A eine Struktur für die Beschreibung vor. Hiernach beginnt die Beschreibung mit einer kurzen Definition, gefolgt von einer ausführlicheren allgemeinen Beschreibung des Dienstes. Anschließend wird das Verhalten des Dienstes für Aktivierung, Aufruf, Benutzung, Änderung und Deaktivierung aus Sicht des Nutzers beschrieben. Dabei wird zwischen dem normalen Verhalten des Dienstes, dem Ablauf bei aufgetretenen Fehlern in der Dienstausführung und optional möglichen Alternativabläufen unterschieden. In weiteren Abschnitten der Beschreibung werden die Anforderungen an die Tarifierung und die Zusammenarbeit mit anderen Netzen oder Diensten erläutert. Trotz der vorgegebenen Struktur handelt es sich um eine nichtformale Beschreibung.
• • Schritt 2 (Statische Beschreibung): In diesem Schritt werden die statischen – d. h. zeitunabhängigen = Eigenschaften des Dienstes mit einer in der Empfehlung I.140 [ITU93b] festgelegten Attribut-Technik beschrieben. Jedes Attribut gibt hierbei mögliche Ausprägungen einer elementaren Diensteigenschaft vor (vgl. auch die Methode des Morphologischen Kastens in Abschnitt 4.1.1). Diese Attribute werden eingeteilt in generische Attribute, Dienstattribute und Netzattribute. Dienstattribute beschreiben Eigenschaften, die für den gesamten Dienst mit allen seinen Kommunikationsbeziehungen gelten. Für die einzelnen Komponenten des Dienstes können dann weitere Attribute bestimmt werden. Im Anhang von I.140 und in den Anhängen B und C von I.210 werden für unterschiedliche Dienstarten die zu bestimmenden Attribute und ihre möglichen Werte vorgegeben. Im Gegensatz zur Technik des Morphologischen Kastens handelt es sich hierbei um sehr technische, oft ISDN-spezifische Eigenschaften.
• • Schritt 3 (Dynamische Beschreibung): Der dritte Schritt beschreibt das dynamische Verhalten des Dienstes. Hierzu werden die möglichen Interaktionen des Nutzers mit dem Netz aufgeführt. Alle Informationen, die der Nutzer an das Netz sendet oder die er von diesem empfängt, werden in einem Ablaufdiagramm dargestellt. Das Netz wird hierbei als eine Einheit angesehen. Informationsströme innerhalb des Netzes werden nicht betrachtet. Zur grafischen Darstellung des Ablaufs wird die „Specification and Description Language" (SDL) [ITU99] genutzt. Eine kurze Beschreibung des Einsatzes von SDL für diesen Schritt wird im Anhang D von I.210 gegeben. Hierzu wird der Dienstablauf in Zustände eingeteilt, und die einen Zustandsübergang auslösenden Ereignisse werden dargestellt. Diese Ereignisse können Ergebnisse von dienstinternen Prozessen oder externe Interaktionen mit dem Nutzer sein.

The first phase looks at the planned service from the user's perspective. The goal is to describe the desired service with its dynamic and static properties. The description takes place in three steps with increasing formality.

• • Step 1 (Informal description): The first step describes the service in prose. Recommendation I.210 [ITU93c] specifies in Annex A a structure for the description. Thereafter, the description begins with a brief definition, followed by a more detailed general description of the service. Then the behavior of the service for activation, invocation, use, modification and deactivation is described from the user's point of view. Here, a distinction is made between the normal behavior of the service, the sequence of errors that have occurred in the service execution and optionally possible alternative procedures. Further sections of the description explain the requirements for tarification and cooperation with other networks or services. Despite the given structure, it is a non-formal description.
• • Step 2 (Static description): In this step, the static - ie time-independent = properties of the service are described with an attribute technique specified in Recommendation I.140 [ITU93b]. Each attribute specifies possible expressions of an elementary service property (see also the method of the morphological box in Section 4.1.1). These attributes are divided into generic attributes, service attributes, and network attributes. Service attributes describe properties that apply to the entire service with all its communication relationships. Further attributes can then be determined for the individual components of the service. In the Annex to I.140 and Annexes B and C of I.210, the attributes to be determined and their possible values are specified for different types of services. In contrast to the Morphological Box technique, these are very technical, often ISDN-specific properties.
• • Step 3 (Dynamic Description): The third step describes the dynamic behavior of the service. For this, the possible interactions of the user with the network are listed. All information that the user sends to or receives from the network is shown in a flowchart. The network is considered as one unit. Information flows within the network are not considered. For a graphical representation of the process, use the "Specification and Description Language" (SDL) [ITU99] A brief description of the use of SDL for this step is given in Appendix D of I.210 the state transition events are presented, which may be results of in-service processes or external interactions with the user.

Phase 2: Necessary network functions

• • Schritt 1 (Funktionales Modell): Zunächst werden die zur Diensterbringung notwendigen Funktionen identifiziert. Das Konzept eines funktionalen Objekts im Rahmen des ISDN wird dabei in der Empfehlung I.310 [ITU93d] definiert. Die zwischen den funktionalen Objekten notwendigen Informationsbeziehungen vervollständigen das funktionale Modell des Dienstes. Auch die Beziehung zwischen dem Basisdienst und seinen möglichen Zusatzdiensten wird in diesem Modell dargestellt.
• • Schritt 2 (Ablaufdiagramme): Die zwischen den funktionalen Objekten notwendigen Informationsströme werden mit den möglichen Abläufen dargestellt. Neben dem normalen Verhalten können auch alternative Abläufe, beispielsweise für Fehlerfälle, hinzugefügt werden. Die Bedeutung und der Inhalt der einzelnen Informationselemente ist hier festzulegen.
• • Schritt 3 (SDL Diagramme für funktionale Objekte): Die von einem funktionalen Objekt auszuführenden Operationen werden identifiziert, und das Verhalten des Objekts wird in einem SDL-Diagramm spezifiziert. Die Ein- und Ausgaben müssen den vorher identifizierten Interaktionen mit dem Nutzer oder den Informationsflüssen zwischen den funktionalen Objekten entsprechen.
• • Schritt 4 (Aktionsliste): Die von den funktionalen Objekten durchzuführenden Aktionen werden in Form einer Liste zusammengestellt. Jede Aktion wird in informeller Form beschrieben.
• • Schritt 5 (Örtliche Funktionsverteilungen): In diesem Schritt werden mögliche Verteilungen der funktionalen Objekte auf die physikalischen Komponenten des Netzes (beispielsweise Vermittlungseinheit oder Endgerät) ausgewählt und durch Szenarien beschrieben.

In the second phase, a functional model for the delivery of the service will be elaborated. This consists of the description of the functionalities necessary for the service provision and the information relations necessary between the functionalities. Both the interfaces between network and user as well as the internal interfaces between the different network components are considered. Different possible physical distributions of the required functionalities on the components of the network complete this phase. The development of this model is divided into the following five steps:

• • Step 1 (Functional Model): First, the necessary functions for service provision are identified. The concept of a functional object in the context of ISDN is defined in recommendation I.310 [ITU93d]. The information relationships necessary between the functional objects complete the functional model of the service. The relationship between the basic service and its possible additional services is also shown in this model.
• • Step 2 (Flowcharts): The information flows necessary between the functional objects are displayed with the possible procedures. In addition to the normal behavior, it is also possible to add alternative procedures, for example for error cases. The meaning and content of the individual information elements must be defined here.
• • Step 3 (SDL functional object diagrams): The operations to be performed by a functional object are identified, and the behavior of the object is specified in an SDL diagram. The inputs and outputs must correspond to the previously identified interactions with the user or the information flows between the functional objects.
• • Step 4 (Action list): The actions to be performed by the functional objects are compiled in the form of a list. Every action is described informally.
• • Step 5 (Local function distributions): In this step, possible distributions of the functional objects to the physical components of the network (for example, switching unit or terminal) are selected and described by scenarios.

Phase 3: implementation in network components

• • Schritt 1 (Protokolle und Formate): Im ersten Schritt werden die notwendigen Nachrichten zwischen den Netzkomponenten identifiziert und die zur Signalisierung notwendigen Protokolle festgelegt.
• • Schritt 2 (Vermittlungs- und Dienstknoten): Die vorher identifizierten Funktionalitäten werden in die bestehenden Funktionalitäten der Vermittlungs- und Dienstknoten eingearbeitet.

In phase 3, the necessary changes of the existing network components are determined for a selected distribution of the functional objects in two steps.

• • Step 1 (Protocols and formats): In the first step, the necessary messages between the network components are identified and the protocols required for signaling are defined.
• • Step 2 (Switching and Service Nodes): The previously identified functionalities are incorporated into the existing functionalities of the switching and service nodes.

With its recommendations, the ITU offers a development process geared specifically to the creation of telephone-based services. Due to the specific focus on ISDN, using this process for other networks and platforms is fraught with great difficulty. Also in the description of the service functionality with the attribute technique (phase 1, step 2 ) resorted to ISDN-specific details. A clear separation between specification and implementation of the service is not given. While adapting the process to the specific characteristics of the services is present, the strong focus on telephone-based services and the associated functional model makes it difficult to transfer to multimedia services with a variety of different communication relationships.

The formality of the modeling languages used varies greatly. Non-formal descriptions, such as the informal service description in Phase 1, are complemented by semiformal modeling, such as attribute technique and formal descriptions with SDL diagrams. For the transition between the different types of description, the process offers little support. Formal rules for verifying the consistency of the various descriptions do not exist. An iterative approach to the development and subsequent modification of existing services are not supported by the process.

4.2.2 Intelligent network

As described in Section 2.3.4, is the "Intelligent Net "to a supplement of the telephone network for the flexible implementation of telephone-based services. in this connection can the individual services are composed of generic, functional components become.

For the development of services in the Intelligent Network, the ITU proposes in Recommendation I.312 [ITU92] an adaptation of the process described in the previous section. The necessary extensions concern in particular the finding of the service-independent building blocks (SIBs) and are described in Recommendation I.329 / Q.1203 [ITU97b]. In an eight-stage procedure (cf. 17 After the exact definition of the basic functions, these are compared with the existing service modules, from which the need to expand an existing module or to develop new modules can be recognized become.

Around the introduction Intelligent network and cooperation between Systems from different manufacturers and operators the ITU far-reaching standardization of various expansion phases Intelligent Network called "Capability Sets". The first stage ("Capability Set 1 ") [ITU93e] is aimed at services controlled by a central body be ("Single point of control ") and their individual service functions each relate to only one participant ("Single ended service feature "). For this Expansion stages, the ITU also sets the service modules used firmly. This ensures that service developers are independent of the execution platform used to be able to fall back on a uniform construction set from SIBs. At the same time it will but the range of variation possible Services restricted.

For the development of concrete services based on the service building model of the intelligent network, graphic service description methods have been established. Here, the service flow is described by the graphical linking of the blocks using a software tool [Sie01]. An example of such a graphical development environment shows 18 , The graphical representation supports the quick creation and recognition of the service flow. In order to complete the service logic, a large number of parameters generally have to be set for the individual blocks of the sequence graph for the configuration. However, this parameterization requires more detailed knowledge about the concrete implementation of the function modules and severely restricts the simplicity of the service development.

The Concatenation of functional blocks leads to a run graph to problems in describing services with a variety of communication relations, as a graphical assignment of functions to the individual connections of the service is not given and a parallel execution of features in this model can not be described. A Application of this originating from telecommunications technology multimedia and in particular multiple connections Services seems problematic [Fre99, Jur01]. The scope of possible Services is often due to the functionality of the components included strongly limited and is based on the features of the platform used limited. frequent Extend this functionality by modifying existing blocks or Add new building blocks is with high administrative overhead in the services used different versions of the building blocks [Kös97].

By the fixed reference to the building blocks of the implementation platform is a separation between specification and implementation of Services not given. An independent specification of service behavior is not intended and is not covered by the development process. Due to the formal specification of the service modules is a support by Software tools largely possible. Also can existing services are modified and further developed.

The described restrictions have recently replaced graphical development methods with more flexible methods based on general software development. Siemens AG is now using a flexible program development environment [Sie02], which enables the free development of service logic in the Java programming language. Single service function will continue to be provided as building blocks. The way of linking the functions to the flow logic of the service, however, the developer is free.

4.3 Development Processes from the field of software development

by virtue of of the high software share in the implementation of a service The question arises as to the applicability of procedures from the general software development to the development of services. In particular, in the software development in the last Time increasingly prevalent formal description languages Basis of the "Unified Modeling Language "(UML) [FS00, For02] are to be considered here. For the use of UML are a number of procedural models have been developed, of which the "Rational Unified Process "one has outstanding publicity.

4.3.1 Rational Unified Process (RUP)

With the advent of the object-oriented software paradigm, a number of formal and non-formal description languages have been developed in the late 1980's for representing the different views on object-oriented software. A large variety of co-existing methods with similar focus, but different notations emerged. It was not until the 1990s when three key method developers - Booch, Rumbaugh and Jacobsen - joined together at "Rational Software" and merged their methods that a single language, the "Unified Modeling Language" (UML), could prevail. In the following period, a number of other descriptive languages have influenced the further development of UML. The further development and standardization of UML is meanwhile handled by the "Object Management Group" (OMG) coordinated.

On Basis of the UML has the company "Rational Software "(meanwhile IBM) created a process model for software development - the "Rational Unified Process "(RUP) [Kru99, Rat01]. He should be in the context of development activities coordinate necessary tasks and work and manage facilitate the created artifacts. These artifacts are here With the description languages of UML developed models of the creating software system.

The application of the UML and the procedure of the RUP should ensure the timely and cost-effective creation of the desired software product. The RUP software development takes place in four phases, each of which is completed by an important milestone (see 19 ).

In the first named "Inception" Phase, the environment of the planned software product is analyzed. To this end, the underlying business model and the main players identified. The later main uses the planned software will be in first rough interaction diagrams with the help of "Use Cases ". The creation of a glossary and an initial project plan complements the first phase.

The now following phase "Elaboration" has the creation a well-founded architectural model and a precise project plan for the subsequent implementation to the goal. To support a first functional prototype the software will be created. A detailed analysis of the success factors and the specific risks of the project should be adequately Assess the project effort. To conclude the The second phase is a detailed analysis of the planned project instead, in which the match with the original ones Targets checked will and a decision over the realization can be made.

In The "Construction" phase will now be developed the necessary components of the software and to the overall system integrated. All functions and properties have to be extensively tested become. The management of the resources used and the control progress, costs and quality Software are important tasks in this phase. The third Phase ends with a first version of the finished software product including documentation, which will be handed over to the client can.

The The subsequent "transition" phase includes the introduction of the product at the client and possibly because of this experience gained necessary changes and extensions of the software product. It ends when the client is more satisfactory State of the software has been achieved. To develop a more extensive Version of the software can be anytime a new development cycle to be started.

In spite of of the sequential construction with the four phases supports the RUP the iterative development of software. The tasks of each Phases can to do this in iterative steps. Subsequent changes However, the requirements should be avoided and lead in the Generally for the start of a new development cycle.

to support In the process presented, the RUP offers a number of other tools. So be for the individual phases offered detailed work schedules which the ones to perform Describe tasks and the affected artifacts. By the description with work processes ("Workflows") can do these tasks be divided among the various necessary actors. Of the RUP distinguishes nine types of work processes, the For example, when creating the business model or testing the To deal with software.

As described at the beginning, the RUP builds on the modeling languages the UML on. The artifacts used in the RUP are therefore almost continuous described in UML languages.

to support In the process, the company "Rational Software" offers a comprehensive Software tool. This contains u. a. a knowledge database for the administration of the individual documentation and instructions of the procedure model. Here is the adaptability of the process to the specific requirements of the respective development project in the foreground. Also a set of tools to work with UML and the development of the program code is included.

By its general orientation is the RUP not specific to the development adapted by I & K services. Due to the explicit possibility to modify the process, such an adjustment appears possible, but with a big one Effort connected. So provide the used description languages The UML does not have any service specific elements which are efficient Use as part of service development. One Another disadvantage of the RUP is the insufficient separation between specification and implementation of the product. Already in the early "elaboration" phase of the process a functional model of the planned product is designed which if possible the Core of the subsequent implementation. Creating however, purely functional prototypes are also allowed allowing an explicit separation of specification and implementation a service by the user seems possible.

4.3.2 Model Driven Architecture

One Disadvantage of classical software development procedures is that the Explicit notation of a specification often considered too time consuming is seen. Many programmers keep creating models for secondary and see only in the generation of program code a productive Project progress. The knowledge about the structure of the developed system is located exclusively in the heads the involved programmer. Also a subsequent writing down this Knowledge usually disappears. The disadvantages of this approach will be later visible when errors are fixed or changes are made to the program code Need to become and the structural knowledge of the programming team has been lost or the team has changed.

In spite of This largely known problem is such a procedure still common encountered. Cause for this In particular, there is the lack of compelling link between specifications and the developed code. Models and specifications usually have only descriptive character. Despite a possibly initial Generation of code fragments from the specification usually exists a clear media break between model and implementation. Frick [Fri95] speaks in this context of a structural break, as the information from the specification in the context of the system design must be interpreted and reworked. This often leads to a recognized and accepted deviation in the design of the specifications of the specification. In particular, at later changes of the system concept in the course of progressive code development the necessary adaptation of the specification documents is usually neglected.

This is the starting point of a process model called Model Driven Architecture "(MDA), currently being developed and standardized by OMG [MM01, MM03]. The focus of MDA is on the specification of the system through models. It is crucial that both the used Models as well as the mapping rules between the models formally must be defined. The writing of program code is as far as possible in this approach possible be replaced by the development of models [Fra03].

A clear separation between specification and implementation is achieved by defining two different types of models. Platform-Independent Models (PIMs) describe the structure and behavior of the planned system while avoiding all implementation-specific details (cf. 20 ).

to Implementation of the specified system then becomes a selected suitable platform. Another formal model ("Platform Specific Model "- PSM) the implementation of the system on the chosen platform. The illustration of the PIM on the chosen one PSM is supported by a suitable set of rules, which a verification of the developed implementation model in relation allowed on the specified system. For the implementation of the platform-specific Model in the for The platform necessary code is intended to be the formal definition of the PSM enable extensive automation.

The clear separation between platform-independent specification (PIM) and Platform - Specific Implementation Model (PSM) should be a Implementation of the specified system on different platforms enable. In addition to the reusability of the specification, the formal Foundation of the pictures the consistent system behavior independent of ensure the platform used.

So far necessary to implement a system even on a Combination of multiple platforms are used. The PIM is here in different parts on the different PSMs displayed. The necessary interactions between the used Platforms are modeled using PSM bridges [KWB03].

central Part of the MDA are the models used. A model poses the abstraction of a real system from a given point of view The respective abstraction of the real system can be the Function, structure or behavior of the system [MM01]. For The formal definition of a model must have syntax (form) and semantics (Meaning) to be well defined. They can be supplemented by rules for Analysis or review of internal consistency of a created model. The defined syntax can be graphic as well as textual, but must be hard Formality criteria sufficient to enable automated processing by software tools. The semantics is often subject to a certain blurring and can either through the relation to things of the real world or by reference to elements other formal languages [MM01]. The OMG proposes as a description language for the Notation of PIMs and PSMs the use of UML before.

While formal Models (mostly based on UML) also in traditional software development processes MDA is characterized by the formalization of the Illustrations between the models used. This concerns before all the picture of the PIM on a PSM. An automatic code generation out of formal models, such as an SDL model, is partially already in use. The transformation of a However, specification in an implementation model is currently, such as described above, mostly made by hand. By the formal Definition of transformation rules, the MDA wants a tool-aided implementation here enable. The formal transformation rules should further the consistency from PIM and PSM over ensure the entire development process. Here is however, to take into account that a fully automatic implementation of the PIMs into a PSM due to the different levels of abstraction is generally not possible. A manual intervention in the transformation process or a subsequent Modify and complete The generated PSM is necessary because the PSM does not have all the information may contain in the context of possible implementations too to answer appropriate decisions. In a fully automatic Implementing the PIM into a PSM and then into the necessary code would be one Separation of abstraction levels between PSM and code useless, because the entropy of the developed system through the automated Implementation does not continue to increase (see section 3.3.1). The most extensive Formalization of the individual development steps frees the developers By contrast, largely of automatable work and allows the Concentration on the concrete characteristics of the to be developed System.

By the clear separation of specification and implementation allowed a use of MDA in the development of I & C services the implementation of a once specified service on a variety of different platforms. The tool support and the formalized mapping rules allow a fast prototypical development and represent the consistency of the system also with later changes and further developments.

While the structure of the MDA represents a good implementation of the concept of abstraction levels, It should be noted that a concrete implementation of the process proposed by the OMG has so far been realized only to a limited extent. The necessary models and tools are not available to a sufficient extent. A corresponding development, however, is driven by the OMG. The favored description language UML is very software-specific. For the use in the development of I & C services for the creation of a PIM, the UML is only limited, since it does not provide service-specific concepts (see also Section 4.3.1). Even the way how the developer should develop the complete specification of the platform-independent model (PIM) from the initial requirements is still only vaguely addressed by the MDA. Reference is made to the existence of conventional methods, although their applicability to creating the formal model remains open. The early stages of the development process are therefore insufficiently supported by the MDA.

4.4 Research Projects to service development processes

A Series of research papers and projects has evolved with service development employed from different views. Often, those developed in the field of software engineering formal description languages on their applicability to service development examined. The following is a selection of such research presented and compared. Here, their suitability for development from I & K services assessed in terms of the criteria set out in section 3.5.6.

4.4.1 RATS

A size Difficulty in the service development method recommended by the ITU (Section 4.2.1) and many other development methods is the Implementation of the initial, informal description of the proposed service in a formal Specification. Due to the non-formal nature of the first description can For this purpose only limited (formal) rules and assistance are given become. Eberlein [Ebe97] strikes for this Phase of the development process with his "Requirements Assistant for Telecommunications Services "(RATS) a methodical approach. It is based on parts of the the ITU proposed development method and tries this in the implementation of the first requirements in a full, formal Specification of the service to support.

The Process model distinguishes on the way from the first, informal description of the formal specification the three dimensions Completeness, Refinement and formality, where development can progress.

The Dimension completeness ("Completeness") trying to ensure that all necessary parts are present in the specification and no gaps remain. For this purpose, the description of the desired service behavior in divided into three steps. First In the first step, the normal behavior of the service is described. This includes the behavior of the service, which is the usual Process is the same as service and user behave as planned and no peculiarities occur. The next step will be this Behavior around possible alternative processes added. This includes all functionalities in addition to the normal Alternatively, behavior can be performed in the service. in the third step is the behavioral description of the service the possible ones faults added, the one to actually unwanted Conduct behavior of the service. All developed behavioral descriptions are in a final step the completeness dimension assembled to a global description of the complete service behavior.

The Dimension Refinement ("refinement") is oriented the recommendations of the ITU on the development of services in the intelligent Network (Section 4.2.2) and consists of three stages. It is the Service in individual functionalities ("service features "), the then on off-duty Blocks (SIBs) are mapped. For these service-independent components RATS tries to break away from the rigid definition of ITU enable a more flexible application of the block concept. You need to therefore not necessarily existing building blocks of the implementation platform used but rather provide generic specification building blocks An implementation of the specification appears on other platforms therefore possible in principle.

The formality dimension supports the increasing formalization of the developed specification, starting with a non-formal, textual description of the planned service by the client, and the subsequent requirements are then classified according to different criteria The descriptions of the service behavior are developed with increasing formality in three steps: the first textual descriptions become uniform structured and then transferred into a special formal procedure description. The final step of the formality dimension is the implementation of the formalized procedure descriptions in SDL diagrams.

To Eberlein should look at the temporal evolution of the service specification preferably evenly extend all three dimensions. To support this approach there the author describes and describes the structure of the artefacts to be created the actions to be performed in each step. By the multiple use of ITU methods, such as attribute technique, is the variety of possible Destination services limited to telephone services. A universal description for multimedia I & K services will unsupported.

One greater The focus of the RATS process model is the management of the requirements, which are created in the course of the service specification. By a Chain of requirements for origin and impact can with subsequent changes and extensions to the consistent context of the entire specification be restored. A software tool described in [Ebe97, EH97] intended to handle the method by managing the artifacts and facilitate the methods to be used.

4.4.2 CoCoN

The full Formal specification of a service was and is the subject of a Series of research projects. In many of these projects that is Objective of the formal specification avoiding the in section 2.3.5 described undesirable Service Interactions ("Feature Interaction ") the formal specification of the complete system behavior the impact of new services can be determined on the overall system.

Next Consideration of the interaction issue may require such formal service specifications but also the starting point for form the implementation of a service. A large part However, research on the formal service specification dates back to from the field of telephone networks (for example [Eti95] or [Zav99]). These works can therefore difficult to transfer to the heterogeneous platforms of I & C services become. As an example for the comprehensive formal service specification is hereafter the project "Provably Correct Communication Networks "(CoCoN) [Kle96, Kle97a, Kle97b]. The procedure proposed here can be general for the development of distributed systems is applied and is not limited to telephone networks. Although it is for Any distributed systems can be used, it is from the authors for the specification of I & K services especially highlighted.

The The goal of CoCoN is to extend extensions of an existing system as far as possible perform simple and verifiable to be able to so that the original one functionality trouble-free preserved. The iterative supplement and further development of an existing system is thereby supported.

starting point are the requirements to be made to the system which are collected and not written down formally. All requirements, which describe functional properties of the system are then formalized. This is done using a special kind of flowcharts called "trace diagrams". they allow a formal, graphical description of desired possible system sequences.

The Specification of the system to be developed is using finite Automata performed. to The more complex system behavior becomes the finite automata supplemented with local variables. For this purpose, a specification language "SL" developed in the project ProCoS ("Provably (Correct Systems") is used for linking and hierarchical arrangement of machines facilitates the structural Development of the system. By suitable mathematical procedures In CoCoN, the formal system specification can be checked for "deadlock freedom" and "freedom from divergence". A "deadlock" describes this a state of the system in which due to an internal blockage no further communication and thus no further course of the service possible is. By the "deadlock" can be guaranteed be that the system can not get into a state in the system is no longer capable of further reaction. The divergence describes the occurrence of a delimited section the system functionality, in which an internal communication of the system takes place, change of state So continue to take place, however, an intervention in the process from the outside not possible anymore is and thus no longer influences the behavior of the system from the outside can be. The distinction between "inside" and "outside" is subject to the definition by the developer.

Further analysis allows CoCoN to ensure that the specified system meets the functional requirements formalized in the trace diagrams. According to the developer this is to be started with a simple basic system, which is then refined and expanded. The application of special transformation rules in this iterative development ensures that the already developed system functionality is not destroyed by the extensions and the deadlock freedom can still be guaranteed.

By the formal analyzes can with the gradual development of the whole system the fulfillment of the Requirements and safe operation are largely guaranteed. These possibilities However, the price of the complete, fine-grained behavioral specification of the system. For a unified, over is a system used and developed over a long period of time this approach is a viable option. For the heterogeneous environment of the Provision of I & C services this procedure appears only partially suitable. Also, some can The components used here are difficult to model by automata become.

By the very early Including concrete system components is a platform-independent system specification not possible with the presented procedure model. Already the formalized in the Tracediagrams Requirements describe concrete communication processes of the Systems and can therefore only limited for different implementations are used.

4.4.3 FRIENDS

a model-based approach to service development has the project "Framework for Integrated Engineering and Deployment of Services "(FRIENDS) [TQ01a, MBB00]. The concept of service here is very far including all component-based software systems, with which an external user interacts. The focus of service development is based on the compilation of the finished service from software components. The target platform can be chosen relatively freely. In the FRIENDS project are used to split the components concepts of TINA (section 2.3.3). To model the components is a separate Component model called Distributed Software Component "(DSC) used [VBM00].

in the Focus on the development of a service in the FRIENDS project the specification of the desired Behavior with the modeling language AMBER ("Architectural Modeling Box for Enterprise Redesign "). AMBER is a description language for business processes and was developed by Telematics Institute in Holland develops [EJL + 99].

to Modeling the different aspects of business processes AMBER distinguishes three levels. An actuator model (level 1) provides the different actors and their relationships to each other. In behavior diagrams (level 2), possible processes can be linked by concatenating Actions are mapped. The artifacts used in the business process are modeled as elements (level 3). For AMBER exists a graphic Presentation form and a semantic model, which is the formal, tool-supported analysis the modeled business processes allows.

in the FRIENDS project will be the actuators of AMBER for the modeling of each used on a service components. The interfaces between the components are through the interaction relationships shown. The items to be executed on the elements of the service Actions are described with the behavioral diagrams. The formal Model of AMBER allows the global consistency of a concrete Check modeling.

For the development of the service beats FRIENDS a multi-step approach before [TQ01a, QSP99]. In a Specification phase will be the desired Behavior of the service. FRIENDS gives no further Assistance, but refers to common methods. Goal of the following Design Phase is an AMBER model of the complete service.

For this is using a system of a single, unspecified Component started, which identify the desired service behavior to the outside should. By refining the necessary functionalities and By grouping the functionalities into components one can developed component-based model of the desired service become. In this case, a recursive change of the model should be possible largely compatible with existing software components be developed.

By comparing the necessary function blocks with the existing blocks and their properties, a decision can be made about the effort required to implement the service [TQ01b]. Missing building blocks can be redeveloped or purchased during the implementation phase. The development process concludes with extensive testing of the implemented service. By monitoring individual processes of the implemented system, compliance with the specified model can be verified.

By the adaptation of the sub-functionalities of the specified service to the skills the existing software components is a clear distinction between Specification and implementation of the service is not given. For the implementation an already implemented service on a new platform with other components is therefore a revision of the specification necessary. The absence of formal mapping rules between the different levels of abstraction complicates a subsequent change the specifications and the rapid development of prototypes as part of an iterative approach. Within each phase However, this is due to the gradual refinement of the developed System model an iterative approach to the development possible. By the broad focus and poorly adapted to I & K services Description language AMBER will be the specific characteristics these services only inadequate supported by FRIENDS. Suitable building blocks and templates must be used for the respective purpose be redefined.

4.4.4 SCREEN

The Project "Service Creation Engineering Environment "(SCREEN) [Scr99, DMC + 98] is part of the fourth EU Framework Program Advanced Communications Technologies and Services "(ACTS) is the support the development of innovative communication systems and services the cooperation of science and industry.

The The goal of SCREEN is to provide a tool-supported service development process, to create more diverse Services is suitable. The focus of the project is on the Extension and merge existing technologies into an integrated, tool - supported process for component-based service development. Also the practical use The methods used in field trials are part of SCREEN.

As a target platform for the later implementation of the services, SCREEN envisages various distributed platforms such as TINA (Section 2.3.3), CORBA or typical Internet service platforms. One focus of SCREEN is on the use of components in service development and especially the reusability of these components. For the service development process, SCREEN proposes a five-phase process ( 21 ).

In the first phase ("Requirements Gathering and Analysis ") will work together with the client to meet the requirements of the new Service collected. The initial textual, non-formal requirements are classified and on ambiguities, gaps or inconsistencies are investigated. The found requirements become now gradually formalized. First, the possible Interactions of subscribers with the service described by UML "use cases" static structure of selected Parts of the service may additionally be presented with class diagrams. With the help of flowcharts ( "Message sequence charts ") can more complex interaction patterns are formulated. The view of the user to the service is clarified by creating a prototypical user interface. The techniques proposed for this include Visual Basic, Java, Tcl / Tk and HTML.

If structured the planned target platform according to the TINA concepts SCREEN provides for further detailing of the first phase. This consists in the illustration of the service on the TINA business model and in adapting the created documents to those used by TINA Concepts (for example, the session concept).

In the second development phase ("Service Analysis") of SCREEN created a first component-oriented model of the service. For this, the functionalities to be provided by the service are structured and assigned to the respective actuators. A static model describes the components required in the service and their relationships to each other. The chosen one Partitioning the service into components happens from the viewpoint of the developer. It should adhere to the functional structure of the Service and not based on the form of the later implementation. However, specific component concepts of the implementation platform may already considered become. The dynamic behavior of the service is due to the refinement the flowchart completes.

In the following phase ("Service Design ") that will be rough component model of the service through the use of implementation components refined. The goal is to create a complete component model Implementation-specific building blocks. The dynamic behavior the chosen one Components are specified with SDL diagrams. As description The interface between the components becomes the "Interface Description Language "(IDL) used.

In a separate phase ("Validation and simulation ") The generated model of the service is extensively tested and verified. The Simulation of the modeled service allows validation that the originals Requirements of the client to be met by the service. Gaps and errors in the specification are to be detected at this stage and be eliminated.

In the fifth and last phase ("DPE Targeting ") Development process will now be necessary for the execution platform Code generated. By the formal modeling of the previous ones Phases is in many cases a largely automatic code generation possible. Then you can the developed service is installed on the target platform and in Operation.

As described, SCREEN places a great emphasis on the component-based Development of services. Here are two types of components distinguished. For the use on a high level of abstraction become "Customer Components "defined. These describe function modules of the later service and are supposed to be similar to the SIB model of the Intelligent Network (see Section 2.3.4), a graphical modeling of the service by the client. For the implementation-related Layers become "Developer Components "defines correspond to the real software components. As part of the implementation of the service, these components are used by the developer.

to Evaluation was in SCREEN the developed process model in several Field tests used. As a development environment for the concrete Usage beats SCREEN two variants based on two commercially available Tools (ObjectGEODE and SDT). This is used by the standardized description languages. Since the used However, description languages (UML, SDL, IDL) are not native SCREEN sees a central role in providing service-specific elements Filing once created components before going on to this in later service developments To fall back on to be able to.

Of the high degree of formalization of the presented procedure model allowed next to the tool support also an iterative approach to service development. A clear one Separation between specification and implementation is in the process not given, since early Platform-specific structures in the development of the service model be included. This complicates the implementation of one already created service on a new platform.

4.5 Summary and discussion

The explained Methods and methods are to be given as typical examples in the Service development procedures used with their specific Introduce features. The following table 4.1 summarizes the following assessment carried out in section 3.5.6 the presented method together.

Tabelle 4.1: Vergleich der vorgestellten Methoden und Verfahren

Table 4.1: Comparison of the presented methods and procedures

• - Requirement is not fulfilled
• o Requirement is partially fulfilled
• + Requirement is fulfilled
• 1) Limited on services in the telephone network.
• 2) Must be ensured by the user.
• 3) formality in the process flow.
• 4) within each phase, not across processes.
• 5) Service-specific blocks must first be created.

It shows that almost all development processes presented support an iterative approach to development. Purely sequential processes have in the past been considered too rigid for development of software, since there are many requirements to be developed Often only concretizing the system in the further course of development. In many cases The client can only meet his requirements after the development clearly recognize and express a functional prototype. This is synonymous with services Often the case, since the desired Dynamic behavior is difficult to describe informally with text or drawings leaves. In such descriptions is usually only the typical behavior of the service, whereas atypical modes of application or error cases only in later Development phases taken into account become.

The extensive use of formal description languages in the examined Development processes is probably less on the increasing Attributed to these methods as rather, the selection made here of the one to be compared Procedure, in particular the use of formal methods in the Service development The subject of the present work is. In many The presented methods are scientific results Research. While Strengthen the formal description languages in the field of research Received encouragement, they are used by the industry for real development processes are still cautiously taken up. In many make must increase efficiency through the use of formal description languages still be occupied in practice.

The starting point in most of the processes considered is the collection and analysis of the requirements placed on the service to be developed. A consistent process with a direct link to the process of brainstorming can not be found. As creativity is at the forefront of this process described in section 4.1, rigid involvement in a formal development process will not be effective. Nevertheless, the process of brainstorming in individual areas can be aligned to the requirements of the subsequent development process, to a transfer to facilitate the requirements in the formal development process. Thus, for example, formal "use case" diagrams can be used in brainstorming, which are then taken over into the development process.The service properties gained through a Morphological Box can also be used later in the development process, for example, by ITU attribute technology (see Section 4.2.1 ) continue to be used.

The Extension of the procedures for the implementation of a specified service on a new execution platform is in most cases possible. Only where developed with regard to a specific platform example, the SIB-based method for the intelligent Network (Section 4.2.2), use on other platforms is made more difficult. Many of the considered methods, however, relate very early In the development process specific details of the later implementation platform one. In these cases is the afterthought Implementation of a finished service on another Realize platform only with great effort. For the efficient Implementability of the specified service on different platforms is the clear distinction between specification and implementation an important condition, but only part of the procedure satisfactorily fulfilled becomes.

The biggest deficits with regard to the criteria set out in section 3.5.6 However, the investigated methods with regard to their specific Fitness for I & C services. For the procedures outlined in section 4.3 general software development, this is understandable, because their goal is just the universal applicability. But also the service-specific development processes are either aimed at one specific type of services (eg telephone services) or offer only a few concrete aids (eg service-specific building blocks) for Description of I & K services. Generic formal description languages, such as UML know No service-specific concepts such as "user", "device" or "communication channel." For effective and easy use of these languages to describe services have to Such building blocks are created. That such building blocks so far are only partially to be found, should also be conditioned by that the concept of the I & C service described in section 2.1 is still is relatively young.

The Analysis of the presented method has shown that no procedure all about a successful I & K service development process equally fulfilled requirements. The procedures included however, a number of important approaches and concepts for service development can play a major role. So For example, the concept of Model Driven Architecture (MDA) offers a good one Approach for the Separation of specification and implementation. An application However, this concept of service development is still pending. The aim of the present work is based on existing concepts developing and adapting an efficient, create a service-specific development process for I & C services.

5 Overview of the developed process

The previous analysis and evaluation of the presented development methods has shown that the evaluation criteria explained in section 3.5.6 for one successful development process for I & C services from existing procedures only partially fulfilled become. In particular, the clear separation of the specification of the desired Service behavior of the implementation is only a few procedures supported. It should also be noted that a specific orientation procedural models to the development of I & C services so far only inadequate took place.

The In this work described development process "MEMICS" Model-based Engineering Method for Information and Communication Services) was in view designed with the special requirements in mind I & K services, as defined in Section 2.1.2. It sees a clear separation between the specification of the desired Behavior and the implementation of this service at different levels execution platforms in front. The models and description languages used in MEMICS are specially adapted to the characteristics of I & K services. The goal is that Provide a unified, end-to-end process in which everyone seamlessly interlocked description languages without media breaks.

The This chapter gives an overview of the method described in this work. The ones used in MEMICS Concepts are based on the ones outlined in section 3.4 Success factors of development processes presented.

First, the abstraction levels used in MEMICS are explained. Subsequently, the properties of the description languages used in MEMICS are summarized. This includes as well an explanation of the chosen procedure for the definition and notation of these description languages. The presentation of the individual steps of the procedure model shows the basic procedure for the development of services with MEMICS. A detailed explanation of the models, languages and mapping rules of MEMICS is contained in the following two chapters.

5.1 abstraction levels

In MEMICS, a clear distinction is drawn between the specification of the desired service and the subsequent implementation of this service by the implementation on one platform. For this, the in 22 Three abstraction levels are defined, which are based on the concept of "Model Driven Architecture" presented in Section 4.3.2.

In the top level, the specification level, becomes the desired behavior of service - d. H. what the service should do - described. For this purpose, an implementation-independent model of the service is developed. Components of this model are in addition to the participants in the service used communication channels and the above exchanged media. The model serves as a specification of the required Properties and the desired Behavior of the service. It describes the service from the viewpoint the participant and sets the perceived behavior of the participant Service. This specification completely abstracts from all the details of a technical implementation. Because in the specification level no implementation-specific details are included is one Implementation of a once specified service on different Way, for example on different platforms possible.

In The implementation level will now describe how the desired behavior of the service is realized by a concrete implementation. The concepts used to describe the implementation are on the type of chosen Implementation platform dependent. For one concrete platform must have a specific model of usable platform components to be created. These components can be, for example, a web service module to send an email or the functional building blocks ("SIBs") of an IN platform.

In This work will be an implementation model for distributed, component - based Service platforms with central service control presented. It is based on the application on an existing, prototypical service platform explained. For others Platform types need created appropriate implementation models within the framework of MEMICS which take into account the platform-specific features.

In The implementation level will be based on the chosen platform model Created model of the implemented service. Several different ones Implementation models for Different service platforms may be at the implementation level coexist and different implementations of the describe the same service.

component the lowest level of abstraction - the coding level - are the for the elected Platform to set up the service necessary artifacts. These generally include program code, database structures, user interfaces, etc. Their concrete design depends on the platform used. by virtue of formal, platform-specific modeling at the implementation level is a largely automated generation of these code artifacts possible from the implementation model.

By the clear separation of specification and implementation of the service can be a once-specified service on different platforms be implemented without changing the specification must be made. This procedure allows that specification and implementation of different people, for example, a service provider and an external service developer, carried out can be. The formal specification can ensure that that is a specified services provided by different developers is implemented on different platforms, in all implementations behaves the same way.

5.2 description languages

The central core of MEMICS is a description language - the Universal Service Description (USD) - for formal specification of the characteristics of the desired service. It is the tool in the specification level and is used there for the notation of the implementation-independent service specification. This USD-based service description is the starting point for the implementation level and, as a formal requirement description, forms the framework for the subsequent possible implementation tions of service.

In the procedure model for implementation proposed in this thesis a service on a component-based platform becomes a used further description language. The "Service Platform Component Description "(SCD) allows the formal description of each element of the platform, the can be used to create an implementation. The Blocks described with the SCD can become a model of the technical Implementation be composed and describe the structure the technical system with which the desired service is realized. Due to the formal basis of the SCD, newly added components can be added the technical platform in a simple way in the Development environment are integrated.

5.2.1 The "Universal Service Description "(USD)

One The main problem of development projects is the different one Experience horizon of client and developer [BEP + 00]. During the Client has extensive knowledge of the application environment, he rarely has deeper knowledge about the technical realization of the desired system. The developer again, the technical environment knows in detail, but usually has only inaccurate notions of the application environment. The resulting lead to different perspectives often to communication problems and misunderstandings in the determination of the desired Development Goal. Finding a common language is particular in service development difficult as the planned service only inadequate Express with texts and pictures leaves. With the "Universal Service Description "(USD) In this work, this is a specific one for the specification of I & K services Language proposed.

The Objectives of "Universal Service Description " to compare with those of an architect's plan in the field of house building. This plan tries the wishes and requirements of the client in a given, uniform Format to describe. The blueprint of the architect serves here on the one hand the communication with the client, putting him in one graphic and easy to understand Way describes the house to be built. The later appearance and the characteristics of the planned house are defined in detail by the plans and visualized. Through the uniform and well-defined form provides on the other hand, the architect's plan is the normative specification - the "specification sheet" - of the house to be built Different contractors can based on this plan create the house and for this purpose different methods and procedures use. The plan forms the basis of the contractual agreement between client and contractor.

such fixed formats for Requirement descriptions are common in different areas (eg design drawings in mechanical engineering). They are clear adapted to the specific characteristics of their application and provide prefabricated constructs for those frequently used in this field Elements. A formal, standardized definition of their shape allows the Passing on a created specification and the clear interpretation by different readers avoiding ambiguity. In the field of development of I & C services is currently a comparable, service-specific description language not common. The "universal Service Description "(USD) was designed to fill this gap to fill.

The USD provides language elements for easy description of the functional and non-functional requirements to an I & K service from the perspective of the participants of this service. It offers ready-made Templates describing the objects that constitute the service. This includes in particular the participants of the service who used Communication channels and the transferred ones Media. Based on these templates, language elements can be defined Be used in a variety of service descriptions can be.

By the strict alignment of the USD with the interests of I & K services They provide the user with extensive support in the creation of a Service specification. The specification of the usable language elements and the formal definition of the way of their use helps to avoid ambiguity in the specification. The formal Definition allows Furthermore, a review of Specification for completeness and internal consistency. These properties allow a service specification based on the USD as the basis of a contractual agreement for a to be developed service to be developed.

The abstract service description does not contain specific details of a later technical implementation of the service. It is independent of the systems used for implementation and platform to shape. A service specified with the USD can therefore be implemented on different platforms.

For the presentation a USD-based service specification became a machine readable Text format based on XML. A creation and Further processing of specifications with software tools made possible thereby. To the easy grasping of the specification by humans too support, This textual format is represented by a graphical representation added.

5.2.2 The "Service Platform Component Description "(SCD)

By the heterogeneity of the networks used described in section 2.3.1 changes those in the field of I & K services used technical building blocks and systems frequently. Often a new one can Service not realized with the functions of an existing system become. In these cases have to existing system components are extended or new components added. The possibility flexible expansion with new building blocks is an important feature which must fulfill the platform used.

however not just the execution platform The addition allow new components, but also in the context of implementation methods used and in particular the software tools used have to with a changing one Functionality of the platform can handle. New components must therefore not just the platform, but also the development environment easy added can be.

To For this purpose, a description language was used in the present work for the individual elements of a component-oriented service platform - the "service Platform Component Description "(SCD) - developed. The used elements are divided into terminals, networks, media and additional devices. With the SCD can the respective properties of the existing elements are formally described become. The format used is based on XML and is therefore machine-readable. Suitable development tools can read in new elements and offer the user to create an implementation. This The procedure should be self-development and the purchase of new components support, by a product to be created or supplied with the purchase of the component Description document based on the SCD the correct use of the Component in the implementation phase.

5.2.3 The definition of Description languages

In Section 3.4.2 discussed the benefits of the formal definition of Syntax and semantics of a used description language in contrast to non-formal descriptions. Not addressed However, the question was how a formal description language is defined can be, so syntax and semantics clearly and intelligibly set can be.

The connection between Model and language

his system description created in a particular language a model, that is an abstract representation of reality real system is considered from a specific point of view. The chosen one Perspective determines what specific characteristics of the system expressed in the model and what details of the real system in the model are neglected. By neglect the details that are unimportant from the specific point of view can be one Model can generally be met by a variety of real systems.

The Descriptive language, in turn, is the means to the created model express and write down. So it's first to distinguish between a model and the description of this model in a chosen one Language. One and the same model can be different Languages are described.

When working with models, the shape and structure of these models are often defined only by specifying the form (syntax) of a used description language. This can be determined for example with the Backus Naur Form (BNF) [ML87]. It determines which keywords are allowed in the language and which arrangements (sequences) of the keywords and data are allowed. The structure and form of the models thus described is thus only implicit and difficult to understand. The explanation of the meaning (semantics) of such models is often made only by way of examples. System models that are described with such defined languages, implemented in their interpretation more field-specific knowledge of the developers ahead. The use of such a description language is therefore only helpful if there is agreement on the way in which it is used among the participants.

For a uniform and cross-developer Use the descriptions created in a development process have to Form and structure of the models used are formally defined. The meaning of the models can then be based on the formal model definition explained become.

Definition of the structure of models

• • M0 (Instanzen): Diese Ebene enthält die realen Systeme. Es handelt sich hier um die konkreten, spezifischen Instanzen. Im Bereich der Systementwicklung kann es sich hier beispielsweise um ein bestimmtes Bestellsystem X handeln. Die Ebene M0 enthält die Hard- und Softwareelemente, aus denen dieses Bestellsystem besteht.
• • M1 (Modell): In dieser Ebene stehen die Modelle, welche die realen Systeme der Ebene M0 beschreiben. Ein Modell aus M1 legt daher fest, wie die zugehörigen konkreten Instanzen der Ebene M0 aussehen können. Ein Modell des Bestellsystems enthält beispielsweise eine Definition für die vom System verwalteten „Kunden" und die bestellbaren „Produkte". Dieses Modell kann beispielsweise in einem UML-Klassendiagramm niedergeschrieben werden. M2 (Metamodell): Die Ebene M2 enthält das Modell des Systemmodells aus Ebene M1. Ist das Systemmodell aus M1 durch ein UML-Klassendiagramm beschrieben, so beschreibt das UML-Metamodell aus der Ebene M2 das Aussehen eines Klassendiagramms im Allgemeinen. Für die UML ist dieses Metamodell in der UML-Spezifikation festgelegt, welche in der aktuellen Version von der OMG publiziert wird.
• • M3 (Metametamodell): Betrachtet man die Elemente der Ebene M2, also das Modell eines Modells, so stellt sich die Frage, wie ein Metamodell festgelegt werden kann. In naheliegender Weise geschieht dies wiederum durch ein Modell. Die OMG schlägt hierzu die „Meta Object Facility" (MOF) [OMG02] vor. Es handelt sich dabei um eine Sprache, welche die Definition von beliebigen Metamodellen ermöglichen soll. Mit der neuen Version 2.0 soll auch die UML zukünftig durch ein MOF-Modell definiert werden. Um die Zahl der Ebenen zu begrenzen, legt die OMG des Weiteren fest, dass Elemente von MOF nicht durch eine weitere Ebene definiert werden, sondern mit Hilfe der MOF selber beschrieben werden.

The question now is how to define the specific characteristics and perspectives of a model. Here, a model is to be created, which describes how valid models of the desired way look like. Such a model of a model is called a meta-model. It describes the structure and properties of all system models that satisfy this model approach. Such a procedure is also used by the OMG and used, among other things, to define the UML. The OMG approach is divided into four levels called M0 to M3 [OMG02, KWB03]. The meaning of these levels is defined by the OMG as follows:

• • M0 (Instances): This level contains the real systems. These are the specific, specific instances. In the area of system development, this can be, for example, a specific ordering system X. Level M0 contains the hardware and software elements that make up this ordering system.
• • M1 (model): This level contains the models describing the real systems of level M0. A model from M1 therefore determines what the associated concrete instances of the M0 level can look like. For example, a model of the ordering system includes a definition for the "customer" managed by the system and the "products" that can be ordered. For example, this model can be written down in a UML class diagram. M2 (meta-model): The level M2 contains the model of the system model from level M1. If the system model from M1 is described by a UML class diagram, the UML meta-model from level M2 describes the appearance of a class diagram in general. For the UML, this meta-model is specified in the UML specification, which is published in the current version by the OMG.
• • M3 (Metametamodel): Looking at the elements of the level M2, ie the model of a model, the question arises, how a meta-model can be determined. Obviously, this is again done by a model. The OMG proposes the "Meta Object Facility" (MOF) [OMG02], which is a language that will allow the definition of any meta-model, and with the new version 2.0, the UML will be replaced by a MOF model In order to limit the number of levels, the OMG further determines that elements of MOF are not defined by another level, but are described using the MOF itself.

The Use the MOF to explicitly define a metamodel a number of advantages over an implicit, unscripted model definition. So facilitates the uniform and standardized definition of this understanding and work with the created models. Based on the metamodel can be clear Mapping rules for set the notation of the models in a description language become. Are there multiple pictures in different description languages, Thus, the underlying meta-model may be the consistency between make sure of the different pictures. Also the transformation of a model in an associated one A different view of the real system is modeled by the common definition the associated Metamodels based on the MOF facilitates, since the relationships, the exist between the elements of the two points of view on the Level of meta-models can be defined [KWB03].

Use of the OMG model levels in the service specification

If one uses the OMG procedure to define a new service specification language, a meta-model for I & C services (hereinafter referred to as "MEMICS service meta-model") must be created using the MOF (level M3) (see 23 ).

This service meta-model (level M2) determines from which elements a service model exists as part of the specification of the service with MEMICS and how these elements can be used. A concrete service model as a specification of a planned service based on the service meta-model is part of level M1. To define a notation form for these service models at level M1, a mapping rule between the service meta model and the definition of a description language can be specified at level M2. This mapping rule defines how service models of level M1 in the USD can be expressed. The service meta model and the defined description language USD for notation created service models are the basis of the specification level of MEMICS.

A service specification of level M1 can be realized in MEMICS by various implementations in level M0. The procedure for creating a realization depends on the chosen implementation platform. In this thesis, a procedure for the realization of the service on a component-based service platform is presented. For this approach, a model-based approach is again chosen, in which the creation of the implementation model is supported by a meta-model. The explicit, formal definition of the metamodels used in the specification level and the implementation level with the help of the MOF also makes it possible to explicitly specify the mapping rules used between the levels ( 24 ). These rules can be used to verify that the implementation created represents a correct implementation of the specified service.

For the definition of the MEMICS service metamodel appears in Chapter 6 Diagrams Based on MOF version 1.4 [OMG02]. Also the implementation meta model for the The service platform used in this work is included in Chapter 7 Help defined by MOF diagrams. The charts of the MOF are it is a limited one Variant of UML class diagrams. The restrictions apply in particular Associations that can only be binary in the MOF, ie only connect two classes. Association classes and UML templates are not used in MOF. An overview of the MOF notations used in this work are in the Appendix A.

The Consistency rules for checking whether a created implementation model provides a correct mapping of the Service model is used together with the implementation meta model in chapter 7.

5.2.4 Data formats for description languages

Next the formal definition of the underlying system description However, models are also formats for the notation of these models set. In addition to text-based formats win in particular the graphic notations become more important as these in general by humans as clearer be assessed and thereby be detected faster.

The Service specifications created using the MEMICS service meta model on the one hand, the specified service behavior for humans easy to understand represent. Because these specifications are also for discussion of the planned Serving with clients is intuitive understandable Notation form necessary. For this purpose, a graphical representation is available at. On the other hand, the created specifications are the starting point the subsequent, tool-supported implementation of the service be. The created specifications must therefore also by software tools can be read and understood. For this purpose, a machine-readable format must also be defined become.

The components of the execution platform used in an implementation model have to in particular read by suitable development tools and can be processed. Here, the machine readability is clearly in the foreground. The Component descriptions need however created by humans and used in the implementation so that here too the addition of a graphical representation helpful.

machine-readable notation

For the definition Formal data formats are provided by the "Extensible Markup Language" XML [BPSM00]. Here, the data is recorded in a text format, the Data is separated from each other by so-called "tags." A "tag" consists of this a keyword, which is enclosed in angle brackets. The end of a with a data area beginning with "day" is marked with a final "day", which before the keyword contains a "/" (for example: "<first name> Peter </ first name>"). Different data areas can be sequential combined or nested in a tree.

There are two ways of defining the structure of an XML-based data format, the "Document Type Definition" (DTD) and the schema: Permitted keywords, the structure of the language, and the types of stored data can be defined flexibly , BM01] is much more powerful and allows a stricter definition of the structure and the usable data types In the formal schema, suitable programs can verify the consistency of an XML file with the defined data format.

• • Formalität: Die formale Definition des Datenformats mit Hilfe des XML-Schemas ermöglicht die Verifikation erstellter Beschreibungen. Hierzu können handelsübliche Werkzeuge eingesetzt werden.
• • Schnittstellen: Für die Verarbeitung XML-basierter Daten existiert eine Reihe von Programmierschnittstellen. Softwarewerkzeuge können daher leicht an das genutzte Datenformat angepasst werden.
• • Werkzeugunterstützung: Es existieren bereits geeignete XML-Werkzeuge, welche die Erstellung und Visualisierung einer Beschreibung auf Basis des Schemas unterstützen.
• • Verständlichkeit: Das textbasierte Format und die Wahl aussagekräftiger Schlüsselwörter erlaubt ein intuitives Verständnis erstellter Dienstspezifikationen und Plattformkomponenten auch durch den Menschen.
• • Flexibilität: Die Anpassung oder Erweiterung der Datenformate an zukünftige Anforderungen kann durch Modifikation der Schemata erreicht werden. Das bestehende Schema der USD definiert darüber hinaus Bereiche, in denen proprietäre Daten in eine USD-konforme Spezifikation eingefügt werden können.

After an in-depth analysis, an XML-based data format based on an XML schema was defined for the USD and the SCD. This procedure offers the following advantages in particular:

• • Formality: The formal definition of the data format using the XML schema allows the verification of created descriptions. Commercially available tools can be used for this purpose.
• • Interfaces: There are a number of programming interfaces for processing XML-based data. Software tools can therefore be easily adapted to the data format used.
• • Tool support: There are already suitable XML tools that support the creation and visualization of a description based on the schema.
• • Comprehensibility: The text-based format and the choice of meaningful keywords allow an intuitive understanding of created service specifications and platform components also by humans.
• • Flexibility: Adapting or extending the data formats to future requirements can be achieved by modifying the schemas. The existing USD schema also defines areas where proprietary data can be inserted into a USD-compliant specification.

For a with The MOF defined meta-model is provided by the OMG with the "XML Metadata Interchange "(XMI) [OMG03] A standardized approach to developing one to this Meta model matching XML schemas. With XMI can do this to everyone MOF-based metamodel automatically creates a suitable schema which defines how those defined by this meta-model Models are mapped into an XML-based data format. by virtue of universal applicability for any in MOF noted Metamodels, however, are very complex with XMI-generated schemas and contain a high proportion of superfluous type definitions [Ogb02]. The XML files are based on a schema generated with XMI therefore very extensive and difficult to read by humans. The approach of XML, despite the machine readability also intuitive for humans understandable to be, this is not taken into account. Also were the Working to create a schema with XMI at the time of present work at an early stage and not through tools supported. For this reason was for The USD and the SCD each create their own XML schema, which not compliant with XMI. A transformation into XMI-compliant schemas However, it can be later Time to be made.

For the development a human-readable text format for a MOF-based The OMG is currently working on a "human-useable textual notation" (HUTN) for the meta-model Data format. This format is not XML-based and is located still in development. Because the created schemas have a good readability USD-based service specifications and SCD-based component descriptions allow, was a figure of USD and SCD on the HUTN in this Work not pursued.

Graphical notation

The Definition of a graphical representation is currently used by the MOF unsupported. Suitable graphic structures must therefore be set in a different way. For the USD In this work in Chapter 6, suitable graphic forms are created for the Presentation of the service graph proposed. In chapter 7 becomes a Graphic representation of the components described with the SCD shown. The proposed graphical representations are in two prototypical software tools and could be thoroughly evaluated by working with the tools. Deviating or supplementary However, graphical representations are conceivable.

5.3 Procedure Model

The development of I & K services with MEMICS takes place in several steps. 25 shows the steps of the proposed procedure model.

One is purely sequential procedure in the execution of the steps not necessary because the formal definition of the used models and description languages allows any iterative approach. The procedure leaves but roughly divided into the phases "specification" and "implementation".

The following is an overview of the individual steps of the procedure model. In the 25 The chapter numbers given in parentheses refer to the later sections, which describe these steps in detail.

5.3.1 Specification phase

The goal of the specification phase is the preparation of the in 22 shown, implementation-independent specification of the desired service based on the USD. For this purpose, a model of the desired service conforming to the MEMICS service meta model has to be created. First of all, the specific properties (attributes) of the individual elements of the service (subscribers, communication channels, media) are defined. This is done by defining suitable classes from which the necessary objects for the specification of the service can then be instantiated. For example, the participants describe in these classes the context of service usage (eg "stationary" or "mobile" usage), whereas different quality parameters can be defined in the media classes.

Creation of the service graph

In order to determine the desired service behavior, the possible combinations of subscribers, communication channels and media during the service run are described. Each possible configuration of these objects in the service sequence represents a state of the service. Such a service state thus describes the connection of the subscribers existing at a given moment through communication channels and the media exchanged via these channels. To represent the possible sequences of these service states, the individual states are concatenated in a directed graph (see 26 ).

Everyone Path through this graph describes a possible course of the service, which is composed of the service states passed through this path and describes how the current configuration consists of subscribers and communication channels in the course of the service changes.

Around To facilitate the creation of the complete service graph, the used service conditions as normal, optional or extraordinary Behavior will be flagged. For the development of the service graph is recommended first the description of the desired usual ("Normal") behavior of the Service. This behavioral graph will then be a possible optional extension of behavior expanded. The description of the error in the service execution achieved service conditions ( "Extraordinary Behavior ") complements the Behavior graph. As described above, however, it is an arbitrary iterative Development of the graph possible.

By the iterative approach can be a rough service description of a Client are implemented in a first run graph and this afterwards in several passes be refined together with the client. This approach considered, that optional or extraordinary Behavior of the service usually in a first requirement description not taken into account by the client becomes. These components of service behavior often arise only in the context of a more detailed analysis of normal behavior.

Description of the triggers of State changes by triggers

The Edges of the developed run graph interpose transitions the different states of the service in which the service from one state to one Next state changes. This state change is with a change connected to existing communication relationships: communication channels between the participants are added or fall away, or those used Media are changing. For a detailed definition of the service behavior, the Events are described that are leaving the current state trigger and thus lead to a change of state.

The Lot of possible Events result from the current configuration Communication relations and participants in the considered initial state. Possible Events are, for example, the termination of a connection by a subscriber or sending a signal on a signaling channel. In the individual service states The run graph now defines triggers that are set by which events a state change is triggered.

The necessary changes in the context of the state change Communication relationships can be described as actions to be performed describe (eg "structure Compound X and Degradation Compound Y "). The execution of these actions in turn has specific events result (eg "Participant A can not be reached become").

Each action is assigned specific events by the underlying service be defined model. The events occurring in the state change can be used to change the service flow by defining suitable triggers. This alternative routes can be realized in the service flow.

Validation of the service specification

is the wished Service behavior has been described by the service model, so the potential service procedures be run through simulatively. This can be used to check if the specified service indeed the wished Behavior shows. By the possibility for the iterative development of the service graph and the simulation of a previously specified partial behavior can be early be validated in the development process that actually the desired Service is developed. In this case noted deviations between The specified and planned behavior can be modified by changes in the run graph Getting corrected. The feasibility a specification ("executable specification ") is an important tool to get started early in the development process to consider, whether the service shows the expected properties and the requirements fulfill the client becomes [KHEB99].

5.3.2 Implementation phase

is the complete behavior of the desired Service defined by the developed service model, so can this service specification in the subsequent implementation phase be implemented on different platforms. For the notation the created service specification will, as explained, be the developed "Universal Service Description "used. The service specifications created with the USD are the starting point the implementation phase.

The Concrete design of the implementation phase is, as in the beginning explains dependent of the service platform used and the platform used for this platform Implementation models. To explain a potential Procedure in the implementation phase becomes one in this work Implementation of a specified service on a component-based Service platform presented. This procedure may be for use on similar component-based service platforms. For the implementation on other platform types appropriate approaches are developed.

Implementation procedure on a component-based service platform

To implement a specified service on a component-based service platform, this model proposes a model-based approach. An implementation metamodel defines the form and structure of possible implementation models (cf. 24 ). Such an implementation model describes the terminals used by the subscribers, the transmission media and networks used and the control components of the platform used.

For a concrete one Platform will be first the existing terminals, Networks, media formats and accessories modeled. These individual Model elements describe the specific capabilities of the elements (eg. B. "SMS consists of text "," GSM network can transfer SMS "). You will be with described in Sect. 5.2.2. A suitable tool can then read these descriptions and the elements to the user as building blocks for the development of an implementation model to disposal put. This implementation model describes the way the technical realization of the specified service.

ingredients of the implementation model field

In order to create an implementation model, first of all suitable elements of the implementation platform are selected for each service state of the service specification, with which the communication relationships established in the service state between the participants in the implementation level are reproduced. A real-time voice channel of the specification can be realized, for example, by a telephone connection in the ISDN network in the implementation ( 27 ). By comparing the required quality parameters of the specification with the values of the selected implementation components, it can be ensured that the selected implementation meets the requirements of the specification.

Development of the service behavior

Are all communication relationships of the specification depicted in the implementation model? the, then the flow logic necessary for the expiration of the service must be described. In the presented implementation meta model, state machines are used for this, with which the necessary behavior of the central service control is modeled. The behavior of the service specified by the triggers at the specification level is mapped in the implementation model by program lines of the service control state machine. The development of these program lines is based on the formal specification of the interface offered by the implementation components. The events and actions described in the specification are thereby mapped to corresponding signals of the platform components.

by virtue of the formal definition by the implementation metamodel verify the consistency of created implementation models. By the specified consistency rules between the service meta model and the implementation metamodel may also be broad be verified that the developed implementation model the original Service specification fulfilled.

Test of the implemented service

If the dynamic behavior of the service completely in program lines The state machine is modeled is the implementation phase completed. The program lines of the state machine can be found in the program code for the service control can be converted, and the service can the service control will be installed. Finally, the developed service be started and tested.

The Implementation metamodel developed in this work has been released applied an existing prototype service platform. It can be transferred to other component-based platforms. For others Platform types need created appropriate implementation metamodels within the framework of MEMICS become.

6 The implementation-independent service specification

This Chapter explains the approach of MEMICS to build the implementation-independent service specification. The desired Properties and the planned behavior of a new service in the context of MEMICS through the creation of a corresponding service model Are defined. The elements that can be used to create a service model and their relationships to each other are through a service meta model established. This service meta model is constructed using MOF charts presented.

to Notation of created service models became a suitable formal description language - the "Universal Service Description "(USD) - developed. A service model quoted in the USD represents the specification of the desired Service and is the starting point of the subsequent implementation phase.

In this chapter will be first presented the individual elements with the help of the service meta model, which can be used in a service model. These are around objects whose respective properties are defined by classes become. For the modeling of service behavior becomes the objects in the service model in individual service states arranged, which then assembled to the service flow graph become.

to Clarification of the presented service meta model is described in this Chapter of the click-to-talk service presented in section 2.1.3 and modeled by way of example. The full service model of the "click-to-talk" service is located as a USD document in Appendix B.

6.1 The objects of the service meta model

For modeling of a service the relevant objects in service and their relationships be described to each other. The for the description of a desired Service relevant objects are first the participants of the service. For a click-to-talk service (Section 2.1.3) can be, for example, the customer and the consultant as Identify participants. Become the participant of a service in the service flow through different communication channels with each other connected, over which certain media are transported. So should the adviser and the customer can be connected through a voice channel over the they can talk to each other. This over the connecting communication channel transported medium is the Language. These objects too can be modeled in the service model.

modeling the object properties through classes

The different objects of the service are characterized by specific properties. Thus, a permitted maximum delay time can be defined for the communication channel and the minimum required quality can be specified for the medium language. The properties of the objects that are relevant from the point of view of the service specification are modeled in the service model by attributes. To facilitate the multiple use of an object in the service model, the attributes of the object are grouped together. The required properties of the media object "help" exchanged in the "click-to-talk" service between customer and advisor are described in the service model, for example by the class "voice" (see 28 ).

In the class "Voice" of the service model become the specific properties of the medium, for example the necessary frequency range, described by attributes. Which Attributes for a particular object type of the service model must be specified defined by the service meta-model which, for example, the for one Class of type "audio that "to be given Defines attributes.

The classes of the service model

All classes of the service model are derived from a base class "service_element_class" (see 29 ) and thus inherit two basic attributes. The attribute "class_name" contains the name of the class created in the service model and a textual documentation can be given to the class with the attribute "description". The data type "XHTML" allows the use of formatting in the documentation.

The classes usable in a service model are divided as in 29 shown in four types. The participants in a service are described in the service model by endpoints ("endpoint_class") The media exchanged between the participants ("medium_class") are transported via channels ("channel_clas") The group of special objects ("special_object_clas") describes additional , objects involved in the service, such as timers or counters. In the following, the four feature types with their respective attributes are presented.

6.1.1 Endpoints ("Endpoint_clas")

In the service model, all objects that are the start or end point of a communication channel are displayed as endpoints in the service model. As 30 In the service model, it can be specified whether an end point in the service flow is stationary or mobile ("mobility" attribute) Furthermore, it can be specified whether the end point from the point of view of the service anonymously participates in the service or must be registered for participation or must authenticate to the service (attribute "access").

The objects occurring as endpoints in the service model correspond to the Participants of the service. For further distinction they can into human participants "user_class" and non-human participants "machine_clas". For the human participant can be defined in the "user_class" whether the subscriber is predominantly the service private or business uses (attribute "use_environment").

There the service model no details of a technical implementation of the service, only technical devices are considered endpoints included in the service model that actually subscribes to the service are. This can be, for example, a vending machine whose inventory is via a remote maintenance service is controlled. terminals of the subscriber or a video server for playing one in the service used movie are not modeled in the service model.

For the description of the two participants "customer" and "advisor" of the "click-to-talk" service, in the service model, for example, the in 31 shown two classes "Private Customer" and "Internal Advisor" are modeled.

Of the Customer is described as a private customer, the service anonymous from home uses. The consultant in this example is an internal company Client advisor. He takes business participate in the service and must for the use of the service to be authenticated.

6.1.2 Media ("Medium_class")

In describing the required properties in the service of media used, a distinction is first made between moving and still media. Within these groups different types of media are distinguished. shows the moving media classes used for audio ("audio_class"), video ("video_class"), character streams ("charflow_class"), and data streams ("dataflow_class"). For still media shows 33 the classes for images ("Image_class"), text ("Text_class") and data packages ("Datapacket_class").

each Contains media class specific attributes that represent the required properties of the Describe medium. They represent the for this medium from the point of view of Participants need quality parameters To give a clear specification. to enable desired media qualities In this case, physical parameters are used. The selected parameters do not specify a specific implementation as they are the basic ones Describe characteristics of the respective media by the participant be perceived of the service.

In many cases a certain range of variation of the quality parameters is acceptable. For this can with the selected Data type "PositiveValue" a value range with a lower and an upper limit. At the Data type "PositiveIntValue" are these values natural Numbers and the data type "PositiveValueUnit" can be the value range a unit (for example, "seconds" or "minutes") are added. For the media classes for Audio, video and images will have the property parameters through an additional Quality parameter "quality" added is used for the description of the same property parameters of Users perceived different qualities of the media, for example can be caused by a lossy compression. Of the associated Data type "QualityType" allows the use different quality descriptions. In addition to a purely textual description is a review after the evaluation system MOS proposed by the ITU ("Mean Opinion Score ") [ITU96] possible, the rating of perceived quality on a 5-step scale provides.

With the presented media classes, media with different quality requirements can be modeled. For example, the four quality gradings "A0" to "A3" proposed by the ITU for audio media in the recommendation F.700 [ITU00] may be as in 34 be modeled.

These Media classes describe four audio media of different quality levels starting with simple speech quality ("A0") to good music quality ("A3"). For modeling of the "click-to-talk" service between Customers and consultants in the consultation exchanged mediums language can for that Service model, for example, that he was selected class "A0", which describes a simple, but for understanding sufficient voice quality.

In addition to the use of individual media, various media can also be combined into one media class in the service model. This can be used, for example, to model the combination of a video and an audio medium for a videoconferencing connection. For this purpose, the individual media classes can be integrated into a class for a composite medium. As 35 shows that only either moving media ("flow_compound_class") or still media ("still_compound_class") can be combined with each other.

6.1.3 Channels ("Channel_class")

To model the exchange of media between endpoints as part of the service model, these media are assigned to communication channels that describe the transport of the media. The characteristics of these channels which are relevant from the point of view of the service specification relate to the time requirements imposed on the information transport. In addition to the modeling of payload transport in service, communication channels in the service model are also used to model the interactions of subscribers with the service functionality. The channel classes of the service meta model differ, for example 36 shows media channels ("medium_channel_class") and control channels ("control_channel_class").

media channels

For modeling media channels, the three different, in 38 used classes. Real-time media transports, where a fixed end-to-end delay between sender and receiver must not be exceeded, are modeled with the "realtime_class".

On Based on this class, for example, a channel class "Realtime" can be defined for the "click-to-talk" service, the for the voice channel between customer and consultant specifies a maximum delay time ("maximum_end_to_end_delay") of 100 ms.

One Channel for the continuous transmission moving media, such as a video being played described by a "streaming_class" View of the participant here is the allowed delay at Starting the medium crucial ("maximum_start_delay"). In addition to the transfer of the user medium, this class can also have one from the receiver to the other Sender include ongoing interaction channel with which the receiver, for example can control the playback. additionally to specify the maximum allowed response time ("maximum_interaction_delay_in_ms"), the potential Control commands ("command") are described. In the transmission idle media is the maximum total transmission time from the service user's point of view ("Maximum_transmission_time") crucial For the description such communication channels the "datagram_class" is used.

control channels

To describe interactions of the service subscribers with the service functionality, control channels are used in the service model. Here four types of control channels are distinguished ( 37 ).

I would like that Participants in the course of the service functionality intervene, so to the service control Send signal, this will be used to model this control channel used the class "Signal_class" in this Class can the maximum permitted time delay ("maximum_delay") and the possible control commands ("Command") are defined. receives conversely, the subscriber provides information in connection with the service functionality from the service control, the class "Message_class" is used for this purpose If the participant is presented with a selection menu in the course of the service, this can be done with a control channel of class "Menu_class". In addition to the maximum delay time until the presentation of the menu ("Maximum_presentation_delay") can the allowed Response time ("maximum_reaction_delay") of the service functionality to the Selection of a menu item ("Item"). All other interaction options between subscriber and service functionality, such as the input specific data by the participant are modeled by the class "Interaction_class".

In the example of the "click-to-talk" service, the customer must be able to signal his need for advice while browsing through the service control catalog To describe this control channel, the service model defines a class "GetHelp" that is based on the "Signal_class" Class of the service meta model is based ( 39 ). For the reaction time of the service to the signaling of the consultation request, a duration of up to 60 seconds seems acceptable. For the actual signaling, the control command "needHelp" is defined in this class.

6.1.4 Special objects ("special_object_class")

Next Endpoints, media, and communication channels can be viewed from the perspective of the service specification in some cases other objects for the modeling of the desired Service be necessary. This can be, for example Timer, counter or data processing objects. To represent these objects in the service model to be able to The service meta model includes another class named "Special_object_class." It may contain appropriate classes Classes describing the specific properties of others Objects are derived. In the service model, however, only objects modeled their characteristics and behavior for the participants of the service are recognizable.

At the in 5 For example, as shown in the variant of the "click-to-talk" service, the subscriber can specify that the connection to the advisor should take place only after a certain period of time. To model the behavior of this service, therefore, a timer is imperative. The way of realizing this temporal dependency in the context of a concrete service implementation is not determined thereby.

6.2 Development of the service graph

After describing the objects used in the service model by the associated classes, the desired behavior of the service can be modeled. For this, the individual in the service process occurring arrangements of the objects involved in service states summarized. In this case, a service state expresses the connections of the subscribers occurring at a time in the service sequence by means of communication channels, the media exchanged about them and the possibly used special objects.

creation the service conditions

Like the diagram in 40 Each service state ("service_state") is denoted by a name, and it can also be specified whether this service state belongs to the optional ("isOptional") or exceptional ("isExceptional") behavior of the service, with optional service states not being mandatory The designation as exceptional is purely declarative to see from the developer's point of view, which can hereby mark service states that do not occur in the usual course of the service and, for example, are considered essential to the actual function of the service Represent responses to errors during service execution.

The In the service state contained objects are each by a Name and the indication of their class. As endpoints can in a service state, two types of objects occur. On the one hand these are the already described participants of the service ("User") some service states Alternatively, additional endpoints can be added. This acts these are communication partners who are not subscribers of the service are present but as a source or sink of a communication channel have to be. For example, a participant in the service process receives a video played this video from a source in the associated communication channel be fed. This source is used in the service model as a service-supporting component ("Service Support Component "- SSC). The representation of such objects in the service model is always then necessary if the service participants regardless of the type of implementation of the service necessarily the presence of any kind Can recognize source or sink. The modeling of these sources and sinks does not represent any restriction the way of their implementation.

Media channels must be in Service status at least over two connections ("connection") with endpoints be connected. The endpoints can here transmitter and / or receiver For this Be a channel. control channels are each associated with exactly one participant.

For the clearly arranged and easily comprehensible representation of the service statuses, a graphical display format is used in MEMICS. Service states are represented by a rounded rectangle with the name of the service state at the top. Endpoints can be visualized by an image, which is supplemented above by the name and below by specifying the class of the endpoint. Media and control channels are represented by arrows. The different types are characterized by the in 41 marked line types and thicknesses.

The connections of the media channels begin or end at the respective endpoints. The arrow shape shows the direction of the media flow for this endpoint. If the end point simultaneously represents transmitter and receiver of the transported medium, then the double-sided arrow direction is symbolized by a rectangle on the tip (compare the real-time channel in 41 ). Control channels are each connected to only one endpoint. Its second end is therefore connected to the borderline of the service state.

In the "click-to-talk" service, two service states can be identified initially: In the initial state, the customer scrolls through the catalog and has the option to signal his request for personal advice modeled class "GetHelp" is ( 42 , Left).

The linguistic connection between customer and consultant established on the basis of an advisory request constitutes the second service state ("consultation") ( 42 , right). Here, the customer and consultant are connected by a real-time media channel "hotline" of the class "Realtime" via which the medium "help" of the class "Voice" is transmitted.

Linking the service states to Service flow graph

To represent the dynamic behavior of the service, the individual service states have to Sequence graphs of the service are composed. For this, the service states are connected via transitions. These start at the initial state at a rectangular box with the name of this transition and end with an arrow at the target state. In the "click-to-talk" service, for example, the two service states shown are connected by a transition "needHelp" ( 43 ).

Of the first service status reached in the course of the service is with a from a completed Circle outgoing arrow marked. Transitions leading to one Stop the service, end in a filled Circle, which is surrounded by another ring.

Of the Established service flow graph shows the possible sequences of the modeled Service states. By Branches can Alternatives in the service flow are presented. Every possible way through the run graph represents a possible expiration of the service which consists of the service conditions passed through this route.

Of the However, the service history graph does not tell us when a service state over a transition will leave and under what conditions possible alternative routes selected become. Also these triggers and conditions must for one full Modeling of service behavior will be described.

6.3 refinement of the dynamic behavior

For a more detailed Description of the dynamic service behavior will be the service meta model the description of actions and events added. Events can for example, terminating a connection by a subscriber or transmitting a signal on a signaling channel. The Actions on the other hand describe those in the service flow in the transitions be executed Tasks, such as setting up or dismantling the communication channels. The execution In turn, these actions can lead to specific events that For example, express the success or failure of an action. The Service Meta Model assigns a lot of possible actions to the actions Events too. Other events may be after a service model Need added become.

occurring Events can in the service model as a trigger for one Service status changes are used. You are going through the definition appropriate conditions integrated into the service model.

6.3.1 Actions and events

The Actions in the service model describe those in the transitions between the service conditions to be executed with the objects Tasks. For all objects are for the creation and deletion of the object defines the actions "new" and "delete". The connections of a media channel are set up and dismantled by the actions "connect" and "release". Participants who for the Service usage must be registered ("Access = registration "), are during the handling of this process in the "register" action, for the authentication of a subscriber the action "authenticate" is defined accordingly.

The Within a transition to be performed actions arise by comparing the in the initial and final state of the transition existing objects. So must for all objects. in the target state, but not in the initial state are present, the action "new" will be performed.

While performing the actions, certain events may generally occur. For example, a connection to be established with "connect" can not be created, or a participant cancels an authentication.These events are described in the service model by elements of type "Event". As 44 shows, they are assigned to the objects via the respective class.

Next the event has a value whose name is denoted by the name Attribute "type" is set. Each event can only be used for certain actions of the service flow occur. This action is determined by the attribute "in_action." For events that occur within a service condition can occur This attribute is set to the value "none" or "connectionNone" for the connections set a media channel.

Since the establishment of a communication relationship can principally turn out to be impractical due to problems or errors that occur, each channel in the service model is assigned an event "creatingFailed", which can occur during the action "new". The data type "type = Error" assigned to this event indicates that the associated object - the communication channel - could not be created te and therefore also does not exist after the action "new." The service meta model specifies the events shown in Table 6.1 for the different object types.

Tabelle 6.1: Durch das Dienstmetamodell vorgegebene Ereignisse

Table 6.1: Events Given by the Service Meta Model

Out The service flow graphs can now be used in the individual service states and during the Transitions possible Determine events. They arise from the existing ones Considering objects the one to be performed Actions.

The events possible in the first service state "ReadCatalog" of the "click-to-talk" service model are the two events "channel-broken" and "signal" belonging to the signaling channel "button." For unambiguous identification, they are displayed in the service model in the form "object "event". In the service state "ReadCatalog", the event "button.channelBroken", which is of the type "Error", can occur on the one hand, while the value "true" indicates that the signaling channel has collapsed and no longer exists. Furthermore, the event "button.signal" can occur, which is of the type "enume rate" and can be changed by the "GetHelp" class (cf. 39 ) value "needHelp" indicates the consultation request signaled by the customer.

The Occurrence of the signal for The request for advice is the trigger for leaving the service state "ReadCatalog" via the transition "needHelp" with the goal of subsequent service state "Consultation" to carry out this Transition are now to perform some actions that are different by comparison the objects in the initial state with those for the target state resulting necessary objects. In the example of the "click-to-talk" service, the "needHelp" transition first needs the Participant object "consultant" of the class "InternalAdvisor" for the addition Consultants are generated. This consultant must be here for the service use authenticate. Furthermore, a new communication channel "hotline" of class "Realtime" must be generated. Subsequently This channel must be connected to the two endpoints "customer" and "consultant". As the last action, the signaling channel "button", which is no longer required in the destination state, must be disconnected and thus deleted become. Table 6.2 shows the actions to be performed and the ones to be performed connected possible Events that can occur in the "needHelp" transition.

Based The events shown will show that the desired service status not in everyone. Trap can be achieved. If during the Transition of one of the possible Events occurs, so due to the data type "Error" the associated action not successfully completed become. Thus either the consultant can not be authenticated or the voice channel between customer and consultant can not be fully established become. In all cases The defined prerequisites for the target state "Consultation" are not met the dynamic behavior of the specified service must be around the consideration these error cases added become.

Tabelle 6.2: Aktionen und Ereignisse der Transition "needHelp"

Table 6.2: Actions and events of the transition "needHelp"

6.3.2 Trigger the Service status change by trigger

With Help the possible Events can for the service states and the transitions of the service model now defines conditions be the trigger represent a service status change. As stated above The event "button.signal. occurring in the service state" ReadCatalog " = needHelp "the trigger for the Leave this service state. This condition may be in the service model be expressed by the definition of a trigger. A trigger exists here from a Boolean condition and the designation of a Transition at fulfillment the condition is triggered becomes.

In the "ReadCatalog" service state, the definition of a trigger with the condition "button.signal = needHelp" and the "needHelp" transition to be triggered can specify that the signaling of the customer's request for consultation determines the service status via the "needHelp" transition leaves. For the "Consultation" service status, a trigger can also be set with the condition "hotline.channelBroken || hotline.customer.connectionBroken || hotline.customer.partyFinished || hotline.consultant.connectionBroken || hotline.consultant.partyFinished" It causes the transition state to be "consultationFinished" after termination of the voice channel by one of the two subscribers or the collapse of the connection, leaving the service status via the "consultationFinished" transition. This transition will stop the service.

By defining appropriate triggers in the service model, the behavior of the service can be uniquely described in response to occurring events. Triggers are used for this not only in the service states, but also within the transitions. When fulfilling the condition of a trigger within a transition, the service flow can branch at this point and an alternative route to ei take another service condition.

By defining a suitable trigger, you can respond appropriately to the error events listed in Table 6.2 that might occur in the "needHelp" transition by using a trigger with the condition "consultant.authenticatingAborted || consultant.authenticatingFailed || hotline. creatingFailed || hotline.consultant.connectingFailed || hotline.customer.connectingFailed ", which points to an alternative transition called" callSetupFailed ".This transition can then, as in 45 shown leading to a new service state "notification" in which the customer is informed by a message channel "message" that the service can not be executed at present.

however can also be the structure of such a news channel, such as table 6.1 indicates that the event "message.creatingFailed" is thwarted. This means that the message channel will not be established can and therefore the customer does not over the existing problem can be informed. In this case is also the realization of the alternative service status "notification" in the service flow not possible. Two solutions are available to address this problem. Firstly, in the transition "callSetupFailed" by the definition another trigger the service when the event "message.creatingFailed" in an alternative way branch through which the service immediately stops without further action becomes. In the service meta model, however, another possibility intended. So can communication channels in the individual service states by setting an attribute "mightFail = true" as for this Service state not essential to be defined. Becomes this for the message channel "message" performed, so For example, the service flow may reach the service state "notification" even without the message channel "message" if this could not be built. The so-defined service status "Notification" expresses that the customer - if possible. - from that should be informed that the consultation request will not be executed can.

With the introduced extensions, the service model of the "Click-to-talk" service has now been completely created. The graphical representation of the service graph in 45 shows clearly and clearly the possible behavior of the service. Detailed information about the desired properties of the specified communication channels

can the be taken from respective class definitions. The dynamic Behavior of the service is in response to the service flow possibly occurring events using the triggers clearly defined Service.

6.4 Verification of service models

By the formally defined service meta model can be created service models diverse be verified. This was a set of verification rules developed, for example, by a suitable software tool checked can be. These rules are presented below.

Verification rule 1: "Are the correctly specified the classes assigned to the objects? "

Here to be checked, whether the classes assigned to the objects exist and whether these Satisfy classes of the respective definition by the service meta model. The in the service meta model for The classes set attributes must be in the classes of the service model exist and be provided with values of the defined data type. Furthermore, must the classes contain the events associated with them in Table 6.1.

Verification rule 2: "Exist all associations defined in the service meta-model? "

For this rule, verify that all relationships between the objects specified in the service meta-model have been applied correctly. So must, as in 40 All media channels of a service state contain at least two connections, each associated with an endpoint present in the same service state. The objects and events used in the conditions of the triggers must be present in the respective service state or in the respective transition. Branches defined by the triggers must exist as transitions or alternative routes in the service model.

Verification rule 3: "Is the Service history graph completely? "

For the existence of a complete service graph, some conditions must be met. Thus, it must first be checked whether the start state of the service is correctly marked. All service states need further at least one input and one output. So that the outputs of the service states and the possible alternative paths of transitions in the sequence can be reached, there must be at least one trigger pointing to this path. Furthermore, all service states must have at least one path through the flow graph leading to termination of the service.

Verification rule 4: "Are the Conditions of triggers completely and clearly? "

For a clear Definition of triggers allowed at the same time do not overlap active triggers in their conditions. It must therefore be ensured that on any occurrence of events, only a maximum of the condition of a trigger is fulfilled. The conditions are allowed to do so in the space of possible Do not overlap events.

Within Transitions must further apply that for each distribution the possible Events a trigger condition is met, otherwise another Expiration of the service is not possible is. However, not every event needs to be within a health state lead to a reaction of the service, so that the cover of all possible Events by trigger here is not necessary.

Verification rule 5: "Become the error events of the communication channels marked as essential are correct treated? "

All in the service conditions not with the attribute "mightFail = true "marked communication channels be for the fulfillment defined service status is considered essential. Can these channels can not be set up correctly in a transition, then the Service status can not be achieved. It therefore needs to be checked whether for all error events of these communication channels corresponding triggers defined which were an alternative branch of the service flow to lead. Within the service states have to Trigger defined on the occurrence of an error event react to the essential communication channels and thus to one Leaving the service state, if one of the essential communication channels of the service state during the Dienstausfühung is ended.

6.5 Notation of the service model in XML

to Processing and further use of the service models must be created Service models are written in a well-defined form can. For a Such notation format offers itself as explained in section 5.2.4 Definition of a data format based on Extensible Markup Language (XML) [BPSM00]. For the reasons presented there was for the definition of the data format used in MEMICS is not that from the OMG with the "XML Metadata Interchange "(XMI) [OMG03] Proposed procedure applied, but its own Data format called "Universal Service Description" (USD).

For the USD, an XML-based data format is specified by means of an XML schema [TBMM01, BM01] for notation of the service models created on the basis of the service meta model (cf. 23 ). The scheme defines what a valid USD document looks like. It defines the keywords that can be used in the USD, the structure of the document, and the types of data that can be used in the various data fields.

The basic structure of an XML document is tree-shaped by nesting the tags. A USD document begins, as does the graphical representation of the USD schema in 46 shows, always with the tag "service".

This is followed by two sections. In the section "class_definitions" the used classes are sorted according to endpoints, media, channels and special objects defined endpoints can occur as "user" or "machine" The individual attributes of the classes are enclosed by corresponding tags (see 47 for the class "User_class").

All Class definitions include the possibility for an additional section "proprietary" in this section can Any further data will be filed that is not covered by the USD become. here we can Software tools proprietary Save data that is not processed by other tools Need to become. This procedure allows a flexible extension of the data format and allows the processing of such extended USD documents also by Tools that do not know these extensions.

After defining the classes of the service model, the USD document in the section "service_graph" contains the description of the service flow graph ( 48 ). All service states ("state") are represented with the endpoints, media channels, control channels and special objects that they contain.The possible outputs ("exit") from the service state become with the triggers triggering them and the description of the transition to be carried out ("transition"). The start of the service also takes place within the framework of a transition ("start_transition") whose goal is to reach the first state of service.

All transitions are indicated in the USD document by the in 49 First, the destination state of the transition and the triggers to be passed for a successful pass are specified, and alternative routes ("alternative") can be specified. These in turn consist of the triggers triggering them and the transition to be carried out ("transition").

in the Appendix B contains the USD document matching the scheme presented of the service model for the "click-to-talk" service as it is in This chapter is an example. Using the schema, you can use standard XML tools check the correct form of the USD document. The scheme allows the Further, to create a USD document, a generic XML tool to use. Due to the formal USD scheme, the tool can be used by the tool Users extensive support when creating the USD document. It must therefore to the specification of a service with the help of the USD not necessarily new tools are developed.

6.6 Validation of the specified Service flow through simulation

To the creation of the service model for a scheduled service the behavior of the service determined by this with the help of a suitable tool can be examined simulatively. This can be validated that the specified service corresponds to the original wishes.

For one Simulation process will be the for generates a service state defined objects in the service model and the user of the tool the possible in this context Events are displayed. By choosing the occurring events the user can control the course of the service. The simulation tool in each case represents the configuration resulting from the service model objects - participants and the connecting communication channels - and determines the to be performed Actions and the possible occurring events.

6.6.1 Rules for the temporal Expiration of the service

For a clear behavior of the service, determinations must be made about the time sequence of actions to be performed and events occurring. For this purpose, the following expiration rules are defined in the service meta model:
Flow rule 1: "Within a service state, events occur sequentially one after the other. Upon reaching the service state and every occurrence of an event, it is checked whether a trigger condition is fulfilled and thus the service state is left. "

This behavior corresponds to a service control in which the signals of the occurring events are processed individually in the order of their arrival.
Process rule 2: "Within a transition, all actions except 'release' and 'delete' are executed at the same time. All occurring events are checked together and the triggered trigger is triggered. Before entering a new service state, the outstanding 'release' and 'delete' actions are performed. "

For the service model is hereby set that initially all in one transition to be established communication channels be created before the no longer necessary channels are mined become. In the case of a transition, in the case of failure to establish a Communication channel back again leads to the initial service state, becomes thereby the unnecessary Aband again construction of communication channels prevented. In the implementation of a service may be due to limited resources (for example, through Using the same device at the participant for on the other hand, it will be necessary to first degrade channels, before the new communication channels can be created.

There is no need to specify a sequential order when performing the actions to establish or clear the communication channels. For the specification of the service behavior is only relevant which of the actions could be carried out successfully and which actions failed. It should be noted that the individual connections of a media channel can not be successfully created if the associated channel can not be created.

The Process rules show the different temporal behavior of the Service in the service conditions on the one hand and the transitions on the other hand within the specification. While a Service state represents a time-continuous state of the service, is assumed in the service meta model that transitions instantaneously - ie without Time loss - be performed can.

For the "click-to-talk" service, therefore, the determination of the permitted delay time on the signaling channel "GetHelp" (cf. 39 ) of 60 seconds that 60 seconds may elapse in the service flow until the service has responded to the signaling of the advisory request by reaching a new service state. Therefore, the time consumed in an implementation of the service within the needHelp transition must be included in the sixty seconds in addition to the duration of the signaling channel used in the implementation.

6.6.2 Example procedure the "click-to-talk" service

The simulation of the "click-to-talk" service starts with the execution of the first transition, which leads to the start state "ReadCatalog" of the service. For this, the objects for the customer and the signaling channel connecting them must be created. In the first service state there is then the signaling channel "button" to which two possible events are connected: "button.channelBroken" and "button.signal" ( 50 ).

Of the Users of a simulation tool can now, for example, the Select event "button.signal" and set the value "needHelp" here now notes that this event defines the defined trigger condition Fulfills and therefore the service state is left by the transition "needHelp".

The The goal of this transition is the "Consultation" service status States are the actions shown in Table 6.2, the with the possible Occurrence of a series of events are connected. As in flow rule 2 determines, be first the actions to create the advisor object, its authentication, the structure and connections of the voice channel. in this connection can the events also shown in Table 6.2 occur. exemplary Let's assume that the connection of the voice channel to the consultant can not be established. For the simulation will therefore set the signal "hotline.consultant.connectingFailed" to the value "true". Since the Voice channel between consultant and customer not fully developed The question now arises as to how the service reacts to this becomes. An evaluation of the triggers active in this transition gives that the condition for the trigger of the branch "callSetupFailed" is fulfilled. The process of the service now branches to the associated alternative route with the target state "Notification".

Within of the chosen Alternatively, again, a series of actions is to be performed. First is in doing so, after expiration rule 2, the message channel "message" of the class "Not-Possible" for notifying the subscriber to create. For The simulation process is now assumed that the associated Event "message.creatingFailed" does not occur - the notification channel so it can be generated correctly. Before the transition now through the entry into the service state "Notification" is finished, still need pending "release" and "delete" actions are performed. Here, the partially existing voice channel "hotline" and the signaling channel "button" of the customer are reduced and the object for deleted the adviser.

The in this condition may be events occurring in the news channel (see Table 6.1 the possible ones Events of the "Message_class") regarding the successfully sending the message ("message.sendingSuecessful"), the arrival the message to the recipient ("Message.messageArrived") and the confirmation of the Receive ("message.receiverAcknowledged") are received from the service not waiting. Rather, it is triggered by a trigger with an empty condition the service state over leave the transition "finished" immediately.

In this transition, the remaining objects of the service are deleted and the service is terminated. In the described service model, erroneous notification of the subscriber thus does not lead to a change in the service behavior. Another reaction of the service to the impossibility of Be Notification of the participant about the failure of the voice channel also does not appear in this case.

By the described process of simulation can be the reaction of the service on the different possibilities occurring events are tested. This can be checked whether the behavior of the service specified in the service model is the original one To wish equivalent.

6.7 Prototypical software tool MEMICS Designer

in the The present work became a prototypical software tool for the creation, verification and simulation of service specifications developed on the basis of the presented service meta model. Goal of this Tool development was the applicability of the presented To examine development method in practice. This requires the tool in particular a simple and fast creation and editing support the service models. The focus of tool development was therefore on the graphic Representation of the service graph and the graphical user interface.

The Development of the software tool called "MEMCIS Designer" was based on a Linux operating system and the C ++ programming language. For the graphic user interface became the library "Qt" of the company Trolltech [Tro04] used. The software tool developed in the context of this thesis is being prototype for a service specification tool. The program code is freely available and can be used as the basis for the development of further tools are used.

The main window of MEMICS Designer ( 51 ) is used for the graphic creation of the service flow graph. Here the service states can be created and connected by transitions to the run graph. The included endpoints can be visualized by images. The graphical notation presented in section 6.2 is used to represent the objects. The graphical representation of the run graph facilitates developing the service graph and intuitively capturing the specified service behavior.

To define the classes used in the created service model, MEMICS Designer provides a class browser ( 52 ), which manages the created class definitions in a tree structure. The attributes to be defined in the different class types are specified for each class type. The possible events assigned to the classes are generated automatically.

Next the support through the graphical representation of the tool to the user in particular also by checking the match of the developed service model with the service meta model help. The actions necessary in a transition and the resulting potential Events are automatically calculated by the tool. Already in the Graphing is a variety of possible errors of the service model visualized. So are undefined classes or used several times Object names displayed in red. At the request of the user can the tool creates the created service model with the ones described in section 6.4 check the verification rules. Be in a log all violations against listed these rules.

In order to validate that the specified service behavior corresponds to the actually desired behavior, the possible operations in a created service model can be simulated with MEMICS Designer. The tool represents the current configuration of the service consisting of subscribers and communication channels ( 53 , below).

At the same time, the actions to be carried out and the possible events ( 53 , above). The user of the tool can select events and test the response of the service behavior. Different processes of the service can be played through and the reaction of the service can be tested in different situations.

created Service models can with MEMCIS Designer finally described in the "Universal Service Description "Language be stored. This XML document can then be used by others Tools are processed.

7 Implementation of the service specification on a platform model

The specification of a service described in the context of MEMICS with the service model describes the properties and behavior of the desired service. This determines what the To do service. In the implementation of this service through an implementation must now be decided in what way - so how - this service should be realized. It is necessary to select which technical systems are used and how they should be used. This includes the choice of networks used, subscriber terminals, service control platform, transmission media and protocols, and others. The high degree of freedom generally allows a service specification to be implemented through a variety of technically different implementations.

For the development of an implementation of a specified service, in MEMICS, as in 24 shown a model-based approach chosen. First, a model of the planned implementation is created. For this, the code artifacts (program code, database structure, etc.) necessary for the selected service execution platform can then be largely automated.

The Shape and the structure of the possible Implementation models are defined by a meta model. As for the realization of I & K services a variety of different technical systems and platforms (see Section 2.3) can not be a single implementation metamodel all systems alike represent well. This is how the component model of a TINA platform differs from a web service-based platform. In the flow logic descriptions (Section 2.3.4), for example, functional procedures, like the SIB graph of the Intelligent Network, of object-oriented Procedures, for example the "Session Programming Language "(SLP) the SAMSON architecture. It is therefore for everyone Platform type to create a suitable meta model, which, however subsequently for all following implementations on this platform type can.

Of the One time effort to create this meta model is provided by a Range of benefits justified. As with the service specification in chapter 6, the metamodel becomes structure and meaning an associated one Model formal and understandable established. This represents a uniform modeling by different Involved and a clear meaning created models certainly. Also, you can create model building blocks that are in a variety can be reused by models. Furthermore, mapping rules specified between the service meta model and the implementation meta models be checked by the can see if a created implementation model of the associated service specification equivalent. Through these rules can with subsequent changes the specification the changes to be made in the implementation be determined, thereby ensuring the consistency of the implementation can be.

As mentioned above, have to for different Platform types each have their own, customized implementation metamodels to be created. To show the procedure by way of example, in This work is an implementation of the proposed development method on a distributed, component-based architecture with central Service control presented. Such architectures are for the realization from I & K services particularly suitable on the basis of open network interfaces. The Implementation meta model used for this purpose will be discussed in this chapter presented with the help of MOF diagrams.

The The presented meta-model was developed for the implementation of services an existing prototype service execution platform. This platform is the foundation of this chapter examples for the service implementation. As part of the work carried out has emerged a software tool that the systematic and tool-supported Implementation of a service on the existing service platform allows.

The The service meta model presented in this chapter is an example for the principle of MEMCIS. It can work on service execution platforms be transmitted with comparable properties. For others However, platform types are suitable implementation metamodels to develop.

7.1 Distributed, component-based Service architectures with central service control

• • Abgegrenzte Einheit: Eine Komponente ist eine von der Umgebung klar abgegrenzte Einheit, die eine bestimmte Funktionalität realisiert. In dieser Einheit wird dabei ein spezifisches Wissensteilgebiet gekapselt (beispielsweise ISDN-Protokolle und -Schnittstellen in einer ISDN-Komponente).
• • Definierte Schnittstelle: Eine Komponente verfügt über klar definierte Schnittstellen. Über diese Schnittstellen kommuniziert die Komponente mit ihrer Umgebung zur Realisierung ihrer spezifischen Funktionalitäten. Diese Schnittstellen müssen so klar und eindeutig festgelegt sein, dass sie beispielsweise die Grundlage einer vertraglichen Vereinbarung darstellen können.
• • Wiederverwendbarer Baustein: Eine Komponente kann als generischer Baustein in einer Vielzahl unterschiedlicher Systeme eingesetzt werden. Sie kann unabhängig von einem spezifischen Einsatz entwickelt oder eingekauft werden.
• • Festgelegtes Komponentenmodell: Ein Komponentenmodell definiert die Anforderungen, die an eine Komponente gestellt werden, damit diese in einer bestimmten Komponentenarchitektur eingesetzt werden kann. Das Komponentenmodell legt beispielsweise die Laufzeitumgebung und die prinzipielle Art der Schnittstellen fest.

The aim of a component-based architecture is to reduce dependencies within the system by dividing the system into clearly separated units ("components") [ALM + 01], but the term component is used in many different ways: An overview of different definitions [And03] For the present work, the following properties of components are determined in accordance with [SGM02]:

• • Demarcated unit: a component is a unit clearly defined by the environment, which realizes a certain functionality. In this unit, a specific area of knowledge is encapsulated (For example, ISDN protocols and interfaces in an ISDN component).
• • Defined interface: A component has clearly defined interfaces. Through these interfaces, the component communicates with its environment to realize its specific functionalities. These interfaces must be so clear and unambiguous that, for example, they can form the basis of a contractual agreement.
• • Reusable building block: A component can be used as a generic building block in a variety of different systems. It can be developed or purchased independently of a specific application.
• • Fixed component model: A component model defines the requirements that are placed on a component so that it can be used in a particular component architecture. For example, the component model defines the runtime environment and the principal nature of the interfaces.

In a system for realizing I & C services, the components are building blocks that provide individual network and basic services (see interface ➀ in 8th ). Such components can, for example, enable the sending of an email, the receipt of an SMS or the establishment of a telephone connection. They are supplemented by components for additional functionalities, such as the conversion of a text into speech or for database functions.

For the compilation the components to a complete System must the components over their interfaces are interconnected. Here are the Components do not necessarily share a common physical Place to be gathered. You can Instead, they also exist remotely if their interfaces have appropriate Networks are connected. Such a system made locally from each other removed components is called a distributed component architecture designated. As explained in section 2.2.3, the network and Basic services for an I & K service often provided by different providers, so that an architecture for I & K services mostly is a distributed system.

The components of a service platform must be properly coordinated to provide a particular I & C service. In many cases, this control functionality is consolidated in a central service control. Such a service control engages, as in 54 shown, via a suitable signaling network to the control interfaces ("API") of the components to use the network and basic services offered by the components.

7.1.1 The prototypical service platform

• • Ein Softwareprogramm ermöglicht den Versand von Emails. Es kann auf jedem Linux-Rechner gestartet werden, der ein eingerichtetes 'mail' Programm zur Verfügung stellt. Der Text der Email kann der Komponente entweder als Parameter beim Aufrufen der Sendefunktionen übergeben werden oder aus einer angegebenen Datei vom Fileserver eingelesen werden.
• • Durch ein weiteres Programm wird der Empfang von Emails realisiert. Dieses Programm läuft auf einem Mailserver und überprüft in regelmäßigen Abständen das angeforderte Emailverzeichnis auf eingegangene Nachrichten. Der Text der Email kann entweder als Parameter der Signalisierungsnachricht für den Empfang der Email an die Dienststeuerung übergeben oder als Datei auf dem Fileserver abgelegt werden.
• • Mittels eines an einem Rechner angeschlossenen Mobiltelefons ist der Versand und Empfang von Kurznachrichten (SMS) über die Mobilfunknetze möglich. Auch hierbei kann der Nachrichtentext entweder über einen Parameter der Signalisierungsnachricht oder als Datei übergeben werden.
• • Ein weiterer Rechner der prototypischen Dienstplattform ist mit einer Einsteckkarte für den Anschluss an das ISDN Telefonnetz ausgerüstet. Mit Hilfe dieser Karte kann ein auf dem Rechner installiertes Programm eine Reihe von Telefonfunktionalitäten ausführen [FF02]. Hierbei stehen durch das ISDN-System zwei Telefonkanäle zur Verfügung. Die ausführbaren Funktionen umfassen den Auf- und Abbau von Verbindungen, das Aufnehmen und Abspielen von Ansagen und das Erfassen gedrückter Tasten am Teilnehmerendgerät durch die dabei erzeugten DTMF-Töne. Des Weiteren können durch das System zwei erstellte Telefonverbindungen zusammengeschaltet werden, so dass die beiden verbundenen Teilnehmer miteinander reden können.
• • Auf Basis eines Konvertierungsprogramms des MBROLA-Projekts [Mbr04] ermöglicht eine weitere Komponente der Dienstplattform die Umwandlung von Text in Sprache. Die Sprache wird dabei in einem Dateiformat abgespeichert, welches von der ISDN-Komponente über eine Telefonverbindung als Ansage abgespielt werden kann.

The process for developing an implementation for a specified service presented in this paper has been applied to an existing prototype service platform. This platform represents a distributed, component-based, central service control architecture as described in the previous section. The components of this platform are various hardware and software components that implement the following network and basic services:

• • A software program allows the sending of emails. It can be started on any Linux machine that provides a set up 'mail' program. The text of the email can either be passed to the component as a parameter when the send functions are called or can be read in from a specified file by the file server.
• • Another program is used to receive emails. This program runs on a mail server and periodically checks the requested email directory for incoming messages. The text of the email can either be passed as a parameter of the signaling message for receiving the email to the service control or stored as a file on the file server.
• • By means of a mobile phone connected to a computer, the sending and receiving of short messages (SMS) over the mobile networks is possible. Again, the message text can be passed either via a parameter of the signaling message or as a file.
• • Another computer of the prototype service platform is equipped with a plug-in card for connection to the ISDN telephone network. Using this card, a program installed on the computer can perform a variety of telephone functions [FF02]. In this case, two telephone channels are available through the ISDN system. The executable functions include establishing and releasing connections, recording and playing announcements, and detecting depressed keys on the subscriber terminal by the DTMF tones generated thereby. Furthermore, the system can interconnect two created telephone connections so that the two connected parties can talk to each other.
• • Based on a conversion program of the MBROLA project [Mbr04], another com component of the service platform, the conversion of text into speech. The language is stored in a file format, which can be played by the ISDN component via a telephone connection as an announcement.

For driving through the central service control, the described components offer their functionalities for use via suitable interfaces. Since the components are distributed on different computers, a suitable signaling system must be provided. For this purpose, a system was developed in this work in which all components connect via TCP connections to a central server program ( 55 ). The task of this server program is to receive the signaling messages sent between the components from the sending component and to send them to the destination component via the corresponding TCP connection. The service control also participates in this signaling system as a component of the system.

7.2 The Objects of the Implementation Metamodel

The goal of the implementation phase of MEMICS is, as in 22 shown the creation of a platform-specific model of the implementation of the service on the chosen platform. This model must describe the characteristics and characteristics of the implementation relevant to the chosen platform. In developing a suitable implementation metamodel for the in 54 The component-based service platform type shown is to decide which are the relevant characteristics and properties of the possible service implementations. The following section examines which objects must be represented in the implementation models and which specific properties distinguish these objects.

These Analysis begins with the participants of the service. For her is especially those used by them in a service implementation terminal with its specific properties of importance. different Service implementations can yourself through by the participant during used the service execution terminals differ significantly. For For example, a mobile subscriber is the option to use a mobile device crucial.

Of Further plays the chosen one technical solution for the realization of the media to be transmitted in the service an important Role for the participant. So can for transmission from text messages to subscribers in a service implementation E-mail, whereas another implementation this uses an SMS. Distinguish different technical solutions significantly in quality features the media. These properties concern, for example, the resolution, coding or compression of the media formats used. they have one important influence on the quality of the service perceived by the participant and must meet the specifications of the service's specification. The modeling of this Properties is an important part of the implementation metamodel.

The User data of the service - the Media formats - need, to fulfillment the service specification, transported between the terminals of the participants become. For this purpose, as explained in Section 2.3.1, different transmission networks used by the transferable User data, delay times and the reachable terminals differ. These properties must be in the implementation models be imaged.

The Implementation models can but not limited to the view of the participants, but have to also the technical necessary for the provision of the service Consider systems. This can equipment for generating or processing the user data, for example a Video server or a unit for converting various in the Service media formats. In the considered component-based Service Platform includes in particular those used in the context of the execution of the service Components.

For this Work, these technical systems are summarized below under the term "ancillary equipment". To create an SMS as part of the service flow, an implementation For example, the SMS component presented in section 7.1.1 use the prototypical platform as an accessory. For this, the specific characteristics of this component (connected networks, usable media formats, delay times, etc.) are described in the implementation model.

For the presentation of the terminals, media formats, transmission networks and additional devices used in the service, four types of objects in the implementation models are used in MEMICS used. Like the MOF diagram of the implementation metamodel in 56 shows that these four types are derived from a parent type "service_component".

each Object of the implementation models contains an attribute "name" for identification the object with a name. The ones used in an implementation terminals are modeled by objects of type "terminal" ("Content"), transmission networks ("Network") and used in the implementation accessories ("Device") are defined by objects represented the types mentioned. The specific properties the objects are described by attributes assigned to them. These attributes and the other properties of the four object types are explained below.

7.2.1 Media Formats ("Content")

First of all, the media formats that are represented in the implementation models by objects of the "content" type are considered.There are often close relationships between the various technical media formats 57 Therefore, the different media formats can be arranged in a hierarchy structure by a link "subtype → parent." The media format "parent" represents a generalization of the subtext format "subtype." For example, subordinate formats for special types of emails, such as emails that contain only text or emails of limited size, provided that the subordinate media format is fully contained in the parent, so if a media format can be transmitted over a particular network, so too All subordinate media formats can be transmitted over this network A terminal can also process all subordinate media formats if it can process the higher-level media format.

Of Further can over the link "payload → carrier" of the implementation metamodel be described that a media format ("payload") as user data within another Media format ("carrier") are transported can. For example, the media format Email can be used as user data in a media format for IP data to be transported. The media format Email can thus be used over all Nets are transported, which transport the media format IP can.

The media formats are further divided into moving ("flow_content") and still ("still_content") media. The quality-determining properties are characterized by type objects. 58 shows the types of objects usable for moving media that can be used to describe audio ("audio"), video ("video"), character streams ("flow"), and data streams ("dataflow"). Immobile media can interact with the in 59 types for images ("Image"), text ("Text"), and data packets ("Datapacket").

The Properties of the media types, as in the media classes of the service model, by quality parameters described as attributes in the type objects. At the quality parameters however, the media types are technical parameters which characterize the respective technical realization. The Data types of the attributes ("PositiveValue", "QualityType", etc.) correspond those of the service meta model.

On the basis of the objects presented, the media formats that can be used in the presented prototypical service platform, such as in 60 Model shown.

The clarity half is here only for the media format "SMS" the media type contained shown. The media format "file" describes a any file. Describe the subordinate media formats limited File types for Files containing text of any length ("file_text") or limited to 160 characters ("file_text_SMS"). The Media format "file_audio_alaw" describes one File containing audio data as recorded by the ISDN system of the prototype service platform or can be played.

Around the different audio qualities in the different telephone networks express to be able to different media formats for the GSM mobile telephony networks ("telephony_GSM") and the ISDN ("telephony_ISDN") are modeled. For the cases in which these quality differences can not play a role on the network-specific media formats subordinate media format "telephony_PSTN" become. It represents the lowest common denominator of the network-specific Media formats.

Unlike the media formats just described for telephony, each audio under The media format "ISDN_1B_rawData" describes the pure data transmission in the ISDN and therefore contains an object of the "Dataflow" type as the media type.

The DTMF tones how they can be generated with the keys of a telephone described by the media format "DTMF" contains a media type of the possibility for signaling 16 different characters as a character stream ("Charflow") describes Media format "telephone_call_signaling" is used in cases in the modeling used in which the signaling of a telephone call as information transmission - for example to start a service - used becomes. Since no further user data is transmitted here, it contains none Media type.

7.2.2 Transmission networks ("Network")

For transmission of the media formats between the terminals of the participants different transmission networks are used. They are modeled in the implementation models by objects of the type "Network." These objects can also be modeled as in 61 shown to be arranged in a hierarchical structure by a link "subnetwork → parent".

Subordinate Networks ("subnetwork") represent this a part of a parent Net ("parent"). So that can general telephone network ("parent") into different Network types such as GSM and ISDN ("subnetwork") Network must have all the skills the parent network fulfill can, however, may have more advanced skills to have. So the GSM network can over the abilities of the general telephone network for the transmission of speech also send SMS.

to Modeling the over the networks are transferable Media formats contain the "Network" objects with "Transported_content" shortcuts to the corresponding media format objects ("Content") in the network usually occurring transmission delay specified become ("delay_in_ms").

The modeling of networks that can be used with the prototype service platform shows 62 , The transmittable media formats ("Transported_content") are listed directly in this figure as attributes of the networks ("transp."), Each containing the transferable media format and the delay time.

Also if the central used by the prototype service platform File system is not a network in the true sense, it becomes the Exchange of files between the components of the service platform used and therefore in the implementation models as a network ("filesystem") modeled, which the media format "file" with a delay time transmitted from 1 to 100 ms can.

The general telephone network ("PSTN") is through two subordinate subnets GSM and ISDN complements which additional specific transmission capabilities exhibit.

7.2.3 Terminals ("Terminal")

The terminals used by the subscribers of a service are represented in the implementation model by objects of the "terminal" type 63 shows that the "use_environment" attribute can be used to describe whether the terminal is predominantly used in a private or business environment.The attribute "mobility" describes whether it is a stationary or a mobile terminal. These two attributes support the selection of a terminal matching the service specification.

Have terminals furthermore connections ("connectivity") .Each of these connections describes the ability of the terminal, above specified Networks ("Network") certain media formats (Attribute "processed_content" of "Connectivity_content") to send or (attribute "direction"). The attribute "delay_in_ms" can be used by the terminal conditional delay time be specified.

In connection with the prototype service platform, a number of terminals can be used. A possible modeling of these terminals for the implementation models shows 64 ,

With the terminal "PC" can this Media format "email" over the network "internet" with a delay of 10 to 100 ms are sent and received. Model three different telephone terminals the specific skills the phones in the ISDN ("phone_ISDN") and the GSM networks ("phone_mobile") and the general Skills in all telephone networks ("phone_any").

7.2.4 Additional devices ("Device")

All further, in addition to the central service control necessary technical equipment are modeled as auxiliary devices in the implementation models. These are in particular those for the production or processing of the media formats necessary systems. In the case of the prototype service platform this includes all components listed in section 7.1.1 Platform.

For the modeling of ancillary equipment, the implementation metamodel contains the in 65 Each device contains any number of "Content_unit" objects. These model the individual components of the attachment. involved in the production or processing of the media formats. Here, a distinction is made between three types of these components. "Port" objects describe all connections of the auxiliary device to external networks The attribute "connected_with" designates the connected network. The device's building blocks, which represent sources and sinks of media formats, are described by "Data_unit" objects, whereas a building block that can convert an incoming media format to another outgoing media format is modeled by a "Converter" object. The time required for the conversion is specified by the attribute "delay_in_ms".

Next these building blocks must now be modeled in the additional equipment, how the respective media formats are exchanged between the blocks become. For this purpose actions ("Action") are added to the "Device" object. each Action describes the transport of a media format ("transported_content") with a specified Delay Time ( "Delay in ms ") between the building blocks identified by the connectors. The direction of the media transport is indicated by the attribute "direction" from the perspective of the Block described.

The presented modeling describes the components of the prototype service platform for the implementation model. 66 shows a graphical representation of the models for the component to send emails. As described in Section 7.1.1, the text of the e-mail can either be passed as a parameter at the poll or read from a text file. For the transfer as parameter, the model ( 66 , left) a source ("Data_unit") with the name "mail_from_parameter" is inserted, from which an action transfers the media format "email_onlyText" to the port "sendmail". The specified delay time of the action of 100 to 1000 ms describes the processing time occurring in the component until the e-mail is sent.

If, on the other hand, the text of the e-mail is to be read from a file, then in the model of the component ( 66 , right) the file format read by the file system "file_text" converted in a converter "mail_from_text" in the media format "email_onlyText".

In a similar way, the component for modeling emails can be modeled. Again, the text of the received email can be passed either as a parameter of the sent to the service control signaling message ( 67 , left) or as a text file on the file server ( 67 , right).

The Component of the service platform for receiving and sending SMS messages can be modeled in the same way. These are the Media format "email_onlyText" replaced by "SMS" and the network "internet" through "GSM".

The modeling of the ISDN component with the different possible telephone functionalities shows 68 , The first variant (top left) represents the ability of the components to detect incoming calls. For this, the media format "telephone_call_signaling" is routed to a sink "call_detector". The component can establish a connection by accepting an incoming call or by actively initiating a call. The ISDN system can simultaneously have two connections for which two connections to the ISDN network are modeled in the model ("port0" and "port1").

With an existing connection, the component can perform a number of functionalities. First, it can retrieve an audio file in the ISDN-specific data format ("ALAW") from the file server and play it over the connection (in 68 The converter "audio_converter" for the conversion of the media formats "file_audio_alaw" and "telephony_ISDN" is also used for the in 68 Middle case shown on the left to record audio data into a file.

Using a "DTMF_receiver" sink, the component can recognize and analyze the DTMF tones generated with the keys of a telephone ( 68 Middle right). This capability can be used to enable interactions of the subscriber with the service control (eg, selecting a menu item, entering a PIN).

If there are connections on both ports of the ISDN component, the component can interconnect these two connections. For this purpose, the incoming data of the two connections are forwarded to the respective output of the other connection. In the implementation model of the component ( 68 bottom left), this is represented by an action in which the ISDN_1B_rawData media format is bidirectionally transmitted between the two ports, in which case it may be any data that does not necessarily represent an audio medium, in this way interconnected connections, the component's ability to recognize DTMF tones may also be activated so that the component registers incoming DTMF tones on both connections ( 68 bottom right). The presented models describe the extensive functionalities of the ISDN component.

The component of the prototypical service platform for the conversion of text into speech can be explained as in 69 Modeled on the left by a converter, which converts the media format "file_text" coming from the file server into the media format "file_audio_alaw" and sends it back to the file server. The program used for the conversion requires a certain conversion time for longer texts, so that a delay time of 0.5 to 20 seconds is modeled in the converter module of the model.

Also, the file server implicitly mentioned in the description of the prototype service platform in Section 7.1.1 must be described for the implementation model. This in 69 The model shown on the right describes the file server as a source and sink for the media format "file", which is transported via the "filesystem" modeled as a network.

With The models presented are all within the scope of the prototype Service platform usable terminals, Media formats, networks and accessories described. You can now to create a technical model of the implementation of a Service be used.

7.3 Compiling a technical model

aim Creating an implementation model is the description the structure and the specific characteristics of the technical Implementation of a service. For this purpose must from the modeled blocks the platform creates the overall technical model of the implementation become. This model describes which devices, networks, media formats and accessories for the Realization of the service used and in what way it be interconnected.

to Creating the implementation model will be the terminals and the Ports of accessories via networks connected with each other. The transferable media formats result from the modeled capabilities of networks, terminals and ancillary equipment.

at When creating an implementation model, note that this in the context of MEMICS a given service specification fulfill should. Therefore, it must be ensured that the chosen technical Realization meets the respective requirements of the specification. For this MEMICS defines a set of consistency rules that based on the formal meta-models the consistency between service model and implementation model.

7.3.1 Consistency rules

The task of the consistency rules is to ensure that a created implementation model is a valid representation of the given service model (cf. 24 ). On the one hand, these rules have to give the developer certain options, so that he can select a suitable one from the different possible implementations. On the other hand, the rules should ensure that the chosen implementation fulfills the specification through appropriate restrictions [KWB03]. Here is a certain balance to be made.

Within MEMICS, an implementation model must conform to the following consistency rules to be a service specification-compliant implementation of the service:
Consistency Rule 1: "Each contiguous engineering submodel of deployment components is associated with a service state of the specification."

A compilation of implementation components whose ports and terminals are interconnected via networks represents a coherent technical submodel. All submodels of the implementation model are assigned to exactly one service state of the specification. This splits the implementation model down to the individual service states of the specification.
Consistency rule 2: "All end devices of the implementation model are assigned to subscribers of the respective service status. Mobile subscribers can only be assigned to mobile devices. "

The terminals represent the interface between the subscribers of the service and the communication channels. The attributes describing the predominantly private or business use are intended to assist the developer only in selecting a suitable terminal and are therefore of a purely informative nature.
Consistency rule 3: "Within a service state, the requirements of the media exchanged between the participants in the service model must be met by the media formats that can be transferred between the participants' devices in the implementation model."

For this rule, it must first be determined for each service status which media in the service model is exchanged between the participants. It then has to be examined whether a suitable media format can be transmitted in the implementation model between the terminals of the participating subscribers for each of these media. In order to compare whether the technical characteristics of the media formats meet the requirements of the respective specified media, suitable metrics can be created, since the physical properties of the media can be largely derived from the technical parameters of the media formats. For an audio medium, for example, it may be required that the attributes of a specified medium "spec" relate to the attributes of the corresponding media format "impl" in the following relationship:
impl.number_of_channels ≥ spec.number_of_channels
impl.samples_per_second ≥ 2 · spec.maximum_frequency
impl.quality.MOSvalue ≥ spec.quality.MOSvalue

For some of the property values, however, only a subjective assessment can be made. For example, the influence of the compression factor of a media format on the perceived quality can only be assessed subjectively. Therefore, in some cases, the developer must decide for himself whether a chosen media format can meet the requirements of the specification. However, the selected property parameters will, in many cases, allow a far-reaching preselection.
Consistency rule 4: "The transmission times of the media formats between the participants must not exceed the requirements specified in the specification for the communication relationship."

Here have to now for those transferred in the implementation model Media formats the end-to-end delay times from the individual delay times the participating terminals, Nets and accessories be calculated. The maximum times are allowed in the service model for the corresponding media defined allowed delay times do not exceed.

Under Consideration of the presented consistency rules can now be added to the specification appropriate implementation model for a service. To clarify the application of the rules, below an implementation model for described in Chapter 6 exemplified "click-to-talk" service.

7.3.2 Implementation Model for the "click-to-talk" service

The service model of the click-to-talk service created in Chapter 6 contains three service states (cf. 45 ). For each of these three service states (consistency rule 1), a technical submodel is subsequently developed which describes a possible technical realization of the service state.

Service status "ReadCatalog"

In the first state of service, the customer scrolls through a catalog and can signal his desire for personal advice via the "button" signaling channel.The implementation model requires the creation of a technical submodel that describes an implementation of this signaling channel. 70 shows a possible submodel created from the modeled elements of the prototype service platform.

In this submodel, the customer is assigned a PC as a terminal device. As the customer through the in 31 With the "PrivateCustomer" class specified as stationary, a stationary terminal can also be assigned to it (Consistency rule 2) .This terminal, which is connected to the "internet" network, can request it by sending an email consisting of text ("e_onlyText" media format). The sending of this email can either be done explicitly by using an email program or by pressing the button of a corresponding website implicitly from the browser program out.

The e-mail sent, as the implementation model shows, is received by the e-mail receiving component of the service platform. Since no explicit usable medium is transported in the specified signaling channel "button" of the service model, it is not necessary to check the consistency rule 3. The addition of the delay times of the implementation model results in an end-to-end transmission time of 1101 to 11110 ms for the transmission of the e-mail. This is within the allowed delay time of 60 s of the in 39 Thus consistency rule 4 is also met and the partial model shown represents a valid implementation of the service state.

Service status "Consultation"

In the "Consultation" service state, the customer and the consultant should be connected by a real-time voice channel.To this end, the use of a telephone connection between the two subscribers within the framework of the prototypical service platform is an option 71 ,

In this case, the consultant is assigned an ISDN telephone ("phone_ISDN") as the terminal, and the customer can in turn use any telephone ("phone_any"). To establish the connection between the two terminals, the ISDN component of the prototype service platform is used. The consultant's ISDN telephone is connected via the "ISDN" network and the customer's telephone via the "PSTN" network to the ports of the ISDN component. The connection of the network "PSTN" to the connection "port1" connected to the network "ISDN" is possible here, since the network "ISDN" has been defined as a subnet of the network "PSTN" (cf. 62 ).

The bidirectional media format transmitted between the terminals is "telephony_PSTN" 60 It is transported via the "ISDN_1B_rawData" media format and therefore transmitted between the two ports in the ISDN component Since it also represents a subordinate format of the "telephony_ISDN" media format, it can be transported over the "ISDN" network instead of this media format and transmitted by the Terminal "phone_ISDN" are processed.

To Consistency rule 3 is now by comparing the quality parameters Check the media class "Voice" with the media format "telephony_PSTN" to see if the media format meets the requirements of the specification. For this Example is without explanation The examination believed that the quality of the media format "telephony_PSTN", which is the voice quality of a any telephone connection complies with the specification.

The Addition of the individual delay times gives an end-to-end transmission time from 22 to 80 ms for the transfer the media format between the two participants. This is in the frame the permitted delay time of 100 ms defined in the service model (consistency rule 4). Thus fulfilled Also, this part model the consistency rules and provides a possible implementation of the service state "Consultation".

Service status "Notification"

in the last service status should be sent to the customer a message if the desired voice channel between customer and consultant could not be created. In the Implementation of the service is the participant an email Posted.

Im in 73 shown partial model is assigned to the subscriber again the PC as a terminal. The creation of the email is done by the email sending component of the prototype service platform. The network "internet" is used for the transmission, resulting in an end-to-end transmission time from 1101 to 11010 ms, which fulfills the maximum transmission time of 20 s specified by the specification (consistency rule 4). The used media format "email_onlyText" is also suitable for the transmission of the required notification (consistency rule 3).

The overall technical model the "click-to-talk" service

By the creation of the three partial models shown could be for each Service state of the specification found suitable implementations become. The combination of the three submodels results in the overall technical model this implementation of the "click-to-talk" service. The model So far, however, only provides the static part of the implementation because there are no statements about the realization of the necessary flow logic makes. For the description This dynamic behavior of the implementation must be the implementation model be extended appropriately.

7.4 Description of the dynamic service behavior

Next the representation of the terminals used for the realization of the service, media formats, networks and components must also express the implementation model, such as the process defined by the specification of the service implemented becomes. For the description of the dynamic behavior of the service implementation be for it first the interfaces between the auxiliary devices and the service control modeled. Subsequently based on these interfaces the necessary program logic the service control to realize the specified service flow logic to be created.

7.4.1 Modeling the Interfaces for service control

For use by the central service control, the additional devices provide suitable interfaces ("API" in 54 ). The service control can call functions of the additional devices via these interfaces and receives messages from the additional devices. For example, the ISDN component can be sent the 18 different messages listed in Table 7.1, which each activate specific functions of the ISDN component.

Tabelle 7.1: An die ISDN-Komponente schickbare Nachrichten

Table 7.1: Messages sent to the ISDN component

The ISDN component can in turn send 34 different messages to the service controller. These messages signal, for example, to the service control the success or failure of a called function. For the implementation model, these messages are modeled with objects of type Signal ( 72 ). They contain the name of the message and a list of the parameters contained in the message.

The Choice of possible Messages sent to an attachment or that of this one can be sent varies greatly with the particular state in which the attachment located. Thus the message for interconnecting can be sent to the ISDN component two connections are only sent, if at both haven the ISDN component telephone connections exist. This results in fixed possible procedures of exchangeable messages, which in their entirety constitute a protocol represent [JW98].

Protocol definition with machines

One Such protocol defines in which possible sequences the messages can be exchanged between the service control and the auxiliary device. to Description of these protocols will be available in MEMICS state machines used. A state machine is a system with a lot of interior conditions and possible Input and output messages.

• • Endliche Zustandsmenge: Der Automat kann nur eine endliche Anzahl an unterschiedlichen Zuständen einnehmen. Sie bilden die Zustandsmenge Z.
• • Ein- und Ausgabenachrichten: Es existiert eine Menge E möglicher Eingabenachrichten, die an den Zustandsautomaten gesendet werden können und eine Menge A möglicher Ausgabenachrichten, die der Automat versenden kann.
• • Zustandsübergangsrelation: Es existiert eine Relation R ⊆ Z × (E∪ε) × A × Z, welche die möglichen Zustände und Eingabenachrichten auf Folgezustände und Ausgabenachrichten abbildet. Das Element ε steht hierbei für „keine Eingabenachricht".
• • Startzustand: Ein Element z₀ der Zustandsmenge Z ist als Startzustand markiert.

Depending on the type of state quantity and the relationship between state changes and the input and output messages, different types of state machines are distinguished (for the definition of the different types, see for example [Fri95]). The state machines used in this work to describe the interface protocol of the attachments are finite state machines. Such a machine in this work consists of the following elements:

• • Finite state quantity: The automaton can occupy only a finite number of different states. They form the state quantity Z.
• Input and Output Messages: There are a lot of possible input messages that can be sent to the state machine and a set of possible output messages that the machine can send.
• • State transition relation: There exists a relation R ⊆ Z × (E∪ε) × A × Z, which maps the possible states and input messages to subsequent states and output messages. The element ε stands for "no input message".
• • Start state: An element z _{0 of} the state set Z is marked as start state.

It It should be noted that an additional device is also without an input message (eεE = ε) send an output message and change state can. So sends the ISDN component For example, a message to the service controller when a subscriber the existing telephone connection is terminated. Such state transitions of a Vending machines are called spontaneous transitions.

Of Another is the behavior of the attachment from the point of view of the interface nondeterministic, since the same original state and input message possibly several different state transitions can be performed. So The ISDN component may request the receipt of a "connect0" message to establish a connection on port 0 either with the message "error0" (connection can not be established) or the message "alerting0" called). The external events, which condition the different behavior of the attachment (in this case the accessibility of the called connection) not shown in the interface modeling.

For a simpler description, Cartesian products from state subsets can be used in MEMICS for the state set Z. Thus, the state space of a simplified ISDN component can be modeled from the three state subsets Port0 = (zero, alerting, established}, Port1 = {null, alerting, established} and Bridge = {unbridged, bridged} Connection states of the two ports (null = "no connection", alerting = "subscriber is called", established = "connection exists") The third state subset describes whether the two connections are interconnected (bridged) or not (unbridged) Z of the machine results as Cartesian product Port0 × Port1 × Bridge of these three sets and thus contains 18 state values The starting state z _{0 of} the ISDN component is the state (zero, zero, unbridged).

Out the possible Behavior of the ISDN component can now be the state transition relation determine the interface. For a simplified ISDN component this is shown in Table 7.2.

Tabelle 7.2: Zustandsübergangsrelation einer vereinfachten ISDN-Komponente gänge aufgeführt. Diese Zustandsübergänge bestehen dabei aus gesendeten Ausgabenachrichten und den neu eingenommenen Zuständen. Ein leeres Feld bei den Ausgangszuständen steht dabei für eine unveränderte Übernahme des entsprechenden Eingangszustands.The left half of the table lists the input states and input messages. For a shortened representation, an '*' replaces any element of the corresponding state subset in the input states. In the right half of the table, the possible state for the given input states and input messages is over

Table 7.2: State transition relation of a simplified ISDN component is listed. These state transitions consist of sent output messages and the newly adopted states. An empty field in the output states stands for an unchanged acceptance of the corresponding input state.

The second line of the input states describes, for example, the possible Behavior of the ISDN component when a subscriber is on port 0 is called (Port0 - alerting). The state value of Port 1 (Port1) and interconnection (Bridge) are irrelevant ('*'). In this condition Now, the ISDN component can on the one hand without input message ('ε) a spontaneous state transition To run. In In this case, it sends the output message "established0" (the subscriber has accepted the connection). As a result, Port0 will open set the value established during Port1 and Bridge remain unchanged.

With the same input states On the other hand, the ISDN component can also receive an input message "release0" (connection terminated), whereupon it terminates the connection. It sends the output message "released0" and Port0 assumes the value zero.

Out the state transition relation let yourself see which sequence of input and output messages the interface of the ISDN component are possible. Also each case assumed state values can be specified. So that all state changes of an additional device are recognized from the outside must be assumed that each state change with associated with sending a unique output message. So For example, the service controller can track all state transitions of the accessories and with the help of the state transition relation determine at any time which input messages to send to the attachment and what possible Issue news she can get.

The presented form of the interface specification allows a comprehensive and accurate description of what can be observed at this interface Protocol. The for The state quantities used in the interface specification do not have to inevitably with the inner states of the attachment match. Instead, they are the ones from the outside over the Interface observable states of the additional device.

Verification of the interface specification

With the methods of automaton theory for state space exploration the interface specification is extensively verified. This will be all possible Sequences of state changes and the states thereby achieved in one Graphs shown. It can then be checked whether states are reached can, for the no further state transition more is possible is. Such conditions can can not be left anymore and are called "deadlock".

Also can be checked whether transitions are defined in the state transition relation are never due to the required input states accomplished become. Furthermore, the accessibility of selected states can be checked. For the ISDN component can be checked, for example, whether the state (established established, bridged) can be achieved, in which two telephone connections through the ISDN component are interconnected. On the other hand, it can be checked that, for example, the states (zero, established, bridged) and (established, zero, bridged) never be achieved, since the activation of the interconnection is not makes sense if there is no connection on one of the two ports consists.

The therefor the ISDN component presented interface description provides only a section of the complete Interface of the ISDN component, as it the other functionalities, such as Recording and playing back audio data and accepting DTMF tones not considered. By adding However, other state subsets and state transitions can also do this Behavior can be modeled.

Linking interfaces and Actions

In order to complete the description of the behavior of the additional devices, the actions of the additional devices described in Section 7.2.4 are now combined with the states of the interface modeling. For the actions, it is determined in which states of the attachment they exist. For the ISDN component, it is described, for example, that the in 68 The action shown below on the left, in which the media format "ISDN_1B_rawData" is transmitted between the two ports of the ISDN component, takes place precisely when the interface description of the ISDN component is in the state (established, established, bridged).

Also the further actions of the ISDN component, for example, the Playing and recording audio data can be described assign a suitably extended state quantity. In this way can the connection between executed actions and those at the Interface sent and received messages described become.

Also for the further modeled accessories The prototypical service platform allows interface modeling create the described type.

Use of interface modeling in the implementation model

With the help of the introduced interface modeling, it is possible to determine in which states the interface of an additional device must be located in the individual technical submodels of the implementation model. So must the interface of the ISDN component in the in 71 The sub-model for the service state "Consultation" can also be found in the state (established, established, bridged) The necessary states of the additional devices can also be determined for the other submodels presented respective submodels have to be achieved.

7.4.2 Program Logic of service control

For the implementation model, the technical submodels have been created for each service state of the specification so far and with the aid of the interface modeling for all additional devices in the submodels the necessary conditions. 74 shows the created for the implementation of the "click-to-talk" service submodels with the necessary states of the accessories arranged in the flow graph of the service.

in the Service state "ReadCatalog" is supposed to be the email receiving component here in the state parameter are. In the associated interface modeling parameter indicates the status of the email receiving component, in the text of an incoming email in the parameters of a Signaling message to the service control sends. The interface description contains the email sending component contrast, only a single state zero, since the choice of shipping (Text as a parameter or from a file) through the different, reached messages sent to the component.

The tasks of service control

Out The presentation shown can now be the tasks of the service control determine the implementation of the specified service flow logic accomplished Need to become. So must the service control during the transition when starting the service to reach the service state "ReadCatalog" the email receiving component from the initial state to the state parameter. Within this service state It must be according to the service specification on the occurrence of the event "button.signal = needHelp "wait. In the implementation model for the service state "ReadCatalog" corresponds to this Event of the arrival of an email, which is the service control of the email receiving component is notified by the message "newMail". The occurrence of the message "newMail" may therefore be for service control the event "buttonsignal = needHelp "equated so that the service control on the arrival of this message the service status must leave the transition "needHelp".

In This transition from the service state "ReadCatalog" to the destination service state "Notification" must be the service control now on the one hand, the email receiving component back to its original state reset to default, since this is no longer needed in the further course of the service. Furthermore, the service control must service the ISDN component from the startup state (null, null, unbridged) in the state defined in the submodel of the service state "Notification" (established, established, bridged). The occurrence of an error in Establishment of the connection leads here after the service specification to the alternative branch "callSetupFailed", which leads to the service state "Notification".

Also for the further service conditions and transitions can be performed by the service control Determine tasks accordingly. To complete the implementation model it can be used for execution These tasks necessary program logic for the service control to be developed.

Development of the program logic for the service control

to Description of the program logic of the service control are in MEMICS in turn used vending machines. This is done for each transition and each Service state of the service flow graph separated by a separate machine modeled. The state quantities of these machines result as Cartesian products of state quantities of all accessories that involved in the corresponding transition or service status.

to explanation is the automaton for developed the transition "needHelp" from the service state "ReadCatalog" to the service state "Consultation" here are tasks to be performed by the service control, as described above, from the transfer of the Email receive component in the initial state and the transfer of the ISDN component from the start state to the state (established, established, bridged). From the Cartesian product of the state quantities of these two additional devices results the state quantity of the corresponding service control automaton for this Transition.

The necessary lines of the table for the state transition function can be determined using the interface specification of the two additional devices. Table 7.3 shows on the left side the necessary states of the additional devices (input states) and the received message, which lead to a state transition. In the right-hand column, either the amount of messages to be sent or the output path to be taken, which leads to the termination of this machine, are indicated for the state transition. The resulting sequential states of the additional devices are not included in this table because they can be tracked by the service control using the interface specifications of the accessories by the incoming messages. In this modeling, the service control leads quasi "Book" about all state changes of the accessories.

Tabelle 7.3: Zustandsübergangsfunktion für die Transition "needHelp"

Table 7.3: State transition function for the "needHelp" transition

The individual lines of the table now represent the program logic of the service control at first In the initial state of the additional devices, the message "unallocate ()" is sent to the email receiving component (line 1 of Table 7.3). This message shows the Email receive component to return to the initial state and is acknowledged by the message "unallocated ()" Reception of this message by the service control is by line 2 causes two messages to be sent to the ISDN component.

By the first message ("connect0") should be the ISDN component on port 0 establish a telephone connection to the consultant and through the second message ("connect1") corresponding to one Telephone connection on port 1 to the customer. Depending on the behavior of the participants can doing different messages from the ISDN component to the Service control sent back become. The service control follows with the help of the interface specification the resulting state changes. If both telephone connections could be successfully established, so the ISDN component is in the state (established, established, unbridged). In this case, the input states of line 3 are the state transition table fulfilled and the service controller sends the message "bridge" to interconnect the connections to the ISDN component. After performing this interconnection line 4 ends the machine because the service status "Consultation" has been reached. The program logic for This service status is modeled in a separate machine.

The last four lines of Table 7.3 terminate the described machine, if the service controller receives a message from the ISDN component receives which signals an error in the connection establishment. In this case the alternative route "callSetupFailed" will now be used in the service logic, with an '*' at the input states again for any value of the corresponding partial state quantity.

On the manner described can now all for the specified flow logic necessary service control machines be modeled. The entire program logic of service control consists of machines for each transition and each service state of the specified run graph, which are connected together according to the sequence graph.

Check the program logic

at the described development of the program logic for the service control The developer is largely guided by the formal interface specification the accessories supported. For a given development step, the possible receivable and sendable messages from the interface specifications determine. Through state space exploration can be ensured be that unreachable or not relinquishable conditions be defined in the program logic. These tasks can be done by adopted suitable tools which make it easier for the developer to create the program logic. Such a tool is presented as an example in Section 7.6.

The determined by the interface specification possible Sequences of the input and output messages of an additional device can Further visualized by suitable tools. This can do that To help developers understand how this attachment works.

In spite of the extensive support through the formal interface description, the developer must in some cases in addition to more precise Knowledge of the operation of the auxiliary equipment used. This For example, it is necessary to understand the effects of sending to the attachment To consider messages, the above the behavior described with the actions in the models. Also, the exact meaning of each parameter in the news is not covered by the interface description. she must therefore from the developer of the further documentation of the respective platform component be removed.

7.5 Notation of Implementation Objects in XML

The used to create the implementation models objects (terminals, networks, Media formats and accessories) provide a model description of those in the considered service platform existing elements. Explicit modeling of these objects serves in particular the reusability in a variety of Implementation models. For this purpose is a suitable, versatile usable notation of the modeled objects necessary.

Out described in section 5.2.4 establish was also for this purpose a data format based on XML developed. It combines machine readability with one too for the Understandable people Shape. To define the data format named "Service Platform Component Description "(SCD) a corresponding XML schema created.

The schema of the SCD contains definitions for the four types of implementation objects. They correspond to an implementation of the presented MOF diagrams in an XML format. 75 shows a graphical representation of the terminal definition scheme 76 the SCD document based thereon is described for the description of the terminal "telephone_any".

The Elements of the service platform noted in this way can be used with Read in appropriate tools and create implementation models be used. This procedure allows a flexible modification the existing platform components and the rapid expansion the platform with new components. Any resulting changes the model objects can in the XML-based data format. development environments can then the changed Read object descriptions and the new model objects for development of services.

So For example, when purchasing a new component for a service platform from the component manufacturer an SCD document with the model description supplied with this component. This allows a simple and fast Integration of the new component in the environment for the development of Services. Also the use of network and basic services by third parties can be offered by the proposed formal description the interface are significantly facilitated. A faulty one Control of these interfaces can be largely avoided.

7.6 Prototypical Software Tool MEMICS transformer

in the As part of this work, a prototypical software tool called "MEMICS Transformer "to Creation of implementation models based on the presented Method developed. It should show the applicability of the presented Method for implementing service specifications on a component-based Demonstrate service platform.

task the tool is the support the implementation of a service specified by the USD on one component-based service platform. For this purpose, the tool can Based on the USD created service models and the descriptions import existing platform components based on the SCD. The Program supported the developer in more diverse Way in creating a service specification Implementation model from the platform components. With the tool can both the technical submodels and the program logic for service control to be created.

7.6.1 Preparation of the technical part models

to Creation of the technical submodels for a service implementation must first the service specification will be read in based on the USD. These Specifications can For example, with the help of the tool described in section 6.7 "MEMICS Designer "created become. Subsequently can the descriptions of the elements of the intended implementation Platform based on the SCD.

Now you can start creating the technical submodels for the individual service states of the specification. This is the in 77 divided main window of the developed software tool divided in half.

In the upper half the imported service model is displayed with the individual service states. In the lower half can create an implementation model based on the imported platform elements become. You can do this in the graphical representation the platform elements to technical Submodels are assembled. When connecting terminals and accessories the program can automatically select suitable networks. Created for Submodels can check the tool whether these meet the requirements of the service specification.

The Tool can also be instructed, independently possible sub-models to develop and thus possible Suggest implementations of the service. To do this creates the Program internally one after the other all with the given platform elements potential Submodels and then rate them how well these requirements meet the specification. The goodness the fulfillment The requirements are evaluated with a score.

These Score is determined by the degree of compliance in the consistency rules 3 and 4 (see section 7.3.1). The user will be afterwards for all service states the submodels that meet the requirements of the specification sorted offered according to their score. To limit the search space can the number of additional devices that can be used in a submodel can be limited. The calculation time of the program is strongly influenced by this limit.

• • Eine SMS wird mit der Email-Sendekomponente über das GSM-Netz gesendet und vom Teilnehmer mit einem Mobiltelefon empfangen.
• • Eine Email wird mit der Email-Sendekomponente über das Internet gesendet und vom Teilnehmer mit dem PC empfangen.
• • Eine Audiodatei wird vom Fileserver genommen und mit der ISDN-Komponente dem Teilnehmer über das Telefonnetz vorgespielt.
• • Eine Textdatei wird vom Fileserver mit der Text-zu-Sprache-Komponente in eine Audiodatei umgewandelt und diese dem Teilnehmer mit der ISDN-Komponente über das Telefonnetz vorgespielt.

On a computer with a 2.4 GHz processor, for example, possible submodels for the specification of the "click-to-talk" service developed in Chapter 6 were determined on the basis of the elements of the described prototype service platform. For the "Notification" service state, in which the subscriber is informed by a message channel about the failure of the connection establishment, the 207 partial models that are possible with only one additional device can be tested in less than a second, and the number increases with up to two additional devices in a submodel possible submodels for this service state already have 15076 possibilities that can be tested in two seconds.For the verification of 1482027 submodels with up to three additional devices already four minutes are needed.The following possible submodels for the implementation of the Service status "Notification" found:

• • An SMS is sent with the e-mail sending component via the GSM network and received by the subscriber with a mobile phone.
• • An e-mail is sent via the Internet with the e-mail sending component and received by the subscriber with the PC.
• • An audio file is taken from the file server and played to the subscriber over the telephone network with the ISDN component.
• • A text file is converted by the file server with the text-to-speech component into an audio file and this is played to the subscriber with the ISDN component via the telephone network.

7.6.2 Development of the program logic

After creating the submodels for the service states, the program logic of implemen- tation must be development model. In the creation of the lines necessary for the state transition tables of the machines, the developer is supported by the created tool far reaching. The in 80 The editor shown in each step represents the possible states and messages of the components to the developer in each step. The possible resulting states resulting from the created lines are calculated on the basis of the interface descriptions of the additional devices. Unreachable or unavailable states are marked.

By the procedure described ensures that the developed Program logic in all cases conform to the specified interfaces of the accessories. It can no messages are sent to the accessories that are sent from this can not be processed. Furthermore, all possible receivable messages of the accessories in the development of Program logic considered.

7.6.3 Testing the Service Implementation

With the creation of the program logic for the machines of all service states and Transitions is fully described the implementation model of the service. For one given service control from the program logic of the implementation model a suitable Create control logic automatically.

To test the created service, the "MEMCIS Transformer" tool can be used directly as a service control for the described prototypical service platform by executing the created machines in the tool and sending the messages to the auxiliary devices via the signaling server described in section 7.1.1 Conversely, the messages sent by the components are forwarded to the tool via the signaling server, so that the implementation of the service can be started directly from the development tool and tested with the real platform components the auxiliary devices and the received and sent messages ( 78 ).

hereby may be the behavior of the service implementation defined by the program logic at different service processes considered and examined.

The realized tool chain

In the present work, a tool chain was realized with the two presented tools "MEMICS Designer" and "MEMICS Transformator", which prototypically implements the integrated, tool-supported development of I & C services ( 79 ).

Out An existing service idea becomes a formal one with MEMCIS Designer Specification of the desired Created service in the form of a service model. This service model is stored in XML-based format the "Universal Service Description" (USD).

to Implementation of the specified service as part of an implementation is first to choose a suitable platform. If it is a component-based platform, then the Elements of the platform using a standard XML editor through the "Service Platform Component Description "(SCD) formally described.

The Description of the platform components and the service specification can read in by the tool MEMICS Transformer. With the help of this The developer can now implement a service specification-compliant implementation of the service on the chosen Create platform. This is done on the basis of the platform components an implementation model of the chosen service implementation developed. Consistency rules can ensure compliance with the Service specification to be ensured.

The Service logic developed within the service model can be transformed into a completed implementation of the service on the chosen platform. The procedure described in this work was based on a prototype Dienstplattfom applied.

8 summary and outlook

8.1 Content and Results

The increasing diversity of multimedia information and communication services places high demands on the development processes used here. New services need in no time Time to be developed and offered. The realization of the services used networks and platforms are a fast technological Undergone change leading to a high level of heterogeneity technical systems leads. A service therefore becomes common implemented on different technical platforms.

The Analysis of existing procedures in Chapter 4 has a number of shortcomings these procedures with regard to the specific requirements the development of I & C services result. A clear separation of the specification of the desired Service behavior of the way of technical realization this service is rarely given. Many development processes are to specific platforms or specific types of services bound. More universal processes, for example from software development, consider the service-specific requirements inadequate.

In The present work has been a new method of development multimedia information and communication services. The development process MEMICS is based on the concepts of "Model Driven Architecture ". The specification of a new service is provided in MEMICS by the Development of an implementation-independent service model performed. This Model describes the characteristics and requirements of the planned Service based on a formal meta-model. The consistency of created Service models can be verified with the specified verification rules.

to technical realization of a planned service can generally a variety of different technical platforms and systems be used. A specific development process can not be adapted to all platform types alike. The implementation phase from MEMICS can adapt to different platform types adapted to suitable meta-models. In the context of the present Work becomes a metamodel for the implementation of service specifications on a component-based Service platform with central service control presented. The application the procedure on an existing, prototypical service platform is shown as an example.

For the practical Trials of the proposed method were used in this work developed two prototypical software tools that provide a consistent tool chain for the Development of I & K services realize. You can as a basis for the development of other tools are used.

8.1.1 Contributions to this job

• • Durchgängiges Entwicklungsverfahren: Die Arbeit stellt ein Entwicklungsverfahren für I&K-Dienste vor, welches die durchgängige Entwicklung ausgehend von der Spezifikation des Dienstes bis zur Implementierung auf der gewählten Plattform beschreibt. Brüche im Entwicklungsablauf werden hierbei vermieden.
• • Implementierungsunabhängige Dienstspezifkation: Das vorgestellte Verfahren ermöglicht die Erstellung einer implementierungsunabhängigen Spezifikation eines gewünschten Dienstes. Diese Spezifikation abstrahiert von allen technischen Details möglicher Implementierungen des Dienstes. Ein einmal spezifizierter Dienst kann dadurch auf unterschiedlichen Plattformen umgesetzt werden.
• • Die „Universal Service Description" (USD): Zur Notation der Dienstspezifikationen wird in dieser Arbeit eine Beschreibungssprache auf der Basis von XML vorgeschlagen. Die Definition der USD wird mit Hilfe eines XML-Schemas vorgenommen. Das resultierende Format verbindet die notwendige Maschinenlesbarkeit mit einer weitgehend intuitiven Verständlichkeit durch den Menschen. Spezifikationen auf Basis der USD können daher die Grundlage für eine vertragliche Vereinbarung über die Entwicklung eines Dienstes bilden. Implementierung auf komponentenbasierten Dienstplattformen: In der vorliegenden Arbeit wird eine Methode zur Umsetzung der implementierungsunabhängigen Dienstspezifikationen auf komponentenbasierten Dienstplattformen vorgestellt. Ein für diese Plattformen geeignetes Metamodell wurde erstellt.
• • Die „Service Platform Component Description" (SCD): Die in dieser Arbeit vorgestellte Beschreibungssprache SCD erlaubt die flexible Beschreibung der einzelnen Elemente einer komponentenbasierten Dienstplattform. Modifizierte oder neue Komponenten können durch die XML-basierte Komponentenbeschreibung schnell und einfach in den Entwicklungsablauf integriert werden.
• • Formale Modellierung: Die in dieser Arbeit genutzten Modellierungen sind durch Metamodelle auf Basis der MOF formal definiert. Erstellte Dienst- und Implementierungsmodelle können auf ihre Konsistenz überprüft werden. Durch die in der Arbeit vorgestellten Regeln kann weitgehend sicher gestellt werden, dass eine Implementierung den Anforderungen der entsprechenden Dienstspezifikation genügt.

The contributions made by this paper to development of information and communication services can be summarized as follows:

• • Consistent Development Process: This paper presents a development process for I & C services that describes end-to-end development from the specification of the service to implementation on the chosen platform. Breaks in the development process are avoided.
• • Implementation-independent service specification: The presented procedure enables the creation of an implementation-independent specification of a desired service. This specification abstracts from all technical details of possible implementations of the service. A once specified service can be implemented on different platforms.
• • The Universal Service Description (USD): For purposes of notation of service specifications, this paper proposes an XML-based description language, defining the USD using an XML schema, and combining the necessary machine readability with one For example, USD-based specifications may form the basis for a contractual agreement to develop a service Implementation on Component-Based Service Platforms: This paper presents a methodology for implementing implementation-independent service specifications on component-based service platforms Meta model suitable for these platforms has been created.
• • The "Service Platform Component Description" (SCD): The descriptive language SCD presented in this paper allows the flexible description of the individual elements of a component-based service platform Modified or new components can be quickly and easily integrated into the development process thanks to the XML-based component description.
• • Formal modeling: The modeling used in this work is based on meta-models the MOF formally defined. Created service and implementation models can be checked for consistency. By the rules presented in the work can be largely ensured that an implementation meets the requirements of the appropriate service specification.

8.1.2 Fulfillment of the established evaluation criteria

in the Section 3.5.6 became five Evaluation criteria for Service development process presented. They were made of the most mission critical Factors of development processes (section 3.4.6) under consideration derived from the specific requirements of I & C services (Section 2.5). The following is the fulfillment the established evaluation criteria by the in this work presented method "MEMICS" discussed.

separation

The first criterion calls for a clear separation of specification and Implementation in the abstraction levels of the development process.

The Service model used in MEMICS to specify a desired Service allows the description of the requirements, the specific Characteristics and the desired Behavior of the service through an implementation-independent service model. This model developed in the specification phase of the desired Service contains no specific details of the way of a possible technical Realization of the service. A developed service model can work without necessary changes as a specification document for the implementation of the service used on different platforms become.

hereby becomes a complete one in MEMICS Separation between the specification of the desired service and the subsequent platform-specific one Implementation achieved.

I & K service specificity

The Service model used to specify services provides building blocks describing the elemental components of I & C services. For the Subscribers, the communication channels used and the media transmitted in MEMICS prefabricated building blocks, which the way the Set modeling of these service elements. An intuitive and uniform use of the service elements is thereby supported.

The The graphical representation of the specified service flow allows this easy and fast capture of the specification specified by the specification Service behavior. Even complex service graphs that have a variety Contained by participants and communication relationships can be clearly arranged being represented.

In the implementation phase created models and description languages within the framework of MEMICS be the ones chosen Service platform type are adapted. In the present work is a Model for the implementation of services on a component-based service platform presented. It contains adapted building blocks, which contain the description of the used terminals, networks, Media formats and accessories to create the desired Support implementation model.

For further So far, MEMICS does not offer customized models for platform types and description languages. For the use of other types of service platforms must therefore suitable meta models are created.

formality

The used in MEMICS in the specification and implementation phases Models were formally based on the MOF. By the specified Meta-models become the form and structure of possible service and implementation models clearly defined.

The used for the notation of the models are descriptive languages defined by XML schemas. This formal definition allows the Verification of created descriptions by standard XML tools.

The Verification and consistency rules of MEMICS have been used in the present Work described nonformally. A suitable for metamodelling formal language for The definition of such rules has not yet prevailed. However, a number of such languages are being discussed in the OMG. A formal definition of the described rules based on the presented Meta models can be carried out in the presence of a suitable language (see also section 8.2.2).

expandability

to Implementation of a service can be a variety of different technical systems and platforms. A universal one Service development process must therefore be flexible to new platforms can be adjusted.

The explained in this work Procedure for implementing a specified service on a component-based Service platform considered the possibility of changes of used platform. Modifications of the components used or newly added Blocks can a development environment using the presented description language SCD added quickly and easily become. New or changed Blocks can thus flexible in the creation of an implementation model considered become. The specified consistency rules and those given by the meta-model allow predetermined structure also the later Exchanging a component in an existing model. In this case become the resulting inconsistencies and therefore changes to be made of the model visible.

The Implemented implementation meta model can be used for different types of component-based service platforms. In the The elements present in the respective platform can be determined by the building block models be described flexibly. For however, other platform types must be the proposed meta-model adapted or developed a new meta-model.

iterativity

By support An iterative approach is the rapid development prototypes of a new service and the subsequent modification or extension of existing services.

The procedure presented in this work does not specify a specific order in the methodology for creating service and implementation models. In the 25 The procedure shown here shows the basic steps in service development in the context of MEMICS, which, however, can largely be performed in any order. The defined meta-models and the specified consistency rules ensure the internal consistency and correct connection of the created models.

The described "Click-to-talk" service can be retrofitted to the in 5 shown possibility for the customer to choose a later call time to be extended. For this purpose, another service state is inserted between the service states "ReadCatalog" and "Consultation" in the existing service model. In this service state, the desired time behavior of the service can be described with the aid of a timer modeled as a special object. In existing implementations, this newly inserted service state is recognized in the implementation model, and the resulting gap can be appropriately closed by integrating a timer component.

Also In the described implementation, the realization of the message channel in the service state "Notification" by one of in Section 7.6.1 listed variants. So could the participant For example, instead of an email, a text message will be sent. The necessary changes in the program logic are determined by the divergent interface specifications the accessories used in the submodels.

For a created Service Model allows the facility described in Section 6.6 to simulate possible service procedures the early one Evaluation of a planned service. Change requests can be made by modification or Extension of the service graph can be flexibly taken into account.

8.2 Outlook

In In the present work, the basic principles of a new service development process. Result from this a number of wider questions, some of which are referred to below Initiation of future Research work will be briefly outlined.

8.2.1 Implementation on other platforms

The Implement specified services on other service platform types can be treated in further work. For this must for the respective Platform type adapted meta models are developed. These must be the specific properties and the structure of possible implementations describe these platforms.

In an implementation metamodel for those presented in Section 2.3.3 TINA architecture are, for example, the component and session models.

Also in modeling the necessary program logic, the specific characteristics of the chosen platform become. For the implementation on an IN platform (Section 2.3.4) are the function blocks offered by the platform (SIBs). When creating the program logic must considered here are that the service controls used in general no concurrency allow in the created run graph.

8.2.2 Standardization

in the Related to the proposed service development process a series of questions regarding the relationship to current and future Standards. So is first to look at which of those currently in development Standards effects on possible further developments of MEMICS.

As explained in section 5.2.4, is currently being used by the OMG with the "XML Metadata Interchange" (XMI) [OMG03] developed a standardized procedure, which is the illustration of a Enable meta-models to a matching XML schema should. After completing this work could be for the USD and the SCD schemes developed on the basis of XMI. These would be a more universal data exchange with other software tools.

For future uses is the formalization of nonformal in this work described Verification and consistency rules helpful. As part of the OMG are currently a number of proposals for the development of a universal formal language for the work with meta models under the name QVT ("Query Views Transformations ") discussed [GGKH03]. With this language it should be possible Views on models and transformations between models Formally describe the basis of the underlying meta-models. These Language could to formalize the rules presented in this paper to offer.

in the Context of standardization is further to be considered what impact the present work will have on future standards could have in the field of service development.

The proposed type of service specification using the described Dienstmodells can because of their universal usability and the platform-independent Specification in many areas are used. After another Practical experience could be based on the presented service meta model a standardization proposal for developed a new description language for the service specification become.

Also the standardized description of the capabilities and interfaces of platform components, as is the aim of the proposed description language SCD is the flexible and cross-vendor use of platform components facilitate. Any necessary extensions of the presented Language with regard to the variety of functions available Components must be tested by the use in practice. Again, here is one followed by Suggestion for standardization conceivable.

8.2.3 Consideration of Interaction problems

To solve the problem of undesired interactions between different services ("Fea ture Interaction ", Section 2.3.5), the use of formal methods at all stages of the development process is often considered necessary, and further investigations should examine the extent to which the proposed formal service specification can be used.

The Investigations to the early Detection of possible Interactions between services within the specification phase, as it is recommended by the ITU [TTU97a], for example the proposed formal service specification will be facilitated. To do this the service models of different services in the specification phase combined and examines the resulting possible overall processes become. For the combination of several service models are their relationships to describe each other. For example, these relationships must be indicate which participant of a service model at the same time can act as a participant in another service model. On Basis of definition of suitable limiting conditions (for example maximum number of communication relationships of a participant) can possible interactions are detected by the analysis of possible service processes.

in this connection however, only interactions that are independent of a technical implementation through the specified service flow are conditional. Interactions that are different by the way the technical Realization of the services could, on the other hand, be based on the Implementation models are examined.

Appendix A Explanation of the used MOF notation

Appendix B USD specification of the click-to-talk service

bibliography

• [AB02] T.T. Ahonen, J. Barrett: Services for UMTS - Creating Killer Applications in 3G. John Wiley & Sons Ltd, West Sussex, England, 2002
• [AFH + 02] R. Anderson, B. Francis, A. Homer et al .: ASP.NET Developer's Guide. Markt + Technik Publisher, Munich, Of 2002.
• [ALM + 01] A. Alessandra, C. Licciardi, C. Moiso et. al .: Requirements analysis and architecture definition. Eurescom project P1109 "Next Generation Networks: The service offering standpoint ", Technical Information, November 2001.
• [And03] A. Andresen: Component-based Software Development with MDA, UML and XML. Carl Hanser Verlag, Munich Vienna, 2003.
• [Aub03] R. Auburn: Voice Browser Call Control: CCXML Version 1.0. W3C Working Draft, World Wide Web Consortium, June 2003.
• [BBH01] E. Bohlin, E. Brousseau, S. Hultén: Innovation in the Telecommunications Industry. In "Economics of Innovations and New Technology ", pp. 73-87, Vol. 10, No. 2-3, 2001.
• [bem03] bemobile GmbH: SMS-game "Ivan", bemobile GmbH, Hamburg, http://www.handy.de, July 2003.
• [BEP + 00] M. Broy, H. Ehler, B. Paech et. al .: Software Engineering: key to process control and information management. Transfer-Centrum GmbH, TCW report no. 24, Munich, 2000th
• [BG00] R.R. Bhat, R. Gupta: JAIN Protocol APIs. IEEE Communications Magazine, Vol. 38, No. 1, pp. 100-107, January 2000th
• [BHG00] H. Berndt, T. Hamada, P. Graubmann: TINA: Its Achievements and its Future Directions. IEEE Communications Surveys & Tutorials, Vol. 3, No. 1, 2000.
• [BHP + 00] M. Broy, H.-G. Hegering, A. Picot, A. Butterman, M. Garschhammer, R. Hauck, S. Vogel: Communication and Information Technology 2010: Trends in technology and market. Federal Office of Security in Information Technology, SecuMedia Verlag, Ingelheim, Germany, 2000th
• [BJ02] J.-L. Bakker, R. Jain: Next Generation Service Creation Using XML Scripting Languages. In Conference Records of the International Conference of Communications (ICC), New York City, US, April / May Of 2002.
• [BM01] P.V. Biron, A. Malhotra: XML Schema Part 2: Datatypes. W3C Recommendation, World Wide Web Consortium, May 2001.
• [Boc97] P. Bocker: ISDN - Digital Nets for Voice, text, data, video and multimedia communications. knight Publisher, Berlin, 4th ed., 1997.
• [BPSM00] T. Bray, J. Paoli, CM Sperberg-McQueen, E. Maler: Extensible Markup Language (XML) 1.0 (Se cond edition). W3C Recommendation, World Wide Web Consortium, October 2000.
• [Bro95] F.P. Brooks Jr .: The mythical man-month: essays on software engineering. Anniversary ed., Addison Wesley Verlag, 1995.
• [Bro96] M. Broy: Formal description techniques - how formal and descriptive are they? In R. Gotzhein, J. Bredereke (Ed.) "Formal Description Techniques IX - Theory, application and tools. ", Pp. 95 - 112, Conference tape of the FORTE / PSTV '96, Chapman & Hall Publisher, 1996.
• [BZB + 97] R. Braden. L. Zhang, S. Berson et. al .: Resource Reservation Protocol (RSVP) version 1 functional specification. IETF RFC 2205, September 1997.
• [CGMW03] R. Chinnici, M. Gudgin, J.-J. Moreau, S. Weerawarana: Web Services Description Language (WSDL) Version 1.2 Part 1: Core Language. W3C Working Draft, World Wide Web Consortium, June 2003.
• [Coc01] A. Cockburn: Writing Effective Use Cases. Addison-Wesley Publisher, 2001.
• [DH98] S. Deering, R. Hinden: Internet Protocol, Version 6 (IPv6) Specification. IETF RFC 2460, December 1998.
• [DMC + 98] D. Demany. K. Milsted, P. Combes et. al .: SCREEN Engineering Practices for Component-based Service Creation. ACTS project AC277 SCREEN, Deliverable D28, verse 5, December 1998.
• [Ebe96] J. Eberspächer: Subproject C2: Software engineering for communication networks. In "Bavarian Forschungsverbund Software-Engineering ", Application for Establishment to Bayerische Research Foundation, M. Broy et. al., pp. 117-132, Technische Universität München u. a., November 1996.
• [Ebe97] A.P.G. Eberlein: Requirements Acquisition and Specification for Telecommunication Services. PhD Thesis, University of Wales, Swansea, UK, November 1997.
• [Ebe01] J. Eberspächer: The future of the Internet in the light of convergence. In "Internet @ Future", Yearbook Telecommunications and society 2001, H. Kubicek et. al. (Ed.), P. 17 - 27, Hüthig Verlag, Heidelberg, 2001.
• [Ebe03] 7. Eberspächer: Video Digital - Trends and scenarios for an open media world. In "Video Digital - Quo vadis television? ", J. Eberspächer, A. Ziemer (ed.), Pp. 1-9, Springer Verlag, Berlin and Heidelberg, 2003.
• [EH97] A.P.G. Eberlein, F. Halsall: Telecommunications service development: a design methodology and its intelligent support. In Journal "Engineering Applications of Artificial Intelligence, Vol. 10, No. 6, Elsevier science, December 1997th
• [EJL + 99] H. Eertin, W. Janssen, P.O. Luttighuis, W. Teeuw, C. Vissers: A Business Process Design Language. FM'99 - Formal Methods: World Congress on Formal Methods in the Development of Computing Systems, Vol. 1, pp. 76-95, Springer Verlag, Heidelberg, September 1999.
• [Eti95] P.-A. Etique: Service Specification Verification and Validation for the Intelligent Network. Thése N ° 1442, École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, 1995.
• [ETSI01] European Telecommunications Standards Institute: Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1. ETSI TS 102 812 V1.1.1, Sophia Antipolis, France, November 2001.
• [ETSI03] European Telecommunications Standards Institute: Open Service Access (OSA); Application Programming Interface (API); part 1: Overview. Final draft ETSI ES 2002 915-1 V1.2.1, Sophia Antipolis, France, 2003.
• [EVB01] J. Eberspächer, H.-J. birds, Ch. Bettstetter: GSM - Switching, Services and Protocols. John Wiley & Sons. Chichester, England, 2nd ed., 2,001th
• [FF02] C. Felbermeir, T. Furtmeier: Development of a Simple, multimedia service execution platform. Interdisciplinary project, Chair for Communication Networks, Technische Universität München, 2002.
• [FGM + 99] R. Fielding, J. Gettys, 7. Mogul et. al .: hypertext Transfer Protocol - HTTP / 1.1. IETF RFC 2616, June 1999.
• [For02] P. Forbig: Object-oriented software development with UML. Specialist book publisher in Carl Hanser Verlag, Leipzig, 2002.
• [Fra03] D. S. Frankel: Model Driven Architecture - Applying MDA to Enterprise Computing. Wiley Publishing, Indianapolis, USA, Of 2003.
• [Fre99] M. Fesson: IN based video conference services for CSCW Systems. Diploma thesis, chair for Communication Networks, Technische Universität München, February 1999.
• [Fri95] A. Frick: The Software Development Process - Holistic View. Carl Hanser Verlag, Munich Vienna, 1995.
• [FS00] M. Fowler, K. Scott: UML Concentrated. Addison-Wesley Publisher, Munich, 2000th
• [FSV01] A. Franz, P. Sties, S. Vogel: Formal Specification of E-Commerce Applications - An interdisciplinary approach. In Proceedings of the Sixth INFORMS Conference on Information Systems & Technology, pp. 314-332, Miami, USA, November 2001.
• [GFL + 03] V.K. Gurbani, I. Faynberg, H.-L. Lu et. al .: The SPIRITS (Services in PSTN requesting Internet services) Protocol. IETF Internet draft "draft-ietf-spirits-protocol-06", August 2003.
• [GGKH03] T. Gardner, C. Griffin, J. Koehler, R. Hauser: A review of OMG MOF 2.0 Queries / Views / Transformations Submissions and Recommendations towards the final standard. MetaModelling for MDA Workshop, York, England, 2003.
• [HKS97] U. Hinkel, W. Kellerer, P. Sties: Multimedia Applications in the telecommunication scenarios and Processes. Technical Report TUM-LKN-TR-9702, Technical University Munich, September 1997th
• [HSSR99] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg: SIP: session. Initiation Protocol. IETF RFC 2543, March 1999.
• [ITU88] International Telecommunication Union: Method for the characterization of telecommunication services supported by an ISDN and network capabilities of ISDN. ITU-T Recommendation I.130, Melbourne, USA, November 1988.
• [ITU92] International Telecommunication Union: Principles of intelligent network architecture. ITU-T Recommendation I.312 / Q.1201, October 1992.
• [ITU93a] International Telecommunication Union: Vocabulary of terms for ISDNs. ITU-T Recommendation I.112, Helsinki, Finland, March 1993.
• [ITU93b] International Telecommunication Union: Attribute technique for the characterization of telecommunication services supported by ISDN ITU-T Recommendation I.140, Helsinki, Finland, March 1,993th
• [ITU93c] International Telecommunication Union: Principles of telecommunication services supported by ISDN and the means to describe them. ITU-T Recommendation I.210, Helsinki, Finland, March 1993.
• [ITU93d] International Telecommunication Union: ISDN - network functional principals. ITU-T Recommendation I.310, Helsinki, Finland, March 1993.
• [ITU93e] International Telecommunication Union: Introduction to intelligent network capability set 1. ITU-T Recommendation Q.1211, Helsinki. Finland, March 1,993th
• [ITU96] International Telecommunication Union: Methods for subjective determination of transmission quality. ITU-T Recommendation P.800, August 1996.
• [ITU97a] International Telecommunication Union: Intelligent Network service plane architecture. ITU-T Recommendation I.328 / Q.1202, September 1997th
• [ITU97b] International Telecommunication Union: Intelligent Network - Global functional plane architecture. ITU-T Recommendation I.329 / Q.1203, September 1997.
• [ITU98] International Telecommunication Union: Glossary of terms used in the definition of intelligent networks. ITU-T Recommendation Q.1290, May 1998.
• [ITU99] International Telecommunication Union: Specification and description language (SDL). ITU-T Recommendation Z.100, November 1999th
• [ITU00] International Telecommunication Union: Framework Recommendation for multimedia services. ITU-T Recommendation F.700, November 2000.
• [Jec03] M. Jeckle: Web Services - Idea, Technology and Potentials. Magazine "it - Information Technology ", Oldenburg Publisher, March Of 2003.
• [Jes01] E. Jessen: The future of the Internet - and in particular the science networks. In "Internet @ Future", Yearbook Telecommunications and society 2001, H. Kubicek et. al. (Ed.), Pp. 11-16, Hüthig Verlag, Heidelberg, 2,001th
• [Jur01] R. Jurleit: Development of an IN-based service platform for telephone internet services. Diploma thesis, chair for communication networks, Technical University Munich, November 2001.
• [JW98] V. Jung, H.-J. Warnecke (ed.): Handbook for Telecommunications. Springer Verlag, Berlin Heidelberg, 1998.
• [KBS + 01] W. Kellerer, C. Bettstetter, C. Schwingenschlögl, P. Sties, K.-E. Steinberg. H.-J. birds: (Auto) Mobile Communication in a Heterogeneous and Converged World. IEEE Personal Communications Magazine, Vol. 8, No. 6, pp. 41-47, December 2,001th
• [Kel98] W. Kellerer: Service Architectures in Telecommunications - Evolution, Methods and Comparison. Technical Report TUM-LKN-TR-9801, Technical university Munich, April 1998.
• [Kel01] W. Kellerer: Intelligence on Top of the Networks: SIP based service control layer signaling. In proceedings IN2001, IEEE Intelligent Network Workshop, Boston, USA, May 2001.
• [Kel02a] W. Kellerer: Server architecture for network-independent service control in heterogeneous communication networks. Dissertation, Technical University of Munich. Herbert Utz Verlag, Munich, Of 2002.
• [Kel02b] W. Kellerer: Server architecture for network-independent service control in heterogeneous communication networks. Dissertation lecture at the Technical University Munich, January 31, 2002.
• [KHEB99] K. Kimbler, C.-H. Hagenfeldt, J. Ellsberger, G. Bergmann: An Environment for IN Service Prototyping and Validation. In Proceedings of 6 ^th International Conference on Intelligence and Services in Networks, IS &N'99, Barcelona, Spain, May 1999th
• [Kle96] S. Kleuker: The extension of existing telecommunication software with new services using formal methods. In T. Margaria (ed.): Proceedings of the International Workshop on Advanced Intelligent Networks. S. 91 - 106, University of Passau, 1996.
• [Kle97a] S. Kleuker: Incremental Development of Deadlock-Free Communicating Systems. In E. Brinksma (eds): Proceedings of the Third International Workshop Tools and Algorithms for the Construction and Analysis of Systems (TACAS'97), Pp. 306-320, Springer-Verlag, 1997.
• [Kle97b] S. Kleuker: Incremental development of verified Specifications for Distributed Systems. Dissertation, University of Oldenburg, Department of Computer Science, December 1997.
• [Kös97] T. Kösling: Draft interface for dynamic integration of SIBs in an existing router model. Diploma thesis, Chair of Communication Networks, Technical University Munich, December 1997.
• [Koo85] C.J. Koomen: The Entropy of Design: A Study on the Meaning of Creativity. IEEE Transactions to systems, man, and cybernetics, Bd. SMC-15, no. 1, January / February 1985.
• [Kru99] P. Kruchten: The Rational Unified Process - An Introduction. Addison Wesley Longman Verlag, Munich, 1999th
• [KSE00] W. Kellerer, P. Sties, J. Eberspaecher: IP Based Enhanced Data Casting Services over Radio Broadcast Networks. In Proceedings IEEE European Conference on Universal Multiservice Networks (ECUMN 2000), Colmar, France, October 2000.
• [KSM00] W. Kellerer, P. Sties, P. Moritz: Service Interactions beyond IN: The New Challenge for Multimedia and Convergence. In Proceedings of ^5th International Conference on Intelligence in Networks ICIN'2000, Bordeaux, France, Jan. 2000th
• [KSM02] W. Kellerer, P. Sties, P. Moritz: Method and Apparatus for the control of multimedia information and communication services. Laid-open publication of the international patent application PCT / DE01 / 03464, March 2002.
• [KSS01] W. Kellerer, A.B. Schmidt, P. Sties: Structured Software development of information and communication services. Research Network FORSOFT, Technical University Munich, November 2001.
• [KT97] N. Kosmas, KJ Turner: Requirements for Service Creation Environments. In Proceedings of 2 International Workshop on Applied Formal Methods ^nd in System Design, pp 133-137, Zagreb, May 1997th
• [KTG00] J. de Keijzer, D. Tait, R. Goedman: JAIN: A New Approach to Services in Communication Networks. IEEE Communications Magazine, Bd. 38, No. 1, pp. 94-99, January 2000.
• [KWB03] A. Kleppe, J. Warmer. W. Blast: MDA Explained. Pearson Education Inc., Boston, USA, 2003.
• [LDH99] X. Logean, F. Dietrich, J.-P. Hubaux: On Applying Formal Techniques for the Development of Hybrid Services: Challenges and Directions. In IEEE Communications Magazine, pp. 132-138, July 1999th
• [Lor02] P.A. Lorenz: ASP.NET - Fundamentals and Expertise. Carl Hanser Verlag, Munich Vienna, 2002.
• [LWS03] J. Lennox, X. Wu, H. Schulzrinne: CPL: A Language for User Control of Internet Telephony Services. IETF Internet draft "draft-ietf-iptel-cpl-07", August 2003.
• [Mas03] MasterMind Technologies: Service Creation Environment. Information about the product "MasterVox", website MasterMind Technologies, http://www.mastermindtechnologies.com/mmt/products/servicecreation.htm, As of 07. August 2003.
• [MBB00] H.B. Meeuwissen, H.J. Batteram, J.-L. Bakker: The FRIENDS Platform - A Software Platform for Advanced Services and Applications. Bell Labs Technical Journal, Vol. 5, No. 3, pp. 59-75, Lucent Technologies Inc., July-September 2000.
• [MBC + 03] S. McGlashan, D.C. Burnett, J. Carter, et. al .: Voice Extensible Markup Language (VoiceXML) version 2.0. W3C candidate Recommendation, World Wide Web Consortium, February 2003.
• [Mbr04] Homepage of the MBROLA project, TCTS Lab, Faculté Polytechnique de Mons, http://tcts.fpms.ac.be/synthesis/mbrola.html, January 2004.
• [Mil67] G.A. Miller: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. In G. A. Miller "The psychology of communication - Seven Essays, "Basic Books, New York and London, 1967.
• [Mit03] N. Mitra: SOAP Version 1.2 Part 0: Primer. W3C Recommendation, World Wide Web Consortium, June 2003.
• [MK03] A.-J. Moerdijk, L. Klostermann: Opening the Networks with Parlay / OSA: Standards and Aspects behind the APIs. IEEE Network Magazine, Vol. 17, No. 3, pp. 58-64, May / June 2003.
• [ML87] M. Marcotty, H. Ledgard: The World of Programming Languages. Springer-Verlag, 1987th
• [MM01] J. Miller, J. Mukerji: Model Driven Architecture (MDA). Object Management Group Architecture Board, White Paper, July 2001.
• [MM03] J. Miller, J. Mukerji: MDA Guide Version 1.0.1. Object Management Group, June 2003.
• [MMO + 98] R.D. McKinney, W.A. Montgomery, H. Ouibrahim, P. Sijben, J.J. Stanaway Jr .: Service Centric Networks. Bell Labs Technical Journal, Lucent Technologies, July - September 1998.
• [Mül96] H. Müller: Flexible signaling architecture for multimedia services with heterogeneous Terminals. Dissertation, Technische Universität München, Herbert Utz Verlag, Munich, 1996th
• [Odl01] A. Odlyzko: Content is not king. In First Monday, Chicago, USA, Vol. 6, No. 2, February 2001.
• [Ogb02] U. Ogbuji: XML, The Model Driven Architecture, and RDF. In Proceedings of XML Europe 2002, IDEAlliance, Alexandria, USA, May 2002.
• [OMG02] Object Management Group: Meta Object Facility (MOF) - Specification. Object Management Group (OMG), Version 1.4, April 2002.
• [OMG03] Object Management Group: XML Metadata Interchange (XMI) - Specification. Object Management Group (OMG), Version 2.0, document formal / 03-05-02, May 2003.
• [PC00] S. Petrack, L. Conroy: The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services. IETF RFC 2848, June 2000.
• [Pos80] J. Postel: User Datagram Protocol. IETF RFC 768, August 1980th
• [Pos81a] J. Postel: Internet Protocol. IETF RFC 791, September 1,981th
• [Pos81b] J. Postel: Transmission Control Protocol. IETF RFC 793, September 1981.
• [PR85] J. Postel, J.K. Reynolds: File Transfer Protocol. IETF RFC 959, October 1985.
• [QSP99] DAC Quartel, MJ van Sinderen, LF Pires. A model-based approach to service creation. In Proceedings of the 7 ^th IEEE Computer Society workshop on future trends of distributed computing systems, pages 102-110, Cape Town, South Africa, Dec. 1999th
• [Rat01] Rational Software: Rational Unified Process Best Practices for Software Development Teams. Rational Software White Paper TP026B, Rev 11/01, 2001.
• [Reg03] Regulatory Authority for telecommunications and Post: Annual Report 200 ?. Regulatory Authority for Telecommunications and Post, Bonn, February 2003.
• [RKS01] C. Rauch, W. Kellerer, P. Sties: Hybrid Mobile Interactive Services Combining DVB-T and GPRS. In Proceedings 4 ^th European Personal Mobile Communications Conference (EPMCC 2001), Vienna, Austria, February 2001.
• [RLL + 94] D. Ranasinghe, C.A. Licciardi, K. Lillegraven et. al .: Technical Report no. 1 - Selection of services. Technical Report, Eurescom Project EU-P103 "Evolution of the Intelligent Network ", December 1994.
• [SCFJ03] H. Schulzrinne, S. Casner, R. Frederick. V. Jacobson: RTP: A Transport Protocol for Real-Time Applications. IETF RFC 3550, July 2003.
• [Sch99] H. Schlicksupp: Innovation, creativity and brainstorming. Vogel Verlag. 5th ed., Würzburg, 1999th
• [Scr99] SCREEN: Final Report. Final report of the ACTS project AC227 Service Creation Engineering Environment SCREEN, March 1999.
• [SEC + 99] P. Sties, J. Eberspächer, W. Kellerer, B. Kreutzer, H. Reichel, G. Zurek-Terhardt: Broadband Internet Access Over Digital Video Broadcast (DVB). European Conference on Networks and Optical Communication (NOC'99), Delft, Netherlands, June 1999.
• [SGI99] Standish Group International: CHAOS: A Receipe for Success. 1999th
• [SGM02] C. Szyperski, D. Gruntz, S. Murer: Component Software - Beyond Object-Oriented Programming. Addison-Wesley Verlag, 2nd ed., November 2002.
• [Sha49] C.E. Shannon: The Mathematical Theory of Communication. The University of Illinois Press, Urbana, USA, 1949.
• [Sie01] G. Siegmund (ed.): Intelligent Networks - Technology, Services, marketing. Hüthig Publisher, 2nd ed., Heidelberg, 2001.
• [Sie02] Siemens AG: Service Creation Environment (SCE). Customer Handbook for the IN @vantage Platform, Siemens AG, Munich, 2002.
• [SK99] P. Sties, W. Kellerer: Radio Broadcast Networks Enabling Broadband Internet Access for Mobile Users. 5 ^th Open Summer School on Access to Internet in the Next Century (EUNICE'99), Barcelona, Spain, September 1999.
• [SK01] P. Sties, W. Kellerer: A Generic and Implementation Independent Service Description Model. International Conference on Distributed Computing Systems, Distributed Dynamic Multi Service Architecture Workshop (DDMA), Mesa, USA, April 2001 Proceedings ICDCS 2001, 21 ^st.
• [SKZ02] P. Sties, W. Kellerer, G. Zurek-Terhardt: System for data transfer from a provider to a user. German Patent 199 10 023, July 2002.
• [SS00] B. Skiera, M. Spann: Flexible Pricing in Electronic Business. In R. Weiber (ed.) "Handbook Electronic Business", 1st ed., Pp. 539-557, Wiesbaden, September 2000.
• [Sti01] P. Sties: Method of providing information, in particular an entertainment program, and device for receiving and reproducing information. Laid-open publication of the German patent application DE 100 20 168 , November 2001.
• [Sti02a] P. Sties: A service creation model for network spanning services. In new communication applications in modern networks, 3rd ITG Symposium Networks and Applications, Duisburg, March 2002.
• [Sti02b] P. Sties: Innovation Management: Brainstorming and Assessment in the development of information and communication services. Thesis. Chair for Business Administration Prof. H. Wildemann, Technical University Munich, June Of 2002.
• [Sti02c] P. Sties: Pricing of information and communication services. Seminar paper, Chair of Be Business Administration Prof. H. Wildemann, Technical University Munich, October 2002.
• [SV99] C. Shapiro, H.R. Varian: Information rules: a strategic guide to the network economy. Harvard Business School Press, Boston, USA, 1999.
• [TBMM01] H.S. Thompson, D. Beech, M. Maloney, N. Mendelsohn: XML Schema Part 1: Structures. W3C Recommendation, World Wide Web Consortium, May 2001.
• [TIN + 97a] Telecomunications Information Networking Architecture Consortium: Service Architecture. TINA-C Deliverable, Version 5.0, June 1997.
• [TIN + 97b] Telecommunications Information Networking Architecture Consortium: TINA-C Glossary of Terms. January 1997.
• [TQ01a] WB Teeuw. DAC Quartel: Model-Based Service Creation in the Friends Project. In Proceedings of 6 ^th International Conference on Protocols for Multimedia Systems (PROMS 2001), Springer-Verlag, pp 192-203, Berlin Heidelberg., 2001
• [TQ01b] W.B. Teeuw, D.A.C. Quartel: A Model-Based Service Creation Platform. International Workshop on Multimedia Middleware M3W, Ottawa, Canada, October 2001.
• [Tro04] Trolltech: Qt 3.3 Whitepaper. Trolltech AS, http://www.trolltech.com, Oslo, Norway, March Of 2004.
• [VBM00] J.P.C. Verhoosel, H.J. Batteram, R.S. Millian: The FRIENDS Platform: Conquering Complexity using Distributed Software Components. Software Symposium, Lucent Technologies, April 2000.
• [Vin02] S. Vinoski: Web Services Interaction Models - Part I: Current Practice. IEEE Internet Computing Magazine, May / June 2002.
• [WHKT02] C. Wenz, T. Hauser, A. Kordwig, C. Trennhaus: ASP.NET - Powerful Web Applications with Visual Basic.NET and C #. Markt + Technik Verlag, Munich, 2002.
• [Wir00] B. W. Wirtz: Electronic Business. operating Accounts Verlag Dr. med. Th. Gabler GmbH, 1st edition, Wiesbaden, October 2000.
• [Zav99] P. Zave: Formal Description of Telecommunication Services in Promela and Z. M. Broy, R. Steinbrüggen (ed.): Calculational System Design, Proceedings of the 19 ^th International NATO Summer School, pp. 395-420, 1999th
• [ZH99] S. Znaty, J.-P. Hubaux: Telecommunication Services Engineering Definitions, Architectures and Tools. In "The Telecommunications Handbook ", CRC and IEEE, December 1999.
• [ZPS + 01] A. Zerdick, A. Picot, K. Schrape et. al .: The Internet Economy. Springer-Verlag. Berlin Heidelberg, 3rd ed., 2001.

Claims (2)

Method for creating system blocks for telecommunication and internet services with at least one of the above-disclosed features of inventive Quality. System module for Telecommunication and Internet services with at least one of previously disclosed features of inventive quality.