Software-Technologien und -Prozesse: Tagungsband/Proceedings zur 2. Konferenz STeP 2010, Hochschule Furtwangen, 6. Mai 2010 9783486853162

Citation preview

Software-Technologien und -Prozesse Tagungsband/Proceedings zur 2. Konferenz STeP 2010, Hochschule Furtwangen, 6. Mai 2010 Herausgegeben von Steffen Thiel, Christoph Reich und Frank Dölitzscher

Oldenbourg Verlag München

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

© 2010 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0 oldenbourg.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Lektorat: Kathrin Mönch Herstellung: Anna Grosser Coverentwurf: Kochan & Partner, München Gedruckt auf säure- und chlorfreiem Papier Gesamtherstellung: Grafik + Druck GmbH, München ISBN 978-3-486-59816-2

Inhaltsverzeichnis Vorwort ………………………………………………………………….

ix

Organisation …………………………………………………………….

xi

Sponsoren ………………………………………………………………. xiii Keynote ………………………………………………………………….

xv

Teil I: Technisches Programm A Software Architecture for Automotive Multimedia-Platforms Supporting Software Product Lines …………………………………….. Elmar Cochlovius

3

A Discussion of Three Visualisation Approaches to Providing Cognitive Support in Variability Management …...…………………….. Ciaran Cawley, Patrick Healy, Goetz Botterweck

15

A Database Architecture for Scalability and High Availability ………… Andreas Weininger

33

Vermeidung der Abhängigkeitsdivergenz zwischen Design und Implementierung in Java ………………………………………………... 39 Jens Cornelis, Klaus Dorer Master Data Management – Moderne Stammdatenverwaltung in einer SOA Architektur …..…………………………………………........ Romeo Kienzler

51

vi

Inhaltsverzeichnis

Teil II: Tutorials Scala – Neuer Dampf für die virtuelle Maschine ……………………….. 61 Lothar Piepmeyer Was Sie schon immer über Architektur-Evaluierung wissen wollten, aber bisher nicht zu fragen wagten… …………………………………... Uwe Werner

75

Teil III: Industriepräsentationen Developing Secure Web Applications with OWASP Resources …........... 87 Martin Knobloch Linux in Automotive Infotainment Systems ……………………………. Rainer Oder, Jürgen Wölfle, Oliver Hartfuss, Karl Bühler, Markus Zinser Orchideo - Ein schmerzfreier Ansatz für Modellgetriebene Softwareentwicklung …………………………………………………… Ralf Grossklaus

89

93

Modellbasierte Implementierung einer Ontologie-Zugriffsschicht …….. Thomas Wehner, Michael Jungmann, Markus Pilzecker

95

Generative Entwicklung in einem langlaufenden Projekt ……………… Ralf Simon

99

Stoppt die Architektur Erosion: Beispiele aus dem Open Source Bereich …………………………………………………… 103 Bernhard Merkle Prozessdokumentation in kleinen und mittleren Unternehmen ……….... 105 Klaus Gurr

Inhaltsverzeichnis

vii

Agile Methoden und Nearshoring - funktioniert das? ………………….. 109 Felix Rüssel

Teil IV: Young Researchers Adapting Self-Organizing Maps to the MapReduce Programming Paradigm ………………………………………………………………... 119 Christian Weichel SOAP kritisch betrachtet ………………………………………………... 133 Holger Staudacher, Jens Lauble Machbarkeitsuntersuchung eines Requirements Lifecycle auf Basis von Microsoft Team System ……………………………………………. 151 Christopher Martel

Vorwort Dieser Tagungsband umfasst Beiträge und Tutorien der 2. Konferenz Software-Technologien und -Prozesse (STeP 2010), die am 6. Mai 2010 in Furtwangen stattfand. Die STeP 2010 wurde von der Fakultät Informatik der Hochschule Furtwangen veranstaltet und richtet sich an Vertreter der industriellen Praxis sowie an anwendungsorientierte Wissenschaftler aus dem akademischen Umfeld. Sie bietet ein Forum, um aktuelle Trends und Themen der Softwaretechnik mit Experten eingehend zu diskutieren. Die diesjährige Konferenz wurde mit einer Keynote von Herrn Dr. Stefan Ferber, Innovations Software Technology GmbH eingeleitet. Das Tagungsprogramm umfasste folgende Schwerpunkte: x

Technisches Programm: Technische Beiträge aus dem Umfeld Software-Produktlinien, Variabilitätsmanagement, Service-Orientierte Architekturen und Softwarequalität.

x

Tutorials: Tutorien zu den Fachthemen funktionale Programmierung und Software-Architekturevaluierung.

x

Industriepräsentationen: Praxisorientierte Beiträge zu innovativen Technologien und Erfahrungsberichte aus Softwareprojekten, insbesondere zu den Themen modellbasierte Softwareentwicklung, agile Methoden, Prozessverbesserung, Software-Architekturen und eingebettete Systeme.

x

Young Researchers: Beiträge von jungen Wissenschaftlern zu den Themen Programmierkonzepte, verteilte Systeme und Requirements Engineering.

Wir möchten uns bei allen Kolleginnen und Kollegen sowie Helfern für die tatkräftige Unterstützung bedanken. Ohne dieses vielfältige Engagement wäre die Organisation und Durchführung einer solchen Konferenz nicht möglich gewesen. Besonderer Dank gilt dabei dem Rektor der Hochschule Furtwangen, Herrn Prof. Dr. Rolf Schofer, Herrn Edmund Kintzinger, Leiter Marketing/PR sowie der Fakultät Product Engineering für die freundliche Bereitstellung der Räumlichkeiten und Infrastruktur. Ferner möchten wir uns bei allen Mitgliedern des Programmkomitees für die fachkundige Begutachtung der zahlreichen Beiträge bedanken. Unser Dank gilt auch unseren Sponsoren für die großzügige Unterstützung.

x

Vorwort

Schließlich danken wir dem Oldenbourg-Verlag für die gute Zusammenarbeit bei der Veröffentlichung des Tagungsbandes. Furtwangen, Mai 2010 Steffen Thiel, Christoph Reich und Frank Dölitzscher

Organisation Veranstalter Fakultät Informatik, Hochschule Furtwangen

Tagungsleitung Christoph Reich, Hochschule Furtwangen Steffen Thiel, Hochschule Furtwangen

Organisationskoordination Frank Dölitzscher, Hochschule Furtwangen

Programmkomitee Urs Andelfinger, Hochschule Darmstadt Goetz Botterweck, Lero, University of Limerick, Ireland Detlef Fehrer, SICK AG Ralf Hahn, Hochschule Darmstadt Andreas Hein, Bosch Rexroth AG Albert Held, Daimler AG Bernhard Hollunder, Hochschule Furtwangen Thomas Koch, Credit Suisse AG, Schweiz Franz Lehner, Universität Passau Gunther Lenz, Microsoft, USA Peter Liggesmeyer, TU Kaiserslautern & Fraunhofer IESE Ludger Meyer, Siemens AG Gustav Pomberger, Johannes Kepler Universität, Linz, Austria Mohsen Rezagholi, Hochschule Furtwangen Stefan Strobel, cirosec GmbH Thomas Strohm, Robert Bosch GmbH

Sponsoren Wir danken der Hochschule Furtwangen und unseren Sponsoren für die freundliche Unterstützung.

Gold Sponsoren

Silber Sponsoren

Keynote STeP 2010 was opened by a refreshing keynote given by Dr. Stefan Ferber from Innovations Software Technology GmbH. Short biography Dr. Stefan Ferber is Product Manager for eMobility at Innovations Software Technology GmbH in Waiblingen. Innovations belongs to the Software and System House of Robert Bosch GmbH. Dr. Ferber has more than ten years experience in software development, software processes, software product lines and software architectures for embedded, computer vision and IT domains. He has developed automotive specific adaptations of the product line approach together with the Software Engineering Institute (SEI) in Pittsburgh, USA as well as software architectures in cooperation with Bosch business units and public-funded projects. He joined the SEI International Process Research Consortium as a business representative to draw a roadmap for research in the area of process engineering. He is a certified ATAM lead evaluator and a proud user of the Personal Software Processs (PSP). Dr. Ferber worked at the research center of DaimlerChrysler AG in Ulm in the field of 3D computer vision, robotics, and measurement technologies. In 2000 he joined Robert Bosch GmbH working on software architectures and software product lines as an internal consultant and researcher in Frankfurt. Starting in 2004 he was responsible for the Corporate Systems Engineering Process Group (C-SEPG) and the research department for software and system processes at Bosch in Stuttgart. Prior to joining Innovations he was on a special project assignment for Technology Planning in the field of Internet of Things and Services. Dr. Ferber holds a Ph.D. and a diploma degree in Computer Science from the University of Karlsruhe, Germany and a MSc. in Computer Science from the University of Massachusetts Dartmouth, USA.

Teil I: Technisches Programm

A Software Architecture for Automotive Multimedia-Platforms Supporting Software Product Lines Dr. Elmar Cochlovius Harman/Becker Automotive Systems GmbH Becker-Göring-Straße 16 76307 Karlsbad [email protected]

Abstract: In current- and next-generation car models, automotive infotainment systems integrate several complex applications including multimedia, which operate in parallel in a real-time environment. This paper outlines relevant constraints of the software design process to address the diverging requirements of different OEM customers, market segments and target hardware. The resulting conflicts mandate a flexible software architecture. We outline the close relation and interaction between development process and software architecture to result in a scalable multimedia platform.

1

Introduction and Domain-specific Requirements

From the end user’s point of view, multimedia is one of the central applications in modern automotive infotainment systems next to car navigation, tuners, telephone, speech and connectivity applications. It is mandatory for the multimedia application to adapt the rapid development progress in the PC and consumer world to the specific requirements of the automotive environment. Careful definition and the efficient implementation of these requirements enable tier-1 suppliers of integrated infotainment systems to develop comprehensive multimedia solutions on cost-optimized target hardware platforms and deliver to different OEM customers addressing their particular requirements. We have designed an automotive-grade multimedia software platform (Multimedia Engine MME [1]), which is being used today in various models of leading car manufacturers. Here, we address several requirements, constraints and challenges resulting in a flexible software architecture and a specifically tailored software development process integrating internal and external suppliers as well as OEM customers. First, some requirements are introduced which are specific to the domain of automotive infotainment. Some properties of the target hardware platforms

4

Cochlovius

currently in use are explained, since one of the challenges in defining an embedded software architecture is the efficient mapping of domain requirements to specific constraints imposed by the target hardware platforms. Based on requirements and target platforms, a step-wise process of defining a scalable software architecture for multimedia systems is highlighted. Then the resulting architecture is briefly discussed.

1.1 Domain-specific Requirements for Automotive Multimedia Applications This list indicates some requirements which help to better understand the design decisions: New media formats: The number of media formats to be processed is increasing rapidly, and innovation cycles are getting shorter all the time. The growing CPU capacity in the PC sector has enabled the development of compressed digital audio formats such as MP3, WMA or AAC. And the development is by no means complete, as new formats such as MP3Pro or MP3Surround promise additional user benefits. As soon as the lifecycle of the media formats to be processed become substantially shorter than the lifecycle of the vehicles, it is clear that the traditional solution strategy based on hardware decoders is not feasible any longer for automotive systems. Instead, modern multimedia architectures must efficiently integrate both hardware accelerators and full software decoders. Flexible media interfaces: Also a growing number of interfaces, mediastores and protocols have to be supported. Driven by the progress of navigation systems, the CD disk drive in the car has been replaced by the DVD diskdrive, while hard disk drives are the standard solution in high-end infotainment systems. In parallel, the standard interfaces and devices, such as USB and SD cards must be supported. Not only passive data carriers like USB memory sticks can be read via these interfaces; but external devices can also be integrated and controlled. Examples include the iPod/iPhone family with its different generations and protocol dialects as well as PFS players (plays for sure) that are based on MTP (media transport protocol) and AVRCP-based bluetooth devices. This requires a flexible and robust driver architecture, which can also securely manage devices that are not fully standard compliant. Video and multichannel sound: The current generation of infotainment systems already features high-resolution TFT displays with 800 x 480 and even 1280 x 480 pixels, thus enabling high-quality map displays as part of the navigation application. However, the display is also to be used for video content, especially in user scenarios related to rear seat entertainment. Here

A Software Architecture for Automotive Multimedia-Platforms

5

the media sources are DVD disk drives, large memory sticks and digital cameras with USB interfaces. On all except the most advanced target platforms decoding of video and multichannel audio streams must be offloaded from the CPU to a dedicated DSP or DVD decoder. Only recently embedded CPUs with substantially higher performance suitable for automotive use have become available. This requires a high-performance interface to external hardware to be an important part integrated into the multimedia middleware. Novel user scenarios: In earlier generations of automotive infotainment systems the multimedia application was focussed on the playback of media; in current systems, recording and ripping is also required in a mobile environment. Media sources are e.g. CD or DVD disk drives as well as radio tuners or telephones. The media sink is the built-in hard disk drive with its dedicated multimedia partition of approx. 30 to 50 GByte. The rip-and-play function allows the decoding and playback of the already encoded part of the audio stream while the ripping process is still busy encoding the rest. This requires a flexible connection between the encoding and decoding components in the multimedia middleware, e.g. based on filtergraphs. Media database and metadata: Besides encoding and decoding media streams, a major challenge for an embedded multimedia middleware is the management and efficient access of the media available. The metadata of a title in the popular ID3 format contain additional information such as artist, genre, album, composer, etc. For 30 GByte of media, approx. 20-30 MByte of metadata have to be stored. This is implemented in a standard database that permits comfortable queries. For example, the SQL statement select * from … where genre=“Jazz“ and artist=“Dave Brubeck“ and source=“HDD“ results in a list of all jazz titles by Dave Brubeck currently available on the hard disk drive. This list can then be directly passed into the playback engine. Parallel media streams: The rip-and-play functionality mentioned above already requires the handling of parallel data streams in the CPU. While one audio stream is encoded and stored on the hard disk drive, read access of the hard disk drive is performed simultaneously to retrieve a second audio stream that is to be decoded. Both streams behave completely asynchronous to each other since ripping occurs at maximum speed while playback is single speed. Multiple Entertainment Zones: Multi-zone operation is a must in modern high-end infotainment systems. Each zone is identified by a media source possibly exclusively used - and a separate output for audio (e.g. main amplifier, headphones) and potentially for video. The current generation of embedded graphics controllers support several displays, each rendered with in-

6

Cochlovius

dependent content. This kind of configuration provide e.g. DVD-video for the front-seat passenger with headphones, MP3 playback in the main cabin zone and an additional zone in the integrated rear-seat entertainment system. Access to the media is provided by the multimedia middleware including the consistent presentation of all metadata, the initialization of all decoder components required and the management of all user queries and commands.

1.2 Additional Constraints require a Flexible Architecture After some of the domain-specific features of automotive multimedia systems have been outlined, this section is focussed on additional constraints of the architecture which are driven by the automotive software development process. Customer-specific Configuration: Not only the graphical user interface (GUI) but also the set of features and their parameterization (e.g. size of multimedia database), operational paradigms (database schema and query operations) are highly customer- and even model-specific. Depending on the playback strategy, some customers require an alphabetical list of all titles available on a mediastore (e.g. USB device), which requires first to completely scan the device, extract the metadata, synchronize the metadata into the database and only then start playback. Other customers require rapid start of playback as soon as the device is attached to the system. This requires the architecture to be flexible enough to handle different media detection, synchronization and playback strategies. Different Market-Segments and Target Hardware: A scalable multimedia platform needs to cover the complete range of entry-level, mid-line and high-end segments of the automotive market by defining different product lines based on relevant core features [2] and specific target hardware. Relevant multimedia formats, both audio and video, have to be supported. Audio and video decoders are implemented in software, which however is computationally expensive and only feasible for the high-end segment. Other segments require e.g. video formats to be decoded using a dedicated multimedia core (DSP). Low-end systems are focussed on audio formats only, but also need to be covered by the same multimedia architecture. Severe cost pressure prevents any hardware overhead and leads to a number of different, cost-optimized target hardware platforms. Integrating different Sub-Suppliers: Driven by PC and consumer markets, multimedia technology, formats, applications and interfaces are rapidly evolving. A tier-1 supplier needs to rely on various sub-suppliers to develop and deliver key components, e.g. video codecs and DVD navigators. A carefully designed set of APIs allows different low-level and middleware modules to be integrated into the multimedia platform.

A Software Architecture for Automotive Multimedia-Platforms

7

Accommodating Different Project Timelines: In real-life scenarios it is usually not feasible to develop the software platform and the customer product software sequentially. A common feature rollout plan is maintained to coordinate all internal and external sub-suppliers. A risk-aware branching and integration strategy is defined to avoid deliveries of one project compromising deliveries of other projects, while at the same time enabling bugs to be fixed only once.

2

Defining a Scalable Multimedia Architecture

This section describes the stepwise approach we have chosen to define a scalable multimedia architecture and to implement the resulting software platform. The three main steps are the domain-based functional decomposition, the resource-bounded mapping of the resulting components and finally the addressing of system bottlenecks, e.g. by optimized APIs.

2.1 Step 1: Domain-based Functional Decomposition

Figure 1: Functional Decomposition of DVD Playback Core Use Case

As outlined in section 1, the architecture needs to be scalable in two different dimensions. First, it needs to scale across different feature sets. Second, dif-

8

Cochlovius

ferent target hardware platforms, e.g. entry-level, mid-line, high-end systems have to be accommodated. Independent from both aspects, the domain-based functional decomposition step analyzes one or several core use cases and decomposes them into their main functional components which are required independently from any implementation. A functional component represents an essential building block which might be implemented either in software or in hardware. For the automotive multimedia domain, DVD-playback is a good starting point, as this is one of the more challenging use cases. Fig. 1 identifies four classes of functional components, namely data in/out, control, audio-decoding and video-processing. The central component of the DVD-video application is the DVD navigator, which implements the functionality of the DVD menu by interpreting the final state machine encoded on the disk medium and requesting the required data packets from the file system. This is done by the so-called NavPacks, which contain metadata and navigation data. Since the data packets are not stored in a linear fashion on the DVD medium, the file system must provide low-level block access and a CSS decoding module (Content Scrambling System) in order to function efficiently. Buffer management for the read-ahead buffer optimized for in-car usage is positioned above the file system for better modularity. The parser analyzes and unpacks the data stream into separate components for audio, video, sub-picture and DVD navigation. The DVD standard requires four different audio decoders, which are connected to a DTCP encoding module (Digital Transfer Content Protection). The video path contains the MPEG2 decoder and a separate sub-picture decoder for subtitles and animated menus. Both independent video layers must be scaled if necessary, and then alpha-blended pixel by pixel to form the final video frame.

2.2 Step 2: Resource-bounded Component Mapping After step 1 has identified the functional components involved, the second step maps each component to software or hardware modules available on the target hardware platform. This step has to be repeated for each target platform the software architecture is designed for. It results in a set of hardware/software partitionings and identifies the main APIs which have to be preserved across all different implementations. Currently, our multimedia architecture supports six different target hardware platforms. Here, only two examples are presented - a hardware platform based on a dual-DSP approach and a hardware platform based on the Atom family presented by Intel.

A Software Architecture for Automotive Multimedia-Platforms

9

The dual-DSP target hardware platform is based on an automotive-grade low-cost CPU and two different DSPs. The component mapping with the highest level of flexibility is shown in fig. 2. It is characterized by a dedicated DSP1 which decodes all DVD media formats including the audio formats required by the DVD-video and DVD-audio standards. All additional audio functionalities including audio-encoding are mapped to a second DSP due to resource constraints and parallel multi-zone use cases. Buffer management and access to the media drive is handled by the CPU as well as the central DVD navigator component. Synchronization of audio and video streams is mapped to the video DSP.

Figure 2: Component Mapping on a Dual-DSP Target Hardware Platform

This particular target hardware platform and HW/SW partitioning is used in various high-end infotainment systems of the current generation due to its flexibility and cost-efficient approach. The scalability of this solution becomes obvious if DSP1 is omitted. This results in a mid-line infotainment system without DVD-video playback functionality. This can be accomplished without even modifying the remaining multimedia functionality. The dual-DSP target platform is limited by the low-end CPU and thus not extensible to address upcoming media formats such as high-definition H.264 video playback in a cost-efficient way. More scalability and performance is

10

Cochlovius

provided by the target hardware platform based on the Atom CPU. This is a high-performance, embedded computing platform with a hardware accelerated slice-decoder which can be used for various video formats, and a 3D graphics controller.

Figure 3: Component Mapping on a Target Hardware Platform based on Intel’s Atom CPU

As illustrated in Fig. 3, the component mapping results in the following, very streamlined partitioning: every component except video decoding and processing is implemented on the CPU. Next to the navigator, this includes all audio decoding, audio/video synchronization and subpicture decoding.

2.3 Step 3: Addressing System Bottlenecks After defining all relevant component mappings, the next step identifies the critical system resources and addresses potential system bottlenecks as for example: Inefficient DSP communication: On DSP-based target platforms the multimedia streams have to be delivered to the DSP by the CPU. DSPs are used to accelerate the decoding process, but the benefit of offloading from the CPU can be easily compromised by an inefficient DSP communication link. The MM-IPC (Multimedia Inter Processor Communication) has been developed to address the specific requirements of multimedia-related communica-

A Software Architecture for Automotive Multimedia-Platforms

11

tion, namely low latency, high bandwidth and low interrupt loads. The MMIPC is an essential software module and interface which has to be provided for all target platforms which are based on external DSPs. Overloaded system resources: Using a quantitative approach, it is possible to estimate the resulting load of each system resource of a given target platform as indicated in Tab. 1. Use Case

CPU SH4A [Mips], 1000Mips@600MHz

DSP C64x [MHz], 500MHz

CD Audio

30 (3%)

10 (2%)

MP3

10 (1%)

30 (6%)

WMA

10 (1%)

35 (7%)

WMA-encode

80 (8%)

125 (27% @ 3X)

DVD-Video

70 (7%)

325 (65%)

DVD-Audio

110 (11%)

80 (16%)

H.264 (1.5Mb/s)

150 (15%)

450 (90%)

Table 1: Performance Requirements of selected Multimedia Components

A single DSP cannot provide enough performance to handle the complete audio and video decoding next to its additional system tasks. Target hardware platforms based on a single DSP thus can be clearly identified as audioonly entry-level or mid-line, while full DVD decoding requires a dual-DSP or high-end CPU-based platform.

3

Results and Lessons Learned

Following this three-step approach, a scalable multimedia architecture for automotive infotainment systems has been developed [1]. It provides platform independent high-level APIs for multimedia access, management, processing and deployment, which are used by the project development teams to implement the customer-specific graphical user interfaces. The most challenging platform abstraction is related to multimedia processing, i.e. decoding and encoding of audio and video streams, since this requires the most computing resources and thus hardware support and interaction. All multimedia processing is based on a filtergraph paradigm as illustrated in fig. 4. New codecs can be added without affecting the overall architecture. Note, that DSP-based hardware accelerated codecs can be also added by using the Multimedia-IPC (MM-IPC).

12

Cochlovius

Figure 4: Example: Filtergraph for Audio Playback Use Cases

All filtergraphs are instantiated at runtime depending on the current use case(s). They are based on the Multimedia Framework MMF and are part of the middleware software building blocks of the MME multimedia architecture which is shown in fig. 5.

Figure 5: High-Level Blockdiagram of the Multimedia Architecture

All filtergraphs are controlled by the MMF graph managers. The QDB implements a SQL-database. Media detection MDS and mediastore synchronization MSS access various mediastores by means of low level, OS-

A Software Architecture for Automotive Multimedia-Platforms

13

dependent drivers. The CoMMCo Common Multimedia Controller provides a convenience API to the Presentation Controller which implements projectspecific application logic and communicates to the user interface(s). In an industrial setting for software production, a platform team is responsible for all software blocks up to and including the CoMMCo layer. All common features and feature variants used across several projects are implemented by the platform team. In addition, each customer project has allocated a separate team to implement requirements which are unique for a single project or a single OEM customer. This clean separation is essential to manage variability and indicates how organizational structure relates to software architecture.

Figure 6: MMF-API to Integrate Different Software Suppliers

While the multimedia framework MMF provides the same filtergraph API for all target hardware platforms, the codecs require platform-specific optimization in order to be efficient. No single software supplier can handle all different hardware optimizations equally well. Based on the well-defined API the multimedia architecture provides an efficient way to communicate with different suppliers and to verify and integrate their deliveries as illustrated in fig. 6. Each implementation of the MMF-API contributes to the core assets which are reused in a dedicated line of infotainment products addressing a particular market segment [3]. Driven by the domain-specific requirements and automotive-specific constraints, it has been possible to design and develop a multimedia architecture for automotive infotainment systems which is fully scalable from an entrylevel MP3-CD player through an high-end multi-zone audio/video system with full ripping functionality and online access for looking up missing metadata. It is implemented on six different target hardware platforms. The multimedia architecture integrates four different sub-suppliers and today is

Cochlovius

14

running in 15 different infotainment systems developed for nine different OEM customers. During early development, thorough analysis has been critical of both the domain-specific requirements and the additional constraints imposed by the automotive software development environment, its life cycle and processes, supplier management and planning. Clean APIs help to decouple development timelines of each supplier from the integration timelines of different projects.

Literature [1]

E. Cochlovius and D. Dodge: Die Multimedia Engine MME – Teil 1: Anforderungen und Architektur einer flexiblen Middleware für Infotainment-Systeme. - In: Elektronik automotive (2007) Nr. 5, S. 30-34.

[2]

M. Weber and M.-O. Reiser: Requirements-Engineering für Produktlinien in der Automobilelektronik – In: Produktlinien im Kontext, Hildesheimer Informatikberichte 1/2009, S. 24-25.

[3]

F. J. Linden, E. Rommes and K. Schmid: Software Product Lines in Action. 1. Aufl., Berlin 2007

A Discussion of Three Visualisation Approaches to Providing Cognitive Support in Variability Management Ciaran Cawley, Patrick Healy, Goetz Botterweck Lero University of Limerick Limerick, Ireland

[email protected], [email protected], [email protected]

Abstract: Variability management in software intensive systems can be a complex and cognitively challenging process. Configuring a Software Product Line with thousands of variation points in order to derive a specific product variant is an example of such a challenge. Each configurable feature can have numerous relationships with many other elements within the system. These relationships can impact greatly on the overall configuration process. Understanding the nature and impact of these relationships during configuration is key to the quality and efficiency of the configuration process. In this paper we present an overview of three visual approaches to this configuration which utilise information visualisation techniques and aspects of cognitive theory to provide stakeholder support. Using an industry example, we discuss and compare the approaches using a set of fundamental configuration tasks.

1

Introduction

Software Product Line (SPL) engineering claims to realise significant improvements in time-to-market, cost, productivity, and system quality [1]. Establishing a core set of assets from which different software product variants can be subsequently derived is the primary principle underlying the expected benefits. Industrial sized product lines are interesting examples of software intensive systems where there remain difficult challenges in terms of variability management [2, 3]. Information Visualisation techniques have provided a variety of ways for stakeholders to view, comprehend and manage large amounts of related information [4, 5]. However, although recent work has attempted to incorporate these into the domain of variability management [6-8], there appears to be a lack of such research in the literature. Configuring a Software Product Line with thousands of variation points in order to derive a specific product variant is a challenging process. Each configurable feature can have numerous relationships with many other

Cawley, Healy, Botterweck

16

elements within the system. These relationships can impact greatly on the overall configuration process. Understanding the nature and impact of these relationships during configuration is key to the quality and efficiency of the configuration process. In his work on cognitive support in software engineering, Walenstein developed a framework to guide the design of tools so that they take advantage of principles from distributed cognition [9]. In this paper, we use the principles espoused in this framework and attempt to realise them through the employment of a variety of information visualisation techniques in order to provide support for a number of variability configuration tasks. We present three different visualisation approaches that, as their basis, combine principles from cognitive theory with information visualisation techniques to address variability configuration issues. As well as a traditional 2D approach, a 2.5D and 3D approach is explored. The effectiveness of 2D versus 3D is a widely debated area but work such as that by Risden [15] provides interesting evaluations showing certain situations can benefit from a 3D approach. The rest of this paper is structured as follows. Section 2 discusses related work. Section 3 presents the concepts underpinning the approaches taken and outlines the tasks that our approaches aim to support. Section 4 presents the implementations of the three approaches taken while Section 5 provides a discussion on how those approaches support the given tasks. The paper finishes with plans for future work and conclusions.

2

Related Work

Feature modelling is a prevalent mechanism for describing variability in SPL's [10]. These models are typically represented using hierarchical tree views or simple graphs. Tools such as pure::variants [11] and Gears [12] are examples that use such representations. Although these views are familiar and intuitive, there is a lack of evidence supporting their effectiveness in relation to large scale product lines. The DOPLER [7] tool also employs lists and hierarchical trees but allows for more sophisticated graph layouts to be visualised. These, however, follow traditional node-link diagram approaches and do not employ 2.5D or 3D visual environments. Tools such as VISMOOS [13] and MUDRIK [14], although not variability management tools, offer an insight into the use of 2.5D/3D and the possibilities of increased cognitive support within software engineering

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

17

tools. However, these tools concentrate on comprehension alone and not on process support. Information visualisation techniques described and analysed by Ware [5] and Card et al. [4], offer expert opinion on the application of various visual mechanisms. Ware also offers a theory of augmented thinking using visual queries on visualisations - cognitively, constructing a visual query entails identifying a visual pattern that will be used by a mental search strategy over a graphical visualisation. Walenstein provides a set of principles [9] which aim to guide the design of software engineering tools to maximise cognitive support.

3

Concept

3.1 Visualisation Techniques The application of visualisation techniques to address the complexity issues that exist in configuring high-variability systems is the core activity of this work. Figure 1 shows the Visual Reference Model [4] described by Card et al. This visual model provides the basis for our visualisation approaches. A data meta-model, outlined in Section 4, was developed to describe a software product line and the relationships that can exist between its various elements. At a high level, an instance of this model comprises the "Data" as illustrated in Figure 1. The primary area of effort in our work is the development of appropriate "Views" that work over an abstracted representation of that data. Visualisation techniques developed and analysed within the visualisation community [4, 5] are leveraged within our approaches. It is proposed that by using such techniques, the expertise and experience of that community can be brought to bear on the complexity challenges that exist in variability management. For example, some key concepts/techniques used are: Details on Demand; Multiple Synchronised Views and Focus+Context. In addition, motivated by work such as that carried out by Risden and Robertson [15, 16], these techniques are employed in three different visual

Figure 1. Visualisation Reference Model

18

Cawley, Healy, Botterweck

environments - 2D, 2.5D and 3D. These three environments allow a comparative evaluation to be performed, showing strengths and weaknesses of each and where one environment might be more useful than others for specific tasks.

3.2 Cognitive Theory Using a set of principles developed by Walenstein [9] that aim to increase cognitive support in software engineering tools and Ware's theory of augmented thinking using visual queries on visualisations [5], we chose a set of visualisation techniques that aim to realise those principles.

3.3 Relationship-Centric Approach Literature that reports on industrial issues, requirements and tools [2, 3, 17], motivates an important aspect of our approach - a large percentage of the complexity that challenges the configuration process is due to the quantity and varying nature of the relationships that exist between the different configurable elements and the constraints that these relationships impose. With this in mind, the underlying concept used by our visualisation approaches aims to focus on the relationships that exist and not on what they relate.

3.4 Application As the end result of this work is to provide support to stakeholders during the feature configuration stages of SPL product derivation, we set out the tasks for which this support is being provided. The activity of configuring a feature is the fundamental task challenging a stakeholder during the feature configuration process. At a basic level, this involves the ability to either include or exclude a feature from the product under derivation. We would also add that the ability to include/exclude features in groups based on higher level requirements is also a fundamental task (we refer to these higher level requirement groupings as decisions later). Whereas these tasks may seem simplistic, it is the knowledge/understanding (cognition) of the stakeholder that allows these tasks to be performed correctly. Again, drawing on work carried by others [2, 3, 17], we outline a set of simple cognitive tasks that aim to support the activity of the primary task – to decide which features should be included and which should be excluded. 1. Identify / Locate a configuration decision 2. Understand the high-level impact of a decision inclusion (perception of scale and nature of the impact - implements/requires/excludes)

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

19

3. Identify / Locate a specific feature 4. Identify a specific feature's context alternative/supporting features, sub-features

-

parent

feature,

5. Understand the high-level impact of a feature inclusion - a specific feature's constraints (requires/excludes relationships) 6. Identify the state of a feature - included/excluded and why. It is these cognitive tasks that our visualisation approaches target in terms of providing an interactive visual environment. In Section 5 we discuss each of these tasks in the context of the three approaches.

4

Approaches

4.1 Overview In this section, we firstly enumerate and describe the principles and techniques utilised across all three visualisation approaches. Following this, we briefly outline the data meta-model used to describe the data and introduce the industry example used for our discussion in Section 5. We finally present the three visual environments: 2D; 2.5D and 3D as three different approaches to using visualisation to support feature configuration.

4.2 Visualisation and Cognitive Support Based on Walenstein's [9] and Ware's [5] work, we use seven principles to guide our choice of visualisation techniques. 1. Simple query patterns 2. Simplified / Reduced interface 3. Reduced tasks 4. Rapid information recovery 5. Optimisation 6. Distribution 7. Specialisation In summary, the first three are concerned with simplifying the user interface as much as possible. The next two, 4 and 5, are concerned with easy and efficient discovery and calculation of data. The last two, 6 and 7, are concerned with separating data and/or processing ("thinking") so that it is cognitively easier to understand that data.

Cawley, Healy, Botterweck

20

The use of easy to identify/learn iconography and colour encoding is used to help realise principles 1 and 2. Using icons like ticks, crosses and coloured icons allow multiple data items to be encoded in the visualisation. The multiple windows technique helps to realise principles 2, 6 and 7. Using multiple windows, information can be separated in a way so as to reduce individual views and group related information. Focus+Context techniques such as fisheye / degree of interest help to realise principle 2. These techniques are concerned with providing the overall context within which one is working while still allowing a stakeholder focus on specific tasks/data elements. Details on Demand and Distortion help to realise principles 2 and 4. These techniques aim to hide/distort uninteresting information at any given time but allow easy and rapid unveiling of that information when required. Pan & Zoom also helps realise principles 2 and 4 simplifying navigation around large data displays and allowing focus and exploration of specific data areas.

4.3 Meta-Model The data meta-model briefly mentioned in Section 3 is used as the basis for our visualisation approach. It consists of three separate but integrated metamodels and describes a product line in terms of Decisions, Features and Components: x

A decision model captures a small number of high-level questions and provides an abstract, simplifying view onto features.

x

A feature model describes available configuration options in terms of “prominent or distinctive user visible aspects, qualities, or characteristics” [18].

x

A component model describes the implementation of features by software or hardware components.

These three models are interrelated. For instance, making a decision might cause several features to become selected, which in turn require a number of components to be implemented. The details of this meta-model are out of scope for this paper and the interested reader is guided to a previous publication [19] for further information. To evaluate and provide an example for the purpose of discussing the visualisation approaches, we have created such a DFC model using the configuration database of a large industrial system provided by a commercial software development company. This example contains a subset of the

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

21

configuration at approximately 1500 features and 1000 implementing components. The system itself is a transport management system for large companies such as freight forwarders. One high level function of this system is to provide transportation documents that are required when moving goods internationally. This functionality is modelled as a decision with eight implementing features. One such implementing feature is “Commodities”. This feature provides the ability to use and maintain sets of commodity codes that are required to identify the types of goods being transported for documentation purposes. This feature requires three other distinct features to be included. It is this example decision that we use to illustrate the visualisations below.

4.4 2D Approach As discussed in the related work section, using 2D approaches such as matrices and graphs to visualise feature models is the traditional way to allow feature exploration and model manipulation [7, 20]. In our 2D approach we provide a linear horizontal tree as the basis upon which we apply a number of visualisation techniques to support the configuration process. The tree view was implemented using the prefuse visualisation toolkit [21].

22

Cawley, Healy, Botterweck

Figure 2 presents a screenshot from our Eclipse based [22] tool showing our 2D visualisation. In all three approaches, a supporting synchronised view is used. This view in the left of the figure presents a simple list view of the decisions that identify the high level functionality/requirements that the system implements. Through selection of a decision in the supporting view by mouse-click, the main tree view in the centre of the figure displays all implementing features, their location within the feature model and their immediate sub-features. Animation is employed during the tree view transition from its previous visual state to preserve the context. The tree itself is a degree of interest tree and automatically displays features of interest (path to current node, sibling nodes and child nodes) to the current selection and hides all other features. The combination of multiple windows and Degree of Interest aim to provide the Focus+Context described earlier. Colour encoding is employed to highlight what features directly implement (amber) the selected decision and what features are required (blue) or excluded (red) by those implementing features. A colour encoded icon (sphere) to the left of the label of a highlighted feature identifies if the

Figure 2. 2D Visualisation Approach

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

23

feature has been included (green), eliminated (grey) or is un-configured (yellow). The stakeholder can explore the tree through mouse-clicks on nodes of interest. Again the tree, using smooth animation, automatically expands and collapses nodes depending on the selected node of interest. The collapsing/hiding of nodes while exploring the tree can be stopped at the will of the stakeholder to allow manual collapsing and expanding of branches. Using the mouse, the stakeholder can perform full zoom and can also pan the entire tree in any direction. These functions aim to implement the Details On Demand principle.

4.5 2.5D Approach 2.5D is a term that describes the use of 3D visual attributes in a 2D display [23]. For example, adding 3D attributes such as perspective (e.g. making certain objects smaller to indicate distance) and occlusion (e.g. overlapping objects to indicate layers) to a 2D display can be described as creating a 2.5D display.

24

Cawley, Healy, Botterweck

Figure 3. 2.5D Visualisation Approach

Figure 3 presents our 2.5D view. Again, when a selection is made within the supporting decision view, the main view displays the implementing features along with all features that are required or excluded by them. The view, inspired by Robertson et al.’s cone trees [24], consists of three stacked planes. Each plane provides a circular grouping of spheres. In the top plane, each sphere in the circle represents a grouping of features. When any one of those groupings in the top plane is selected (by mouse-click) then all features that comprise that grouping are displayed in the middle plane in a similar circular format. In the lower plane, all related (required / excluded) features are displayed (for all features presented in the middle plane). The innermost circle on the lower plane identifies features that are directly related (required, excluded) to features in the middle plane. In order of ascending radii, each subsequent circle in the lower plane represents the transitive relationships that exist i.e. required features can further require and/or exclude other features. In Figure 3 the stakeholder has selected the “Export Refunds” grouping in the top plane which groups six features. These six features are represented on the middle plane while their related features (required, excluded) are represented on the lower plane.

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

25

By hovering the mouse over any sphere in any of planes, a description of that element will be displayed in the centre of the plane. When a sphere is selected in any plane, the circle on which it is presented will rotate so that that sphere is brought to the front with its description displayed underneath. These functions aim to implement Details on Demand. The colour encoded sphere acts as the representation of a feature and its relationship. An amber sphere indicates a feature that implements the current decision selection. A blue sphere indicates a required feature while a red sphere indicates an excluded feature. Multiple windows (and multiple planes) are employed to separate and distribute decisions, feature groupings, features and relationships. Note that the lower plane displays all related features for all the implementing features in the middle plane. This allows an overview of the impact as a whole for this group of features. When a single implementing feature is selected in the middle plane, the circles in the lower plane rotate to ensure all related features are brought to the front while all other features in the plane are distorted (made transparent) in order to highlight the ones of interest. Animation is again used for all movements to preserve context.

Cawley, Healy, Botterweck

26

Figure 4. 3D Visualisation Approach

4.6 3D Approach Differing reports exist on the effectiveness of 3D visualisations to support software engineering but literature suggests that there is acceptance that it can be effective in specific instances [14-16]. Figure 4 presents a 3D view which attempts to provide a self contained representation of all three models (decisions, features and components) and their inter-relationships. However, at any given time, only information of interest is displayed. As before, multiple windows are employed to distribute the information and provide the supporting decision view. Figure 4 consists of a 3D space containing X, Y and Z axes. A sequential list of the decisions is displayed along the vertical Y-axis, a sequential list of the features is displayed along the horizontal X-axis and a sequential list of all the components is displayed along the Z-axis (moving away from the observer). The key idea here is that a point within this 3D space identifies a relationship between all three models. In other words, a sphere plotted at a particular

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

27

point will identify that the feature labelled at its X co-ordinate implements the decision labelled at its Y co-ordinate and is implemented by the component labelled at its Z co-ordinate. In Figure 4, the stakeholder has highlighted the sphere that represents the “Commodities” feature. However, in addition to this, by looking at the highlighted labels on the axes, we can see that it also represents the “Export Documents” decision that the feature implements and the “XTCM.I Include File” component that implements the feature. Focus+Context and Details On Demand are the main techniques guiding this implementation. We argue that all three models can be perceived to be represented through the listings on each axis. However, the details of any part of any model or its relationships are only displayed when required. For example, when a decision is selected there can be a number of implementing features. For each implementing feature, a sphere is plotted in the 3D space as described above. Other features that are required or excluded by those implementing features are also similarly plotted as spheres and are given a specific colour encoding - required features are blue and excluded features are red. Pan & Zoom are combined with rotation to allow a full world-in-hand manipulation of the view in three dimensions letting the stakeholder position the view depending on the information of interest.

5

Discussion

Our discussion follows a line of argument of how each task identified in Section 3 is supported by each visualisation approach, and discusses the benefits and limitations.

5.1 Identify / Locate Decisions and Features In all the approaches presented, the supporting decision view (displayed to the left of the main views in the figures) provides a simple list of the high level requirements decisions that represent the system functionality. Each decision groups a set of features that satisfy a particular functional need. In our industry example illustration, the “Export Documents” decision groups the set of features that combine to provide the production of printed documentation to allow the movement of goods. To aid fast identification / location of particular decisions, a search field and button are provided which when used will highlight any textual matches. Further to this, within the 3D approach, the main view also contains a search field where the stakeholder can run a search for decisions, features or components. When searching for a decision, the resulting matches are

28

Cawley, Healy, Botterweck

highlighted using increased brightness and enlarging of the text of the corresponding Y-axis labels. When searching for a feature within the 3D view, each matching result is rendered as a sphere, identifying the feature and also its implemented decision and implementing component. The stakeholder may also choose to see all required and excluded features of the features returned by the search. Similarly, the 2.5D view will display a matching feature on the middle plane, however, currently it is restricted to only showing the first exact match. This is a limitation that can be addressed in future work.

5.2 Impact of Decision / Feature Selection When a decision is selected, a stakeholder needs to understand what the impact would be on the system in terms of what features implement the decision, what features would subsequently be required and what features would be removed from the configuration. In the example introduced in Section 3 and illustrated in Figure 2, Figure 3 and Figure 4 the stakeholder has chosen the “Export Documents” decision which has eight implementing features. In the 2D approach (Figure 2), these can be clearly identified by the amber highlighting. Required and excluded features can also be easily identified through their blue and red highlighting respectively. By hovering the mouse over any particular feature of interest, all related features are further highlighted through animated enlargement allowing identification of the required and excluded features. Although the tree visualised in this approach is a degree of interest tree whereby only the nodes of interest are displayed, we would suggest that dealing with more than, say, 20 implementing features, each requiring and excluding other features, would increase the cognitive difficulty - the stakeholder would need to keep a mental map while panning and zooming. In the 2.5D approach (Figure 3), when the stakeholder selects a decision, the top plane in the view is populated with groupings of features. In this view the stakeholder can then choose which group of features to investigate further, once a group is selected, the implementing features are populated onto the middle plane and all their related (required, excluded) are populated onto the lower plane. In Figure 3, the stakeholder has chosen the “Export Refunds” grouping and we can see that there are six implementing features which require another four features and exclude one. Although there is an additional step in this approach (stakeholder must choose a grouping of features), we argue that through this grouping, many more features could be represented without increasing the cognitive effort required.

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

29

In the 3D approach (Figure 4), when the stakeholder selects a decision (or multiple decisions), all implementing features and their required and excluded features are displayed as colour encoded spheres. In addition to this, the implementing component of all the features is also identifiable on the Z-axis. By hovering over any element of interest (spheres, axis labels), that particular element is highlighted using a number of techniques. In Figure 4, the stakeholder is interested in the “Commodity” feature, which has been highlighted along with its implemented decision (“Export Documents”) and implementing component (“XTCM.I Include File”). By performing a mouse-click on any feature (sphere), all related features (required, excluded) are also highlighted. Using this approach, we would argue that it is easy for the stakeholder to comprehend the overall impact of selecting the decision and to also follow that up in order to understand what the impact of including any particular feature would be.

5.3 Feature Context Comprehension The understanding of a feature’s context (parent feature, alternative features, sub-features) is an important cognitive ability during its configuration. This understanding can inform the stakeholders as to what alternatives might be selected or what sub-options are available and how they would alter the impact of a particular configuration. Due to the tree visualisation employed as part of the 2D approach, the context is immediately identifiable. The degree of interest, by default, will always show parent, sibling and children of the node of interest. In both the 2.5D (Figure 3) and 3D (Figure 4) approaches, a supporting tree view along the bottom of the screen is employed which displays the feature of interest in a hierarchical tree. The tree shows the feature’s path from the root node along with the sibling nodes of any node on that path. It also shows the child nodes of the node of interest. As all the approaches essentially employ the same mechanism for this task, there is no evident behaviour that makes one approach better than the other. All three approaches allow quick and easy identification of the feature’s context.

6

Future Work

Additional implementation work is planned for both the 2.5D and 3D visualisation approaches. In both approaches, the use of colour encoding will be employed to identify the state of a feature (included/eliminated/unconfigured). Within the 2.5D approach, improved text rendering and highlighting of selected features is planned. Within the 3D

Cawley, Healy, Botterweck

30

approach, improved text rendering/fisheye will be implemented along with the ability to dynamically separate clustered features. Following these improvements, an evaluation of all three approaches is planned through the elicitation of expert opinion from senior practitioners in the area of large systems development and management.

7

Conclusion

In this paper we have presented and discussed three visualisation approaches to understanding and configuring variability in a software intensive industry example. We combine principles from cognitive theory and information visualisation techniques and use 2D, 2.5D and 3D visual environments in their implementation. We argue that each approach has benefits and limitations when considering a set of cognitive tasks that support the configuration process. We outline our plans for future work and further evaluation.

8

Acknowledgment

This work is partially supported by Science Foundation Ireland under grant number 03/CE2/I303-1.

References [1]

K. Pohl, G. Böckle, and F. v. d. Linden, Software Product Line Engineering: Foundations, Principles, and Techniques, 1st ed. ed. New York: Springer, 2005.

[2]

S. Deelstra, M. Sinnema, and J. Bosch, "Product Derivation in Software Product Families: A Case Study," Journal of Systems and Software, vol. 74, pp. 173-194, 2005.

[3]

M. Steger, C. Tischer, B. Boss, A. Müller, O. Pertler, W. Stolz, and S. Ferber, "Introducing PLA at Bosch Gasoline Systems: Experiences and Practices," in SPLC 2004, Boston, MA, USA, 2004, pp. 34-50.

[4]

S. K. Card, J. D. Mackinlay, and B. Shneiderman, Readings in Information Visualisation: Using Vision to Think: Morgan Kaufmann, 1999.

[5]

C. Ware, Information Visualisation: Perception for Design, 2nd ed.: Morgan Kaufmann, 2004.

[6]

F. Heidenreich, I. Savga, and C. Wende, "On Controlled Visualisations in Software Product Line Engineering," in 2nd International Workshop on Visualisation in Software Product Line Engineering (ViSPLE 2008) Limerick, Ireland, 2008.

[7]

R. Rabiser, D. Dhungana, and P. Grünbacher, "Tool Support for Product Derivation in Large-Scale Product Lines: A Wizard-based Approach," in 1st International Workshop on Visualisation in Software Product Line Engineering (ViSPLE 2007) Tokyo, Japan, 2007.

A Discussion of Three Visualisation Approaches to Providing Cognitive Support

31

[8]

D. Sellier and M. Mannion, "Visualizing Product Line Requirement Selection Decisions," in 1st International Workshop on Visualisation in Software Product Line Engineering (ViSPLE 2007) Tokyo, Japan, 2007.

[9]

A. Walenstein, "Foundations of cognitive support: Toward abstract patterns of usefulness.," in 9th International Workshop on Design, Specification and Verification of Interactive Systems (DSVIS): Springer-Verlag, 2002.

[10] K. C. Kang, J. Lee, and P. Donohoe, "Feature-Oriented Product Line Engineering," IEEE Software, vol. 19, pp. 58-65, 2002. [11] pure-systems GmbH, "Variant Management with pure::variants," http://www.puresystems.com, Technical White Paper, 2003-2004. [12] Biglever Software, "Gears," http://www.biglever.com. [13] O. Rohr, "VisMOOS (Visualization Methods for Object Oriented Software Systems)," University of Dortmund, http://ls10-www.cs.uni-dortmund.de/vise3d/prototypes.html, 2004. [14] J. Ali, "Cognitive support through visualization and focus specification for understanding large class libraries," Journal of Visual Language and Computing, 2008. [15] K. Risden, M. P. Czerwinski, T. Munzner, and D. B. Cook, "An initial examination of ease of use for 2D and 3D information visualizations of web content," Int. J. HumanComputer Studies, pp. 695-714, 2000. [16] G. Robertson, K. Cameron, M. Czerwinski, and D. Robbins, "Polyarchy Visualization: Visualizing Multiple Intersecting Hierarchies," in Conference on Human Factors in Computing Systems Minneapolis, Minnesota, USA.: ACM, 2002. [17] M. Sinnema, O. d. Graaf, and J. Bosch, "Tool Support for COVAMOF," in Workshop on Software Variability Management for Product Derivation - Towards Tool Support, 2004. [18] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson, "Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21," Software Engineering Institute, Carnegie Mellon University 1990. [19] G. Botterweck, S. Thiel, D. Nestor, S. B. Abid, and C. Cawley, "Visual Tool Support for Configuring and Understanding Software Product Lines," in The 12th International Software Product Line Conference (SPLC08) Limerick, Ireland, 2008. [20] C. Cawley, D. Nestor, A. Preußner, G. Botterweck, and S. Thiel, "Interactive Visualisation to Support Product Configuration in Software Product Lines," in Proceedings of 2nd International Workshop on Variability Modeling of Software-Intensive Systems (VAMOS 2008) Essen, Germany, 2008. [21] J. Heer, S. K. Card, and J. A. Landay, "prefuse: a toolkit for interactive information visualization," in Conference on Human Factors in Computing Systems Portland, Oregon, USA: ACM New York, NY, USA, 2005. [22] "Eclipse IDE," http://www.eclipse.org. [23] C. Ware, "Designing with a 2 1/2D Attitude," Information Design Journal, vol. 3, pp. 255-262., 2001. [24] G. G. Robertson, J. D. Mackinlay, and S. K. Card, "Cone Trees: animated 3D visualizations of hierarchical information," in Conference on Human Factors in Computing Systems New Orleans, Louisiana, United States: ACM New York, NY, USA, 1991.

A Database Architecture for Scalability and High Availability Andreas Weininger IBM Deutschland GmbH Hollerith Str. 1 81829 Munich, Germany [email protected]

Abstract: Database applications usually have two main requirements

for a database managements system (DBMS): The DBMS must be scalable to meet the performance requirements of growing data and work loads and it must meet the availability requirements, which often mean that the system has to be available 24 hours on 7 days a week. This paper shows how a database architecture can be defined based on the novel MACH11 technology of IBM Informix Dynamic Server (IDS) which is able to fulfill extreme availability requirements which includes continuous operation even in the case of disasters which bring down whole data centers and which provides scalability for diverse applications ranging from OLTP systems to data warehouses. We illustrate this with an example from a real customer implementation.

1

Introduction

Many database applications no longer allow any downtime, planned or unplanned. Planned downtime was traditionally used for maintenance operations like reorganization of data and backups, upgrades or exchanges of hardware, upgrades of the operating system or upgrades of the database management system, These downtimes were usually planned for the night or weekend. With the globalization of companies and with access to applications via the Internet, there are no longer any time slots available. Unplanned downtimes are caused by failures of hardware or software components. But the requirement that there are always users needing to access the DBMS, means that even in the case of the failure of some component, the whole system has to continue operation.

Weininger

34

This also means that in the case of a disaster like the failure of a whole data center, the DBMS has to continue operation. Besides these availability requirements, there are also new scalability requirements. The peak load for an application and with it the peak load on a database system may change dramatically within a very short time span, for instance because of some promotion for a web application. Therefore, it must be possible to dynamically add and remove resources from a DBMS while all the new computing resources see all the contents of the database immediately and are also able to modify all data immediately. Cloud computing is a model for providing the fast and easy addition of new resources which the DBMS has to support.

2

MACH11 Technology

The IBM Informix Dynamic Server (IDS) [3] has introduced a novel clustering technology for achieving the above mentioned availability and scalability goals [1]. This technology is called MACH11. Avoiding maintenance windows is supported by having all operations like reorganization of data and backup as on-line operations which are performed concurrently to the regular operation. Each MACH11 cluster consists of several nodes. There is always one node which is singled out as so-called primary, and many other nodes called secondaries. There are different types of secondaries: • There may be 0 or 1 High-Availability Data Replication (HDR) Secondary nodes. • There may be any number of Remote Standalone Secondary (RSS) nodes. • There may be any number of Shared Disk Secondary (SDS) nodes. An HDR node has its own copy of the data in the DBMS and is updated from the primary node via synchronous or asynchronous log record replication. When the primary node fails or when the primary node has to be removed from the cluster for some hardware or operating system upgrade, the HDR secondary can immediately take over as primary. An RSS node is similar to an HDR secondary node, but the replication of the log records is always asynchronous and the protocol is optimized for replication over very long distances e.g. several thousand kilometers. It is also possible to configure a delay for the application of log records at a RSS secondary for having a time-shifted copy of the data which is immediately available to protect against errors like accidental dropping of tables.

A Database Architecture for Scalability and High Availability

35

Unlike HDR and RSS secondaries, an SDS node is sharing the DBMS disks with the primary node. But also unlike other shared disk database technologies like Oracle RAC [2], an SDS node is synchronized with the primary node via the database log and the exchange on information about the log progress. This means that making a SDS node to a primary node after the failure of a primary node is much faster since no lock remastering phase is necessary. Also if an SDS node fails, there is essentially no impact on the remaining cluster nodes. Write operations may be performed on all types of nodes of the cluster but the physical writing to disk and in this way the synchronization is done on the primary node. Enterprise Replication is an additional replication technology which can be combined with all of the above technologies. It doesn’t have a dedicated primary and all nodes are considered equal. It even supports rolling upgrades of the DBMS itself.

3

Example

This section shows how the above described MACH11 technologies were used at an investment bank to design a database architecture of a business critical system for analyzing securities. Figure 1 shows how this architecture looks like. New securities data is fed into the cluster via the primary node in the top of the diagram. The users run complicated models on the Linux compute cluster at the right side of the diagram. The application is fully parallelized and a single user usually gets between 5 and 20 nodes. These compute nodes get information about the securities by accessing the SDS nodes via a load balancer. SDS makes it very easy to add additional nodes if the need arises. The HDR node on the right side protects against a possible corruption of the disks of the SDS cluster. This architecture protects against the loss of any disk, any disk array, and any node. Actually the system continues working as long es at least one node survives. Only performance is reduced corresponding to the number of nodes removed from the cluster. How this database architecture protects against the loss of a whole data center in the case of a disaster is shown in figure 2. For this, the nodes are distributed across two data centers which are more than 10 kilometers apart. They are connected via a common SAN and a GBit Ethernet. The primary and three SDS nodes are located in one data center, the HDR secondary and the remaining three SDS nodes are located in the other data center. The shared disk pool and the disks of the HDR node are on two disk arrays, one located in each data center. Each logical disk used by the DBMS is mirrored to physical

Weininger

36

Figure 1. Architecture

disks in the disk arrays where each disk array contains one mirror. In addition RAID-1 is used inside the disk array. If data center 2 fails, operation of the primary and the three SDS nodes in data center 1 continues without interruption. There is only no longer any protection by a HDR secondary and there is reduced performance since three SDS nodes are missing. If data center 1 fails, one of the SDS nodes in data center 2 has to take over as primary. The HDR secondary has to reconnect to the new primary, but otherwise operation continues without interruption. When the failed nodes become available again, they just reconnect to the cluster, and in the case of the HDR secondary it has also to catch up by replicating the transactions which happened in the meantime. Enterprise Replication was used for migrating the previous system to this new architecture since it allowed smooth migration and parallel operation of both systems in the initial phase.

A Database Architecture for Scalability and High Availability

37

Figure 2. Protection against failure of a data center

4

Conclusion

The above described database architecture is now used in production for some time and has shown that it is possible to implement a database which has to satisfy extreme high availability and scalability requirements.

References [1] C. Ballard, J. Baric, A. Gupta, H. Kirstein, R. Naicken, and N. Ozarkar. Informix Dynamic Server 11: Extending Availability and Replication. IBM Redbook. IBM, 2nd edition, June 2008. [2] M. Bauer and R. Strohm. Oracle Real Application Clusters Administration and Deployment Guide 11g Release 1 (11.1). Oracle, January 2009. [3] IBM. IBM Informix Dynamic Server Administrator’s Guide Version 11.50, 2009.

¨ Vermeidung der Abhangigkeitsdivergenz zwischen Design und Implementierung in Java Jens Cornelis, Klaus Dorer Fakult¨at Elektrotechnik und Informationstechnik Hochschule Offenburg Badstr. 24 77652 Offenburg, Germany [email protected], [email protected]

Zusammenfassung: Die Einhaltung der innerhalb der Designphase

festgelegten Architektur eines Softwareprojektes muss w¨ahrend der Entwicklungsphase sichergestellt werden. Dieses Papier beschreibt eine Erweiterung des Eclipse-Plugins JDepend4Eclipse, die die Verwaltung von Regels¨atzen erlaubt und die Pr¨ufung auf in einem Projekt vorhandene, unerlaubte Abh¨angigkeiten auf Knopfdruck innerhalb der Entwicklungsumgebung vornimmt. Die Erweiterung des Plugins wird bereits erfolgreich in internen Projekten der Hochschule Offenburg eingesetzt und soll demn¨achst o¨ ffentlich verf¨ugbar sein.

1

Einleitung

Bei der Definition der Architektur eines Software Systems werden sowohl die Komponenten, aus denen das System bestehen soll, als auch deren Abh¨angigkeiten festgelegt. Diese werden u¨ blicherweise in einem UML Komponentendiagramm oder Paketdiagramm dargestellt. Die in diesen Diagrammen definierten Abh¨angigkeiten sind explizit als erlaubt anzusehen. Andere Abh¨angigkeiten darf es nicht geben, um m¨oglichst loose Kopplung zu erreichen. Diese sind daher als unerlaubt zu betrachten, auch wenn diese unerlaubten Abh¨angigkeiten nicht explizit in den Diagrammen angegeben sind. Das in Abbildung 1 gezeigte Model-View-Controller Pattern legt beispielsweise die erlaubten Abh¨angigkeiten zwischen der graphischen Benutzeroberfl¨ache (View), der Programmlogik (Controller) und dem zugrunde liegenden Datenmodell (Model) fest.

40

Cornelis, Dorer

¨ Abbildung 1. Paketdiagramm fur ¨ die Abhangigkeiten des MVC Patterns

Um zu einem sp¨ateren Zeitpunkt aus einer Desktopanwendung zum Beispiel eine Webanwendung machen zu k¨onnen, soll das Datenmodell keine Abh¨angigkeiten zu Benutzeroberfl¨ache oder Programmlogik aufweisen. Dadurch k¨onnen die Klassen f¨ur die graphische Benutzeroberfl¨ache leicht ersetzt oder ver¨andert werden, ohne dass dies Auswirkungen auf das Datenmodell des Programmes hat. Eine Abh¨angigkeit des Modells zum View ist daher im Paketdiagramm nicht vorgesehen und ist als unerlaubt anzusehen. Eine solche unerlaubte Abh¨angigkeit muss bei der sp¨ateren Implementierung verhindert werden, da ansonsten der urspr¨ungliche Designansatz und die angestrebte Entkopplung der Komponenten nicht mehr greifen w¨urde. Eine Abweichung der Implementierung vom urspr¨unglichen Design kann bereits durch die Sprachunabh¨angigkeit der UML verursacht werden, die sprachspezifische Implementierungsdetails nicht ber¨ucksichtigt und daher durch die Programmiersprache bedingte Abh¨angigkeiten nicht ausreichend abbildet [2]. In Java ist es zum Beispiel nur sehr bedingt m¨oglich, im Design definierte, unerlaubte Abh¨angigkeiten programmatisch zu verbieten. Zwar k¨onnen Klassen und Interfaces als Paket-privat deklariert werden und sind so vom Zugriff außerhalb ihres Pakets gesch¨utzt. Allerdings muss dann eine abstrakte Fabrik in jedem Java Paket daf¨ur sorgen, dass man die Implementierung dieser Komponente auch erzeugen kann, was einen nicht unerheblichen Overhead bedeutet, der in der Regel nicht in Kauf genommen wird. Außerdem ist dieser Mechanismus nicht in der Lage, unerlaubte Abh¨angigkeiten zwischen notwendigerweise nicht Paket-privaten Typen zu kontrollieren. Daher ist es in der Praxis oft so, dass die entwickelte Java Software vom urspr¨unglichen Design abweicht (architectural drift [7]) und sich in

Vermeidung der Abh¨angigkeitsdivergenz in Java

41

diesem Sinn unerlaubte Abh¨angigkeiten einschleichen. Dieser Effekt wird noch dadurch verst¨arkt, dass moderne Entwicklungsumgebungen automatisch import statements generieren. Der Nachteil dieser ansonsten sehr angenehmen Einrichtung ist, dass dem Entwickler so kaum noch auff¨allt, wenn unerlaubte Abh¨angigkeiten entstehen. Im Einzelfall kann eine Divergenz der Abh¨angigkeiten von Design und Implementierung nat¨urlich auch auf Defizite im Design hinweisen (architectural erosion [7]). Die Einsch¨atzung ob eine im Design nicht ber¨ucksichtigte, in der Implementierung aber vorhandene Abh¨angigkeit tats¨achlich als unerlaubt zu betrachten ist, muss daher im Einzelfall entschieden werden. Wird die Abh¨angigkeit in der Implementierung als erlaubt angesehen, muss auch das Design entsprechend ge¨andert werden. Wichtig ist dabei, diese Abweichungen u¨ berhaupt erst erkennen zu k¨onnen. In diesem Papier wird eine Erweiterung des JDepend4Eclipse Plugins vorgestellt, das dieses Problem behebt. Es erlaubt die Spezifikation erlaubter ¨ und unerlaubter Abh¨angigkeiten sowie deren automatische Uberwachung. In Kapitel 2 wird das dieser Arbeit zu Grunde liegende Plugin JDepend4Eclipse vorgestellt. Kapitel 3 beschreibt die n¨otigen Erweiterungen, um unerlaubte Abh¨angigkeiten verwalten und erkennen zu k¨onnen. Kapitel 4 stellt einige Ergebnisse bei der Arbeit mit dem neuen Plugin vor. In Kapitel 5 gehen wir auf andere Arbeiten zu diesem Thema ein. Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick auf zuk¨unftige Erweiterungsm¨oglichkeiten und Trends in Kapitel 6.

2

Hintergrund

Das Eclipse-Plugin JDepend4Eclipse von Andrei Loskutov [4] ist eine Wrapperapplikation von JDepend der Firma Clarkware Consulting. Es erm¨oglicht dem Anwender durch Auswahl des entsprechenden Eintrags im Kontextmen¨u einer Ressource, wie etwa einem Java-Paket oder dem gesamten Quelldateiordner eines Eclipse-Projekts, eine Bestimmung von Softwaremaßen zur Designqualit¨at vorzunehmen. ¨ Der Softwareentwickler erh¨alt einen Uberblick u¨ ber die Abh¨angigkeitsstruktur der von ihm zur Analyse ausgew¨ahlten Pakete und Klassen und kann durch Analyse der afferenten (Ca) und efferenten (Ce) Abh¨angigkeiten eine Aussage u¨ ber die Unabh¨angigkeit und Verantwortlichkeit eines Pakets treffen (vgl. [5]). Die von JDepend untersuchten Metriken sind im Einzelnen: Ca: Anzahl der von dieser Klasse, bzw. den Klassen innerhalb dieses Pakets abh¨angigen Pakete.(Afferente Abh¨angigkeiten)

Cornelis, Dorer

42

Ce: Anzahl der Pakete, von denen diese Klasse, bzw. die Klassen innerhalb dieses Pakets abh¨angig sind. (Efferente Abh¨angigkeiten) A: Verh¨altnis der Anzahl abstrakter Klassen zur Anzahl aller Klassen innerhalb dieses Pakets. I: Anzahl der efferenten Abh¨angigkeiten im Verh¨altnis zur Summe der afferenten und efferenten Abh¨angigkeiten. D: Distanz von der Ideallinie A + I = 1 Insbesondere k¨onnen so auch einfach ungew¨unschte zyklische Abh¨angigkeiten erkannt und deren Ursache bestimmt werden. Nicht ber¨ucksichtigt werden bei dieser Analyse durch JDepend4Eclipse bislang allerdings derlei Abh¨angigkeiten, die aufgrund der in der Designphase der Softwareentwicklung f¨ur dieses Projekt angelegten Architektur als unerlaubt anzusehen sind. Im Rahmen einer an der Hochschule Offenburg durchgef¨uhrten Thesis wurde die Funktionalit¨at des Plugins um eine ¨ M¨oglichkeit zur Definition erlaubter Abh¨angigkeiten und Uberpr¨ ufung des Projektes auf das Vorhandensein von unerlaubten Abh¨angigkeiten erweitert.

3

Erweiterung von JDepend4Eclipse

Um JDepend4Eclipse in Softwareprojekten zur einfachen Kontrolle der Umsetzung vereinbarter Architekturans¨atze bei der Implementierung der Komponenten einsetzen zu k¨onnen, wurde JDepend4Eclipse sowohl um einen ¨ Editor zur Pflege der Regels¨atze, als auch um die f¨ur die Uberpr¨ ufung des Projektes auf Regelverletzungen notwendige Anwendungslogik erg¨anzt. Damit die erstellten Regeln sowohl mit dem Editor als auch mit externen Anwendungen erstellt und gepflegt werden k¨onnen, werden die Abh¨angigkeiten in einer Datei im XML-Format projektbezogen gespeichert. Um die Datei dem Plugin eindeutig zuordnen und diese innerhalb von Eclipse auch direkt mit dem daf¨ur vorgesehenen Rule Editor o¨ ffnen zu k¨onnen, wurde die Dateiendung JDR f¨ur diesen Dateityp vorgesehen. Der Pfad und der Dateiname dieser Ressource lassen sich in den Preferences von JDepend4Eclipse angeben. Die Speicherung der Regels¨atze innerhalb des Eclipse Projektes ist insbesondere zur Nachverfolgung von Modifikationen an den erstellten Regeln und zur Verteilung dieser Regeln an die Mitglieder eines Entwicklungsteams von großer Bedeutung. Zudem lassen sich auf diesem Weg auch außerhalb der Eclipse Entwicklungsumgebung Modifikationen am Regelwerk vornehmen und eine weitere Verwendung in anderen Werkzeugen ist m¨oglich. Als

Vermeidung der Abh¨angigkeitsdivergenz in Java

43

sichtbare und stets verf¨ugbare Datei innerhalb des Projekts erfahren die dort gespeicherten Regeln eine große Aufmerksamkeit und sind im t¨aglichen Entwicklungsprozess pr¨asent. In den folgenden Abschnitten wird die Benutzung von JDepend4Eclipse anhand der Verwaltung der Abh¨angigkeiten mit dem Rule Editor und der zur Betrachtung der Analyseergebnisse vorgesehenden Ansicht erl¨autert.

3.1

¨ Abhangigkeiten verwalten

Zielanwender des Editors ist ein Entwickler, der neu hinzugekommene Abh¨angigkeiten innerhalb des Projekts mit Hilfe des Editors anhand der Architektur oder in R¨ucksprache mit dem Software-Architekten pr¨uft und bislang nicht erlaubte und nun im Projekt vorhandene Abh¨angigkeiten entweder explizit als erlaubt markiert oder deren Regelwidrigkeit best¨atigt. Durch die Versionierung der Datei und die damit einhergehende ¨ Nachverfolgbarkeit der daran vorgenommenen Anderungen, kann ein Missbrauch des Editors weitestgehend ausgeschlossen werden.

Abbildung 2. JDepend4Eclipse RuleEditor zur Bearbeitung der ¨ Regelsatze

Der in Abbildung 2 zu sehende Editor ist in drei Bereiche aufgeteilt. Die linke Tabelle zeigt dem Anwender jene Abh¨angigkeiten innerhalb seines Projekts, welche nicht als erlaubt markiert wurden und somit verboten

Cornelis, Dorer

44

sind. Neue und noch nicht best¨atigte Abh¨angigkeiten sind mit einem Fragezeichen-Symbol gekennzeichnet und k¨onnen entweder explizit als verboten best¨atigt oder den erlaubten Abh¨angigkeiten hinzugef¨ugt werden. Die Tabelle rechts zeigt die explizit als erlaubt deklarierten Abh¨angigkeiten an. Die in den beiden Tabellen angezeigten Abh¨angigkeiten stellen also die Gesamtheit der innerhalb des Projektes vorhandenen Abh¨angigkeiten zwischen Java Paketen dar. Durch das Umbenennen oder L¨oschen von Paketen entstehen in der Regeldatei Eintr¨age, die so im Projekt nicht mehr vorkommen. Verbotene oder erlaubte Abh¨angigkeiten, die im Projekt nicht mehr existieren jedoch in der Datei noch vorhanden sind, werden mit einem M¨ulleimer-Symbol gekennzeichnet. Diese k¨onnen entweder in der Datei belassen oder durch Dr¨ucken des entsprechenden Buttons gel¨oscht werden. Unter den Tabellen befindet sich der Bereich f¨ur die Steuerung des Editors. Um etwa Abh¨angigkeiten zu erlauben werden diese markiert und durch Auswahl des entsprechenden Buttons den erlaubten Abh¨angigkeiten hinzugef¨ugt. Entsprechend funktioniert auch das nachtr¨agliche Verbieten bislang erlaubter oder f¨alschlicherweise als erlaubt markierter Abh¨angigkeiten oder die Best¨atigung neu hinzugekommener Abh¨angigkeiten.

3.2

¨ Abhangigkeiten erkennen

Die im Eclipse-Umfeld als Perspective bezeichnete, bisherige Ansicht von JDepend4Eclipse wurde um ein zus¨atzliches Fenster erg¨anzt, das die unerlaubten Abh¨angigkeiten der im PackageTreeView durch den Anwender selektierten Pakete bzw. Klassen anzeigt. Bezogen auf diese Selektion, bekommt der Anwender hier die regelwidrigen Abh¨angigkeiten angezeigt. Die Projektstruktur l¨asst sich in dem in Abbildung 3 zu sehenden PackageTreeView ablesen. Der Anwender kann hier die Auswahl von Paketen und Klassen vornehmen, deren Metriken betrachtet werden sollen. Somit ist nicht nur m¨oglich festzustellen, ob ein Paket unerw¨unschte, efferente Abh¨angigkeiten aufweist, sondern der Entwickler kann auch feststellen, durch welche Klassen diese verursacht werden und kann den Umstand beheben. In der Praxis sind unerlaubte Abh¨angigkeiten h¨aufig f¨ur das Auftreten zyklischer Abh¨angigkeiten verantwortlich. Diese Zusammenh¨ange lassen sich in dieser Ansicht auf einen Blick erkennen. Sollen nur interne Abh¨angigkeiten gepr¨uft werden, so k¨onnen Abh¨angigkeiten zu externen Bibliotheken durch die bereits in JDepend4Eclipse vorhandenen Filter ausgeblendet werden. Diese k¨onnen in den Preferences des Plugins eingestellt werden. Geplant ist, diese Funktionalit¨at projektspezifisch zur Verf¨ugung zu stellen.

Vermeidung der Abh¨angigkeitsdivergenz in Java

45

Abbildung 3. JDepend4Eclipse Perspective

4

Ergebnisse

Zur Evaluation wurde das Plugin in zwei Projekten beispielhaft eingesetzt. Die Ergebnisse sind im Folgenden dargestellt.

4.1

SUN MVC Beispiel

Die Funktionsweise von JDepend4Eclipse wurde zun¨achst in einer u¨ berschaubaren Umgebung an einem im Sun Developer Network als Beispiel f¨ur die Implementierung des Model-View-Controller Patterns zur Verf¨ugung gestellten Projektes [3] erprobt. Da f¨ur den ersten Lauf von JDepend4Eclipse zun¨achst noch keine Datei mit Regels¨atzen zur Verf¨ugung stand, wurden die im Projekt vorhandenen Abh¨angigkeiten in der JDepend4Eclipse Perspective zun¨achst alle als unerlaubt angezeigt. Bei Betrachtung der Metriken war hier vor allem auff¨allig, dass im Projekt zyklische Abh¨angigkeiten vorhanden waren. Das Erlauben der Abh¨angigkeiten im Editor von JDepend4Eclipse erfolgte unter Ber¨ucksichtigung des in Abbildung 1 gezeigten Entwurfsmusters. Zus¨atzlich zu den Java Paketen model, view und controller waren hier noch zwei weitere Pakete zu ber¨ucksichtigen. Das Paket mvc beinhaltete die main() Methode und wies efferente Abh¨angigkeiten sowohl zu model, view und controller auf. Da diese Methode zur Erzeugung der Objekte und zur Dependency Injection genutzt wurde, waren diese Abh¨angigkeiten jedoch als

Cornelis, Dorer

46

gerechtfertigt anzusehen und konnten somit erlaubt werden. Das Paket utilities beinhaltete dem Entwurfsmuster View Helper entsprechend f¨ur die Views notwendige Logik, weshalb die Abh¨angigkeit des Pakets view zu utilities ebenfalls als gerechtfertigt betrachtet wurde und diese daher ebenfalls erlaubt wurde. Zuletzt blieb eine Abh¨angigkeit des view Pakets zum controller Paket in der Liste der unerlaubten Abh¨angigkeiten bestehen.

Abbildung 4. JDepend4Eclipse Analyseergebnis des SUN MVC Beispiels

Nach Fertigstellung der Regels¨atze wurde ein erneuter Analyselauf von JDepend4Eclipse veranlasst. Wie in Abbildung 4 gezeigt, konnten so die Klassen DisplayViewPanel und PropertiesViewPanel als Urheber der unerlaubten und zyklischen Abh¨angigkeit in der JDepend4Eclipse Perspective ermittelt und das Projekt durch entsprechendes Refactoring bereinigt werden.

4.2

Projekt Attractive

Der Einsatz in einem mittelgroßen Projekt wurde anhand des an der Hochschule Offenburg durchgef¨uhrten Projekts Attractive durchgef¨uhrt. In diesem Projekt sind derzeit 230 Java Klassen in 28 Komponenten und 62 Paketen organisiert. Vor der Verf¨ugbarkeit der automatischen ¨ Pr¨ufung auf unerlaubte Abh¨angigkeiten wurde die Ubereinstimmung der Implementierung zur vorgegebenen Architektur manuell mit Hilfe des Vorg¨angers JDepend4Eclipse (Version 1.2.0) gepr¨uft. Dieser Prozess dauerte

Vermeidung der Abh¨angigkeitsdivergenz in Java

47

ca. 30 Minuten und wurde entsprechend selten ca. alle vier Wochen durchgef¨uhrt. Die Ergebnisse der automatischen Pr¨ufung sind in Tabelle 1 dargestellt. Die erstmalige Definition erlaubter und unerlaubter Abh¨angigkeiten mit dem in Abschnitt 3.1 vorgestellten Editor dauerte 36 Minuten und damit nur unwesentlich l¨anger als eine manuelle Pr¨ufung vorher. Ab dann dauerte eine automatische Pr¨ufung 2,7 Sekunden und damit unmerklich l¨anger, als ein Lauf der Vorg¨angerversion ohne automatische Pr¨ufung. Insgesamt wurden 123 Abh¨angigkeiten zwischen Paketen gefunden, davon waren 119 erlaubte Abh¨angigkeiten. Interessant ist also, dass bereits bei der erstmaligen Definition der Abh¨angigkeiten vier unerlaubte Abh¨angigkeiten gefunden wurden, ein deutliches Zeichen f¨ur die Fehleranf¨alligkeit des zuvor durchgef¨uhrten manuellen Prozesses. Mit dem Einsatz des neuen Plugins durch alle Entwickler kann jetzt vor jedem Commit innerhalb weniger Sekunden die Kompatibilit¨at zur Architektur sichergestellt werden. Klassen Komponenten Laufzeit Erlaubte Abh¨angigkeiten Gefundene, unerlaubte Abh¨angigkeiten

230 28 2,7 s 119 4

Tabelle 1. Ergebnisse der Anwendung auf das Attractive Projekt

5

Andere Arbeiten

Das Problem der Divergenz von Architektur und Implementierung wird vielfach in der Literatur diskutiert (siehe z.B. [7]). Die meisten L¨osungsans¨atze basieren darauf, die Architektur in geeigneten Meta-Sprachen zu beschreiben, ¨ um eine automatische Uberpr¨ ufung der Divergenz von Architektur und Implementierung zu erm¨oglichen. Schwanke und andere [8] f¨uhren die Sprache ’Gestalt’ ein mit deren Hilfe Architekturspezifikationen derart formalisiert werden k¨onnen, dass deren Einhaltung durch die Software automatisch verifiziert werden kann. Die industrielle Einsatzm¨oglichkeit wird am Beispiel eines großen Projekts in C belegt. Mens [6] zeigt auf a¨ hnliche Weise am Beispiel von Smalltalk, wie mit einer logischen Meta-Programmiersprache (LMP) der Prozess der Verifikation automatisiert werden kann. Derartige Ans¨atze sind aber relativ aufw¨andig in der Definition und Einarbeitung. Insbesondere f¨ur bereits vorhandene Systeme wird man diesen

Cornelis, Dorer

48

Aufwand nicht leisten wollen. Demgegen¨uber kann die Definition unerlaubter Abh¨angigkeiten mit dem hier beschriebenen Plugin in relativ kurzer Zeit erfolgen. Das Problem der Divergenz von Architektur und Implementierung an der Wurzel packen w¨urde, wenn bereits der Compiler unerlaubte Abh¨angigkeiten erkennen und anzeigen w¨urde. Dies k¨onnte das f¨ur Java7 diskutierte Projekt Jigsaw mit Java Specification Request (JSR) 294 leisten [1]. Dort ist ein Modulsystem vorgesehen, das auf Sprachebene erlaubt, Abh¨angigkeiten von Modulen zu definieren. Allerdings ist derzeit noch nicht klar, ob JSR 294 tats¨achlich Teil von Java7 sein wird. Ebenfalls gibt es Meldungen, dass dieser JSR nicht Teil der Java SE 7 platform specification sein wird und damit nicht zwangsweise von allen Runtimes unterst¨utzt werden w¨urde. In jedem Fall wird JDepend4Eclipse f¨ur bestehende Projekte, die nicht auf Java7 umgestellt werden, ein wichtiges Werkzeug zur Sicherstellung der Implementierungsqualit¨at bleiben.

6

Zusammenfassung und Ausblick

Durch die im Produktiveinsatz von JDepend4Eclipse gesammelten Erfahrungen wurden Erkenntnisse u¨ ber weiteren Funktionsbedarf und ¨ w¨unschenswerte Funktionen gewonnen. Die Uberpr¨ ufung des Projektes auf das Bestehen unerlaubter Abh¨angigkeiten erfolgt derzeit lediglich durch manuellen Start durch den Anwender. W¨unschenswert w¨are eine entsprechende Kontrolle automatisch, beispielsweise durch einen eingesetzten Automation Server erfolgen zu lassen. Ein m¨oglicher Ansatz ist die automatische Generierung eines JUnit-Modultests, der im Rahmen der automatisierten Testl¨aufe die Schnittstellen von JDepend4Eclipse nutzt, ¨ um eine Uberpr¨ ufung erfolgen zu lassen. Bei Vorliegen von unerlaubten Abh¨angigkeiten k¨onnte der Entwickler, der durch seinen Checkin in die Versionskontrolle die Regelverst¨oße verursacht hat, entsprechend informiert und zu einer Korrektur veranlasst werden. Die Schwierigkeit bei der ¨ Umsetzung besteht hier vor allem darin, dass f¨ur die Uberpr¨ ufung ein Start von JDepend w¨ahrend des Testlaufs notwendig w¨are und dies die Installation der Eclipse-RCP-Module zwingend erforderlich macht. Die Erstellung der JDepend-Regeldatei wird beim ersten Start von JDepend4Eclipse angelegt und behandelt derzeit alle Abh¨angigkeiten im Projekt zun¨achst als unerlaubte Abh¨angigkeiten. Dadurch wird sichergestellt, das eine Auseinandersetzung mit den vorhandenen Abh¨angigkeiten erfolgt und der Editor genutzt werden muss, um die Abh¨angigkeiten entweder als erlaubt zu deklarieren, oder aber eine Best¨atigung des Regelverstoßes und eine dementsprechende Korrektur der zugrunde liegenden Struktur

Vermeidung der Abh¨angigkeitsdivergenz in Java

49

vorzunehmen. Die Informationen u¨ ber erlaubte und somit auch u¨ ber unerlaubte Abh¨angigkeiten liegen aber bereits in der Designphase in Form der erstellten UML-Diagramme vor. Um eine Durchg¨angigkeit zu erreichen und beispielsweise auch bei Durchf¨uhrung eines Roundtrip-Engineering die Erstellung der Regeldatei automatisieren zu k¨onnen, ist die Erstellung der Regels¨atze durch das zur Erstellung der UML-Diagramme genutzte Werkzeug w¨unschenswert. Dies k¨onnte ebenfalls in Form eines Plugins f¨ur die jeweilige Software erreicht werden. Nach einer mehrw¨ochigen Testphase hat das neue Plugin inzwischen einen stabilen Stand erreicht. Wie in Abschnitt 4.2 erl¨autert wird das Plugin in internen Projekten der Hochschule bereits erfolgreich eingesetzt. Jetzt ist ¨ geplant, das Plugin der breiten Offentlichkeit zug¨anglich zu machen. Es ist zu erwarten, dass es rege Anwendung finden wird.

Literatur [1] A. Buckley. Java specification request jsr 294. http://jcp.org/en/jsr/detail?id=294, Februar 2010. [2] Cooper et al. Java implementation verification using reverse engineering, 2004. [3] R. Eckstein. Java se application design with mvc. http://java.sun.com/developer/technicalArticles/ javase/mvc, M¨arz 2007. [4] A. Loskutov. Jdepend plugin for eclipse: Jdepend4eclipse. http://andrei.gmxhome.de/jdepend4eclipse/index.html, Februar 2010. [5] R. C. Martin. Oo design quality metrics - an analysis of dependencies, 1994. [6] K. Mens. Automating Architectural Conformance Checking by means of Logic Meta Programming. PhD thesis, Vrije Universiteit Brussel, 2000. [7] D. E. Perry and A. L. Wolf. Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes, 17(4):40–52, 1992. [8] R. W. Schwanke, V. A. Strack, and T. Werthmann-Auzinger. Industrial software architecture with gestalt. In IWSSD ’96: Proceedings of the 8th International Workshop on Software Specification and Design, page 176, Washington, DC, USA, 1996. IEEE Computer Society.

Master Data Management Moderne Stammdatenverwaltung in einer SOA Architektur Romeo Kienzler IBM Schweiz AG Software Group Vulkanstrasse 106 8010 Zürich [email protected] Für Medienanfragen: IBM Schweiz AG, Stephen Funk, [email protected],

Zusammenfassung: In den Unternehmen hat sich SOA von einem Hype zur wichtigsten Systemintegrationsplattform entwickelt. Inzwischen redet man nicht mehr nur über SOA, sondern setzt es um. Der SOA Ansatz funktioniert aber nur so lange gut, bis sich die Daten der verschiedenen Subsysteme überschneiden. Sobald es Überschneidungen gibt oder Daten sogar doppelt geführt werden, sind Fehler vorprogrammiert. Aufwändige Datenabgleiche könnten diese Doppelspurigkeiten zwar bereinigen. Dieser Datenabgleich verzahnt alle Systeme miteinander und die ehemals flexible SOA Architektur wird damit wieder unflexibel. Wie können nun diese Probleme gelöst werden? Anhand diverser Beispiele aus der Praxis erklärt dieser Beitrag diese Herausforderungen genauer und zeigt Lösungen auf. Welchen Einfluss dieses Datendurcheinander auf die Unternehmen hat, wie eine moderne Stammdatenverwaltung implementiert wird und welche neuen Unternehmensszenarien anhand dieser einheitlichen Sicht auf sämtliche Daten möglich sind, werden am Schluss erläutert.

1

Datenhaltung in einer SOA Architektur

Eine SOA Umgebung besteht aus SOA Systemen und jedes dieser einzelnen Systeme besteht aus drei Elementen: Den Daten, der Programmlogik sowie den Schnittstellen, welche als WebServices realisiert sind. Wird nun ein solcher WebService aufgerufen, dann läuft im Hintergrund die dazugehörende Programmlogik ab. Diese verändert die Daten und liefert sie an das aufrufende System zurück. Jedes System führt also seine eigene Datenbasis. Nach aussen versteckt das System diese hinter „seinen“ Schnittstellen. Dies ist ein grundlegendes Konzept [1], welches schon in der objektorientierten Programmierung Anwendung findet.

Kienzler

52

2

Informationschaos durch unstrukturierte Datenbestände

Nehmen wir den klassischen Übernahmefall eines Unternehmens A von einem Unternehmen B als Ausgangssituation. Man konsolidiert dann die ITSysteme oft mithilfe von SOA. Das heisst, die Unternehmen behalten ihre Software-Infrastruktur, erweitern diese mit Schnittstellen und verknüpfen so die zwei unterschiedlichen Systemlandschaften. Wir gehen zur Vereinfachung von folgender Situation aus: Unternehmen A und B haben jeweils zwei Systeme, eines dient zur Kundenverwaltung (KA, KB) und das andere der Produktverwaltung (PA, PB). In KA und in KB sind nun die gleichen Kunden verzeichnet. Produkte, welche die Kunden von Unternehmen A kauften, wurden in KA erfaβt und referenzieren auf Produkte in PA. Die Produkte der gleichen Kunden in KB referenzieren auf Produkte in PB. Nun führen zum Beispiel schon Adressänderungen zu Inkonsistenzen. Kundenverträge und Produktkäufe erscheinen jeweils nur im dafür zuständigen System. Schon dieses einfache Problemszenario zeigt auf, dass die folgenden elementaren Fragen nicht mehr so ohne Weiteres zu beantworten sind, wenn die oben genannten Probleme bei einem Datenbestand mit sehr vielen Kunden auftauchen: x

Wie viele Kunden hat dieses konsolidierte Unternehmen?

x

Welcher dieser Kunden hat schon welches Produkt gekauft?

Um dieses Problem zu umgehen, sind aufwändige Datenabgleiche nötig. Andernfalls müssten bei jeder Anfrage mehrere Systeme aufgerufen werden, um auf die relevanten Informationen zugreifen zu können. Datenabgleiche verzahnen die einzelnen Systeme und die SOA Architektur wird, wie schon erwähnt, wieder unflexibel. Die Unternehmensführung verliert den Überblick über ihre Kunden, was dazu führt, dass die Kunden nicht mehr optimal betreut und deswegen unzufrieden sind. Die Ursache dafür ist nicht Unhöflichkeit, sondern ein Datenqualitätsproblem. Dieses Problem lässt sich jedoch lösen. Die Erfahrung zeigt, dass man zentrale Entitäten identifizieren kann. Diese Entitäten müssen unternehmensweit integriert und verwaltet werden. Im Fachjargon nennt man diese Entitäten „Master Data“. Ein so genanntes Master Data Management System, kurz MDM System, verwaltet ebendiese Daten. Das Ziel von MDM ist, ein System of Trust oder auch eine so genannte „Golden Copy“ [2] aller Master Daten zu erstellen. Das MDM System speichert die Master Daten aller Quellsysteme und entfernt Duplikate.

Master Data Management

3

53

Hoher Wartungsaufwand mit Bastellösungen – Wer will das schon?

Eine Alternative zur Einführung eines MDM Systems wäre, ein bestehendes System, zum Beispiel das KA aus dem vorherigen Beispiel anzupassen. Und zwar so, dass es neben den eigenen Kundendaten auch die Kundendaten der anderen Systeme sowie die Produktdaten (zum Beispiel aus PA und PB) verwaltet. Hierfür müsste man das spezifische Datenmodell, die Programmlogik sowie die Schnittstellen anpassen. Dies hat hohen Entwicklungs- und Wartungsaufwand zur Folge. Die Erweiterung des bestehenden Systems vermischt MDM-Funktionalitäten mit den Kernfunktionalitäten des bestehenden Systems. Eine weitere Alternative wäre die Verwendung eines bereits vorhandenen Data-Warehouses (DWH). Hier sind bereits alle unternehmensrelevanten Daten integriert oder lassen sich auf einfache Weise in die bestehenden ETL (Extract Transform Load [3]) Prozesse integrieren. Ein ETL Prozess ist ein toolunterstützer Prozess der es ermöglicht, Daten mehrerer heterogener Quellsysteme in eine homogene Form zu bringen. Die Daten sind in DWH’s leider „After the Fact“ [4]. Das heisst, sie sind veraltet und für viele transaktionalen Prozesse nicht brauchbar. Ein weiterer Nachteil steckt im Data-Warehouse selbst. Denn dieses für Analysezwecke optimierte Datenmodell (meist Star- [5] oder Snowflake-Modelle [6]), erfüllt nur sehr niedrige Datenintegritätsanforderungen, da es nicht normalisiert ist (Normalform [7]). Zwar würden beim DWH Ansatz keine MDMFunktionalitäten mit den Kernfunktionalitäten eines bestehenden Systems vermischt, jedoch unterscheidet sich der DWH Ansatz vom MDM System durch die Aktualität der Daten und das ungeeignete Datenmodell. Aus diesem Grund hält neben den SOA Systemen und dem DWH System das effizientere MDM System Einzug in Unternehmen welches für OLTP (Online Transaction Processing) geeignet ist (OLTP vs. OLAP [8]). MDM Lösungen werden auf dem Softwaremarkt als fertige Programmpakete angeboten. Alternativ können sie auch eigenentwickelt werden. Hier muss evaluiert werden, welche Lösung langfristig ökonomischer ist. Wie jedes SOA System, besteht auch ein MDM System aus den Daten, der Programmlogik und einer Schnittsstelle in Form von WebServices. Zu diesem System wird in der Regel ein abstraktes Datenmodell mitgeliefert, welche den Anforderungen der jeweiligen Branche des Unternehmens entspricht. Es existieren diverse Datenmodelle für Versicherungen, Banken, Retailer, Telekommunikationsunternehmen usw. [9].

Kienzler

54

Abbildung 1: Der MDM Server als neues Subsystem in der SOA Landschaft. Die Systeme wie zum Beispiel „Order“ oder „Billing“ stellen Datensilos dar. Servicekonsumenten wie beispielsweise ein Web Interface oder eine CallcenterLösung greifen über einen Bus auf die Quellsysteme und das MDM System zu. Quelle: IBM Corporation

Die SOA-Schnittstelle ermöglicht Schreib- und Lesezugriff auf sämtliche Daten. Ein feingranulares, hierarchisches Rechtesystem, welches bis auf Datensatz- und Datenfeldebene konfigurierbar ist, sorgt für die notwendige Sicherheit. Die Benutzer können durch ein User Interface auf die Daten zugreifen. Die meisten Anbieter liefern Wizard-basierte Tools mit, mit welchen man per Mausklick das Datenmodell, die SOA-Schnittstellen und das User Interface erweitern kann.

4

Wie sieht ein MDM Einführungsprozess aus?

Ein Business Analyst oder Architekt identifiziert bei der MDM Systemeinführung die Master Daten in den verschiedenen Systemen und erstellt ein Data Mapping. Dieses beschreibt für jedes System, welche Attribute und Entitäten der Quellsysteme ins MDM Datenmodell überführt werden. Danach synchronisiert man die Daten der Quellsysteme mit dem MDM System. Bei diesem Vorgang gibt es einen so genannten „Initial Load“. Dies ist ein klassischer ETL-Prozess, der mit der Unterstützung von ETL-Tools anhand des Data Mappings sämtliche relevanten Daten aus den Quellsystemen ins MDM System kopiert. Die darauffolgenden „Continuous

Master Data Management

55

Updates“ propagieren Änderungen der Daten in den Quellsystemen an das MDM System weiter. Die Daten, welche sich im MDM System ändern, werden wieder an die Quellsysteme weiterpropagiert. Dabei spielt es keine Rolle, ob die Änderungen direkt im MDM System vorgenommen werden, oder von einem Update eines anderen Quellsystems stammen. Das MDM System fungiert somit als „Transactional Data Integration Hub“ [9]. Hierfür ist es natürlich nötig, die Quellsysteme zu erweitern und mit dem MDM System zu verzahnen. Die Art der Integration zwischen MDM und den Quellsystemen ist abhängig von der Architektur der Quellsysteme. MDM System Anbieter liefern Integrationspakete für die gängigen Quellsysteme mit. In anderen Fällen erweitert man das vorhandene Quellsystem und propagiert Änderungen über die SOA Schnittstelle des MDM Systems. Notfalls greift man direkt auf die Datenbank des Quellsystems zu. Dies muss man zum Beispiel tun, wenn eine Erweiterung des Quellsystems nicht möglich ist (proprietäre Lösung, kein Quellcode vorhanden etc.). Es gab auch schon Fälle, in welchen keine IT-basierte Lösung möglich war. Dabei wurden die Sachbearbeiter durch das MDM System über Änderungen informiert und gaben dann die entsprechenden Daten von Hand in das Quellsystem ein. Solch ein Lösungsansatz ist aber selbstverständlich nur in wenigen Ausnahmefällen die beste Lösung – und keinesfalls elegant. Die doppelten Dateneinträge sind ein weiteres Problem. Datenbestände mit Duplikaten unter 4% werden schon als sehr gut bewertet. Ein MDM System ist aber erst wirklich von Nutzen, wenn auch solche Duplikate eliminiert sind. Ein MDM System unterstützt manuelle und automatische Eliminierungsprozesse. Der automatische Prozess vergleicht zwei Entitäten miteinander und generiert ein Scoring (zum Beispiel mittels Bayesian Classifier [10] oder Probabilistic Matching [11]). Anhand dieses Scorings entscheidet man, was mit den beiden Datensätzen geschehen soll. Ist die Wahrscheinlichkeit für ein Duplikat sehr hoch, wird einer der beiden Datensätze automatisch gelöscht. Wenn sie hingegen sehr niedrig ist, werden beide Einträge behalten. Falls sich das MDM System nicht sicher ist, legt es diese Einträge einem Sachbearbeiter zur Kontrolle vor, der manuell entscheidet, ob es sich um ein Duplikat handelt. Die Hersteller liefern auch für diese Aufgabe entsprechende Tools mit. Nach erfolgreicher Einführung einer MDM Lösung steigt die Datenqualität und die Anzahl der doppelten Einträge nimmt stetig ab.

56

Kienzler

5

Welche Geschäftsprozesse verbessert ein MDM System?

Die Geschäftsprozesse lassen sich also mit Hilfe eines MDM Systems in einer SOA Umgebung drastisch vereinfachen und sogar erweitern. Mit Hilfe des MDM Systems sind jetzt Geschäftsprozesse möglich, die nur mit hohem Aufwand oder gar unmöglich waren. Ein realistisches Szenario sieht folgendermassen aus: Ein Kunde ruft im Callcenter eines Unternehmens an. Das MDM System erkennt den Anrufer nun schon anhand seiner Telefonnummer und noch bevor der Mitarbeiter des Callcenters den Hörer abnimmt, werden sämtliche relevanten Daten aus allen Quellsystemen angezeigt. Der Mitarbeiter weiss nun beispielsweise 1) von dem CRM System, dass der Kunde offene Reklamationen hat, 2) von den ProduktSystemen, welche Produkte er schon gekauft hat, 3) vom DWH System, dass er ein „Premium“ Kunde ist und 4) vom Marketing System erhält er die Information, dass man dem Kunden einen Discount auf seine gewünschten Produkte gewähren darf. Ein Eventmanager, eine Komponente des MDM Systems, kann kontinuierlich auf Veränderungen im Datenbestand reagieren und entsprechende Events (synchrone- oder asynchrone Nachrichten) an Umsysteme generieren. Beispielsweise „merkt“ ein MDM System wenn ein Kunde das Pensionsalter erreicht und informiert automatisch das Marketing- und Produktverwaltungssytem.

6

Schlussfolgerung

Master Data Management Systeme sind eine Notwendigkeit bei der Informationsverwaltung. Die Implementierung ist bei vielen Grossunternehmen bereits in der IT-Agenda verankert (Information Agenda [12]). Master Data Management ist kein Produkt, sondern ein Prozess aus dem intelligenten Zusammenspiel mehrerer Software-Komponenten. Dadurch spart man Kosten, gewinnt eine komplette Sicht auf das Unternehmen und kann flexibel auf Kundenbedürfnisse reagieren.

Verwandte Arbeiten x Verbesserte Kundenorientierung durch MDM – Urs Christen, IBM Schweiz AG - (erschienen in KMU Life 06/09) Inhalt: Das Problem der Dateninkonsistenzen und das Fehlen einer einheitlichen Sicht auf den Kunden wird erklärt.

Master Data Management

57

Abgrenzung: Es wird nicht auf die Integration in eine SOA-Architektur eingegangen. Desweiteren ist der Artikel nicht an ein technisches Publikum gerichtet. x The Seven Building Blocks of MDM: A Framework for Success – Gartner Research 27.05.2009 Inhalt: Das Paper beschreibt sieben verschiedene Aspekte von MDM: MDM Vision, MDM Strategy, MDM Metrics, MDM Governance, MDM Organization, MDM Processes, MDM Technology Infrastructure Abgrenzung: In diesem Paper wird nur auf die Aspekte von MDM Vision, MDM Processes und MDM Technology Infrastructure eingegangen. Dafür aber detailierter. x IBM Master Data Management Strategy: Leveraging critical data to accomplish strategic business objectives – IBM White Paper Inhalt: Anhand der Produkte IBM InfoSphere MDM Server und IBM InfoSphere MDM Server for Product Information Management wird erklärt wie moderne Unternehmen die MDM Strategie umsetzen können. Abgrenzung: Das Paper setzt voraus dass die Problematik der Dateninkonsistenzen bekannt ist. Es werden Strategien aufgezeigt wie diese Problematik mit Softwarelösungen von IBM gelöst werden kann.

Literatur [1]

Prof. Dr. Peter Müller: Information Hiding and Visibility in Interface Specifications URL: http://people.inf.ethz.ch/lehnerh/pm/publications/getpdf.php?bibname=Own&id=Leaven sMueller07.pdf [Zugriff am 18.2.2010].

[2]

David Loshin: "GOLDEN COPY" OR UNIFIED VIEW? URL: http://www.datastrategyjournal.com/index.php?option=com_content&task=view&id=61 &Itemid=1[Zugriff am 18.2.2010].

[3]

Wilhelm Hummeltenberg: ETL URL: http://www.oldenbourg.de:8080/wi-enzyklopaedie/lexikon/datenwissen/Business-Intelligence/ETL [Zugriff am 18.2.2010].

[4]

Allen Dreibelbis, Eberhard Hechler, Bill Mathews, Dr. Guenter Sauter (IBM Corporation): Information service patterns, Part 4: Master Data Management architecture patterns - A pattern taxonomy URL: http://www.ibm.com/developerworks/data/library/techarticle/dm-0703sauter/ [Zugriff am 18.2.2010].

58

Kienzler

[5]

IBM Corporation: IBM Red Brick Warehouse 6.3 URL: http://publib.boulder.ibm.com/infocenter/rbhelp/v6r3/index.jsp?topic=/com.ibm.redbric k.doc6.3/wag/wag32.htm [Zugriff am 18.2.2010].

[6]

IBM Corporation: InfoSphere Warehouse for DB2 for z/OS V9.5.2 URL: http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.dwe.c ubeserv.doc/topics/c_cube-starflakeschemas.html [Zugriff am 18.2.2010].

[7]

Philipp Janert: Practical database design, Part 2 URL: http://www.ibm.com/developerworks/web/library/wa-dbdsgn2.html#norm [Zugriff am 18.2.2010].

[8]

Datawarehouse4u: OLTP vs. OLAP URL: http://datawarehouse4u.info/OLTP-vs-OLAP.html [Zugriff am 18.2.2010].

[9]

Data and Process Models for Your Industry URL: http://www-01.ibm.com/software/data/industry-models/ [Zugriff am 18.2.2010].

[10] Eberhard Hechler, Martin Oberhofer, Paul van Run (IBM Corporation): Implementing a Transaction Hub MDM pattern using IBM InfoSphere Master Data Management Server URL: http://www.ibm.com/developerworks/data/library/techarticle/dm0803oberhofer/index.html [Zugriff am 18.2.2010]. [11] Prof. Dr. Peter Bühlmann, Prof. Dr. Martin Mächler: Computational Statistics URL: http://stat.ethz.ch/teaching/lectures/FS_2009/CompStat/sk.pdf [Zugriff 18.2.2010].

am

[12] Scott Schumacher: Probabilistic Versus Deterministic Data Matching: Making an Accurate Decision URL: http://www.information-management.com/specialreports/20070118/10717121.html [Zugriff am 18.2.2010]. [13] IBM Corporation: Information Agenda Catalog – A Directory of key solutions URL: http://www-01.ibm.com/software/data/information-agenda/ [Zugriff 18.2.2010].

am

Teil II: Tutorials

Scala — Neuer Dampf fur ¨ die virtuelle Maschine Lothar Piepmeyer Fakult¨at Informatik Hochschule Furtwangen University Robert-Gerwig-Platz 1 78120 Furtwangen, Germany [email protected]

Zusammenfassung: Mit Hilfe von Multiparadigmensprachen wie Sca-

la k¨onnen Entwickler in der gleichen Sprache verschiedene Programmierstile pflegen. In letzter Zeit etablieren sich zunehmend Sprachen, die objektorientierte, imperative und funktionale Programmierung erlauben. Diese Begriffe werden am Beispiel von Scala erl¨autert. Dabei zeigt sich, dass insbesondere der objektorientierte Aspekt der Sprache von den funktionalen Einfl¨ussen profitiert.

1

Die Welt ist nicht rein

In dem bekannten Datenbank-Lehrbuch [3] von Chris Date findet sich auf Seite 71 die folgende Bemerkung: SQL is extremely important from a commercial point of view but ” it is very far from being the perfect‘ relational language.“ ’ Zwar hat SQL seine Wurzeln in der Theorie der Relationen, jedoch gibt es signifikante Abweichungen vom relationalen Modell. Dem Erfolg der Abfragesprache hat dies kaum geschadet. Eine a¨ hnliche Entwicklung konnte man bei den objektorientierten Sprachen beobachten. W¨ahrend Sprachen, die sich sehr eng am objektorientierten Paradigma ausrichteten, sich in der industriellen Software-Entwicklung zun¨achst kaum durchsetzen konnten, waren (und sind) hybride‘ Sprachen wie C++ ’ oder Java sehr erfolgreich. In beiden Sprachen ist der imperative Programmierstil nach wie vor m¨oglich, außerdem gibt es hier Datentypen wie int oder float, die u¨ berhaupt nichts mit Objekten zu tun haben.

Piepmeyer

62

In den vergangenen Jahren haben sich zunehmend Multiparadigmenspra” chen“ etabliert, die gleichzeitig objektorientierte, imperative und funktionale Programmierung zulassen. Diese Entwicklung steht im Gegensatz zu rein funktionalen Sprachen, die insbesondere einen imperativen Programmierstil ausschließen und — ganz a¨ hnlich wie SQL — ein starkes formal-logisches Fundament haben. Eine dieser Multiparadigmensprachen ist Scala [8]. Im Folgenden wird ein Einblick in diese Sprache gegeben und aufgezeigt, wie der objektorientierte Aspekt einer Sprache durch Hinzunahme funktionaler Eigenschaften verbessert werden kann.

2

Funktionale Programmierung

2.1

Funktionen sind Burger ¨ erster Klasse

Funktionale Programmiersprachen zeichnen sich durch die Gleichbehandlung von Funktionen und allen anderen Daten aus. Das hat etwa zur Folge, dass Funktionen • auch anderen Funktionen als Argument u¨ bergeben werden k¨onnen. • andere Funktionen als Ergebnis haben k¨onnen. Mit Hilfe dieser Funktionen h¨oherer Ordnung“ kann Funktionalit¨at verall” gemeinert werden. Beispielsweise enthalten die Typen des Java-CollectionFrameworks die spezielle Methode contains, die pr¨uft, ob etwa eine Liste ein bestimmtes Objekt enth¨alt. In funktionalen Sprachen gibt es dagegen f¨ur Listen eine Funktion h¨oherer Ordnung, der man ein Pr¨adikat u¨ bergibt und die pr¨uft, ob es mindestens ein Listenelement gibt, das dem Pr¨adikat gen¨ugt. Dar¨uber hinaus erm¨oglichen Funktionen h¨oherer Ordnung wie map, filter und reduce die komfortable Verarbeitung von iterierbaren Datenstrukturen. Die Idee hinter diesen Funktionen ist auch die Basis f¨ur Map-Reduce Verfahren, wie sie in den letzten Jahren zunehmend popul¨ar geworden sind1 . Java unterscheidet Funktionen in Form von Methoden grunds¨atzlich von anderen Daten. Einer Variablen kann man etwa keine Methode zuweisen, sondern muss sich mit einem Umweg u¨ ber das Strategiemuster2 behelfen3 . In Sprachen wie C# oder Python hingegen sind Funktionen mittlerweile ’first class citizens’. Daher werden auch diese Sprachen mittlerweile immer h¨aufiger als funktional bezeichnet. 1

Siehe [5] Siehe [4]. 3 Zur Zeit (M¨arz 2010) scheinen Closures doch Sprachbestandteil von Java 7 werden; somit bekommt auch Java funktionale Eigenschaften. 2

Scala — Neuer Dampf f¨ur die virtuelle Maschine

2.2

63

Eleganter Quellcode

Die Faszination funktionaler Programmierung besteht unter anderem in der Eleganz des Codes. Mit wenig Code kann sehr viel ausgedr¨uckt werden. Einen Eindruck vermittelt der folgende Scala-Code. Die Methode sort implementiert dabei das Quicksort-Verfahren f¨ur Listen in nur einer einzigen Anweisung: Listing 1. Quicksort in Scala def sort(xs: List[Int]): List[Int] = xs match{ case pivot::ys => sort(ys filter (pivot >))::: List(pivot)::: sort( ys filter (pivot Nil }

Dabei ist filter eine Funktion h¨oherer Ordnung, die hier diejenigen Teillisten der Liste ys ermittelt, die alle Elemente enthalten, die kleiner bzw. gr¨oßer als der Pivot sind.

2.3

Keine Nebenwirkungen

Eine weitere Steigerung der Eleganz erf¨ahrt dieser Programmierstil in rein ” funktionalen“ (engl. pure functional) Sprachen. Hier wird auf jede Form von Nebenwirkung (engl. side effect) verzichtet. Insbesondere gibt es keine vera¨ nderbaren Zust¨ande und somit keine Variablen. Auch Listen, wie sie in Listing 1 verwendet werden, sind unver¨anderbar. Immer wenn ein Element hinzugef¨ugt, ge¨andert oder gel¨oscht wird, muss eine neue Liste erzeugt werden. Da Variablen auch in Kontrollstrukturen wie Schleifen eingesetzt werden, ersetzt man Schleifen durch rekursive Funktionen. Da kein Zustand ber¨ucksichtigt werden muss, spielt auch der Ausf¨uhrungszeitpunkt der einzelnen Funktionen keine Rolle mehr. Diese als referentielle Transparenz bezeichnete Eigenschaft vereinfacht die Parallelisierung von Software ganz erheblich. Rein funktionale Sprachen wie etwa Haskell4 haben ihre Wurzeln im LambdaKalk¨ul. Diese formale Stringenz erm¨oglicht grunds¨atzlich auch die formale Verifikation der Software. Operationen mit Nebenwirkungen, wie die Ein- oder Ausgabe, k¨onnen mit Hilfe von kategorientheoretischen Konzepten wie Monaden5 verarbeitet wer4 5

www.haskell.org Siehe [7], Seite 273ff.

Piepmeyer

64

den. Die Umstellung auf rein funktionale Sprachen wird durch diese L¨osungen f¨ur den Entwickler indes erheblich erschwert. Trotz vieler Vorteile waren funktionale Sprachen wie Lisp und insbesondere rein funktionale Sprachen bisher nur sehr vereinzelt in Gebieten wie etwa der k¨unstlichen Intelligenz zu finden. In kommerziellen Anwendungen bediente man sich bis auf Ausnahmen weiterhin imperativer Sprachen wie COBOL, C oder Java6 . Die Reinheit der Sprache und insbesondere der vollst¨andige Verzicht auf Nebenwirkungen findet offenbar wenig Akzeptanz.

2.4

Die Renaissance

Da auf der einen Seite die begrenzte Leistungsf¨ahigkeit der Hardware als eines der Hindernisse f¨ur den Einsatz der funktionalen Programmierung zunehmend an Bedeutung verliert, daf¨ur andererseits die Parallelit¨at von Software wichtiger wird, erlebt zumindest die Idee, die hinter der funktionalen Programmierung steckt, eine Renaissance. So hat Apple beispielsweise erst k¨urzlich unter dem Begriff Grand Central ” Dispatch“ mit dem Betriebssystem Mac OS X 10.6 eine funktionale Erweiterung der Programmiersprache Objective-C mit der erkl¨arten Absicht7 entwickelt, die Programmierung paralleler Software zu vereinfachen. Neben der Erweiterung bestehender Sprachen, gibt es aber auch Neuentwicklungen. Da Software in den letzten Jahren immer h¨aufiger in Java oder einer der .Net-Sprachen entwickelt wird, f¨uhrt f¨ur neue Sprachen kaum ein Weg an einer dieser beiden Plattformen vorbei. So gibt es f¨ur die .Net-Plattform die neue Sprache F# und f¨ur die Java-Plattformen Entwicklungen wie Clojure8 , eine Sprache mit Wurzeln in Lisp, oder Scala, eine Sprache, die sich eher an Java9 orientiert. Da die Compiler nicht nativen Code, sondern Bytecode erzeugen, der dann von einer Laufzeitumgebung ausgef¨uhrt wird, integrieren sich diese Sprachen in die Plattform und k¨onnen etwa bestehende Klassenbibliotheken wieder verwenden. Umgekehrt kann Scala-Code in Java-Projekte integriert werden. Das senkt die Hemmschwelle zum Einsatz von Scala, da nicht ganze Projekte in Scala entwickelt werden m¨ussen, sondern zun¨achst mit einzelne Teilen angefangen werden kann. ¨ Eine Ubersicht u¨ ber die Gr¨unde, aus denen funktionale Sprachen lange Zeit eine untergeordnete Rolle spielten, findet man etwa in [9]. 7 http://images.apple.com/macosx/technology/docs/GrandCentral TB brief 20090903.pdf 8 www.clojure.org 9 Tats¨achlich gab es vor der Version 2 auch Scala-Compiler, die Code f¨ur die .Net-CLR erzeugt haben. 6

Scala — Neuer Dampf f¨ur die virtuelle Maschine

2.5

65

Scala

Da Scala 10 , wie die meisten anderen funktionalen Sprachen nicht rein ist und Nebenwirkungen zul¨asst, f¨allt Java-Entwicklern der Umstieg auf Scala nicht schwer. Wie andere funktionale Sprachen verf¨ugt Scala u¨ ber ein implizites Typsystem. Eine Konstante vom ganzzahligen Typ Int wird in der Form val v = 23

definiert. Der Compiler verwendet ein als Typableitung (engl. type inference) bekanntes Verfahren und ermittelt den Typ von v aus dem Kontext. Der R¨uckgabetyp einer Methode wird ebenfalls von der Typableitung erkannt: def inc(v: Int) = v + 1

Auch diese knappe Form der Methodendefinition steht in der Tradition funktionaler Sprachen. Funktionen werden in Scala sehr a¨ hnlich wie Methoden behandelt, sind aber doch anders. Eine Funktion, die wie die Methode inc eine Zahl um Eins erh¨oht, wird wie folgt definiert: val f = (v: Int) => v + 1

Alternativ zu dieser so genannten anonymen‘ Definition kann auch eine Me’ thode f¨ur die Definition von f benutzt werden: val f = inc _

In Scala sind alle Daten Objekte. Die Anweisung 47 + 11

ist nur eine Abk¨urzung f¨ur (47).+(11)

Wenn Funktionen wie andere Daten behandelt werden, m¨ussen sie also ebenfalls Objekte sein. Der zu f geh¨orende Typ Function2 hat beispielsweise die Methode compose: val g = (v: Int) => v * v val h = f compose g

Das Ergebnis von h(2) ist somit 5. Die Methode compose verarbeitet eine Funktion und ist damit eine Funktion oder, genauer gesagt, eine Methode h¨oherer Ordnung. 10

http://www.scala-lang.org/

Piepmeyer

66

2.6

¨ Nicht alles, was glanzt...

Arbeitet man mit den Lehrbuchbeispielen f¨ur funktionale Sprachen, st¨oßt man schnell an Leistungsgrenzen. Die Implementierung des Quicksort-Verfahrens aus Listing 1 ist zwar sehr kompakt und reflektiert die Struktur des Algorithmus. Alles ist auf das Wesentliche reduziert, das Verfahren wird deklarativ implementiert, Details sind in den Methoden der Scala-Klasse List gekapselt. Versucht man aber die Anweisung sort(List.range(1,10000))

einzusetzen, um die ersten 10.000 nat¨urlichen Zahlen in aufsteigender Reihenfolge zu sortieren, so wird die Bearbeitung mit einer Exception vom Typ java.lang.OutOfMemoryError abgebrochen. Die Rekursion, wie sie ja beim Quicksort-Verfahren typisch ist, belastet nur den Stack und ist somit nicht unmittelbar f¨ur den Abbruch verantwortlich. Da unver¨anderbare Listen genutzt werden, muss bei jeder Listenmanipulation ein neues Listenobjekt erzeugt werden11 . Die Ursachen der begrenzten Leistungsf¨ahigkeit sind also nicht in Scala12 zu suchen, sondern in der Unver¨anderbarkeit, einer grundlegenden Eigenschaft funktionaler Sprachen. Zwar gibt es auch M¨oglichkeiten, die Laufzeit von funktionalem Code zu verbessern, jedoch geschieht dies sehr oft auf Kosten der Eleganz. Auch wenn es sich bei Quicksort nicht um einen Einzelfall handelt, sind die damit einhergehenden Probleme doch nicht ganz allt¨aglich. Funktionale Ausdr¨ucke k¨onnen etwa sehr effektiv in der Listenverarbeitung eingesetzt werden. Insbesondere ergibt sich die Semantik selbst komplexer Operationen aufgrund des deklarativen Programmierstiles einfach aus dem Code. Die folgende Anweisung ermittelt aus dem ersten Gesang der Ilias alle verschiedenen Worte13 mit mindestens drei Buchstaben und sortiert sie in aufsteigender Reihenfolge: val url= "http://www.digbib.org/Homer_8JHvChr/De_Ilias?textonly=1" scala.io.Source.fromURL(new java.net.URL(url)). mkString. split("\\s+"). filter(s=>s.length>2). removeDuplicates. sortWith((s1,s2)=> s1 c.equals(country) && z.equals(zip) case _ => false } }

Die Klasse ZIPCode ist hier wieder als Case-Klasse implementiert, jedoch wird eine eigene Implementierung von equals gew¨ahlt. Da Any in der Hierarchie des Typsystems von Scala die Wurzel ist, hat der Parameter von equals analog zu Java den Typ Any. In den Standardidiomen zur Implementierung von equals, wie man Sie aus Java kennt, wird mit dem instanceofOperator gearbeitet; eine Vorgehensweise, die zwar funktioniert, aber mit objektorientierten Praktiken wenig gemein hat. Beim Pattern Matching wird der Parameter other mit dem Muster ZIPCode(c, z) verglichen. Wenn other vom Typ ZIPCode ist, werden den lokalen Konstanten c und v die Konstruktorparameter code und zip von other zugewiesen. In diesem Fall ergibt sich das Ergebnis von equals aus den Vergleichen mit den beiden Parametern. Beim Pattern Matching in Scala wird der Unterstrich als Platzhalter (engl. wildcard) bezeichnet, der ein beliebiges Muster repr¨asentiert. Er u¨ bernimmt hier die Rolle, die * bei regul¨aren Ausdr¨ucken spielt. Falls also ¨ keine Ubereinstimmung mit dem ersten Muster vorliegt, greift in jedem Fall der Platzhalter als Muster, und das Ergebnis von equals ist false.

5.3

Extraktoren

Auf den ersten Blick steht diese Form des Pattern Matchings im Widerspruch zur Datenkapslung: Die Konstruktorparameter sind nicht notwendigerweise o¨ ffentliche Attribute. Tats¨achlich k¨onnen nur Klassen in der aufgezeigten Weise zum Pattern Matching genutzt werden, die (mindestens) einen Ex” traktor“ haben. Extraktoren liefern zu jedem Objekt einen oder mehrere Werte. Auch wenn es in Case-Klassen bereits einen Standardextraktor gibt, definieren wir f¨ur die Klasse ZIPCode in ihrem Begleiterobjekt mit Hilfe der Methode unapply explizit einen Extraktor: object ZIPCode{ def unapply(zc: ZIPCode) = Some(zc.country, zc.zip) }

Scala — Neuer Dampf f¨ur die virtuelle Maschine

73

Die Ergebnisse des Extraktionsprozesses werden in ein Objekt vom Typ Some eingepackt; auf sie wird beim Pattern Matching wieder zugegriffen. So gesehen sind Extraktoren verallgemeinerte Getter-Methoden. Zwar reflektieren Extraktoren, so wie hier, in den meisten F¨allen Konstruktoren, sie m¨ussen es aber nicht. Beim Pattern Matching in der equals-Methode wird also nicht mit den Parametern des Konstruktors, sondern mit denen Ergebnissen des Extraktionsprozesses gearbeitet.

5.4

¨ Funktionale Programmierung lasst sich in das objektorientierte Paradigma integrieren

Diese Beispiele zeigen auf, wie sich das Pattern Matching in das objektorientierte Paradigma einf¨ugt und diesem keineswegs widerspricht. Funktionale Sprachen haben Idiome entwickelt, die auch von nicht-funktionalen Sprachen adaptiert werden k¨onnen. In Scala liefern Pattern Matching und Extraktoren den Br¨uckenschlag zwischen beiden Paradigmen. Vor diesem Hintergrund erscheint auch die so genannte 10th Rule of Programming‘ 19 plausibel: ’ Any sufficiently complicated C or Fortran program contains an ” ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.“ Die Liste der Sprachen erhebt dabei sicher keinen Anspruch auf Vollst¨andigkeit.

Literatur [1] J. Backus. Can Programming be Liberated from the von Neumann Style? Communications of the ACM, 21(8):613–641, 1978. [2] J. Bloch. Effective Java. Prentice Hall, 2008. [3] C. J. Date. An Introduction to Database Systems. Addison-Wesley, 1995. [4] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley, 2009. [5] J. Dean, S. Ghemawat. MapReduce: simplified data processing on large clusters. Commun. ACM, 51(1):107–113, 2008. [6] B. Meyer. Object-Oriented Software Construction. Prentice Hall, 2000. [7] P. Pepper. Funktionale Programmierung in OPAL, ML, HASKELL und GOFER. Springer-Verlag, 2002. [8] L. Piepmeyer. Grundkurs Funktionale Programmierung mit Scala. HanserFachbuchverlag, 2010 (erscheint). [9] P. Wadler. Why no one uses functional languages. SIGPLAN Not., 33(8):23–27, 1998.

19

http://philip.greenspun.com/research/

Was Sie schon immer über ArchitekturEvaluierung wissen wollten, aber bisher nicht zu fragen wagten… Dr. Uwe Werner iocon GbR Wickenweg 36 60433 Frankfurt [email protected]

Zusammenfassung: Der Beitrag gibt 10 ehrliche Anworten auf 10 schwierige Fragen zur Evaluierung der Architektur unter besonderer Berücksichtigung der Architektur von Software und Software-Systemen.

1

Übersicht

Die nachfolgenden Fragen und Antworten fassen die Erfahrungen des Autors mit den vielfältigen Hindernisse und Schwierigkeiten bei der praktischen Durchführung von Architektur-Evaluierung von Software und Systemen zusammen. Gleichzeitig geben sie Hinweise, wie die Bewertung von Architektur pragmatisch angegangen und nutzbringend durchgeführt werden kann. In der Folge wird vereinfacht „Erzeugnis“ geschrieben, wenn eine Software, ein Software-Teil, ein Framework, eine Plattform, eine Produktlinie oder ganz allgemein ein beliebig geartetes System gemeint ist. Entsprechend dem Namensgeber [1] dieser Fragen und Antworten empfiehlt sich die Lektüre mit etwas Sinn für Humor und Satire!

Fragen und Antworten (in a nutshell)

2 I.

Architektur-Evaluierung – ist das denn zu etwas gut?

Ja

II.

Ich entwickle funktionsorientiert! Muss ich auf „Qualitäten“ achten?

Ja

III.

Ich entwickle modellbasiert. Das Modell ist doch die Architektur, oder?

Nein!

Werner

76

IV.

Ich kann keine Architektur bewerten, ich habe nämlich keine erstellt!

Doch!

V.

Unsere Architektur-Artefakte sind völlig anders. Kann man die bewerten?

Ja

VI.

Nur harte Architektur-Kennzahlen sind sinnvoll! Wie geht das?

Gar nicht!

VII.

„ATAM = Overkill“?

Es kommt darauf an…

VIII.

Warum Architektur-Evaluierung? CMMI und SPICE werden es doch richten, oder?

Nein!

IX.

Wie geht der Faktor Mensch ein?

Vielfältig.

X.

Ja, wann funktioniert Architektur-Evaluierung denn nun?

Es kommt darauf an…

Tabelle 1: Fragen und Antworten.

2 (I)

Fragen und ausführliche Antworten Architektur-Evaluierung – ist das denn zu etwas gut?

Die Anforderungen an ein zu erstellendes Erzeugnis beschreiben, was es leisten soll und wie gut es diese Leistungen erbringt. Bei der Erhebung der Anforderungen handelt es um eine Standortbestimmung im Problemraum1. Anschließend entsteht ein erster, grober Lösungsentwurf, der sowohl grundsätzliche Lösungsstrukturen wie auch prinzipielle Entscheidungen umfasst. Das ist die Architektur, die das Erzeugnis besitzen soll. Die Bedeutung von Architektur für ein erfolgreiches Entwickeln des Erzeugnisses ist sowohl unter den Theoretikern des Software Engineering als auch den meisten Praktikern aus der Softwareindustrie unbestritten. Die Architektur ist für den nachfolgenden Entwicklungsprozess wegweisend in Richtung einer möglichen Lösung. Die erste Frage ist somit: Stimmt die

1

Geforderte Randbedingungen (constraints) können sowohl die Erstellung als auch Eigenschaften der Lösung betreffen. Im zweiten Fall wird der Lösungsraum eingeschränkt.

Was Sie schon immer über Architektur-Evaluierung wissen wollten…

77

durch die Architektur vorgegebene Richtung? Oder führt der Weg zu einem Erzeugnis, das von den Anforderungen abweichen wird? Ist der Weg auf planbare Weise im möglicherweise vorgegeben Zeit- und Kostenrahmen begehbar oder drohen Schwierigkeiten und gar mit Kosten verbundene Verzögerungen? Wenn das Ziel erreicht ist, dann bestimmt die Architektur maßgeblich über die Eigenschaften der Wartung des Erzeugnisses (z.B. Fehlerbehebung, Weiterentwicklung, Variantenbildung). Der in der Wartung anfallende Aufwand übertrifft den der Erstellung oft um ein Vielfaches. Die zweite Frage lautet also: Trägt die Architektur über die erste Etappe hinaus? Die Bewertung der Architektur liefert Antworten auf beide Fragen. Ganz ähnliche Fragestellungen ergeben sich, wenn die Eignung eines bereits existierenden bzw. zu verwendenden Erzeugnisses (off-the-shelf oder legacy bzw. beauftragt) als Bestandteil in einem zu erstellenden größeren Erzeugnis geprüft werden soll2. Auch in diesen Fällen liefert die Bewertung der Architektur Antworten auf beide Fragestellungen. Die Antwort auf die Ausgangsfrage ist also entschiedenes „Ja“. (II)

Ich entwickle funktionsorientiert! Muss ich auf „Qualitäten“ achten?

Selbstverständlich muss das Erzeugnis die vereinbarten funktionalen Leistungsmerkmale aufweisen. Geplante Funktionalität kann als Leitfaden für die Strukturierung des Erzeugnisses in kleinere Einheiten (z. B. Subsysteme oder Module) dienen. Dogmatisch rein funktional-getriebene Entwicklung vernachlässigt aber i.d.R. querschnittliche und nicht-funktionale Anforderungen an das Erzeugnis und die Entwicklung. Anforderungen dieser Art werden auch als qualitative Anforderungen bezeichnet. Oft von Anforderungen adressierte Qualitäten sind beispielsweise „Verfügbarkeit“ (availability) des Erzeugnisses und „Wartbarkeit“ (maintainability), die weniger den ausführbaren Code selbst, sondern Änderungsfreundlichkeit der unterschiedlichen Darstellungen (Architektur, Design und Source Code) betrifft. Eine Übersicht über Qualitäten liefert z.B. [2]. Qualitative Anforderungen sind schwierig zu präzisieren und auch aufwändig in der Erhebung. Qualitäten konkurrieren miteinander (z.B. der

2

Bei der Bewertung, ob Design und Implementierung konform zur Architektur-Vorgabe erfolgt sind, handelt es sich nicht um Architektur-Evaluierung.

Werner

78

Klassiker memory consumption vs. performance) und müssen dann gegeneinander abgewogen werden. Qualitäten beeinflussen stark den Aufbau des Erzeugnisses und damit die Architektur. Nach einer funktionalen Zerlegung in Blöcke gibt es keinen weiteren Block, der die Eigenschaft safety realisiert. Vielmehr muss ein Safety-Konzept erarbeitet werden. Die Umsetzung des Konzeptes kann durchaus ein gänzlich neues Gefüge von Blöcken nach sich ziehen. Bei isolierter Betrachtung einer anderen Qualität entsteht u.U. ein neues Gefüge. Der Architekt muss mit Augenmaß sowohl Funktionalität als auch die Qualitäten zur Strukturierung des Erzeugnisses verwenden. Die Antwort auf die Frage lautet daher „Ja“. (III)

Ich entwickle modellbasiert. Architektur, oder?

Das

Modell

ist

doch

die

Die vom Entwickler bevorzugte Ausdrucksform wird als source code bezeichnet [3]. In dieser Hinsicht steht das Modell auf einer Ebene mit einer Text-Datei, die C-Code enthält3. Modelle beinhalten oft domänennahe oder problemnahe Abstraktionen als Ausdrucksformen, die einfachere Lösungsstrukturen ermöglichen. Zusammen mit ausgefeilter Unterstützung durch Werkzeuge können im Einzelfall kleinere Probleme ohne explizite Entwurfsarbeit angegangen werden4. In diesem Fall ist die Architektur trivial. Ab einer bestimmten Größe bzw. Komplexität wird auch bei modellbasierter Entwicklung eine eigenständige Architektur vorteilhaft bzw. erforderlich5. Hier lautet die Antwort auf die Frage „NEIN!“. (IV)

Ich kann keine Architektur bewerten, ich habe nämlich keine erstellt!

Jedes Erzeugnis besitzt seine Architektur. Mit der Erstellung des Erzeugnisses wird auch eine Architektur erstellt. Ein Mechanismus der impliziten Architektur-Erstellung wird beschrieben durch Conway‘s Gesetz, nach dem sich die Strukturen von Organisation und Erzeugnis ähneln (siehe [4]). 3

Nach Modell bzw. C-Code folgen oft nur noch (Semi-) Automatismen zum eigentlichen executable.

4

Grundsätzlich ist sich das Software Engineering darüber einig, dass es sich bei diesem „model & fix“ um kein angemessenes Vorgehen handelt.

5

Beispielsweise fallen heutige embedded systems nahezu ausnahmslos in diese Kategorie der nicht-trivialen Erzeugnisse.

Was Sie schon immer über Architektur-Evaluierung wissen wollten…

79

Wenn Architektur nicht explizit erstellt wird, dann ist sie unbekannt und mit großer Wahrscheinlichkeit ungeeignet. Das Erkennen und Dokumentieren der Architektur eines existierenden Erzeugnisses stellt dann eine notwendige Voraussetzung für ihre Bewertung dar. Die Antwort auf die Frage lautet somit „Doch!“. (V)

Unsere Architektur-Artefakte sind völlig anders. Kann man die bewerten?

Architektur eines Erzeugnisses wird durch Sichten (views) beschrieben, die von Standpunkten (viewpoints) aus erhalten werden (zur Nomenklatur siehe [5]). Egal welche Sichten von welchen Standpunkten auch festgehalten werden – externe Gutachter können sich einarbeiten. Gegebenenfalls ist dies etwas bei unkonventionellen Sichten aufwändiger. Interne stakeholder sollten mit dem Erscheinungsbild der Artefakte vertraut sein. Als Produzenten erstellen sie die Artefakte, als Konsumenten müssen sie diese verstehen. Diese Frage wird daher mit „Ja“ beantwortet. (VI)

Nur harte Architektur-Kennzahlen sind sinnvoll! Wie geht das?

Eine extreme Aussage ist „To measure is to know“. Ein anderes Extrem sagt „Wer viel misst, misst viel Mist!“6. Für Architektur existieren keine allgemein akzeptierten, harten Kennzahlen. Das ist anders für konkretes Design (z.B. für Objekte oder Module) und Implementierung (z.B. Source Code in C oder Java). Es gibt keinen Konsens darüber, wie eine Gütezahl für eine Architektur entweder direkt erhoben oder aus anderen Kennzahlen abgeleitet werden kann. Es ist zweifelhaft, dass ein „Nutzen“ von Architektur nach einer allgemein akzeptierten Vorschrift ermittelt und quantifiziert werden kann7. Statt quantitativer sind aber qualitative Aussagen möglich.

6

Die erste Aussage wird William Thomson, dem 1. Baron Kelvin (1824-1907) zugesprochen, die zweite dem Managementberater Reinhard K. Sprenger. Über dysfunktionales Erheben von Metriken soll aber an anderer Stelle berichtet werden.

7

Auch über den Glauben an Die Zahl durch Manager, die damit verbundene Gralssuche sowie die daraus resultierende Dysfunktion in Organisationen soll an anderer Stelle mehr geschrieben werden.

Werner

80

Eine erste Möglichkeit besteht darin, sich auf Kenntnis und Erfahrung von Experten zu verlassen und eine Aussage (d.h. eine Meinung) einzuholen. Dabei sind Experten erforderlich, deren Expertentum sich gleichzeitig auf das Feld der Architektur, das in Frage stehende Fachgebiet und die das Erzeugnis erstellende Organisation erstreckt. Eine andere Möglichkeit besteht darin, wichtige Anforderungen systematisch gegen die Architektur zu spiegeln und damit Risiken und potenzielle Schwierigkeiten zu identifizieren. Dies kann mit (semi-) formalen Ansätzen, die auf Szenarios basieren, erreicht werden. Hier sind zumindest Architekturexperten für die Bewertung erforderlich. Wenn Fachexperten hinzugerufen und die Organisation eingebunden wird, dann kann auf dieses Wissen auf Seiten der Gutachter eher verzichtet werden8. Eine weitere Möglichkeit besteht darin, in einer „Tiefenbohrung“ eine Entscheidung zu Technologie oder lokaler Struktur bis zur Implementierung durchzuführen. So wird eine Aussage über die Tragfähigkeit dieser Entscheidung erlangt. Die Form der Bewertungsergebnisse ist dabei vielfältig. In jedem Fall ist ein den Bedürfnissen der stakeholder angemessener Bericht Teil der Ergebnisse9. Die Antwort auf die Ausgangsfrage lautet also „Gar nicht!“. (VII)

„ATAM = Overkill“?

Das ATAM [6] ist eine vom Software Engineering Institute (SEI) ausgearbeitete und geschützte Methode. ATAMs wurden und werden zahlreich und erfolgreich durchgeführt. ATAMs adressieren übergreifende Geschäftsziele und beziehen dementsprechend oft einen großen Kreis der stakeholder ein. Dies wird zusammen mit dem beim ATAM vorgeschriebenen Vorgehen besonders dann als zu aufwändig empfunden, wenn das Erzeugnis weniger verwickelt, die Organisationen kleiner und/oder das vorhandene ArchitekturBewusstsein nicht voll ausgeprägt ist. Dann kann ein pragmatisch ausgerichtetes, flexibel angepasstes Verfahren (z.B. square-m [7]) zum Einsatz kommen. Die Antwort lautet somit „Es kommt darauf an…“.

8 9

Architektur-Gutachter müssen dann in erheblichem Maße soft-skills besitzen.

Architektur-Gutachter können natürlich die unterschiedlichen quantitativen Ergebnisse nach fragwürdigen Kriterien in eine managementgerechte Zahl oder in eine grob vereinfachende Ampel-Farbe übersetzen.

Was Sie schon immer über Architektur-Evaluierung wissen wollten…

81

(VIII) Warum Architektur-Evaluierung? CMMI und SPICE werden es doch richten, oder? Gute Prozesse sind wichtig, denn sie steigern die Effizienz. Dinge werden dann auf die richtige (oder zumindest auf eine bessere) Art und Weise gemacht. Gute Prozesse tragen zur Planbarkeit und verlässlichen Durchführung von Vorhaben bei. Gute Prozesse können auch die Effektivität erhöhen: Dann werden mit größerer Wahrscheinlichkeit die richtigen Dinge gemacht10. Leider führen auch noch so gute Prozesse nicht zwangsläufig dazu, dass ein erzieltes Ergebnis den Erwartungen entspricht11. Auch wenn ein Prozess Aktivitäten zur Architektur und/oder Architektur als Ergebnis vorschreibt, ist keinesfalls ausgeschlossen, dass „Architektur machen“ frei von Sachverstand erfolgt und/oder eine Architektur als Potemkinsches Dorf [8] erstellt wird, um formal einer Prozessanforderung zu genügen. Die Antwort ist ein entschiedenes „Nein!“. (IX)

Wie geht der Faktor Mensch ein?

Architektur wird von Architekten für andere stakeholder erstellt. Alle Beteiligten sind Menschen und treten als Individuen, im Team und im Rahmen einer Organisation auf. Die explizite Bewertung der Architektur erfolgt durch externe12 Gutachter. Eine aussagekräftige Bewertung durch Gutachter kann nur zusammen mit den Architekten und den anderen involvierten stakeholders erfolgen, nicht gegen sie. Der Gutachter ist auf Unterstützung angewiesen, die ein Vertrauensverhältnis und Akzeptanz erfordert. Dieses Vertrauensverhältnis muss aufgebaut und Akzeptanz erarbeitet werden. Dazu muss sich der Gutachter in die Rolle der stakeholder einfühlen, durch das Stellen von Fragen und Hören von aufrichtigen Antworten ihr Verständnis der Dinge, ihr Gefüge von Prioritäten und ihre Sicht der Architektur erlangen. Um Missverständnisse zu erkennen

10 Schlechte Prozesse bewirken natürlich das Gegenteil. Über die Wahrnehmung von gut gemeinten Prozessen, ob mehr Prozess auch besser ist und wie Prozesse und ihre (vermeintliche) Einhaltung gemessen werden, soll an anderer Stelle berichtet werden. 11 12

Ein Prozess sollte feststellen, ob das erzielte Ergebnis den Erwartungen entspricht.

Relativ zum einzelnen Architekten ist jeder andere Mensch extern. Extern können Mitarbeiter einer anderen Abteilung des selben Unternehmens sein oder auch firmen-externe Gutachter.

Werner

82

und zu beheben, muss der Gutachter den stakeholders spiegeln, was er verstanden hat. Immer muss allen Beteiligten klar sein, dass ausschließlich die Architektur, und keinesfalls der Architekt Gegenstand der Bewertung ist13. Architektur-Evaluierung sollte immer auch das Gute einer Architektur hervorheben und zuerst nennen – „Den Göttern Weihrauch, den Menschen Lob!“14. Hier lautet die Antwort ganz klar „Vielfältig“. (X)

Ja, wann funktioniert Architektur-Evaluierung denn nun?

Hier gibt es keine einfache oder endgültige Antwort. Es gibt aber einige show stopper, die eine erfolgreiche ArchitekturBewertung unmöglich machen: x Den Entscheidern fehlt grundsätzliches Architektur-Bewusstsein x Architekten und Entwickler verstehen den Nutzen von ArchitekturEvaluierung nicht x Menschliche Vorbehalte (Faktor Mensch, s.o.) x Der Glaube an die Zahl (Architektur-Kennzahlen, s.o.) Andere Aspekte erschweren die Akzeptanz von Architektur-Bewertung: x Unkenntnis und falsche Vorstellungen seitens der stakeholder x Das Fehlen einer einheitlichen „Sichtenreferenz“, wie sie in anderen Domänen15 etabliert ist x Die oft stark unterschiedliche Ausprägung Dokumentation für eine bestimmte Sicht

der

Architektur-

x Die oft unklare Kausalität „Schlechte Architektur Æ Problem“16

13

Da der Architekt durch Vorgesetzte auch anhand seiner Arbeitsergebnisse – d.h. der Architektur –bewertet wird, können die beiden Gesichtspunkte nicht wirklich getrennt werden. Das erklärt die in der Praxis verbreitete „Angst des Architekten vor der Architekturbewertung“ und die damit verbundene Hürde für Gutachter. 14

Nach Pythagoras. Anders ausgedrückt: Der Mensch will gelobt werden.

15

Z.B. im Bauwesen.

16

Problembehebung on-the-fly während des Designs und der Implementierung führt zu einer anderen Architektur als geplant. Allzu oft wird die lokal initiierte Änderung der Architektur weder auf globale Nebenwirkungen hinterfragt, noch wird sie dokumentiert.

Was Sie schon immer über Architektur-Evaluierung wissen wollten…

83

Eine durch wichtige stakeholder (z.B. Kunden oder Investoren) geforderte Bewertung öffnet die Tür einen Spalt weit. Der Architektur-Gutachter kann sie dann vielleicht langsam und vorsichtig und immer unter Berücksichtigung des Faktors Mensch (s.o.) letzten Endes auch ganz öffnen, indem er Notwendigkeit und Nutzen von Architektur-Bewertung aufzeigt. Die stakeholder akzeptieren die Resultate einer Architektur-Bewertung eher, wenn ihnen wichtige Randgebiete der Architektur behutsam mit in die Bewertung eingeschlossen werden. So sind beispielsweise aus Sicht der Entwickler die „üblichen Verdächtigen“ schnell aufgezählt: die Prozesse („zu hinderlich“), die Tools („an die Kette gelegt“) und das Management. Grundsätzlich müssen vor der Durchführung der Gegenstand, die Randbedingungen und die Form der Ergebnisse einer Architektur-Bewertung mit dem Auftraggeber vereinbart werden. Immer machen konstruktive, realistische Vorschläge, um Risiken zu mildern oder Probleme zu lösen, eine ablehnende Haltung unwahrscheinlicher. Sie bedeuten aber u.U. erheblichen Mehraufwand zur Erstellung der ArchitekturBewertung. Eine letzte Option besteht im Durchführen einer Architektur-Bewertung als Nebenprodukt anderer Tätigkeiten, z.B. von Verbesserungsprojekten oder im Rahmen einer Prozessbewertung. Größere Organisationen können sich eigene Architektur-Gutachter leisten. Das kann von Vorteil sein, da diese Mitarbeiter in interne Netzwerke eingebunden sind und die Firmenkultur kennen. Allerdings kann die Wahrnehmung der Gutachter durch die Architekten die einer institutionalisierten Architektur-Polizei17 sein – dann entpuppt sich der vermeintliche Vorteil als K.O.-Kriterium. Die kurze Form der Antwort lautet also „Das kommt darauf an…“.

3

Zusammenfassung

Die Antworten zeigen deutlich, dass Architektur-Evaluierung oft nützlich sein kann, aber selten einfach durchführbar ist. Sie geben Hinweise, wie der Nutzen einer Bewertung gegenüber den decision-makers motiviert werden kann. Wenn Architektur bereits akzeptiert ist, dann ist der nächste Schritt zur Akzeptanz der Architektur-Bewertung nicht schwer. 17

Diese Tatsache wirkt sich u.U. negativ auf die Gutachter aus.

Werner

84

Last but not least geben Sie dem Gutachter Hilfestellung zur Durchführung einer Bewertung und helfen ihm, unverzeihliche Fehler zu vermeiden, die eine Architektur-Bewertung scheitern lassen.

Literatur [1] http://de.wikipedia.org/wiki/Was_Sie_schon_immer_über_Sex_wissen_wollten,_ aber_bisher_nicht_zu_fragen_wagten [Zugriff am 10.1.2010] [2]

ISO/IEC 9126-1: „Software engineering – Product quality – Part 1: Quality model“, 2001

[3]

M. E. Conway: How do Committees Invent? – In Datamation 14 (1968)

[4]

http://www.gnu.org/copyleft/gpl.html [Zugriff am 10.1.2010]

[5]

ISO/IEC 42010: „Systems and software engineering – Recommended practice for architectural description of software-intensive systems“, 2007

[6]

http://www.sei.cmu.edu/library/abstracts/reports/00tr004.cfm [Zugriff am 10.1.2010]

[7]

http://iocon.de/index.php?c=square-m [Zugriff am 10.1.2010]

[8]

http://de.wikipedia.org/wiki/Potemkinsches_Dorf [Zugriff am 10.1.2010]

Teil III: Industriepräsentationen

Developing Secure Web Applications with OWASP Resources Martin Knobloch Chair, Global Education Committee Project Lead, OWASP Education Project and Capture The Flag Project OWASP.org [email protected]

Abstract: The Open Web Application Security Project (OWASP)1 is an world wide open source community, containing a lot of tool and documentation projects in the area of secure software development. During this presentation, OWASP.org and the following projects are introduced and their role in a secure development lifecycle is explained: OWASP Top Ten, OWASP SAMM, OWASP CLAS, OWASP ASVS, OWASP Development Guide, OWASP Code Review Guide, and OWASP Testing Guide. 1

http://www.owasp.org

Linux in Automotive Infotainment Systems Rainer Oder, Juergen Woelfle, Oliver Hartfuss, Karl Buehler, Markus Zinser XS Embedded GmbH Roggenbachstr. 6 D-78050 Villingen-Schwenningen http://www.xs-embedded.de [email protected]

Abstract: Making its way from servers over personal computers into the embedded industry, Linux is becoming a real alternative as operating system in the demanding fields of automotive infotainment systems. This article reflects the changes of Linux in this industry, while pointing out the challenges, that automotive suppliers face using Linux as their embedded operating system.

1

Introduction

Considering the catchwords coming with a discussion about Linux, this operating system clearly makes its points even in a demanding environment such as the automotive infotainment business. However, Linux is already far more than just a thought in the automotive field. As an example, the GENIVI Alliance focusing on the development of an In-Vehicle Infotainment (IVI) reference platform on a Linux core with founding members such as the BMW Group or Intel is demonstrating serious business based on Linux. Linux in the automotive industry offers new opportunities for suppliers. However, the new outlooks come with brand new challenges. Using an open source operating system licensed under GNU’s General Public License (GPL) implies not only legal issues. To fulfill the requirements of the automotive industry, new technical solutions need to be delivered, which pay attention to the new legal preconditions. To understand the challenges of Linux in the automotive industry, we will highlight several aspects of issues, which arise from the daily work of high skilled embedded engineers shortly after the first demonstrators have to be transformed into real commercial products.

Oder, Woelfle, Hartfuss, Buehler, Zinser

90

2

Fast Boot

Linux is no micro kernel. This means that drivers are most likely part of the kernel itself and need to be loaded with the kernel during startup. This fact alone is not a problem and a discussion about micro kernels versus nonemicro kernels is far out of the scope of this article. While loading some drivers into memory on personal computers or servers is not a huge problem considering memory bandwidth of these machines and the associated requirements for boot time of the related industries, the automotive industry takes startup as a major demand. Using Linux, engineers need to find a way to avoid delaying components during startup, while using the CPU at maximum capacity to fulfill startup requirements such as early audio and early video.

3

X Server

The X Server is widely accepted as the component to handle window management and rendering functions in Linux systems. The X Server offers interfaces for applications with the need for visual output and nothing seems easier than using X within the automotive Linux approach. After first evaluations and the comparison to hard startup requirements of this industry, X is questioned to be the solution of choice. The advantages in the personal computer world with its rich feature portfolio and various ways of customization could actually be the drawback in an industry, where speed and memory footprint is still a huge matter. But the question of whether the industry needs its own optimized window management system is still not answered. In contrast, when automotive vendors come to the conclusion, that the system’s window management component helps to distinguish their products on the market, a possible automotive solution gains interest. The keywords are open standards like OpenGL ES and maximum hardware acceleration to reduce CPU load and power consumption.

4

Decoding and Decryption

Media content management and playback are topics of specific interest in an automotive infotainment system. Although most media formats can be played on Linux out of the box, some protected formats need additional codecs. So far, the majority of formats have been made available on Linux. Freely available decoders are usually not suitable for an automotive infotainment system in terms of quality or the level of legal risks involved.

Linux in Automotive Infotainment Systems

91

In addition, the integration of new formats like Blu-Ray and popular devices like iPod is still an issue technically and with respect to legal questions. Seamless integration of popular devices and support for new high definition formats are essential milestones in establishing Linux as a basis for full featured automotive infotainment systems.

5

Audio Management

In automotive systems there is a central instance for providing audio streams to the user using different output devices (e.g. loud speakers or head phones). This instance is called the audio management. The audio management can be divided into two main parts. One part is designed to handle routing, ramping, handling prompts and phone calls and storing of source related audio settings. The second part of audio management is the real processing of the audio streams and post processing of the audio signal related to the different sinks. Within a Linux environment there is currently no software available to fulfill all automotive requirements related to the two parts of audio management. Implementations like PulseAudio (http://pulseaudio.org) are targeting some of the features needed. But they are not solving all of the issues. For implementing an automotive audio management fulfilling all requirements there is a tradeoff between keeping standard audio interfaces (e.g. ALSA) and the system resources spend for audio processing. Besides the technical problems one will face legal issues because some of the processing algorithms are protected IP owned by companies not willing to share their deepest knowledge in details.

6

Automotive Interfaces

Compared to the usual usage in PCs and Consumer Electronics, special protocols and buses such as CAN, Flexray, LIN or MOST extend the set of available network interfaces in an automotive environment. While some of these protocols are already supported in standard Linux or easy to implement on a standard kernel, others require special hardware features to operate correctly. To be able to meet the challenging startup, latency and security requirements of these networks, partitioning of hardware and Linux based software features is an important task in early system design.

Oder, Woelfle, Hartfuss, Buehler, Zinser

92

7

Development Process

The legal issues have to be addressed during the development cycle. A process needs to be establish to avoid future legal proceedings to the developing company. The process needs to ensure, that components are evaluated before integration into the product to avoid forcing the company's intellectual property to be open sourced based on GPL rights.

8

Conclusion

Linux offers great commercial and technical chances, even in the automotive infotainment industry. However, the technical issues go hand in hand with brand new legal issues.

Orchideo – Ein schmerzfreier Ansatz für Modellgetriebene Softwareentwicklung Ralf Grossklaus eXXcellent solutions GmbH Beim Alten Fritz 2 89075 Ulm [email protected]

Zusammenfassung: Modellgetriebene Softwareentwicklung (MDSD) war eines der Hypethemen des letzten Jahrzehntes. Doch wie so oft folgte dem Hype die Ernüchterung. Auch wenn MDSD die anfänglichen Erwartungen nicht ganz erfüllen konnte, bleiben die Vorteile von Modellen. Sie bieten eine abstraktere Sicht auf die Software und sind unabhängig von Technologie und Programmiersprache. Doch wer schon einmal das Vergnügen hatte MDSD in einem Projekt anzuwenden, der wird schnell gemerkt haben, dass es in diesem Bereich noch einiges an Verbesserungspotential gibt. Die Entwicklungswerkzeuge nehmen hier eine zentrale Rolle ein. Denn die Wahl der Tools hat erhebliche Auswirkungen auf den Entwicklungsprozess. Oft wird ein UMLWerkzeug für die Modellierung verwendet. Das Ergebnis wird dann in XMI exportiert, aus welchem ein Generator den Programmcode erzeugt. Ein solches Vorgehen ist umständlich und fehleranfällig. Zudem lässt sich, unabhängig davon wie effektiv der Prozess tatsächlich ist, bei den Entwicklern eine Gefühl der Unproduktivität beobachten. Auch in Projekten der eXXcellent solutions GmbH spielt Modellgetriebene Softwareentwicklung eine wichtige Rolle. Um die Arbeit mit Modellen so angenehm wie möglich zu gestalten, und somit die Motivation und Produktivität der Entwickler auf einem hohen Maße zu halten, hat eXXcellent Orchideo, ein aspekt-basiertes MDSD Framework, entwickelt. Das Framework besteht aus den folgenden fünf Komponenten, von denen aufgrund den zeitlichen Vorgaben allerdings nur die ersten beiden vorgestellt werden können: orchideo|engine, orchideo|objects, orchideo|views, orchideo|documents, orchideo|ui-designer. Die Grundidee von orchideo|engine ist, dass sich alle Funktionen einer Anwendung als Aspekte definieren lassen. Da in vielen Projekten immer wieder die gleichen Funktionen gebraucht werden, sind im Paket orchideo|objects die wichtigsten Aspekte vordefiniert. Der dazugehörige auf GMF aufbauende Diagrameditor ist vollständig in die Eclipse integriert, so dass beim Wechsel zwischen Modellen und Programmcode kein Toolwechsel erfolgen muss. Die aktuelle Version 1.7 ist derzeit bei drei Projekten im Einsatz. Eine Testversion kann kostenlos unter http://www.exxcellent.de/ heruntergeladen werden.

Modellbasierte Implementierung einer Ontologie-Zugriffsschicht Thomas Wehner, Michael Jungmann, Markus Pilzecker Pharma Research Scientific Informatics ("PRI") F. Hoffmann-La Roche AG Grenzacher Strasse 124 CH-4070 Basel [email protected], [email protected], [email protected],

Dr. Wehner, Jungmann & Partner ("WJP") IT-Consultants Wiesentalstr. 50 79115 Freiburg

Zusammenfassung: Wir berichten über die modellbasierte Implementierung einer Zugriffsschicht auf einen Ontologie-Server, in dem für die Pharmaforschung relevante Terminologien abgelegt sind. Neben dem fachlichen Hintergrund des Projektes im Bereich Wissensrepräsentation gehen wir insbesondere auf Elemente des Software-Entwicklungsprozesses wie Requirements Engineering, Werkzeugintegration, Build-Management und Kollaborationsplattformen sowie technische Aspekte wie Metamodellierung, Code-Generierung und Architekturen für Repository-Zugriffskomponenten ein.

1 Ausgangssituation Beim Pharma-Unternehmen F. Hoffmann-La Roche werden große Mengen pharmakologisch relevanter Begriffe in Form von Terminologien verarbeitet. Diese Terminologien werden derzeit noch durch eine Reihe heterogener Ansätze verwaltet. Unter der Ägide der Abteilung "PRI" sollen diese Daten auf einer einheitlichen Ontologie-Plattform unternehmensweit zur Verfügung gestellt werden.

2 Ziele x Ermöglichung des einfachen und einheitlichen, unternehmensweiten Zugriffs auf Vokabulardaten durch Fachapplikationen x Trennung der abstrakten Zugriffsschicht von der Implementierung gegen einen konkreten Ontologie-Server und dessen API-Konventionen mit der Möglichkeit, diesen eventuell gegen ein anderes Produkt auszutauschen

96

Wehner, Jungmann, Pilzecker

x Unkomplizierte Erweiterung oder Modifizierung der API, daher modellbasierte Entwicklung x Verwendung standardisierter und Open Source Komponenten bei der Implementierung

3 Beteiligte Rollen x Roche, Auftraggeber: Definition der Anforderungen, Formulierung des Modells für die API, Bereitstellung von Anwendungsbeispielen, Abnahme x WJP, Projektumsetzung: Definition Architektur, Unterstützung Requirements Engineering/Management, Methodik im verteilten Entwicklungsprozess, Unterstützung Kollaboration, Implementierung x Ontoprise, Werkzeughersteller: Support Ontologie-Server, Benutzung Tool-API

4 Vorgehen Roche, WJP und Ontoprise erarbeiteten gemeinsam ein Metamodell, welches die abstrakte Syntax für den Ontologie-Zugriff repräsentiert und aus dem die Schnittstellen für den Ontologie-Zugriff generiert wurden. Die konkrete Abbildung auf die API des Ontologie-Repositories OntoBroker wurde zusammen mit dem Hersteller erarbeitet und entsprechend umgesetzt. Die Implementierung der Abbildung wurde durch Umleitung der Lese-/ Schreibezugriffe auf die native API von OntoBroker realisiert. Eingesetzte Elemente des Software-Entwicklungsprozesses waren u.A. UML (MagicDraw), EMF (Eclipse), Test-Driven Development (JUnit), Continuous Integration (Hudson), und eine Kollaborationsplattform (Trac).

5 Ergebnisse und Erfahrungen Die Integrationskomponente wurde im September 2009 fertiggestellt. In einem anschließenden Pilotprojekt wurden Vokabulare verschiedener Quellen via die abstrakte API als Ontologien zentral verfügbar gemacht. Auf diesen Bestand können Klienten im Unternehmen über alle Schnittstellen Ontobrokers einschließlich der geschaffenen API zugreifen. Der Projektablauf hat gezeigt, dass bei Einsatz einer wohldefinierten Methodik, Verwendung eines klaren Prozesses, Etablierung von Kommunikation zwischen allen Projektbeteiligten, Einhalten von

Modellbasierte Implementierung einer Ontologie-Zugriffsschicht

97

Architektur und Designvorgaben, Aufsetzen einer leistungsfähigen Infrastruktur, sowie Auswahl und Integration von geeigneten Werkzeugen auch herausfordernde Aufgabenstellungen mit überschaubarem Aufwand und im vorgegebenen Zeit- und Kostenrahmen umgesetzt werden können.

Generative Entwicklung in einem langlaufenden Projekt Ralf Simon M&M Software GmbH Web Applications Industriestrasse 5 78112 St. Georgen [email protected]

Zusammenfassung: Die M&M Software GmbH entwickelt zusammen mit der Firma Endress+Hauser eine internetfähige Engineering Anwendung mit dem Namen Applicator® [1], welche die Auswahl- und Auslegung von Messgeräten in verschiedenen Arbeitsgebieten ermöglicht. Die Oberflächen der Anwendung und deren Verbindung zur Berechnungslogik werden mit Hilfe eines Open Source Generators [2] aus einem formalen Modell generiert. M&M stellt die wesentlichen Schritte innerhalb des Generierungsprozesses heraus, die vom Modell bis zur fertigen Software durchlaufen werden.

1

Ausgangssituation

Der Applicator® führt den Anwender durch die einzelnen Stufen eines Prozesses zur Produktauswahl- und Auslegung. Die damit spezifizierten Geräte kommen in verschiedenen Arbeitsgebieten zum Einsatz. Jedes Arbeitsgebiet erfordert unterschiedlich komplexe Berechnungsverfahren, um zu dem passenden Produkt zu gelangen und wird durch ein eigenes Modul in der Applikation repräsentiert. Die Module bieten dem Benutzer spezifische Eingabemasken an, um die erforderlichen Prozessdaten wie Druck und Temperatur eingeben zu können. Trotz unterschiedlicher Berechnungslogik und Attribute soll eine einheitliche Benutzerführung sowie ein durchgängiges look & feel vermittelt werden. Hier hat M&M entsprechendes Optimierungspotential innerhalb des inkrementell durchgeführten Entwicklungsprozesses erkannt, denn der Applicator® wird kontinuierlich durch neue Module erweitert.

2

Modellgetriebene Software Entwicklung (MDSD)

Die Berechnungen sind jeweils sehr unterschiedlich und müssen für jeden Bereich neu entwickelt werden. Die verwendeten Oberflächenelemente, deren Sichtbarkeit in Abhängigkeit zur aktuellen Auswahl, die räumliche

100

Simon

Anordnung auf der Oberfläche sowie die Anbindung an die Berechnungslogik folgen jeweils demselben Muster. Aus diesem Grund haben wir uns entschlossen, die Oberflächen generativ zu erstellen und für diesen Zweck eine eigene, domänenspezifische Sprache (DSL) entworfen.

2.1 Von der DSL zum Modell Um die DSL festzulegen haben wir zuerst manuell ein Beispiel als Durchstich implementiert. Daraus ergaben sich die Anforderungen an die Modellierungssprache. Für die Oberflächenelemente, wie Auswahlboxen und Textfelder, haben wir verschiedene Modellelemente festgelegt, die in einer Grammatik definiert wurden. Die Grammatik hierfür wurde in der BacchusNaur Form beschrieben und mit einem JavaCC Parser [3] ausgewertet. Wir haben es vermieden, für die Erstellung des Modells ein eigenes Modellierungswerkzeug zu entwickeln. Als Alternative erschien uns Excel, als bekanntes Werkzeug, ausreichend. Die Bedienung erforderte keine Einarbeitung und Excel ist ohne Zusatzkosten verfügbar. Der tabellarische Ansatz ermöglicht es, die modellierten Elemente gleich richtig zu positionieren (Grid-Layout), was eine Art „what you see is what you get“ (WYSIWYG) Funktion bietet (siehe Abbildung1: Excel Modell).

2.2 Das Metamodell Aus dem Modell werden Java Code sowie die Java Server Pages (JSP) automatisch erzeugt. Die Transformation des Modells wird vom Metamodell festgelegt. Das konkrete Modell ist eine Instanz des Metamodells. Das Metamodell besteht im vorliegenden Fall aus einer Hierarchie von Java Klassen und Codegenerierungs-Templates, die vom eingesetzten Generator unterstützt werden.

Abbildung 1: Excel Modell

Generative Entwicklung in einem langlaufenden Projekt

3

101

Zusammenfassung

Wiederkehrende, ähnliche Artefakte eignen sich gut als Kandidaten für die Generierung. Der erhöhte Anfangsaufwand wird mit zunehmender Verwendung kompensiert. Die Verschwendung von wertvollen Entwicklungsressourcen für die immer wiederkehrende, manuelle Erstellung gleichartiger Seiten wird auf ein Mindestmaß reduziert. Fehler werden sehr früh erkannt und können zentral im Metamodell behoben werden. Dasselbe gilt für die Erweiterung bestehender Funktionen. Nachfolgende Entwicklungen profitieren von den Arbeiten. Die Produktivität und Qualität der Anwendung erhöhen sich .

Literatur [1] https://wapps.endress.com/applicator/ [2] http://openarchitectureware.org/ [3] http://www.ibm.com/developerworks/xml/library/x-javacc1.html#BNF_onwards

Stoppt die Architektur Erosion: Beispiele aus dem Open Source Bereich Bernhard Merkle Zentrale Forschung und Entwicklung Abt. Software Engineering SICK AG D-79183 Waldkirch [email protected]

Zusammenfassung: Bei der Weiterentwicklung von Systemen wird es mit fortlaufender Zeit immer schwieriger, die originale, zugrunde liegende Architektur zu verstehen und sie einzuhalten. Aufgrund von Faktoren wie Termindruck, eingebaute Workarounds, fehlende Architekturdokumentation oder fehlendes -verständnis setzt ein Erosionsprozess ein. In diesem Papier wird gezeigt, wie man diesem Trend entgegenwirken kann. Wir verwenden ein Beispiel aus dem Open Source Bereich.

1

Software-Architektur

Die Norm IEEE 1471-2000 [1] definiert den Ausdruck Software-Architektur als “The fundamental organization of a system, embodied in its components, their relationship to each other and the environment, and the principles governing its design and evolution”. Viele Software Projekte leiden heutzutage unter dem Problem der SoftwareArchitektur-Erosion und den damit verbundenen Problemen. Oft enden solche Systeme in einer nicht mehr handhabbaren Codebasis: ungewollte und unerwartete Abhängigkeiten und Seiteneffekte machen eine Wartung sehr schwer. Die bisherige Lösung zu verwerfen und es nochmal „neu“ und „richtig“ zu machen, können sich die wenigsten Projekte leisten. Daher ist es essentiell, Software-Erosion und Software-Qualität regelmäßig und möglichst automatisiert zu überwachen.

2

Beispiele aus dem Open Source Bereich

Wir stellen einen Ansatz vor, wie man die Erosion einer Software stoppen und längerfristig die Software Qualität wieder steigern kann. Eine Fallstudie aus dem Open Source Bereich zeigt anhand von 2 Beispielen, wo

Merkle

104

Architektur-Analyse die Erosion nachweisen kann. Weiterhin sehen wir, wie man ein erodiertes System wieder refaktorieren kann [2] und dass Modulsysteme wie z.B. OSGi eine Erosion gar nicht entstehen lassen bzw. stark eindämmen.

Abbildung 1: Stark erodiertes und im Vergleich, wenig erodiertes Software System.

Es wird zusätzlich gezeigt, wie man mit Hilfe geeigneter Metriken problematische Stellen auffinden kann. Interessanterweise lässt sich nachweisen, dass erodierte Stellen immer wieder in der Wartung zu Problemen führen.

3

Zusammenfassung

Für längerfristige Software Projekte sollte eine Architektur-Überprüfung vorgeschrieben werden. Mittlerweile bieten zunehmend Werkzeughersteller (statische CodeAnalyse-Werzeuge und auch IDEs) solche Möglichkeiten an, sodass längerfristig die Architektur-Analyse hoffentlich zu einem etablierten Prozessschritt in der Software Entwicklung werden wird.

Literatur [1]

IEEE 1471-2000: Recommended Practice for Architectural Description of SoftwareIntensive Systems -Description

[2]

Rook, Lippert: Refactoring in Large Software Projects John Wiley & Sons; Auflage: 1. Auflage (7. April 2006), 047085892

Prozessdokumentation in kleinen und mittleren Unternehmen Klaus Gurr Gurr Organisationsentwicklung Härtenstraße 102 72127 Immenhausen [email protected], www.pflow.de

Zusammenfassung: Dieser Beitrag beschäftigt sich mit der Frage, welche Anforderungen an Technologie und Tools beim Prozessmanagement in kleinen und mittleren Unternehmen bestehen. Es wird von der These ausgegangen, dass sich die Situation beim Thema Prozesse in großen und kleinen Unternehmen grundlegend unterscheidet: Können in den großen Unternehmen die elaborierten Softwaretools sinnvoll eingesetzt werden, sind diese in kleinen Unternehmen deplaziert. Hier gibt es bescheidene Anforderungen an die Tools, die sich mit den Begiffen einfach, schnell und günstig zusammenfassen lassen.

1

Situation in großen Unternehmen

In großen Unternehmen wurde in den vergangenen Jahren mehr und mehr die Bedeutung des Themas Prozessmanagement erkannt. Hier finden sich in Fachabteilungen gut ausgebildete und spezialisierte Mitarbeiter, die sich intensiv – oft ausschließlich – mit dem Themenkreis rund um Prozessmanagement befassen. Methoden der Prozessdokumentation, Tools für das Prozessmanagement, Kommunikation und Schulung bezüglich der Prozesse im Unternehmen bis zur Analyse der Prozesse sind fest etabliert und elaboriert entwickelt. Die Mitarbeiter in diesen Fachabteilungen werden unter anderem in den für das Prozessmanagement eingesetzten Tools oft zeitintensiv ausgebildet, die Tools selbst werden häufig mit hohem Aufwand und unter Einsatz externer Berater solide implementiert, in der IT sind Mitarbeiter für den Betrieb der damit verbundenen Datenbanken abgestellt und ausgebildet.

2

Situation in kleinen Unternehmen

Ganz anders stellt sich die Situation in kleinen und mittleren Betrieben dar. Das Thema Prozessmanagement ist quasi ein ungeliebtes Stiefkind, nichts mehr als ein Mittel zum Zweck und bei weitem nicht voll entwickelt:

106

Gurr

reduziert auf die Dokumentation von Prozessen, Mitarbeitern als Nebenaufgabe ohne weitergehende Ausbildung zugeteilt. Dem Tool kommt hier nur eine eindimensionale Bedeutung zu: Es sollen möglichst schnell und einfach die Prozesse dokumentiert und das Ergebnis den Mitarbeitern möglichst und einfach und leicht verständlich zugänglich gemacht werden können. Dass man überhaupt Prozesse dokumentiert, hat sowieso nur ein Ziel: Man will sich zertifizieren lassen nach DIN ISO oder einer anderen der heute vielfach verbreiteten Normen. Und dies eigentlich nur aus einem Grund: Weil die Kunden oder der Markt es fordern – eben nicht aus eigener Überzeugung, weil man die Sinnhaftigkeit von Prozessmanagement erkannt hätte ... (An dieser Stelle sei angemerkt, dass es auch heute noch Wirtschaftsbereiche gibt, in denen eine Zertifizierung nach DIN ISO eher die Ausnahme als die Regel darstellt und das Thema Prozessmangement in Unternehmen dieser Branchen nur wenig verbreitet ist. Als Beispiel sei der Bereich des Handel genannt.) Und so wird es dann häufig in der Praxis gelebt: Das ganze Unternehmen bereitet sich eilig und oft unter hohem Druck auf den Besuch des Auditors vor, ist froh, wenn das Ganze vorbei ist und man sich das mit diesem Aufwand erworbene Zeritfikat schön gerahmt an die Wand hängen darf und der Außenwelt präsentieren kann. Und in logischer Konsequenz kümmert man sich dann in den kommenden Monaten nicht mehr um die Prozesse, wendet sich wieder voll und ganz dem Tagesgeschäft zu, bis sich dann nach vielen Monaten dieses Spiel, in Hinblick auf den erneuten Termin der Zeritifizierung, wiederholt ...

3

Anforderungan an Tools in kleinen Unternehmen

Wenn man diese Situation beim Thema „Prozesse“ in großen und keinen Unternehmen – die oben sicher nur holzschnittartig skiziert wurde – vergleicht, zeigt sich eine geradezu polare Situation. Dabei wird deutlich, dass die Anforderungen an die Technologie – also Tools und Software – sich in diesen beiden Feldern völlig unterscheiden. Können in den großen Unternehmen hoch entwickelte elaborierte Tools sinnvoll eingesetzt werden, sind diese für kleine Unternehmen völlig deplaziert. Hier, in den kleinen Unternehmen, geht es eben nicht darum, was technisch machbar ist, sondern um die sehr viel bescheidenere Frage: Was ist einfach, schnell und dazu noch günstig? Punkte, die sich aus diesem Blickwinkel ableiten lassen, finden sich in der folgenden Liste: x Das Tool muss sich schnell, einfach und ohne hohe Anforderungen in die IT-Landschaft implementieren lassen.

Prozessdokumentation in kleinen und mittleren Unternehmen

107

x Das Tool muss im Betrieb einfach zu handhaben und zu administrieren sein, d. h. ohne besondere Spezialkenntnisse. x Das Tool muss einfach zu bedienen sein, die Anforderungen an die technische Versiertheit der Mitarbeiter müssen möglichst gering sein. Damit ist verbunden, dass Mitarbeiter schnell in das Tool eingearbeitet werden können und mit dem Tool auch noch zurechtkommen, wenn sie ein paar Wochen oder Monate nicht damit gearbeitet haben. x Das Tool sollte den Aufbau einer einfachen Prozessstruktur in einfacher Weise unterstützen. x Das Tool sollte über automatische Funktionen verfügen, welche die modellierten Prozesse verifizieren und den Anwender auf wesentliche Fehler, z. B. fehlerhafte Hyperlinks, hinweisen. x Die Ausgabe der Prozesse sollte in eine HTML-Version der Prozesse möglich sein, damit die Dokumentation für alle Mitarbeiter verfügbar ist. Dabei sollte die Darstellung und Navigation übersichtlich und einfach zu verstehen sein. x Das Softwaretool sollte nicht viel kosten und der externe Beratungsaufwand überschaubar sein. Das Dokumentationssystem PFlow® wurde genau in diesem oben beschriebenen Umfeld entwickelt in dem Versuch, diesen Anforderungen gerecht zu werden (siehe Abbildung 1).

Abbildung 1: Prozesslandkarte des Dokumentationssystems PFlow

108

Gurr

Als technologische Basis werden die Microsoft Standard Office Anwendungen Visio und Excel verwendet. Erweiterte Funktionen sind über über eine Programmierung in VBA realisiert und der HTML-Export der Prozesse aus Visio wird über ein AddOn unterstützt und vereinfacht. Das Dokumentationssystem beinhaltet ein solides Konzept für den Aufbau von Prozesshäusern und steht generell unter dem Motto: „Einfach und schnell in der Modellierung – übersichtlich und anwenderfreundlich für die Mitarbeiter“

Agile Methoden und Nearshoring funktioniert das? Felix Rüssel www.agile-nearshoring.com Märchenstraße 5 76297 Stutensee [email protected]

Stanislav Ulmer www.agile-nearshoring.com Badeniaplatz 5 76189 Karlsruhe [email protected]

Zusammenfassung: Agile Vorgehensweisen wie Scrum werden auf Grund ihrer vielfältigen Vorteile mittlerweile in der IT Industrie sehr häufig eingesetzt. In Kombination mit dem Fremdbezug von IT Dienstleistungen können sich erhebliche Wettbewerbsvorteile ergeben. Im vorliegenden Papier wird erläutert, dass eine Kombination von agilen Methoden und NearshoreOutsourcing funktionieren kann.

1 Ausgangssituation Seit Jahrzehnten führt der Druck Kosten zu senken dazu, dass Aufgaben ausgelagert werden. Um die mit einer Auslagerung verbundenen Risiken beherrschbar zu machen, wird in der Regel auf eine hohe Standardisierung und strikte Dokumentation aller Schritte gesetzt. Detaillierte Verträge und Festpreisvereinbarungen sollen zudem den Projekterfolg sicherstellen. Zu den treibenden Kräften von Offund Nearshoring gehören große Lohnkostenunterschiede, die Globalisierung des Handels mit Dienstleistungen, ein zunehmend geschäftsfreundliches Klima durch Öffnung der Märkte und die steigende Anzahl an verfügbaren Fachkräften in den Anbieterländern. Wichtig für den großen Boom im letzten Jahrzehnt waren zudem die Verringerung der Kommunikationskosten (Internet, Telefon) und eine Standardisierung von Technologien und Software. Ein anderer Ansatz, um den erforderlichen Produktivitätszuwachs zu erreichen, ist der Einsatz von agilen Methoden. Mit diesen soll die Qualität verbessert und die Produktivität gesteigert werden. Zudem werden die Entwicklungsprozesse und organisatorischen Schwächen transparent gemacht. Agile Methoden sind von enger Zusammenarbeit, weniger geschriebener Dokumentation, kürzeren Zyklen und einem Fokus auf Qualität geprägt. Seit kurzem gelingt es immer mehr Organisationen beides zu kombinieren: Agile Methoden bei ausgelagerter Softwareproduktion. Besonders gut funktioniert dies, wenn der Lieferant noch relativ nahe beim Auftraggeber angesiedelt ist und trotzdem große Kostenvorteile bieten kann. Dies ist beim Nearshore-Outsourcing (kurz: Nearshoring) der Fall.

Rüssel, Ulmer

110

2 Nearshore Outsourcing Nearshore-Outsourcing (Nearshoring) ist ein Kunstwort und setzt sich zusammen aus Outsourcing und Nearshore. Unter Outsourcing versteht man den Fremdbezug von Leistungen. Der Begriff Nearshore wird eingesetzt, um geografisch relativ nahe Regionen mit ähnlichen Zeitzonen zu beschreiben. Für Europa sind dies osteuropäische oder nordafrikanische Länder. Die dortigen Entwicklungszentren sind innerhalb kurzer Zeit erreichbar. Dies erleichtert gegenseitige Besuche und ein gemeinsames Arbeiten von Auftraggeber und Entwicklungsteam. Im Gegensatz zu Asien sind die kulturellen Unterschiede aus deutscher Sicht bei vielen osteuropäischen Ländern nicht sehr groß. Die Lohnkosten sind im Vergleich mit Deutschland viel niedriger, der Bildungsstandard ist sehr hoch und die Experten verfügen über gutes Fachwissen. Da der Zeitunterschied zwischen Kunde und Nearshore-Standort nur 1-3 Stunden beträgt, ist eine Kommunikation im Tagesverlauf für beide Seiten einfach möglich. Mittlerweile ist Englisch in Osteuropa etabliert und Mitarbeiter können meist gut auf Englisch kommunizieren. Die Erfolgsquote von Nearshore-Projekten ist zudem höher als bei OffshoreProjekten, da beispielsweise die Kommunikation und Kontrolle von Projektabläufen unproblematischer ist. Die Gründe für Outsourcing sind seit Jahren ähnlich, im Vordergrund steht stets das Kostensenkungspotential. Weitere wichtige Gründe umfassen die Flexibilisierung von Leistungsfähigkeit und Kostenstrukturen, eine bessere Konzentration auf das Kerngeschäft, Zugang zu qualifiziertem Personal sowie eine Verringerung der Zeit bis zur Markteinführung [4]. Neben den genannten Vorteilen gibt es jedoch auch Risiken und Probleme beim Outsourcing, die in vielen Fällen auf eine mangelnde Vorbereitung zurück zu führen sind. Beispielsweise kommt es immer wieder vor, dass einer OutsourcingEntscheidung eine falsche Kostenkalkulation zu Grund liegt und letztendlich keine Kostenvorteile realisiert werden können. Zudem ist die Abhängigkeiten von den Dienstleistern ein Risiko, welches einer genauen Betrachtung bedarf. Falsch abgestimmte Verträge und falsche Partner können dazu führen, dass sich die Flexibilität verringert, statt sich zu verbessern. Auch die Qualität der Dienstleistungen bietet immer wieder Anlass zu Kritik. Hier muss im Vorfeld die Leistungsfähigkeit eines Lieferanten genau geprüft werden.

3 Rollen Es gibt drei zentrale Rollen in einem typischen Sourcing-Projekt. Neben dem Auftraggeber und dem Dienstleister gibt es meist noch die Rolle des Beraters. y

Der Auftraggeber initiiert und finanziert das Projekt und verfolgt damit ein Ziel. Er stellt die Anforderungen und steuert den Projektverlauf durch Vorgabe von Zwischenzielen. Der Kunde gibt kontinuierlich Feedback hinsichtlich Qualität und Zielerfüllung indem er die Projektergebnisse bewertet.

y

Der Dienstleister ist für die Projektrealisierung verantwortlich. Im Vorfeld muss er Aufwand abschätzen und Prototypen erstellen. Bei der Umsetzung der Anforderungen muss er die Qualität sichern und den Projektfortschritt

Agile Methoden und Nearshoring - funktioniert das?

111

regelmäßig an das Onsite-Team (Berater/Projektleiter) sowie den Kunden melden. y

Der Berater/Projektleiter arbeitet eng mit dem Auftraggeber zusammen, um den Projektumfang, die Anforderungen und die zu erzielenden Ergebnisse zu klären. Er erstellt Projektpläne in Koordination mit Kunden und Dienstleister und kontrolliert fortlaufend der Projektfortschritt. Der aktuelle Status wird regelmäßig an den Kunden berichtet und die erzeugten Prototypen und Ergebnisse dem Kunden präsentiert. Mögliche Änderungen im Projektverlauf stimmt er mit allen Beteiligten ab.

4 Agile Methoden Agile Methoden basieren auf einem Wertesystem, welches Ausdruck findet im "agilen Manifest" [5], den "agilen Prinzipien" [6] und den "Scrum Werten" [3]. Im Vordergrund steht der Mensch (statt Werkzeuge und Prozesse) und die Erzeugung von geschäftlichen Werten. Zudem wird mehr Wert auf Zusammenarbeit gelegt als auf strikte Vertragseinhaltung. Statt einem rigiden Plan zu folgen, werden Änderungen aufgegriffen und in die Planung übernommen. Ein weiterer wichtiger Aspekt ist die systematische Arbeitsweise: Planen, Machen, Überprüfen, Anpassen. Dies geschieht in kurzen Zyklen und führt zu einer ständigen Verbesserung der Planung und Umsetzung. Agile Methoden wie Scrum sind geprägt von kurzen Zyklen, einer hohe Transparenz, der Ausrichtung auf Qualität und Nutzung von direktem Feedback. Ziel ist es, so schnell wie möglich Ergebnisse zu produzieren und diese produktiv einzusetzen (Reduzierung Time to Market). Hierdurch können schneller Erlösen erzielt werden. Um das Risiko von technische Schulden zu reduzieren und langfristig produktiv arbeiten zu können, spielt Qualität (Stichwort "done done") eine wichtige Rolle. Durch die kurzen Zyklen und die Zwischenergebnisse wird eine hohe Transparenz sichergestellt, wodurch sich die Erwartungshaltung des Auftraggebers verbessert. Dieser lernt durch die enge Einbindung, was möglich ist und was problematisch sein kann. Die kurzen Zyklen führen auch zu einem verbesserten Risiko-Management: Risiken werden sehr früh identifiziert und werden dadurch besser beherrschbar. Werden die Iterationen einzeln abgerechnet ist eine gute Kostenkontrolle möglich: Iterationen sind leicht zu bepreisen, die Ergebnisse einer Iteration sind gut testbar. Die Kundenzufriedenheit steigt, da durch die Einflussmöglichkeiten im Rahmen der Sprint-Planung der Kunde stets das geliefert bekommt, was er am dringendsten benötigt. Projektmitarbeiter nehmen ein agiles Umfeld meist als gute Arbeitsumgebung wahr, wodurch die Motivation und Identifikation mit den Projektzielen gesteigert wird.

5 Agile Methoden und Nearshoring Die Kombination von agilen Methoden und Nearshoring hat zum Ziel, die günstigen Herstellungskosten in Nearshore-Ländern und gleichzeitig die Vorteile der agilen Methoden in Projekten zu nutzen. Hierbei gibt es die besondere Herausforderung trotz verteilter Projektteams die Projekte mit hoher Qualität erfolgreich

Rüssel, Ulmer

112

abzuschließen. Die methodische Transparenz und ausgeprägte Qualität durch agiles Vorgehen führen dazu, dass gewisse Risiken, die durch verteilte Entwicklung entstehen, reduziert werden. Historisch betrachtet geht man beim Einsatz von agilen Methoden von einer Idealvorstellung aus: Kleine Teams, die direkt zusammen arbeiten und ein allgegenwärtiger Kunde, der jederzeit Fragen beantworten kann und Prioritäten klärt. In vielen Unternehmen sind heute in komplexen Projekten große Teams im Einsatz, die verteilt arbeiten. Dies wird sich in Zukunft verstärken, der Trend ist klar: Projekte werden von weltweit verteilten Teams bearbeitet und die Ergebnisse müssen hohen Anforderungen an Funktionalität, Usability, Skalierbarkeit gerecht werden. Hierbei besteht das Problem, dass große Projekte besonders risikoreich sind - je größer das Projekt, umso größer das Risiko zu scheitern. Ein Grund für das Scheitern ist häufig mangelhafte Kommunikation zwischen den Projektbeteiligten. Der Einsatz von agilen Methoden hilft, Probleme frühzeitig zu identifizieren, da eine enge Kommunikation nötig ist, um Fortschritte im Projekt zu erreichen. Hierbei spielt auch die Zusammenarbeit in Echtzeit mittels diverser technischer Hilfsmittel (Wiki, IM, Screen-Sharing, Web-Meetings) eine wichtige Rolle. Zudem sind bei agilen Methoden robuste Plattformen, Infrastrukturen und Entwicklungspraktiken wichtig. Stichworte hierbei sind Re-Use, Reengineering, Collective Code-Ownership, Continuous Integration. Auf eine große Transparenz des Projektstatus wird viel Wert gelegt.

6 Ergebnisse und Erfahrungen Wird heute mit Outsourcing-Dienstleistern diskutiert, wird in vielen Fällen behauptet, dass agile Methoden zum Leistungsspektrum gehören. Bei genauerer Betrachtung stellt sich jedoch meist heraus, dass die Umsetzung von agilen Prinzipien sich auf wenige isolierte Praktiken beschränkt. Will man demnach wirklich agil mit einem entfernten Team arbeiten, ist es wichtig, einen Dienstleister zu wählen, der bereits einige Erfahrung mit agilen Methoden hat. Erfolgreiche Projekte zeigen, dass agile Methoden gut mit verteilten Teams funktionieren und Vorteile gegenüber konventionellen Methoden bieten.

7 Erfolgsfaktoren Zu den Erfolgsfaktoren verteilter Entwicklungsprojekten und agilem Nearshoring gehören: y

Partnerschaftliche Beziehung: Im Rahmen einer Sourcing-Beziehung spielen informelle Steuerungsformen, wie zum Beispiel Verhaltensnormen und Vertrauen, eine wichtige Rolle. Die Beziehungsprotokolle werden im Laufe der Zeit aufgebaut und basieren auf Werten wie Fairness, Respekt und Commitment [2]. Das Vorhandensein einer partnerschaftlichen Beziehung wird in der Praxis als der dominierende Erfolgsfaktor angesehen: „[…] ist zudem die Dominanz des Erfolgsfaktors ‚Schaffen einer partnerschaftlichen Beziehung’ zwischen den Projektpartnern bemerkenswert. Dieser Faktor wurde von den Befragungsteilnehmern insgesamt fast doppelt so oft wie der nach unserer Befragung zweit wichtigste Erfolgsfaktor (‚Sicherstellen eines kontinuierlichen Kommunikationsflusses’) genannt.“ [1].

Agile Methoden und Nearshoring - funktioniert das?

113

y

Kommunikation: Alle am Projekt beteiligten Personen müssen die "gleiche Sprache sprechen", die technische Infrastruktur (Skype, VoIP, IM, Screensharing, Telefon, Konferenzschaltungen, …) muss die Kommunikation erleichtern. Trotz des technischen Fortschritts ist die direkte Kommunikation in Form von gegenseitigen Besuchen weiterhin sehr wichtig, da bei diesen Gelegenheiten Vertrauen und Verständnis zwischen den Beteiligten aufgebaut wird. Leichte Erreichbarkeit (Stichwort: Flugverbindungen) sind deshalb von großer Wichtigkeit. Im Idealfall kann morgens angereist werden und abends der Flug zurück genutzt werden.

y

Offenheit & Vertrauen: Es muss eine offene Zusammenarbeit gepflegt werden, die auf Vertrauen basiert. Sobald Verträgen gesichtet werden (müssen) ist im Allgemeinen das Projekt gescheitert. In der täglichen Kommunikation dürfen sich die Beteiligten nicht hinter Floskeln verstecken. Das gemeinsame Ziel ein gutes Ergebnis für das Projekt zu erreichen, muss von allen verfolgt werden. Durch ihre kurzen Zyklen und Transparenz durch schnelle Zwischenergebnisse helfen agile Methoden, da Schwächen und Probleme frühzeitig identifiziert werden können. Aus operativer Sicht ist es wichtig, dass der Auftraggeber stets Zugang zur Entwicklungsumgebung hat sowie alle erzeugten Artefakt sichten und sichern kann. Damit kann der Kunde direkt den Projektfortschritt verfolgen und den gesamten Prozessverlauf unmittelbar nachvollziehen.

y

Einfachheit: Eine einfache Struktur des Projektes, der Prozesse und der Rahmenbedingungen helfen den Projekterfolg zu sichern. Dahinter verbirgt sich die Konzentration auf das Wesentliche und die Vermeidung von Ablenkung. Im Tagesgeschäft helfen einfache Prozesse und Werkzeuge bei der Fokussierung auf die Arbeit am eigentlichen Projektziel. Auch die Verträge müssen einfach sein je einfacher, umso transparenter und umso mehr Erfolgswahrscheinlichkeit. Vor diesem Hintergrund bietet sich ein Vertrag nach Aufwand oder ein Festpreis für Iterationen an. Festpreisangebote für ganze Projekte und Produkte führen unweigerlich zu einer Projektkalkulation, in der Aufschlägen für Schätzrisiken, Controlling, Monitoring, Claims-Management und Änderungswesen eingepreist sind.

y

Fokus: Fokussierung auf die Werterstellung und die eigentliche Arbeit ist ebenfalls ein Erfolgsfaktor. In vielen Wasserfall-Projekten wird auf das Monitoring, Reporting und dem Kampf um Änderungen viel Zeit verwendet, ohne für das eigentliche Projektziel Wert zu schaffen. Aus Entwicklungssicht bedeutet dies vor allem, dass eine Fokussierung auf werterzeugende Tätigkeiten (Entwurf, Entwicklung, Tests, Überarbeitungen) stattfinden muss. Im Projektverlauf sollte nicht die Verwaltung, sondern die Beseitigung von Mängeln im Vordergrund stehen. Zudem ist eine gemeinsame Sicht darauf, was wichtig und Ziel ist ebenfalls von sehr hoher Wichtigkeit.

8 Risikofaktoren Es gibt eine ganze Reihe an Risikofaktoren, die im Vorfeld einer SourcingEntscheidung zu überdenken sind, Beispiele hierfür sind:

114

Rüssel, Ulmer

y

Keine Partnerschaft: Der Anbieter "passt nicht" zu Auftraggeber. Dahinter verbergen sich Faktoren wie Unternehmensgröße, Fokussierung auf Märkte und Technologien, Strategien und Vision. Zudem spielt auch das persönliche Verhältnis der Schlüsselpersonen eine wichtige Rolle für den Projekterfolg.

y

Kommunikation: Die Bedeutung einer reibungslosen Kommunikation wird unterschätzt und der Austausch zwischen den Projektbeteiligten funktioniert nicht. Gerade agile Methoden verlangen jedoch nach einem andauernden Austausch, einer kontinuierlichen Kommunikation. Der Auftraggeber ist eng eingebunden und spielt eine sehr wichtige Rolle bei Erreichung der Projektziele.

y

Interpretation von „Agile“: Die agilen Prozessen werden unterschiedlich interpretiert, das Nearshoring-Team und der Auftraggeber haben ein unterschiedliches Verständnis von agilen Methoden. Dies führt im Projektverlauf immer wieder zu Problemen.

y

Abhängigkeit: Eine zunehmende Abhängigkeit vom Anbieter auf Grund von Verträgen und dem Verlust von eigenem Know-how kann die eigene Flexibilität verringern. Zudem existieren beispielsweise zusätzliche Risiken wie der Marktaustritt eines Nearshore-Lieferanten (z.B. Konkurs).

y

Zusammenstellung des Teams: Die Bildung des Nearshoring-Teams wird komplett dem Dienstleister überlassen. Um Kosten zu senken werden beispielsweise häufig junge Entwickler eingesetzt, die noch keine oder nur wenig Berufserfahrung besetzen. Die sind meist sehr motiviert, aber es fehlt die Erfahrung mit komplexen internationalen Projekten.

y

Kostensteigerungen & Fluktuation: Nicht unterschätzt werden darf, dass die Kosten auch in den Nearshoring-Ländern stetig steigen. Manche Länder werden in absehbarer Zeit als Nearshoring-Anbieter an Attraktivität verlieren, da die Lohnkostenvorteile schwinden. Die teilweise hohen Fluktuationsraten in Nearshoring-Teams erschweren eine erfolgreiche Kommunikation und führen ebenfalls zu zusätzlichen Kosten.

y

Recht & Vertrag: Rechtliche Fragestellungen - gerade im Vertragsrecht stellen ebenfalls ein relevantes Problemfeld dar. Fragen zum intellektuellem Eigentum (Rechte an der geschriebenen Software) müssen im Vorfeld geklärt werden.

y

Erreichbarkeit: Nicht alle Entwicklungsstandorte sind direkt per Flug und ohne Visum erreichbar. Es ist zu prüfen wie viel Zeit die gesamte Anreise benötigt. Eine einfache Erreichbarkeit ist wichtig für vertrauensbildende Maßnahmen wie gegenseitige Besuche.

y

Sicherheit: Sicherheit der Infrastruktur muss gewährleistet sein. Die moderne Kommunikationsmittel sind nicht immer sicher. Sehr oft wird vergessen dass die Datenübertragung nicht ohne Aufwand zu sichern ist. Hier muss der Anbieter darlegen, welche Maßnahmen er unternimmt, um eine hohe Sicherheit bei maximaler Flexibilität zu gewährleisten.

Agile Methoden und Nearshoring - funktioniert das?

115

Einige der Risikofaktoren lassen sich im Vorfeld relativ einfach bewerten (Beispiel: "Erreichbarkeit"). Andere Risiken können im Projektverlauf näher betrachtet werden bzw. es handelt sich um latente Risiken. Letztendlich helfen die agilen Methoden mit ihrer Transparenz dabei, frühzeitig auf Probleme aufmerksam zu werden. Sollte es beispielsweise ein Problem mit der Kommunikation geben, so wird dies schnell sichtbar, da agile Methoden ohne gute Kommunikation nicht funktionieren.

9 Zusammenfassung Das Nearshoring von Leistung eröffnet Kostensenkungspotentiale und bietet weitere mögliche Vorteile. Die Projektabwicklung ist jedoch komplexer und es gibt vielfältige Risiken, die den Projekterfolg gefährden können. Der Einsatz von agilen Methoden kann helfen, einige der Risiken zu reduzieren. Mittlerweile haben immer mehr Nearshoring-Anbieter Erfahrungen mit agilen Methoden, einige fokussieren sich auf diese Art der Projektdurchführung. Der Einsatz von agilen Methoden erfordert jedoch eine andere Vorgehensweise in der Projektabwicklung: Weg von Festpreis-Vereinbarungen und riesigen Spezifikationen, hin zu kürzeren Zyklen und der Möglichkeit den Projektverlauf wirklich beeinflussen zu können. Wichtig bei einer Nutzung von agilen Methoden in Nearshoring-Projekten ist Offenheit, ein partnerschaftliches Arbeiten, eine reibungslose Kommunikation und Fokussierung auf das Wesentliche. Dies ist stark abhängig von den beteiligten Personen, deshalb muss dem eingesetzten Personal besondere Aufmerksamkeit gewidmet werden. Fazit: Die Nutzung von agilen Methoden bei Nearshore-Outsourcing bietet vielfältige Chancen und verbessert die Chancen auf einen Projekterfolg. Für die Autoren sind agile Methoden und Nearshoring eine hervorragende Kombination.

Quellen [1]

[2]

[3]

[4]

[5] [6]

M. Amberg, M. Wiener: Kritische Erfolgsfaktoren für Offshore Softwareentwicklungsprojekte – Eine explorative Studie, 2004, URL: http://www.wi3.uni-erlangen.de/OSE/ Studie_KritischeErfolgsfaktorenOffshore Softwareentwicklungsprojekte_Amberg+Wiener.pdf, [Zugriff am19.5.2007]. S. Jahner, T. Böhmann, H. Krcmar, : Eine Typologie von Beziehungen im ITOutsourcing: Ein konzeptioneller Ansatz, in: Oberweis, Andreas et.al, (Hrsg.), eOrganisation: Service-, Prozess-, Market-Engineering, Band1, Universitätsverlag Karlsruhe, Karlsruhe 2007, Seite 347-364. F. Rüssel: Zusammenfassung Scrum User Group Karlsruhe – 1. Treffen, 2009, URL: http://www.armerkater.de/2009/02/scrum-user-group-karlsruhe-1-treffen/, [Zugriff am: 17.03.2010]. J. Schaaf, M. Weber: Offshoring-Report 2005, in: Economics – Digitale Ökonomie, Nr. 52, Deutsche Bank Research, 14. Juni 2005, URL: http://www.bitkom.org/files/documents/ OffshoringReport2005_BITKOM_DBR _ECO52.pdf,[Zugriff am 6.4.2007] K. Beck et al.: Agiles Manifest, URL: http://agilemanifesto.org/, [Zugriff am 17.03.2010]. K. Beck et al.: Principles behind the Agile Manifesto, URL: http://agilemanifesto.org/principles.html, [Zugriff am 17.03.2010].

Teil IV: Young Researchers

Adapting self-organizing Maps to the MapReduce programming paradigm Christian Weichel Fakult¨at Informatik Hochschule Furtwangen University Robert-Gerwig-Platz 1 78120 Furtwangen, Germany [email protected]

Abstract: We present an adaption of the self-organizing map (SOM)

useful for cluster analysis of large quantities of data such typically found in the domain of knowledge management. The algorithm is based on the batch SOM formulation. That particular algorithm has been successfully adopted to other parallel architectures and perfectly suits the map reduce programming paradigm. Thus it enables the use of self organizing maps on large cloud computing infrastructures such as Amazon EC2. With the algorithm initially presented in this paper we allow the integration of data classification tools within existing cloud infrastructures.

1

Introduction

The self-organizing map (SOM) [8] is a neural network which is capable of projecting a high-dimensional vector space onto a low-dimensional (mostly two) topology. This non-linear projection results in a ”feature map” of the high-dimensional space which can be used for detecting and analyzing features, such as clusters. Self organzing maps have been applied in a variety of fields, e.g. document retrieval [10], finance data analysis [4], forensic analysis [7] and engineering applications [14][11]. Classification is one of the major fields of application for neural networks. Those networks of which learning must be supervised train their weights against samples of training vectors and known outcome. Unsupervised learning in contrast, is used when possible classes of data are not known a priori or no training pairs exist as there is no

Weichel

120

known outcome. With the SOM learning unsupervised it is able to identify features and structures of the high-dimensional data. They show a self organizing behavior with the capability of detecting emergent features amongst clusters when used with a sufficient amount of neurons. Records unknown during the training phase can be classified using the weights of a trained map. Thus SOMs can be used to identify objects with similar features once the map is trained. In this paper we develop an adoption of the SOM algorithm to the MapReduce programming paradigm, thus making SOMs computable on cloud computing systems. By this we open them to a field of potential new applications. Data mining is becoming continually important and is a requirement of most large web applications, which are typically hosted on a cloud infrastructure. SOMs have successfully been applied to that field and now fully integrate into existing cloud infrastructures. Cloud computing has recently gained a lot of attention in academia and industry. We expect cloud computing to become a standard way of organizing IT infrastructures. In the first section we introduce self organizing maps, whereas the second section presents the MapReduce programming paradigm. The third section presents the algorithm we developed, while the fourth section summarizes experiments performed and gives evidence of the correctness of the algorithm.

2

Self organizing maps

As mentioned above the SOM produces a non-linear mapping of the highdimensional space, to a low-dimensional one. Several variants of this algorithm have been proposed (see [8], [5]), both of which are discussed in this section. The definitions given in this chapter are widely accepted standard definitions first proposed in the papers cited above. Let x ∈ Rn denote the input vectors and wk ∈ Rn the weight vector of the kth neuron (where k = 1 . . . K). The K neurons are arranged in a twodimensional lattice inducing a grid of weight vectors. A discrete time index t = 1, . . . is introduced so that x(t) is presented to the network at time t and the set of wk (t), ∀k represents the state of the network at time t. The available training vectors are presented to the network several times (called epochs). Before training the SOM the weight vectors have to be initialized, which is typically done by randomly selecting K input vectors.

2.1

Serial SOM

During training phase a metric is needed for the distance between vectors in the input space, where usually the euclidean distance (eq. 1) is used. For each presented input vector we compute the weight vector which is the closest to

Adapting self-organizing maps to the MapReduce programming paradigm

121

the presented input vector x according to eq. 2. We call that particular vector, winning vector and denote it by the subscript c. We finally update the weight vectors according to equation 3. dk (t) = x(t) − wk (t)2

(1)

K

dc (t) = min{dk (t)}

(2)

k=1

wk (t + 1) = wk (t) + α(t)hck (t)x(t) − wc (t)

(3)

The weight update is mainly influenced by the learn rate α(t) which must be monotonously decreasing over time. A common choice for this is an exponential function: t  αtf tf α(t) = α1 · α1 The neighborhood function hck (t) imposes the two-dimensional lattice on the weight update. It controls the extend to which an input vector adjusts the weight of the neuron k in respect to the winner vector c by using the distance on the lattice between those two vectors. Several functions have been proposed for this task, we use the Gaussian neighborhood (which is the most widely used neighborhood function) with a monotonously decreasing σ(t): 

rc − rk 2 σ(t)2 t  σtf tf σ(t) = σ1 · σ1



hck (t) = exp

(4)

The serial SOM algorithm is outlined in figure 2.1.

2.2

Batch SOM

Obviously the learning within an epoch is time dependent where each time step directly responds to the presentation of an input vector. Because of that, data partitioning with the serial SOM algorithm presented above is not possible. Therefore variants of that original algorithm have been proposed (see [5], [9], [12]), one of which is presented here. The batch SOM algorithm updates the weight vectors at the end of each epoch, thus removing the time dependency of the input vector presentation. tf wk (tf ) =

  t =0 hck (t )x(t ) tf  t =0 hck (t )

(5)

Weichel

122

Algorithm 1 Outline of the serial SOM algorithm {initialize weight vectors} for all epochs do t=0 {loop over all input vectors x ∈ X} for all x do t=t+1 {compute winning vector according to eq. 2} for k = 1 to K do {update weight vector wk according to eq. 3} end for end for end for

where tf denotes the end of an epoch, hence the summation is done for all vectors presented during an epoch. The winner vector is now computed using a slight variation of equation 2: d˜k (t) = x(t) − wk (t0 )2 K

dc (t) = min{d˜k (t)} k=1

(6)

where wk (t0 ) denotes the weight vector of the kth neuron of the previous epoch. For a more in depth discussion of the batch SOM algorithm see [13]. This approach offers several advantages over the serial SOM algorithm. First of all the time dependency and recursive weight vector update is removed, thus allowing data partitioning. It also removes the learn-rate coefficient α(t) which can be a source of poor convergence if improperly specified (see [13]). Also the two separated sums (numerator and denominator) allow further parallization, especially in the context of MapReduce.

3

The MapReduce programming paradigm

When dealing with large amounts of data, it is a common approach to distribute the load onto an adequate amount of machines. This is not a trivial task and several problems have to be dealt with, including failure safety (esp. in respect to the faulty hardware), inter-machine communication and algorithm design. The later imposes questions regarding the granularity and atomicity of the spawned tasks rendering some distributed algorithms useless for certain distributed environments.

Adapting self-organizing maps to the MapReduce programming paradigm

123

The MapReduce programming paradigm first proposed by J. Dean and S. Ghemawat (see [6]) provides a framework for designing and implementing distributed algorithms. It was primarily intended for use at Google Inc. to handle their huge amount of data (according to [6] more than 20 petabytes a day). Within a MapReduce context, the framework takes care of failurecorrection, data distribution and load management thus taking off a great share of issues from the programmers shoulders. In MapReduce generally data is present as key-value pairs (k, v) ∈ Ki × Vi . As the name implies the M/R paradigm consists of two steps. In the first one, called map phase, the input data is mapped to some key-value pairs, constituting the first algorithm specific computation. K0 × V0 −→ K1 × V1 The second step, called reduce phase, reduces all values per key (previously emitted by the Map stage) to a single value per key.    Q = k, (v1 , . . . , vn ) | k ∈ K1 , vi ∈ V1 , n ∈ N (7) Q −→ K2 × V2 It is important to notice that neither the keys nor the values of the map and reduce stage need to be the same. Example 1 illustrates this paradigm on a simple but real world example. Example 1 (MapReduce char count example). Within this example we want to count the characters of a set of given words, so that we know how often e.g. c occurred in the input data. We begin with our initial set of key-value pairs: map(0, lorem) = {(l, 1), (o, 1), (r, 1), (e, 1), (m, 1)} map(1, ipsum) = {(i, 1), (p, 1), (s, 1), (u, 1), (m, 1)} map(2, dolor) = {(d, 1), (o, 1), (l, 1), (o, 1), (r, 1)} There are two things to be noticed: first of all map applications are independent of one another and second the initial keys have no particular semantic, which is often the case for MapReduce applications. After the map phase, the reducer combines the key-value pairs to the final result by spawning a reduce task for each key emitted during the map phase (see eq. 7): reduce(l, (1, 1)) = 2 reduce(o, (1, 1, 1)) = 3 .. . reduce(d, (1)) = 1

Weichel

124

Yet again we notice that the reduce applications are independent of one another, which allows parallel execution.

4

Combining SOM and MapReduce

When designing an algorithm with MapReduce in mind one needs to divide the algorithm into atomic parts. Those parts are then mapped to the map and reduce phase. The batch SOM algorithm presented above can be divided into such atomic parts, when written like shown in algorithm 4. The atomic parts Algorithm 2 Outline of the batch SOM algorithm (see [13]) {initialize weight vectors} for all epochs do t=0 {initialize numerator and denominator of eq. 5 to 0} for all x do {loop over all input vectors} t=t+1 {compute winning vector according to eq. 6} for k = 1 to K do {compute hck x and hck according to eq. 4} {accumulate numerator and denominator in eq. 5} end for end for for k = 1 to K do {update weight vector wk according to eq. 5} end for end for

which can be identified are: • compute winning vector, hck x and hck • accumulate denominator • accumulate numerator • update weight vectors The very first step is the computationally most intensive one, for each input vector we must perform a nearest neighbor search within the current weight vectors (at t0 ) and compute the values required for the next steps. We use the reduction mechanism of MapReduce to compute the accumulations mentioned

Adapting self-organizing maps to the MapReduce programming paradigm

125

above. As each additional task costs in terms of time we strive to minimize that number. Hence we propose the following mapping of the steps to MapReduce: map0 reduce0 reduce1

compute winning vector, hck x and hck accumulate denominator accumulate numerator, update weight vectors

This mapping is the key part of the MapReduce SOM algorithm. The data flow between those phases (depicted in fig. 1), is obviously tied to the constraints implied by complying MapReduce. The first step map0 reads the vast amount of input data (training samples) and has the greatest share of the computational load. reduce0 and reduce1 accumulate the previously computed data into a the new SOM. Two MapReduce jobs are required to implement the mapping. The first job (depicted in algorithm 3) implements map0 and reduce0 . Its input (context, x) reflects the data partitioning approach mentioned earlier as the x denote the training vectors. The context is an arbitrary payload, which is not used during the SOM training but may be utilized to identify the vectors once the SOM is trained. It is important to notice that the reduce phase has a two-fold emit (accept and denomAccept). We will discuss this issue when a possible implementation is described in section 5. The GridKey mentioned used in algorithm 3 is an artificial type denoting the position of a neuron in the SOM lattice. This is a rather practical aspect as during implementation it was observed that it’s easier to work with the lattice position as opposed to a scalar value. The second job (see algorithm 4) implements reduce1 . As the reduce phase of the first job has a two-fold emit, this job has a two-fold acceptance (denoted by the →). It takes the numerators as its regular input and the accumulated denominators using a side channel. map0

GridKey(k)→

reduce1

Figure 1. Data flow of the map reduce SOM

GridKey(k)→ wk

reduce0

P

hck

GridKey(k)→ (hck , hck x)

126

Algorithm 3 First step of the map reduce SOM map(context, x): → {load wk (t0 )} {compute winning vector according to eq. 6} for k = 1 to K do {compute hck x and hck according to eq. 4} ← accept( GridKey(k), (hck x, hck )) end for . reduce (GridKey(k), ((hck x, hck )1 , . . . )) : sum = 0 for all hck do sum+ = hck end for ← accept( GridKey(k), hck x ) ← denomAccept( GridKey(k), sum )

Algorithm 4 Second step of the map reduce SOM map(GridKey(k), hck x): id . reduce(GridKey(k), hck x): → {load denominators produced in step one} wk = 0 for all hck x do wk = wk + (hck x / denomk ) end for accept( GridKey(k), wk ))

Weichel

Adapting self-organizing maps to the MapReduce programming paradigm

5

127

Implementation

Implementing the proposed algorithm in Hadoop (see [1]) seems to be a natural choice as this particular framework is widely used. Our implementation is a formulation of the algorithms 3 and 4 in Java where the two-fold output is implemented using MultipleOutputs while the two-fold acceptance is implemented using the Hadoop Distributed Filesystem. The algorithms parameters (e.g. size of the lattice, the σ for eq. 4, etc.) are provided using the JobConf facility. During the implementation of supporting applications it turned out that the Hadoop native file-formats (especially the SequenceFile) are particularly useful for storing the training data and SOM. Due to the nature of Hadoop it can easily be embedded into an Eclipse RCP application which is used to analyze the resulting SOM by computing the UMatrix (see [16]) and allowing a nearest-neighbor-search of weight-vectors within the training samples.

6

Experiments and proof of concept

Two properties are to be analyzed in the regard of the algorithm proposed in this paper, performance and correctness. Regarding performance we argument that this is basically an adoption of the batch SOM algorithm whichs performance has been discussed elsewhere, see [13]. Notice (without proof) that the space complexity of the proposed algorithm is O(dimX ·#{X} · N ) where dimX denotes the dimension of the input space, #{X} the amount of training samples and N the amount of neurons of the map. In order to show the correctness we have to judge two properties of the resulting SOM. First of all we have to measure how well the weight vectors have adapted the training vector space. That measure, called quantization error, is defined as N x − wk . x∈X k=1

Secondarily we have to measure the topographic preservation of the grid in which the neurons are aligned. Such feature can be quantified using the topographic product (see [3]). We may accept the MapReduce SOM algorithm to be sound if those two figures behave as observed in other experiments. As both figures represent a tradeoff between each other we further expect one measure to become better as the other one becomes worse.

Weichel

128 220 Quantization error over epoch

200

180

160

140

120

100

80

60

40

20 0

1

2

3

4

5

6

7

8

9

Topographic product over k and epoch

0.000102 0.000101 0.0001 9.9e-05 9.8e-05 9.7e-05 9.6e-05 9.5e-05 9.4e-05 9.3e-05 9 8 7 6 0

10

5 20

30

4 40

50

3 60

70

2 80

90

1 1000

Figure 2. Topographic product and quantization error of the Iris data set per epoch

To provide evidence of the correctness of the algorithm several experiments have been conducted. These experiments consist of applying the MapReduce SOM algorithm on a well defined data set and measuring the quality of the resulting SOM. A summary of quality measures can be found in [15] where we use those mentioned above. During the experiments three data sets have been trained: Iris taken from the UCI Machine Learning Repository [2], dimX = 4, #{X} = 150, N = 100. Plot depicted in fig. 2. Parkinson taken from the UCI Machine Learning Repository [2], dimX = 23, #{X} = 197, N = 144. Plot depicted in fig. 3. Square And artificial data set based on a Pareto distribution of the sample vectors. 80% are evenly distributed in [0; 5]20 while 20% are within

Adapting self-organizing maps to the MapReduce programming paradigm

129

18000 Quantization error over epoch

16000

14000

12000

10000

8000

6000

4000

2000

0 0

1

2

3

4

5

6

7

8

9

Topographic product over k and epoch

4.9e-05 4.88e-05 4.86e-05 4.84e-05 4.82e-05 4.8e-05 4.78e-05 4.76e-05 4.74e-05 4.72e-05 9 8 7 6 5

0 20

4

40

3

60 80

2 100 120

1 1400

Figure 3. Topographic product and quantization error of the Parkinson data set per epoch

2.5e + λ0.5e where e = {1}20 is the unity vector and 0 < λ ≤ 1. dimX = 20, #{X} = 2500, N = 440. Plot depicted in fig. 4.

All in all the algorithm behaves as required earlier, throughout the data sets. For the square data set, let us plot the topographic product over k per epoch next to the quantization error over the epoch (see fig. 4), we notice that the topographic product increases while the quantization error decreases. It is to be observed that the topographic product p is in [6.25 · 10−6 ; 6.6 · 10−6 ] for all the depicted epochs, hence close to zero which indicates good topographic perseverance (according to [15]).

Weichel

130 12000 Quantization error over epoch

11500

11000

10500

10000

9500

9000

8500

8000

7500 0

1

2

3

4

5

6

7

8

9

Topographic product over k and epoch

6.6e-06 6.55e-06 6.5e-06 6.45e-06 6.4e-06 6.35e-06 6.3e-06 6.25e-06 9 8 7 6 0

50

5 100

4 150

200

3 250

2 300

350

1 4000

Figure 4. Topographic product and quantization error of the Square data set per epoch

7

Conclusion

In this paper the two basic SOM algorithms have been presented. In chapter 4 we have introduced an adaption of the batch SOM algorithm to the MapReduce programming paradigm presented in chapter 3. The experiments conducted have given a certainty of the correctness of the proposed adaption and its implementation presented in this paper. As the MapReduce paradigm is especially suited for applications within a cloud computing context this adaption allows SOMs to be used in new fields of applications without the previously necessary infrastructure overhead.

Adapting self-organizing maps to the MapReduce programming paradigm

131

References [1] Hadoop web page, 12 2009. [2] A. Asuncion and D. Newman. UCI machine learning repository, 2007. [3] H.-U. Bauer and K. Pawelzik. Quantifying the neighborhood preservation of self-organizing feature maps. IEEE TRANSACTIONS ON NEURAL NETWORKS, 3(4):570–579, 1992. [4] A. Blazejewski and R. Coggins. Application of self-organizing maps to clustering of high-frequency financial data. In ACSW Frontiers ’04: Proceedings of the second workshop on Australasian information security, Data Mining and Web Intelligence, and Software Internationalisation, pages 85–90, Darlinghurst, Australia, Australia, 2004. Australian Computer Society, Inc. [5] C. V. Buhusi. Parallel implementation of self-organizing neural networks. In V. Felea and G. Ciobanu, editors, Romanian Symposium on Computer Science. 9th Symposium, ROSYCS’93. Proceedings, pages 51–8, Iasi, Romania, 1993. Institute for Comput. Sci., Acad. of Sci., Lasi, Romania, Univ. Al.I. Cuza. [6] J. Dean and S. Ghemawat. Mapreduce: simplified data processing on large clusters. Commun. ACM, 51(1):107–113, 2008. [7] H. G. Kayacik and A. N. Zincir-Heywood. Using self-organizing maps to build an attack map for forensic analysis. In PST ’06: Proceedings of the 2006 International Conference on Privacy, Security and Trust, pages 1–8, New York, NY, USA, 2006. ACM. [8] T. Kohonen. The self-organizing map. Proceedings of the IEEE, 78(9):1464– 1480, Sep 1990. [9] T. Kohonen. Things you haven’t heard about the self-organizing map. In Neural Networks, 1993., IEEE International Conference on, pages 1147–1156 vol.3, 1993. [10] T. Kohonen, S. Kaski, K. Lagus, J. Salojarvi, J. Honkela, V. Paatero, and A. Saarela. Self organization of a massive document collection. Neural Networks, IEEE Transactions on, 11(3):574–585, May 2000. [11] T. Kohonen, E. Oja, O. Simula, A. Visa, and J. Kangas. Engineering applications of the self-organizing map. Proceedings of the IEEE, 84(10):1358–1384, Oct 1996. [12] P. Koikkalainen. Progress with the tree-structured self-organizing map. In A. G. Cohn, editor, Proc. ECAI’94, 11th European Conf. on Artificial Intelligence, pages 211–215, New York, 1994. John Wiley & Sons. [13] R. Lawrence, G. Almasi, and H. Rushmeier. A scalable parallel algorithm for self-organizing maps with applications to sparse data mining problems. Data Mining and Knowledge Discovery, 3(2):171–195, June 1999. [14] P. Lehtim¨aki and K. Raivio. A SOM based approach for visualization of GSM network performance data. In Innovations in Applied Artificial Intelligence, volume 3533 of Lecture Notes in Computer Science, pages 588–598. Springer Berlin / Heidelberg, 2005. [15] G. P¨olzlbauer. Survey and comparison of quality measures for self-organizing maps. 2008. [16] A. Ultsch. U*-matrix: a tool to visualize clusters in high dimensional data. Technical Report 36, Philipps-University Marburg, Germany, 2003.

SOAP kritisch betrachtet Jens Lauble, Holger Staudacher Fakult¨at Informatik, Hochschule Furtwangen Robert-Gerwig-Platz 1, 78120 Furtwangen, Germany {j.lauble, h.staudacher}@hs-furtwangen.de

Zusammenfassung: SOAP stellt einen Standard f¨ur den Nachrichten-

austausch von Systemen u¨ ber das World Wide Web dar. Dabei erfreut sich das Protokoll großer Beliebtheit, besonders im Zusammenhang mit Web-Services. Hervorstechende Merkmale von SOAP sind die Interoperabilit¨at, Erweiterbarkeit, lose Protokollbindung und die Tool-Unterst¨utzung. Diese Vorteile werden in der einschl¨agigen Literatur ausf¨uhrlich behandelt. Die vorliegende Arbeit beleuchtet SOAP von der gegen¨uberliegenden Seite. Das heißt, es wird ein kritischer Blick auf das Protokoll geworfen und die Probleme, die SOAP mit sich bringt, genauer betrachtet. Dabei wird der Schwerpunkt auf Probleme der Kategorien Konzeption und Adaptierbarkeit gelegt. Hierbei wird festgestellt, dass SOAP gravierende M¨angel in den behandelten Kategorien aufweist. Ein Beispiel hierf¨ur ist das fehlende, standardisierte Logging-Konzept von SOAP. Um Transaktionssicherheit zu gew¨ahrleisten muss ein Log erstellt werden, wenn dieses allerdings u¨ ber diverse SOAP-Intermediaries geschickt wird entsteht schnell ein aufgebl¨ahter Header-Bereich, der eine SOAP-Nachricht u¨ berproportional wachsen l¨asst.

1

Einfuhrung ¨

Wenn die Anforderung besteht, Nachrichten zwischen Systemen auszutauschen werden Protokolle ben¨otigt. Die g¨angisten Standards im World Wide Web stellen TCP/IP mit HTTP dar. Jedoch ist die Form einer HTTP-Nachricht nicht eindeutig, da der HTTP-Body mit beliebigem Text gef¨ullt werden kann. Somit ist es sehr schwer oder nahezu unm¨oglich, beliebige HTTP-Nachrichten automatisiert zu verarbeiten. Zu diesem Zweck entstand SOAP. SOAP stand urspr¨unglich f¨ur Simple Object Access Protokoll. Heute steht SOAP allerdings als Akronym ohne Bedeutung. Die erste Version von SOAP wurde von Don Box (Microsoft) entwickelt und wurde zu Beginn nur m¨aßig akzeptiert. Jedoch

134

Lauble, Staudacher

a¨ nderte sich dies im Laufe der zeit und SOAP erfreute sich schnell wachsender Beliebtheit. Bereits in Version 1.0 wurde SOAP zum W3C-Standard erkl¨art und bis heute in Version 1.2 fortgef¨uhrt. Die genaue Entstehenungsgeschichte beschreibt Bayer in [5]. Eine der Hauptaufgaben von SOAP besteht darin, ein Nachrichtenformat zu definieren welches automatisiert verarbeitet werden kann. Dabei baut SOAP auf anderen Protokollen auf, z. B. HTTP und verwendet stark andere Standards wie z. B. XML f¨ur die Nachrichtenrepr¨asentation. Abbildung 1 stellt den Aufbau einer SOAP-Nachricht grafisch dar. Jede SOAP-

Abbildung 1. Aufbau einer SOAP-Nachricht, entnommen von [8]

Nachricht verwendet einen Umschlag (Envelope) in dem sich zwei Nachrichtenteile befinden. Zum einen der SOAP-Header und zum anderen der SOAPBody. Der Header beinhaltet Meta-Informationen die die Nachricht betreffen. Dies k¨onnen z. B. Informationen sein, um nicht funktionale Anforderungen zu erf¨ullen. Der Header ist somit von der Applikationslogik losgel¨ost. Der Inhalt des Bodies ist rein applikations-spezifisch, d. h. hier wird die eigentliche Nachricht eingef¨ugt. Eine genaue Beschreibung von SOAP geben Mitra und Lafon in [17]. Verwendet wird SOAP haupts¨achlich in Verbindung mit WebServices. Dabei sind die Merkmale von SOAP auch entscheidende Merkmale von WebServices. Die wohl hervorstechendsten Eigenschaften von SOAP sind: • Interoperabilit¨at: Wegen der starken Verwendung von Standards wie z. B. HTTP und XML k¨onnen SOAP-Nachrichten auf nahezu jedem System ausgewertet werden. Da SOAP selbst einen offenen Standard darstellt existieren auch viele Implementierungen der eigentlichen Verarbeitungs-Engine. Mit diesen k¨onnen SOAP-Nachrichten erzeugt bzw.

SOAP kritisch betrachtet

135

verarbeitet werden. Da die Spezifikation auch die Form der Nachrichten vorschreibt, k¨onnen SOAP-Nachrichten system¨ubergreifend verarbeitet werden. • Protokollbindung: Die SOAP-Spezifikation schreibt die Bindung an HTTP nicht vor. Vielmehr steht es dem Entwickler frei, bestimmte Protokollbindungen zu nutzen. So kann SOAP bspw. auch an Java Message Service (JMS) oder andere Transportprotokolle gebunden werden. ¨ • Tool-Unterstutzung: Die Tool-Unterst¨utzung f¨ur SOAP und WebServices existiert beinahe f¨ur jede Programmiersprache. Dies r¨uhrt vor allem daher, weil SOAP standardisiert ist. Sergeant beschreibt in [23] eine Reihe von unterst¨utzten Sprachen, die allerdings mittlerweile ihre Vollst¨andigkeit einbußen musste. Neben den eben aufgef¨uhrten Vorteilen von SOAP existieren noch weitere. Horn beschreibt in [13] z. B. die Offenheit, Robustheit, Skalierbarkeit und Plattformunabh¨angigkeit, die an dieser Stelle jedoch nicht von Belang sind. Neben den Vorteilen die SOAP bietet, existieren auch Nachteile die nur selten erw¨ahnt werden. An dieser Stelle setzt die vorliegende Arbeit an. Dabei wird SOAP kritisch betrachtet und explizit auf die Nachteile des Protokolls eingegangen. Die vorliegende Arbeit ist dabei nach folgender Struktur aufgebaut. Als erstes werden in Kapitel 2 verwandte Arbeiten vorgestellt und mit der vorliegenden Arbeit in Verbindung gebracht. Nachfolgend werden in Kapitel 3 konzeptionelle Kritikpunkte ausgef¨uhrt, die z. B. semantische Br¨uche nach sich ziehen. Anschließend wird die Adaptierbarkeit von SOAP in Kapitel 4 n¨aher betrachtet. Hierf¨ur werden Anforderungen aus der Praxis und deren Zusammenspiel mit SOAP untersucht. Zu guter Letzt wird in Kapitel 5 die vorliegende Arbeit zusammengefasst und ein Ausblick gegeben, inwieweit die aufgedeckten Kritikpunkte der Arbeit in zuk¨unftige SOAP-Versionen einfließen k¨onnten.

2

Verwandte Arbeiten

Probleme, die das SOAP-Protokoll mit sich bringt, werden in der Literatur meist nur teilweise betrachtet. So gibt Sergeant in [23] als einzigster einen ¨ allgemeinen Uberblick u¨ ber Vor- bzw. Nachteile von SOAP. Jedoch ist die Beschreibung sehr d¨urftig ausgef¨uhrt und mittlerweile veraltet. Auch u¨ berwiegen in Sergeants Material die Vorteile von SOAP. Die vorliegende Arbeit greift zwei Ans¨atze von Sergeant auf und f¨uhrt diese ausf¨uhrlich aus. Diese sind der konzeptionelle Bruch der HTTP-Semantik (siehe Kapitel 3.1) und das Logging (siehe Kapitel 4.1).

Lauble, Staudacher

136

Andere Arbeiten besch¨aftigen sich haupts¨achlich mit Problemen der Performance oder der Entwicklung. So vergleichen Elfwing et al. unter [8] die Performance des SOAP-Protokolles mit der Middleware-Technologie CORBA. In Bezug auf die Abbildung zwischen XML und anwendungsspezifischen Daten zeigen Wei Jun et al. unter [15], die in diesem Zusammenhang auftretenden Schwierigkeiten. AbuGhazaleh et al. f¨uhren in [2] und [3] die Nachteile der Serialisierung und Deserialisierung (Parsen) auf. Weitere Probleme hinsichtlich des Parsens der XML-basierenden SOAP-Nachrichten werden von Takase und Taijama unter [24] beschrieben. Die Probleme bei der Entwicklung wurden in verschiedenen Arbeiten behandelt. So beschreibt Mitschang in [18] Probleme die im Zusammenhang mit der Erlernbarkeit von SOAP zu anderen Technologien bestehen. Des Weiteren besch¨aftigt sich Degenring in [6] mit Interoperabilit¨atsproblemen die im Zusammenhang mit der Nutzung verschiedener Implementierung stehen. Die vorliegende Arbeit besch¨aftigt sich vor allem mit konzeptionellen Problemen und Problemen der Adaptierbarkeit. Dabei werden unter anderem Ideen von Sergeant aufgegriffen und genauer ausgef¨uhrt. Diese Ideen sind in seiner Arbeit unter [23] nur sp¨arlich beschrieben und zusammenhangslos dargestellt. Des Weiteren werden eigene Ideen vorgestellt, die die eben aufgef¨uhrten Problematiken weiter ausf¨uhren. Im Bereich des Konzeptionellen werden Themen wie SOAP in Verbindung mit Sessions, Thin-Clients oder HTTPS detailliert beschrieben. In dem Gebiet der Adaptierbarkeit wird genauer auf Logging und die Erweiterbarkeit von SOAP eingegangen.

3

Konzeptionelles

Die Kommunikation mittels SOAP erfolgt u¨ ber so genannte Knoten. Ein Knoten kann dabei als eigenst¨andige Recheneinheit angesehen werden. Eine SOAP-Nachricht kann bis zur entg¨ultigen Verarbeitung u¨ ber mehrere Knoten versendet und weitergeleitet werden. Somit entsteht ein Pfad, den die Nachricht zur¨ucklegt, der auch als SOAP-Nachrichtenpfad bekannt ist. Dabei f¨uhren Gudgin et al. in [10] drei Rollen f¨ur die einzelnen Knoten ein. Ein Knoten kann gleichzeitig mehrere Rollen einnehmen. Diese definierten Rollen sind: • Initial Sender: Der Initial Sender erzeugt eine SOAP-Nachricht und versendet diese an einen Ultimate Receiver oder an einen Intermediary. Somit stellt der dieser den Beginn eines SOAP-Nachrichtenpfades dar. • Ultimate Receiver: Diese Rolle stellt den endg¨ultigen Bestimmungsort einer SOAP-Nachricht dar. Von diesem wird die Nachricht nicht weitergeleitet und somit verarbeitet. Der Ultimate Receiver stellt das Ende

SOAP kritisch betrachtet

137

des SOAP-Nachrichtenpfades dar. Auch ist in [10] spezifiziert, dass eine Nachricht den Ultimate Receiver in jedem Fall erreichen muss. • Intermediary: Der Intermediary agiert sozusagen als Umschlagplatz f¨ur SOAP-Nachrichten. Eine Nachricht kann auf ihrem Weg von dem Initial Sender zum Ultimate Receiver n Knoten passieren. Diese Knoten benennt die SOAP-Spezifikation Intermediary. Ein Intermediary verarbeitet bei dem Empfang einer SOAP-Nachricht Teile von dieser. Dabei wird lediglich der Header einer Nachricht ver- bzw. bearbeitet. Der SOAP-Body ist ausschließlich f¨ur den Ultimate Receiver bestimmt. Damit ein Knoten die eben aufgef¨uhrten Rollen einnehmen kann, ben¨otigt dieser die Funktionalit¨at um SOAP-Nachrichten zu erzeugen, zu versenden, weiterzuleiten und zu verarbeiten. Diese Funktionalit¨at wird in Form eines SOAP-Prozessors, auch bekannt als SOAP-Enginge, bereitgestellt. Verschiedene SOAP-Prozessoren versenden SOAP-Nachrichten, indem sie existierende Transportprotokolle nutzen, so z. B. HTTP. Das folgende Kapitel behandelt Nachteile und Fehler, die auf Grund des SOAP-Konzepts entstehen. Dabei wird ein besonderes Augenmerk auf semantische Br¨uche gelegt.

3.1

Bruch der HTTP-Semantik

Ein Vorteil bei dem Nachrichtenaustausch u¨ ber SOAP, ist die Tatsache, dass SOAP nicht an das darunter liegende Protokoll gekoppelt ist. Dies beschreiben Mitra und Lafon ausf¨uhrlich in [17]. Diese lose Kopplung zu den darunter liegenden Protokollen bringen eine Reihe von Vorteilen hervor, die klar f¨ur SOAP sprechen. So ist es z. B. m¨oglich HTTP (Hypertext Transfer Protocol) als Transportprotokoll zu nutzen. Das bedeutet, dass SOAP-Nachrichten u¨ ber einen normalen HTTP-Kanal verschickt und empfangen werden k¨onnen. Da HTTP immer synchron kommuniziert, muss auch die SOAP-Kommunikation dar¨uber synchron erfolgen. Andere Protokolle k¨onnen benutzt werden, um beispielsweise asynchrone Kommunikation zu realisieren. Kandidaten f¨ur dieses Szenario sind z. B. SMTP (Simple Mail Transfer Protocol) oder JMS (Java Message Service). Weitere Protokolle k¨onnen, solange ein SOAP-Binding m¨oglich ist, ebenfalls genutzt werden. Wenn SOAP an Transportprotokolle gebunden wird, besitzt es die gleichen Vor- bzw. Nachteile des Transportprotokolls. Das bedeutet, falls SOAP z. B. an JMS gebunden wird, kann damit asynchron kommuniziert werden. Der entscheidende Nachteil der jedoch entsteht ist, dass die SOAP-Nachrichten nicht interoperabel sind, da JMS auf die JavaWelt beschr¨ankt ist. Nicht zuletzt aus diesem Grund wird SOAP bevorzugt an HTTP gebunden. Hiermit ist ein wichtiges Merkmal einer SOA, n¨amlich

138

Lauble, Staudacher

die Interoperabilit¨at der Nachrichten, gew¨ahrleistet. HTTP ist auf den meisten Plattformen nahezu vollst¨andig implementiert. Des Weiteren besitzen die meisten Programmiersprachen Frameworks um u¨ ber HTTP zu kommunizieren. Somit beschreiben auch Gudgin et al. in [11] die Bindung von SOAP an HTTP. Wenn man diese Bindung und deren Semantik der von HTTP, wie sie von Fielding et. al. in [20] beschrieben ist, gegen¨uber stellt, so erkennt man, dass die SOAP-Bindung Unterschiede zur Spezifikation des HTTP-Messaging aufweist. Fielding et al. spezifizieren acht Methoden f¨ur HTTP. Die vier h¨aufigst verwendeten werden nachstehend erl¨autert: • GET: Die GET-Methode sollte benutzt werden, um Informationen anzufordern. Dabei ist mit Information jegliche Art von Ressource gemeint. Eine GET-Anfrage enth¨alt keinen HTTP-BODY und wird rein u¨ ber den HTTP-HEADER definiert. Die Antwort eines Kommunikationspartners erfolgt als Inhalt im HTTP-BODY. HTTP spezifiziert ebenfalls die Methode HEAD, diese ist in ihrer Bedeutung mit HTTP-GET gleichzusetzen. Der Unterschied besteht darin, dass die Antwort des Kommunikationspartners nicht im HTTP-BODY erfolgen muss. • POST: Die POST-Methode wurde eingef¨uhrt, um Ressourcen zu beeinflussen. Hierf¨ur werden anders als bei GET schon w¨ahrend der Anfrage Inhalt im HTTP-BODY u¨ bertragen. Wenn POST als Methode genutzt wird, muss die angefragte Ressource die u¨ bertragenen Informationen verarbeiten. Der Kommunikationspartner kann entweder eine Antwort im HTTP-BODY senden oder eine reine HTTP-HEADER-Antwort, die aussagen soll, dass kein wieterer Inhalt als Antwort vorliegt. • PUT: Bei der PUT-Methode werden ebenfalls wie bei POST, Daten schon w¨ahrend der Anfrage im HTTP-BODY u¨ bertragen. Das Benutzen der PUT-Methode soll den Angefragten anweisen, eine Entit¨at auf der angefragten Ressource zu persistieren. • DELETE: Die Bedeutung der DELETE-Methode ergibt sich bereits aus der Benamung. So muss ein Kommunikationspartner die angefragte Ressource l¨oschen. Um SOAP mit einer Protokoll-Funktionalit¨at zu verkn¨upfen, wird das SOAP Web-Method Feature genutzt. Gudgin et al. spezifizieren in [11] lediglich zwei Properties, die SOAP-Funktionalit¨at an HTTP-GET und HTTP-POST binden. Weitere Properties f¨ur HTTP-PUT, HTTP-DELETE etc. werden nicht spezifiziert und k¨onnen somit auch nicht als Anfragemethoden verwendet werden.

SOAP kritisch betrachtet

139

Dies ist ein klarer Bruch der HTTP-Semantik, welcher sich an folgendem Szenario erl¨autern l¨asst: Gegeben sei ein SOAP-Web-Service der f¨ur das L¨oschen einer Entit¨at verantwortlich ist. Dieser definiert eine Methode genannt dele” teRessource“. Im HTTP-Sinn w¨are nun, dass ein Client eine HTTP-DELETEAnfrage stellt, welche den Angefragten anweist, die angegebenen Ressource zu l¨oschen. Der SOAP-Web-Service kann eine solche Anfrage allerdings nicht entgegen nehmen, da HTTP-DELETE nicht von SOAP unterst¨utzt wird. Somit muss der Client eine SOAP-Nachricht definieren, die die angefragte Methode aufruft und den Identifizierer der Ressource als Parameter u¨ bergeben. Versendet wird eine solche Nachricht meist als HTTP-POST-Anfrage. Wie bereits aufgef¨uhrt wurde ist die Aufgabe von HTTP-POST nicht das L¨oschen von Ressourcen, vielmehr soll es verwendet werden um Informationen zu verarbeiten und evtl. neue Ressourcen zu erstellen. Komplement¨ar verh¨alt sich solch ein Szenario auch zu anderen HTTP-Methoden. Ein weiterer Bruch der HTTP-Semantik ist nicht auf die SOAP-Spezifikation zur¨uckzuf¨uhren, sondern vielmehr auf Implementierungen dieser. Viele Implementierung nutzen HTTP-POST exzessiv. Das heißt, dass selbst f¨ur Anfragen die zur reinen Informationsbeschaffung dienen, HTTP-POST verwendet wird. So wird z. B. f¨ur eine Anfrage an eine Web-Service-Methode, genannt getIn” formation“ die lediglich Daten abfragen soll, eine POST-Nachricht definiert. F¨ur solch einen Zweck ist allerdings HTTP-GET gedacht. Dieser Bruch r¨uhrt vor allem daher, da SOAP nicht ressourcenorientiert ist. Ressourcen werden nicht eindeutig u¨ ber eine URI (Uniform Ressource Identifier) identifiziert und m¨ussen mittels Parametern identifiziert werden. Aus den vorangegangenen Ausf¨uhrungen l¨asst sich schließen, dass SOAP, HTTP wegen seiner Verbreitung nutzt und nicht wegen seiner Semantik. Aus diesem Grund l¨asst sich sagen, dass SOAP das Potenzial von HTTP nicht ausnutzt. Dies liegt wohl eher an der spezifizierten Bindung an HTTP als an SOAP selbst. Jedoch a¨ ndert dies nicht die Bedeutung des semantischen Bruches. Diese ist folgende: Ein Entwickler kann die Funktionalit¨at von HTTP nicht voll nutzen und ist auf die zwei spezifizierten SOAP-HTTP-Methoden angewiesen. Mit wachsender Verbreitung von SOAP wird HTTP somit verst¨ummelt“ und ” das Web an sich verliert zwangl¨aufig an Semantik.

3.2

Sessions

Unter einer Session innerhalb einer Client-Server-Umgebung versteht man das Halten eines Status auf der Server-Seite u¨ ber mehrere Client-Aufrufe hinweg. Um solch ein Szenario zu realisieren, werden Mechanismen ben¨otigt, die den Status an einen Client binden. Dies kann erfolgen, indem z. B. der Client bei jedem Aufruf eine eindeutige Session-ID u¨ bertr¨agt. Anhand dieser ID

140

Lauble, Staudacher

k¨onnte der Server den ben¨otigten Zustand identifizieren. Auf diese Art realisiert z. B. die Programmierpsrache PHP das Session-Prinzip, wie es in [25] von Wenz und Hauser beschrieben ist. Auf weitere Arten, wie ein Session-Konzept realisiert werden kann, wird an dieser Stelle nicht n¨aher eingegangen. Der Einsatzbereich von Sessions ist vielf¨altig. So existieren Szenarien in der Praxis, bei denen der Status eines Clients ben¨otigt wird. So z. B. bei Banking-, zugrangsbeschr¨ankten- und Multi-User-Awendungen. Im Gegensatz zu Sessions steht die Zustandslosigkeit, welche ein Prinzip von Service-orientierten Architekturen (SOA) ist. SOAP wird gerne in Verbindung mit Service-orientierten Architekturen gebracht weil es f¨ur den Einsatz in solch einer Umgebung pr¨adestiniert ist. Allerdings ist SOAP nicht auf SOAs beschr¨ankt und war auch vor der Verbreitung dieser schon verf¨ugbar. Erl beschreibt in [9] die Zustandslosigkeit wie folgt: Ein zustandsloser Dienst beh¨alt keinerlei Nachrichten-Kontext beim Versenden einer Nachricht und u¨ bergibt die volle Kontrolle u¨ ber die Nachricht an den Empf¨anger. Somit darf streng genommen keinerlei Status u¨ ber mehrere Dienstaufrufe gehalten werden. Dies widerspricht jedoch den Anforderungen aus den oben beschriebenen Szenarien. Mitra und Lafon beschrieben in [17] keinerlei Konzept um Sessions mittels SOAP zu realisieren. Aus diesem Grund haben es sich einige Anbieter von SOAP-Prozessoren zur Aufgabe gemacht, eigene Konzepte zu entwickeln, wie z. B. das Axis2-Session-Konzept welches von Jayasinghe in [14] beschrieben wird. Dabei realisiert Axis2 mehrere Arten von Sessions, unter anderem SOAP-Sessions die nachfolgend erl¨autert werden. Das Grundprinzip der SOAP-Sessions ist das Gleiche wie bei PHP-Sessions, die bereits weiter oben beschrieben wurden. Der Service-Konsument sendet bei der Anfrage ein zus¨atzliches SOAP-Header-Attribut mit, welches eine Referenz des Zustands darstellt. Des Weiteren muss das Benutzen einer SOAPSession bekannt gemacht werden. Aus diesem Grund muss die Dienstbeschreibung, welche als WSDL-Dokument realisiert ist, angepasst werden. Hierf¨ur wird dem service-Element ein zus¨atzliches Attribut names scope hinzugef¨ugt, welches den Wert soapsession enth¨alt. Somit erm¨oglicht Axis2 ein voll funktionsf¨ahiges Session-Konzept, welches mit dem SOAP-Protokoll harmoniert. Aus einem anderen Licht betrachtet, stellen die verschiedenen Session-Konzepte der Anbieter allerdings einen Bruch wichtiger service-orientierter Prinzipien dar. Wie bereits erw¨ahnt brechen Sessions das Konzept der Zustandslosigkeit, dieser Bruch ist allerdings notwendig um Anforderungen bestimmter Dom¨anen zu erf¨ullen. Ein weiteres wichtiges Prinzip welches gebrochen wird, ist die Interoperabilit¨at. Die Interoperabilit¨at gilt als Markenzeichen von SOAP, da es technologieunabh¨angig verwendet werden kann. Wird allerdings ein Session-Konzept verwendet, wie es z. B. von Axis2 realisiert ist, so ist

SOAP kritisch betrachtet

141

eine SOAP-Nachricht nicht l¨anger interoperabel. Dies ergibt sich aus dem Fakt, dass zus¨atzliche SOAP-Header-Attribute eingef¨uhrt werden, die lediglich von dem Axis2 SOAP-Prozessor verarbeitet werden k¨onnen. Weitere SOAPProzessoren k¨onnen diese Attribute nicht verarbeiten und werden vermutlich Fehlermeldungen erzeugen. Somit kann eine SOAP-Nachricht nicht l¨anger als technologie-unabh¨angig angesehen werden. Neben der Interoperabilit¨at wird wegen dem Benutzen von SOAP-Sessions, im Axis2-Sinn, das Prinzip der losen Kopplung verletzt. Rederlechner beschreibt in [21] mehrere Merkmale der losen Kopplung. Als ein wichtiges Merkmal sieht er die Trennung von Service-Vertr¨agen und Service-Implementierung. Wenn man dieses Merkmal aufgreift, so kann man es auch als die Losl¨osung des Service-Vertrags und der SOAP-Prozessor Implementierung sehen. Da f¨ur die Benutzung von Axis2-SOAP-Sessions allerdings der Service-Vertrag be¨ arbeitet werden muss und dort Axis2 spezifische Anderungen vorgenommen werden, wird der Vertrag an die Axis2-Implementierung gebunden. Wegen dieser Bindung an die Implementierung, wird die lose Kopplung verletzt. Die Ursache dieser Br¨uche liegt nicht bei den SOAP-Prozessor-Anbietern, da diese lediglich auf Anforderungen aus der Praxis reagieren. Vielmehr ist es ein Verschulden der SOAP-Spezifikation, da diese kein Session-Konzept beschreibt noch standardisiert.

3.3

Thin-Clients

Wenn sich eine Schwachstelle innerhalb eines SOAP-Nachrichtenpfades befindet, so sind diese die sog. Thin-Clients. Wie Hill in [12] beschreibt, realisiert ein Thin-Client die strikte Trennung von Pr¨asentations- und Logik-Schicht einer Anwendung. Das bedeutet, dass ein Thin-Client lediglich f¨ur die Darstellung einer Anwendung zust¨andig ist. Als Beispiel eines Thin-Clients kann ein Web-Browser angesehen werden. In diesem werden, in aller Regel, WebAnwendungen lediglich dargestellt. Da Thin-Clients ausschließlich in verteilten Umgebungen existieren, ben¨otigen diese eine Funktionalit¨at, um entfernte Aufrufe durchzuf¨uhren. Hierf¨ur wird in der Praxis auch SOAP als NachrichtenProtokoll verwendet. Somit verwundert es nicht, dass SOAP-Prozessor-Implementierungen auch f¨ur Thin-Clients existieren. So z. B. die Implementierung JSSC welche den Web-Browser in Form einer JavaScript Implementierung um SOAP-Funktionalit¨at anreichert. JSSC wird ausf¨uhrlich in [1] beschrieben. Mittels dieser Funktionalit¨at wird der Thin-Client zu einem Knoten innerhalb des SOAP-Nachrichtenpfades. Das Problem, welches sich aus dieser Tatsache ergibt ist folgendes: Laut Gudgin et al. in [10] sollte ein SOAP-Knoten die Rollen des Initial Sender, Ultimate Receiver und Intermediary annehmen k¨onnen. Wenn ein Thin-Client allerdings z. B. die Rolle eines Intermediary an-

Lauble, Staudacher

142

nimmt, so agiert dieser neben seiner T¨atigkeit als Client auch als Server. Dies stellt einen Bruch der Thin-Client-Semantik dar, weil der Client nicht l¨anger f¨ur die reine Darstellung verantwortlich ist und gleichzeitig weitere Aufgaben annimmt. Die Folgen dieses Bruches sind vermutlich unter anderem Performance-Einbußen, da ein Thin-Client meist nicht f¨ur die Lasten eines Servers ausgelegt ist. Auch sind viele SOAP-Prozessor Implementierungen f¨ur Thin-Clients keine vollwertigen SOAP-Prozessoren, da bei vielen Implementierungen lediglich die Rolle des Initial Senders realisiert ist.

3.4

HTTPS

Um Nachrichten u¨ ber HTTP sicher zu u¨ bertragen, wird in den meisten F¨allen HTTPS, wobei das S“ ein Akronym f¨ur secure“ ist, genutzt. Da eine HTTP” ” Nachricht komplett textbasiert ist, wird bei HTTPS der gesamte NachrichtenBody verschl¨usselt. Zur Verschl¨usselung nutzt HTTPS den Algorithmus Trans” port Layer Security“ oder kurz TLS, welcher als eine Weiterentwicklung von dem Secure Socket Layer“ (SSL) gilt. TLS ist ein Algorithmus, der eine ” asymmetrische Verschl¨usselung verwendet um einen symmetrischen Schl¨ussel zu u¨ bertragen. Dies ist notwendig, damit ein Client und Server denselben symmetrischen Schl¨ussel kennen und somit Nachrichten symmetrisch ver- bzw. entschl¨usseln k¨onnen. Dieses Verfahren zum Schl¨usselaustausch nennt man TLS-Handshake und beschr¨ankt TLS somit auf genau zwei Parteien. Eine genaue Ausf¨uhrung wie HTTPS funktioniert gibt Rescorla in [22]. Abbildung 2 zeigt die einzelnen Schritte eines TLS-Handshakes. Diese Schritte werden ausf¨uhrlich in [7] von Dolsch erkl¨art. An dieser Stelle z¨ahlt lediglich die Anzahl der ben¨otigten Schritte bis zu einer erfolgreichen Verschl¨usselung. Wie in Abbildung 2 zu sehen ist, werden 13 Nachrichten ben¨otigt bis ein Handshake durchgef¨uhrt wurde und eine symmetrsiche Verschl¨usselung verwendet werden kann. Da HTTPS auf HTTP aufsetzt und SOAP an HTTP gebunden werden kann, kann dies auch an HTTPS gebunden werden. In der Praxis existieren weitere Technologien zur Sicherung von SOAP-Nachrichten wie z. B. WS-Security ¨ mit XML-Encryption, jedoch wird h¨aufig HTTPS f¨ur die sichere Ubertragung verwendet. Wenn SOAP allerdings HTTPS verwendet, kann dies Folgen f¨ur die Performance und Semantik von SOAP haben. Dies kann am besten an Folgendem Szenario verdeutlicht werden: Gegeben sei eine SOAP-Nachricht die u¨ ber drei Intermediaries an den Ultimate Receiver gesendet wird. Da es die Aufgabe von Intermediaries ist SOAP-Header zu verarbeiten m¨ussen diese von den Knoten gelesen werden k¨onnen. Da TLS allerdings die gesamte Nachricht verschl¨usselt m¨ussen diese den symmetrischen Schl¨ussel kennen.

SOAP kritisch betrachtet

143

Abbildung 2. Ablauf eines TLS-Handshakes, entnommen von [7]

Bekannt gemacht wird dieser Schl¨ussel mittels des TLS-Handshakes. Somit m¨ussen der Initial Sender und die Intermediaries untereinander Handshakes durchf¨uhren. Da 13 Nachrichten f¨ur einen Handshake ben¨otigt werden, werden somit 52 HTTP-Nachrichten mehr ben¨otigt um eine SOAP-Nachricht zu versenden. Wenn diese zus¨atzlichen Handshakes nicht durchgef¨uhrt werden kann ein Intermediary die SOAP-Header nicht verarbeiten da er den symmetrisches Schl¨ussel nicht kennt. Dies bricht die Semantik von SOAP-Nachrichten da diese besagt, dass ein Intermediary SOAP-Header verarbeiten k¨onnen muss. Somit kann gesagt werden, dass SOAP nicht ohne Performanceeinbußen (weil jeder Intermediary ver- und entschl¨usseln muss) oder einem semantischen Bruch zusammen mit HTTPS verwendet werden kann.

4

Adaptierbarkeit

Unter der Adaptierbarkeit von SOAP wird an dieser Stelle die Anwendbarkeit des Protokolls in der Praxis gemeint. In den folgenden Unterkapiteln werden Anwendungszenarien und Anforderungen betrachtet, bei deren Erf¨ullung das SOAP-Nachrichtenprotokoll in Betracht gezogen werden k¨onnte. Diese Anforderungen sind: • Logging-F¨ahigkeit • Erweiterbarkeit

Lauble, Staudacher

144

Nachfolgend werden diese genauer betrachtet und SOAP anhand derer kritisiert.

4.1

Logging

Logging, oder Protokollierung, steht in der Informatik f¨ur das Aufzeichnen von Aktionen. Diese Aktionen k¨onnen z. B. Ereignisse sein, die w¨ahrend des Betriebs einer Anwendung geschehen. Auf nicht verteilten Systemen erfolgt das Logging meist in einer lokalen Datei oder Datenbank. Dabei existieren verschiedene Logging-Mechanismen die von Accorsi in [4] ausf¨uhrlich beschrieben werden. Der Aufgabenbereich des Loggings geht von Fehlerfindung bis hin zur Transaktionsunterst¨utzung. Bei Transaktionen ist das Logging von einer besonderen Bedeutung, da diese die ACID-Regel befolgen m¨ussen. Das bedeutet, dass wenn eine Transaktion scheitert, ein Rollback ausgef¨uhrt werden muss. Hierf¨ur muss nachvollziehbar sein, welche Schritte bis zum Fehlschlag ausgef¨uhrt wurden. Das genaue Prinzip des Loggings bei Transaktionen erkl¨art Kemper und Eickler in [16]. SOAP unterst¨utzt standardm¨aßig keinerlei M¨oglichkeiten Ereignisse zu loggen. Aus diesem Grund beschreiben Mitra und Lafon in [17] keinerlei standardisierten Mechanismus, der eine Logging-Funktion definiert. Dabei w¨are eine solche Funktion auf Protokollebene durchaus w¨unschenswert. Mit einer eingebauten Logging-Funktion k¨onnen Aktionen knoten¨ubergreifend innerhalb eines SOAP-Nachrichtenpfades protokolliert und verarbeitet werden. Dies w¨are durchaus n¨utzlich, wenn es z. B. um das Thema verteilte Transaktionen geht, da somit ein Log-Shipping auf Protokollebene erfolgen k¨onnte. Eine pr¨adestinierte Stelle hierf¨ur w¨are der SOAP-Header. Dieser Teilbereich kann von jedem Knoten eines SOAP-Nachrichtenpfades verarbeitet werden. Somit k¨onnte jeder beteiligte Knoten Aktionen in einem daf¨ur zust¨andigen Header-Attribut protokollieren. Um solch ein Szenario zu realisieren, w¨are es denkbar, neben den Header-Attributen role, mustUnderstand und relay, ein weiteres Attribut zu standardisieren. Dieses Attribut k¨onnte z. B. mit mustLog betitelt werden und einen Knoten dazu auffordern die durchgef¨uhrten Aktionen zu protokollieren. Somit kann gesagt werden, dass ein Logging-Szenario zumindest theoretisch f¨ur SOAP m¨oglich w¨are. Jedoch w¨urde mit einem Logging auf Protokollebene ein entscheidender Nachteil entstehen. Jedes Ereignis m¨usste als XML-Element gelogt werden, weil SOAP XML-basiert ist. Somit w¨urde mit der Granularit¨at des Loggings die Nachrichtengr¨oße proportional anwachsen. Dies w¨urde einen Overhead der Nachrichten erzeugen, da diese somit einen u¨ berdimensionalen Meta-Bereich, den SOAP-Header, besitzen und nur noch einen geringen Nachrichtenteil, den SOAP-Body.

SOAP kritisch betrachtet

4.2

145

Erweiterbarkeit

SOAP bietet die M¨oglichkeit stark erweitert zu werden. Zu diesem Zweck beschreiben Gudgin et al. in [10] das SOAP-Feature. Unter dem SOAP-Feature versteht man eine Erweiterung des SOAP-Nachrichten-Frameworks. Diese Erweiterungen k¨onnen unz¨ahlige Themengebiete abdecken, wie z. B. Zuverl¨assigkeit, Sicherheit oder Routing. Vor allem was nicht funktionale Anforderungen angeht, existieren eine Menge SOAP-Features. Damit ein SOAP-Prozessor eine Erweiterung des Protokolls verarbeiten kann, muss er die Erweiterung verstehen. Damit die Interoperabilit¨at einer Erweiterung gew¨ahrleistet ist, haben sich die WS-*-Spezifikationen entwickelt, wobei das WS f¨ur Web-Services und das * f¨ur den Erweiterungsnamen steht. Diese Spezifikationen beschreiben dabei, inwieweit SOAP erweitert wird, und wie diese Erweiterung von einem SOAP-Prozessor zu verarbeiten ist. Einige dieser Spezifikationen wurden bereits Standardisiert. Standardisierungskomitees sind unter anderem die W3C oder OASIS. An der Art und Weise wie SOAP erweitert wird, gibt es keine Kritik die ge¨ubt werden kann. Vielmehr kann an dem Verfahren, wie solche Erweiterungen standardisiert werden, Kritik ge¨ubt werden. So sind, um Interoperabilit¨at zu gew¨ahrleisten, bei einer Standardisierung viele Interessensgemeinschaften beteiligt. Diese Gemeinschaften sind vor allem Unternehmen die Technologie anbieten wie beispielsweise Microsoft, IBM, Tibco usw.. Klar ist auch, das jede Gemeinschaft eigene Interessen in den Standard mit einbringen m¨ochte um eigene Entwicklungen zu verbreiten. Wegen dieser Tatsache werden WS*-Standards oft als aufgebl¨aht und unbenutzbar angesehen. Ein weiterer Nachteil an dieser Art der Standardisierung sind die verschiedenen Komitees. Dies kann am besten an der Erweiterung WS-Reliability ausgef¨uhrt werden. WS-Reliability ist eine Erweiterung, die die Zuverl¨assigkeit der SOAP-Nachrichtenzustellung gew¨ahrleistet. Dabei wurde die Spezifikation von OASIS 2004 zum Standard erkl¨art. Diese Standardisierung wurde jedoch von zwei Parteien nicht unterst¨utzt, diese sind IBM und Microsoft. Diese Parteien entwickelten eine eigene Spezifikation, genannt WS-ReliableMessaging, welche das gleiche Ziel wie WS-Reliability verfolgt. Der Grund f¨ur die Verweigerung von WS-Reliability ist dessen Unabgestimmtheit zu den u¨ brigen WS-*-Spezifikationen. So kann es bei Verwendung von WS-Reliability geschehen, dass andere Erweiterungen nicht korrekt arbeiten. Nichtsdestotrotz sind diese beiden Erweiterung als konkurrierend anzusehen und k¨onnen nicht zusammen verwendet werden. Wie bei den vorgestellten Erweiterung f¨ur den Bereich Zuverl¨assigkeit existieren noch weitere konkurrierende Erweiterungen auf die allerdings an dieser Stelle nicht n¨aher eingegangen wird.

Lauble, Staudacher

146

Die Freiheit, SOAP auf solch eine Art zu erweitern hat dazu gef¨uhrt, dass es mittlerweile eine un¨uberschaubare Anzahl an Erweiterungen in Form von WS-*-Spezifikationen gibt. Dieses Manko haben auch Industriegr¨oßen erkannt und sich zu einem Konsortium zusammengetan, welches es sich zur Aufgabe gemacht hat, WS-*-Spezifikationen und Standards zu vereinheitlichen um die Interoperabilit¨at nicht zu gef¨ahrden. Dieses Konsortium nennt sich WSInteroperability, oder kurz WS-I, und setzt sich aus Unternehmen wie Microsoft, IBM, Tibco, SAP usw. zusammen. Dabei kreiert WS-I keine Standards sondern erstellt Profile die interoperabel sind. Profile sind Kombinationen von Erweiterungen die problemlos zusammen arbeiten und sich nicht einschr¨anken. Eine genauere Beschreibung der Aufgaben von WS-I ist unter [26] zu finden. Aus der Entfernung betracht ist die WS-I eine gute Sache um Interoperabilit¨at zu gew¨ahrleisten. Die Tatsache allerdings, dass die WS-I notwendig ist stellt einen Hohn dar. Denn Standardisierung bedeutet Vereinheitlichung. Wenn Standards vereinheitlicht werden m¨ussen, so k¨onnen diese keine Standards sein. Dies l¨asst vor allem auf eines schließen: Die Art wie Erweiterungen f¨ur SOAP in Form von WS-*-Spezifikation standardisiert werden ist mangelhaft.

5

Resumee ¨

Das nachfolgende Kapitel fasst die vorliegende Arbeit zusammen und gibt einen Ausblick dar¨uber, inwieweit die mit dem SOAP-Protokoll verbundenen Probleme weiter vertieft werden k¨onnen.

5.1

Zusammenfassung

Das Ziel dieser Arbeit war es Nachteile des SOAP-Protokolles aufzudecken. Um diese analysieren zu k¨onnen wurden in den vergangenen Kapitel verschiedene Themengebiete wie die Adaptierbarkeit und Konzeptionelles betrachtet. So konnte anhand dieser Themengebiet untersucht werden, inwieweit diese von SOAP beeinflusst werden. Dabei stellte sich heraus, dass SOAP in so gut wie allen betrachteten Themengebieten Nachteile aufweist. Besonders schwerwiegende Probleme weist SOAP dabei in der Verwendung von anderen Technologien auf. So bricht es z. B. die HTTP-Semantik oder ist ungeeignet f¨ur eine Kommunikation u¨ ber HTTPS. Des Weiteren existiert kein eingebauter Logging-Mechanismus und die Standardisierung von Erweiterungen ist fehlerbehaftet. Zusammengefasst l¨asst sich sagen, dass SOAP mit Bedacht f¨ur einen Einsatz gew¨ahlt werden

SOAP kritisch betrachtet

147

sollte, da die viel verbreiteten Vorteile des Protokolls auch gravierende Nachteile aufweisen.

5.2

Ausblick

Die in dieser Arbeit aufgef¨uhrte Kritik an dem SOAP-Protokoll deckt zum gr¨oßten Teil behebbare Probleme auf. Zu den behebbaren Problemen geh¨oren z. B. die konzeptionellen Probleme oder die Probleme der Adaptierbarkeit. So k¨onnten in zuk¨unftigen SOAP-Versionen einige Probleme behoben werden, z. B. k¨onnte die Spezifikation ein Logging-Konzept einf¨uhren oder es k¨onnte die fehlerhafte Bindung an HTTP beseitigt werden. Eines ist jedoch in jedem Fall sicher. Mit der Behebung der Probleme werden Inkonsitenzen zu ¨ a¨ lteren SOAP-Versionen entstehen, da die Anderungen am Kern in der SOAPSpezifikation vorgenommen werden m¨ussen. Somit ist evtl. ein gr¨oßerer Ver¨ sionsprung notwendig um die Bedeutung der Anderungen zu unterstreichen. Abschließend l¨asst sich sagen, das SOAP keinesfalls als Optimall¨osung angesehen werden darf. Lediglich die weite Verbreitung f¨ordert die allgemein positive Meinung des Protokolls. Hierbei werden allerdings meist die Nachteile ausgelassen, obwohl diese, wie die vorliegende Arbeit gezeigt hat, durchaus Gewicht haben. M¨ogliche Alternativen existieren bereits und sind auch f¨ur den Produktiveinsatz geeignet. Beispielhaft f¨ur eine Alternative ist REST, die von Monson-Haefel in [19] beschrieben wird.

Literatur [1] What’s javascript soap client? Website, December 2007. Available online at http://www.codeplex.com/JavaScriptSoapClient; visited on December 7th 2009. [2] N. Abu-Ghazaleh and M. J. Lewis. Differential deserialization for optimized soap performance. In SC ’05: Proceedings of the 2005 ACM/IEEE conference on Supercomputing, page 21, Washington, DC, USA, 2005. IEEE Computer Society. [3] N. Abu-Ghazaleh, M. J. Lewis, and M. Govindaraju. Differential serialization for optimized soap performance. In HPDC ’04: Proceedings of the 13th IEEE International Symposium on High Performance Distributed Computing, pages 55–64, Washington, DC, USA, 2004. IEEE Computer Society. [4] R. Accorsi. Towards a secure logging mechanism for dynamic systems. AlbertLudwigs-Universit¨at Freiburg, 2005. [5] T. Bayer. Vergleich von soap, xml-rpc und rest. Orientation in Objects GmbH, August 2003. [6] A. Degenring. Integration eines sas servers in soap-basierte web service umgebungen. Master’s thesis, FernUniversit¨at Hagen, 2003. [7] P. Dosch. Transportsicherheit ssl tls, https. Seminararbeit University of applied Science N¨urnberg, Juni 2006.

148

Lauble, Staudacher

[8] R. Elfwing, U. Paulsson, and L. Lundberg. Performance of soap in web service environment compared to corba. In Software Engineering Conference, 2002. Ninth Asia-Pacific, pages 84–93, 2002. [9] T. Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River, August 2005. [10] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Morea, H. F. Nielsen, A. Karmarkar, and Y. Lafon. Soap version 1.2 part 1: Messaging framework (second edition). W3C Recommendation, April 2007. [11] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. F. Nielsen, A. Karmarkar, and Y. Lafon. Soap version 1.2 part 2: Adjuncts (second edition). W3C Recommendation, April 2007. [12] D. Hill. Thin client oder smart client: Architektur der darstellungsschicht. Website, April 2005. Available online at http://msdn.microsoft.com/ de-de/library/aa480039.aspx; visited on November 30th 2009. [13] T. Horn. Web services mit soap, wsdl, uddi. Website, 2007. Available online at http://www.torsten-horn.de/techdocs/soap.htm; visited on December 17th 2009. [14] D. Jayasinghe. Axis2 session management. Website, July 2006. Available online at www.developer.com//article.php/3620661; visited on November 30th 2009. [15] W. Jun, H. Lei, and N. Chunlei. Speed-up soap processing by data mapping template. In SOSE ’06: Proceedings of the 2006 international workshop on Serviceoriented software engineering, pages 40–46, New York, NY, USA, 2006. ACM. [16] A. Kemper and A. Eickler. Datenbanksysteme: Eine Einf¨uhrung. Oldenbourg, Berlin, 7 edition, April 2009. [17] N. Mitra and Y. Lafon. Soap version 1.2 part 0: Primer (second edition). W3C Recommendation, April 2007. [18] J. Mitschang. Web applications mit soap und rss, 2005. Available online at http://mitschang.net/download/webapplications.pdf; visited on December 10th 2009. [19] R. Monson-Haefel. Rest: An interesting alternative to soap/wsdl. Website, Juni 2002. Available online at http://www.oreillynet.com/xml/blog/ 2002/06/rest_an_interesting_alternativ.html; visited on March 16th 2010. [20] E. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. BernersLee, E. Y. Lafon, and E. J. Reschke. Http/1.1, part 2: Message semantics. HTTPbis Working Group, October 2009. [21] B. Rederlechner. Soa-services: Lose kopplung in der praxis. JAVA Magazine, September 2008. [22] E. Rescorla. Http over tls. Network Working Group, May 2000. [23] M. Sergeant. Why soap sucks, why soap rocks. O’Reilly Open Source Convention, July 2002. [24] T. Takase and K. Tajima. Lazy xml parsing/serialization based on literal and dom hybrid representation. In Web Services, 2008. ICWS ’08. IEEE International Conference on, pages 295–303, Sept. 2008. [25] C. Wenz and T. Hauser. PHP5. Markt und Technik, M¨unchen, 2005.

SOAP kritisch betrachtet

149

[26] WS-I. About ws-i. Website. Available online at http://www.ws-i.org/ about/Default.aspx; visited on December 16th 2009.

Machbarkeitsuntersuchung eines Requirements Lifecycle auf Basis von Microsoft Team System Christopher Martel Fakultät Informatik Hochschule Furtwangen Robert Gerwig Platz 1 78120 Furtwangen [email protected]

Zusammenfassung: Innerhalb des Unternehmens Lexware wird Microsoft Team System als zentrale Entwicklungsplattform eingesetzt. Mittels dieser Plattform werden bereits Tasks und Bugs verwaltet. Dennoch existiert keine Integration des Requirements Engineering und Management in Team System. In diesem Beitrag soll dargestellt werden, inwieweit Microsoft Team System als RM&E System eingesetzt werden kann. Hierzu wird ein Prozess und eine prototypische Erweiterung vorgestellt, welche die Machbarkeit des RM&E auf Basis von Team System demonstriert.

1

Einleitung

In früheren Zeiten wurde Software mittels einfachster Methodik entwickelt. Diese war meist auf einen Anwendungsbereich zugeschnitten und entsprach durch ihre geringe Komplexität den Anforderungen der Anwender. Jedoch nahmen die Anforderungen zu, das System wurde somit komplexer und meist konnte man mit den bisherigen Methoden keine zuverlässige und den Anforderungen des Anwenders entsprechende Software garantieren. Aus diesem Grund wurde das Prinzip des Requirements Engineering und Management geschaffen. Hierzu werden heutzutage in den Unternehmen entsprechende Requirements-Management-Systeme eingesetzt, von denen es verschiedene Ausprägungen gibt. Innerhalb des Unternehmens Lexware wird bereits Microsoft Team System als Application Lifecycle Management-System eingesetzt. Mittels des Systems werden Tasks und Bugs verwaltet. Jedoch existiert noch keine Requirements Engineering und Management Unterstützung. Team System selbst bietet keine Unterstützung in der bisherigen Version 2008. Da Team System im Unternehmen eine zentrale Verwaltungsplattform für den Entwicklungsprozess darstellt und da Anforderungen durchgehend in allen Entwicklungsphasen als Grundlage dienen, soll in diesem Beitrag gezeigt

Martel

152

werden, inwieweit Requirements Engineering und Management mit Microsoft Team System möglich ist. Das Unternehmen Lexware, dessen Sitz in Freiburg ist, ist der führende Anbieter kaufmännischer Software für kleine und mittelständische Unternehmen [1]. Aufgrund der Unterstützung mehrerer verschiedener Produkte ist es notwendig, eine einheitliche Speicherschnittstelle zu definieren, mittels dieser alle notwendigen Daten, wie Dokumente und Anforderungen, aber auch Quellcode, verwaltet werden können. Eine bisherige Herausforderung stellt der bisher wenig unterstützte Requirements Engineering-Prozess für diese Problemstellung dar. Dieser soll nun durch die in diesem Beitrag erarbeiteten Ergebnisse verbessert werden.

2

Requirements Engineering und Management

Eine Anforderung (Requirement) ist „eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird“ [2]. Um Anforderungen eindeutig zu beschreiben und um allen Beteiligten das gleiche Verständnis für das System zu gewährleisten, müssen diese den Qualitätsansprüchen genügen. Nach [2] müssen Anforderungen z.B. vollständig, korrekt, abgestimmt, klassifizierbar, konsistent, widerspruchsfrei, prüfbar, eindeutig, verständlich, gültig und aktuell, realisierbar, notwendig, verfolgbar und bewertet sein.

2.1 Requirements Engineering Requirements Engineering ist ein Prozess, der sich mit der Erfassung, Analyse, Dokumentation, Validierung und Verifikation von Anforderungen befasst (siehe Abbildung 1). Zur Erhebung von Anforderungen werden beispielsweise Fragebogen verwendet. Die Dokumentation der Anforderungen erfolgt sowohl in textueller, als auch graphischer Form mittels Use Cases und weiteren UMLModellen. Eine Überprüfung von Anforderungen wird entsprechend gegen die Anforderungsspezifikation durchgeführt.

Machbarkeitsuntersuchung eines Requirements Lifecycle

153

Abbildung 1: Tätigkeiten und Methoden des Requirements-Engineerings [2]

2.2 Requirements Management Requirements Management befasst sich mit der Verwaltung von Anforderungen. Grundlegend definiert es den Austausch von Informationen, bei der Anforderungen sowie die zugehörigen Dokumentationen zentral für alle zugänglich verwaltet werden (siehe Abbildung 2) Zur Steuerung der Abläufe, zur Verwaltung innerer Zusammenhänge und zur Projektsteuerung ist es wichtig, Anforderungen sowie Änderungen jederzeit nachvollziehen zu können (Traceability). Requirements Management ist dann besonders von Bedeutung, wenn Änderungen verwaltet und nachvollzogen werden müssen.

Abbildung 2: Kernaktivitäten des Requirements Managements [2]

Martel

154

Im Unternehmen Lexware stellt sich das Requirements Engineering und Management als Herausforderung dar. Bisher werden Anforderungen in verschiedenen Dokumenten erfasst. Ein erster Ansatz zur Lösung wurde durch das Tool HP Quality Center geschaffen. Jedoch wird das Tool nicht von allen Abteilungen eingesetzt und ist hauptsächlich zur Analyse der Testabdeckung gedacht.

3

Der RM&E Prozess

Als erster Schritt zur besseren Unterstützung des Requirements Engineering wurde ein Prozessmodell entwickelt, das als Grundlage für den im nächsten Kapitel beschriebenen Prototyp diente. Abbildung 3 gibt einen Überblick über dieses Modell.

Abbildung 3: Das RM&E Prozessmodell

Das Prozessmodell zeigt zum einen die Aufteilung der Verantwortlichkeiten für die Erfassung, Analyse, Verwaltung, Implementierung und Validierung von Anforderungen durch entsprechende Phasen- sowie durch eine entsprechende Gruppenaufteilung. Jede Gruppe setzt sich aus verschiedenen Projektbeteiligten, beispielsweise dem Kunden, dem Produktmanagement und dem Requirements Engineer, zusammen, um allen Beteiligten in jeder Phase von Beginn an dasselbe Verständnis für die Anforderungen und für das zu entwickelnde System zu garantieren. Zum anderen wird der allgemeine Workflow gezeigt, bei dem mittels des zu neue RM&E-Tools Anforderungen erfasst, kategorisiert und analysiert werden müssen.

Machbarkeitsuntersuchung eines Requirements Lifecycle

155

In der Requirements Eliciation Phase werden sowohl unterschiedliche Anforderungen als auch Change Requests erfasst und Anforderungen überarbeitet, die den Qualitätskriterien nicht entsprechen. In der Requirements Review Phase werden die Anforderungen entsprechend gegen die definierten Qualitätskriterien geprüft. Es wird entschieden, ob die Anforderung implementiert werden kann oder überarbeitet werden muss. In den Implementierungs- und Validierungsphasen werden die Anforderungen entsprechend umgesetzt und getestet. Im Vergleich zum bisherigen Vorgehen wird damit die Qualität des Prozesses gesteigert und der Aufwand sowie die Kosten zur Entwicklung reduziert. 3.1

Zustandsautomat einer Anforderung

Mittels eines definierten Zustandsautomaten für Anforderungen kann jederzeit der Umsetzungsstatus von Anforderungen nachvollzogen werden (siehe Abbildung 4). Grundlegend befindet sich eine Anforderung bei der Erfassung im Zustand Active. Sollte sich herausstellen, dass die Anforderung verworfen wird oder bereits existiert, wird der Status auf Completed gesetzt. Solange eine Anforderung sowie ihre „Kind-Anforderungen“ nicht erfolgreich geprüft wurden, befinden sie sich im Status In Revision. Sollte eine Anforderung nicht den Qualitätskriterien entsprechen, muss diese nochmals überarbeitet und detailliert werden. Eine erfolgreiche Überprüfung wird mit dem Status Reviewed gekennzeichnet. Alle Anforderungen, die diesen Status als Grundlage definieren, können anschließend implementiert, getestet und somit erfolgreich verabschiedet werden.

Martel

156

Abbildung 4: Zustandsautomat für Anforderungen

3.2

Unterstützung der Qualitätskriterien durch das SOPHISTRegelwerk

Durch den Einsatz des SOPHIST-Regelwerks in Form von Anforderungsschablonen werden die in Kapitel 2 aufgeführten Qualitätskriterien unterstützt. Abbildung 5 zeigt die Grundstruktur der Anforderungsschablonen.

Abbildung 5: Grundstruktur der SOPHIST-Anforderungsschablonen [2]

Die Struktur definiert drei verschiedene Aktivitäten. x

Selbstständige Systemaktivität

Machbarkeitsuntersuchung eines Requirements Lifecycle

x

Benutzerinteraktion

x

Schnittstellenanforderung

157

Dieses Regelwerk wurde deshalb zur Anforderungsbeschreibung übernommen. Die Anforderungen können so widerspruchsfrei und eindeutig dokumentiert und dadurch von allen Beteiligten auf gleiche Weise interpretiert werden. Dies stellt zusätzlich zum definierten Prozessmodell und dem Zustandsautomaten eine weitere qualitative Verbesserung des RM&E dar. 3.3

Vergleich der RM&E-Prozesse

Vergleicht man nun abschließend sowohl den bisherigen Requirements Engineering und Management Prozess des Unternehmens mit dem in diesem Kapitel vorgestellten Prozess, kann festgestellt werden, dass der neue Vorschlag zusätzliche Vorteile bietet. Der bisherige Prozess verbindet einen dokumentenbasierten mit einem Objekt Tracking-Ansatz. „Dadurch verweilen Business Analysten in ihrer bisherigen gewohnten Umgebung, dennoch fehlt die Darstellung der Granularität“ [3]. Durch den Objekt Tracking Ansatz des neuen Prozesses ist es einfacher, „Änderungen und Verknüpfungen von Anforderungen untereinander sowie mit Dokumenten zu dokumentieren und im Sinne der Traceability nachzuverfolgen“ [3]. Mit dem neuen Vorgehen werden Anforderungen in einem geordneten und strukturierten Ablauf erfasst, verwaltet und geprüft. Sämtliche Aktivitäten werden durch unterschiedliche Gruppen und nicht mehr nur durch eine Person durchgeführt. Es gab bisher keinen gemeinsamen Ablauf für das Requirements-Review. Durch das neue Vorgehen wird auch die Kategorisierung und Aufteilung der Anforderungen in Anforderungstypen ermöglicht. Durch das eingeführte Regelwerk zur Beschreibung von Anforderungen, werden die Qualitätsansprüche an eine Anforderung erfüllt und dadurch das gemeinsame Verständnis für die Anforderungen verbessert. Weiterhin ermöglicht das Vorgehen gegenüber dem alten Prozess eine grundlegende Wiederverwendung von Anforderungen in anderen Projekten. Dies war durch den bisherigen Prozess nicht möglich, da Anforderungen in unterschiedlichen Formen dokumentiert und erfasst wurden. Ein

Martel

158

einheitliches System mittels des Objekt Tracking Ansatzes ermöglicht die Verwendung einer Erfassungs- und Dokumentationsart und dadurch die bessere Wiederverwendung in anderen Projekten, was wiederum zu Zeitund Kosteneinsparungen führen kann. Zusammenfassend kann festgestellt werden, dass durch das vorgeschlagene neue Vorgehen die Qualität der Anforderungen gesteigert wird und dadurch Zeit und Kosten beim Requirements Engineering eingespart werden können. Anforderungen werden erst nach entsprechender Überprüfung freigegeben und garantieren dadurch eine bessere Umsetzbarkeit, Testbarkeit und Verwaltung.

4

LexRequirement Lösungsansatz

Manager

als

prototypischer

Durch die Entscheidung zur Erweiterung von Microsoft Team System [4], wurde ein Prototyp erstellt. Der Prototyp baut auf dem im vorherigen Kapitel definierten Prozessmodell auf und unterstützt das vorgeschlagene neue Vorgehen beim Requirements Engineering. 4.1

Übersicht über den Prototyp

Abbildung 6 zeigt eine Übersicht über den Prototyp und dessen Komponenten. Zur besseren Verständnis der Funktionalität wurden die Komponenten entsprechend mit Buchstaben gekennzeichnet. Anforderungen werden zunächst über einen Anforderungsbaum (B) hierarchisch erfasst. Zur Definition der Eigenschaften einer Anforderung, wird ein generisches Steuerelement – WorkItem Form Control – der Team System API verwendet (A). So kann beispielsweise jederzeit die Änderungshistorie sowie der Status und die Beschreibung der Anforderung geändert und eingesehen werden. Weiterhin existieren eigene Untermenüs sowohl zur Suche nach Anforderungen entsprechend bestimmter Kriterien (C), als auch zur Generierung von Dokumenten aus Anforderungen (D), der Anzeige von bestimmten Reports für das Projektmanagement (E), der Formattierung von Anforderungsbeschreibungen mittels eines Editors (Z.1), der Darstellung und Sortierung der Suchergebnisse nach bestimmten Kriterien (Z.2), dem Aufruf des Enterprise Architect zur Verwendung von UML (F)/(G) und der Erfassung von Anforderungsbeschreibung mittels Spracherkennung (Z.3). Abschließend existiert eine Synchronisationsschnittstelle zwischen Team System und HP Quality Center (H), um Anforderungen zu synchronisieren.

Machbarkeitsuntersuchung eines Requirements Lifecycle

159

Abbildung 9: Übersicht des Tools LexRequirement Manager

Ein weiterer Vorteil des Prototyps ist, dass keine zusätzlichen Lizenzkosten entstehen. 4.2

Umsetzung der von Team System nicht unterstützten Anforderungen

Die folgenden Anforderungen werden durch die Integration von Enterprise Architect umgesetzt: x x x x

Graphische Erfassung mittels UML Modelle Visuelle Darstellung der Anforderungen Verlinkung von Anforderungen durch UML-Diagrammen Generierung von Diagrammen aus Anforderungen

Das UML-Tool Enterprise Architect wird bereits im Unternehmen eingesetzt und muss somit nicht zusätzlich erworben werden. Weiterhin wird mittels des Plugins MDG Link eine Synchronisation der Anforderungen zwischen Team System und Enterprise Architect ermöglicht. So können Anforderungen mit UML-Diagrammen verlinkt und beispielsweise über ein Traceability-Diagramm dargestellt werden. Zusätzlich wird die grundlegende Generierung eines Use Case Diagramms innerhalb des Prototyps ermöglicht. Hierzu müssen die Anforderungen entsprechend den SOPHIST-Schablonen beschrieben werden.

Martel

160

Die Erstellung von Baselines wird durch das Iteration-Attribut im Eigenschaften-Dialog für Anforderungen des Prototyps unterstützt. Hierzu wird aus der Liste die entsprechende Iteration gewählt und gesetzt. Mittels Angabe einer Revisionsnummer im Kontextmenü einer Anforderung im Anforderungsbaum kann diese auf jene Nummer mit entsprechenden Eigenschaften zurückgesetzt werden. Somit kann ein Rollback von Änderungen unterstützt werden. Versionsvergleiche von Dokumenten sowie die automatische Synchronisation von Spezifikationen und Anforderungen werden teilweise durch die zugrundeliegende Sharepoint-Plattform unterstützt. Eine vollständige Unterstützung wäre technisch zu aufwändig gewesen. Vorlagen können entsprechend durch MS Word erstellt und innerhalb des Prototyps zur Generierung von Dokumenten aus Anforderungen importiert werden. Mit Hilfe des Prototyps können Anforderungen in ein MS Word Dokument exportiert werden. Zuvor werden die zu exportierenden Anforderungen mittels eines Filters bestimmt. Da der Prototyp mit C# und dem .NET Framework entwickelt wurde, kann nur eine Unterstützung von Microsoft Betriebssystem gewährleistet werden. Eine Plattformunabhängigkeit herzustellen ist somit nicht möglich. Da grundlegende Funktionen des Team Foundation Servers benötigt werden, kann eine Standalone-Variante sowie die Online/Offline-Synchronisation nicht unterstützt werden. Eine Unterstützung für den Import von Anforderungen aus Dokumenten und Spezifikationen wird im Prototyp nicht geboten, da eine technische Umsetzung zu aufwändig gewesen wäre. Grund dafür stellt unter anderem die uneinheitliche Struktur der vorhanden Anforderungsdokumente dar. Trotz einiger der nicht unterstützten Anforderungen konnte nachgewiesen werden, dass der Prototyp die meisten Anforderungen an ein RM&E-Tool unterstützt [5]. Es konnte zudem gezeigt werden, dass RM&E mit Microsoft Team System durch entsprechende Erweiterung möglich ist.

5

Zusammenfassung

Betrachtet man rückblickend das Requirements Engineering und Management mit Microsoft Team System, kann festgestellt werden, dass eine bisherige Unterstützung lediglich durch Tools von Drittanbietern besteht, die die Erweiterungsschnittstelle von Team System nutzen. Auf Basis einer Make-or-Buy Analyse wurde entschieden, ein eigenes Tool, das

Machbarkeitsuntersuchung eines Requirements Lifecycle

161

gleichermaßen die Erweiterungsschnittstelle von Team System nutzt, zu erstellen. Mittels dieses Prototyps konnte gezeigt werden, dass Requirements Management mit Microsoft Team System möglich ist. Zur Nutzung des Tools ist ein entsprechender Prozess notwendig, der im Rahmen dieses Neitrag kurz erläutert wurde. Dieser Prozess ermöglicht eine Qualitätssteigerung des RM&E gegenüber dem bisherigen Vorgehen im Unternehmen. Für die weitere Nutzung des Tools wird empfohlen, die Testabdeckung weiterhin in HP Quality Center durchzuführen und die durch das Tool ermittelten Anforderungen mit Quality Center zu synchronisieren. Weiterhin ist zu evaluieren, ob das Testmanagement mit Microsoft Team System 2010, das eine eigene Testumgebung beinhaltet, ebenfalls möglich ist und somit Quality Center für das Unternehmen entfallen kann. Dadurch würde die aufwändige Synchronisation nicht mehr benötigt werden, was entsprechende Zeiteinsparungen mit sich bringen würde.

Literatur [1]

Haufe-Lexware GmbH & Co. KG: Wir über uns, URL: http://www.lexware.de [Zugriff am 18.1.2010]

[2]

C. Rupp: Requirements Engineering und –Management, 5. Auflage, Carl Hanser Verlag München 2009.

[3]

Lange, Steve: Requirements Management in TFS. URL: http://blogs.msdn.com/slange/archive/2007/11/06/requirements-managementin-tfs-part-2-of-4-tfs-out-of-the-box.aspx [Zugriff am 18.1.2010]

[4]

Microsoft Corporation: Requirements Management and Visual Studio Team System, Whitepaper, September 2008, S. 23-27

[5]

Incose: Requirements Management Tools Survey. URL: http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx 18.1.2010]

[Zugriff

am