Systeme. Komponentenmodelle und Architekturkonzepte als Integrationsmittel Evolutionäre Entwicklung Methoden und Erfahrungen

Größe: px
Ab Seite anzeigen:

Download "Systeme. Komponentenmodelle und Architekturkonzepte als Integrationsmittel Evolutionäre Entwicklung Methoden und Erfahrungen"

Transkript

1 Gemeinsamer Workshop der Fachgruppen Objektorientierte Softwareentwicklung (OOSE), Software-Reengineering (SRE) und Software-Architekturen (SW-Arch) am 27. Oktober 2006 in Ladenburg In verschiedenen Fachgruppen der GI werden Themen bearbeitet, die sich berühren oder gar überlappen. Im Zuge der zunehmenden Spezialisierung der fachlichen Struktur der GI erschien es uns folgerichtig, die verschiedenen Communities in einer gemeinsamen Veranstaltung zusammenzuführen und Fachgruppenübergreifende Arbeiten anzustoßen. Deshalb waren die Themen zu diesem Workshop bewusst breit angelegt, und es wurden zugunsten von fokussierten Gruppendiskussionen nur relativ wenige Vorträge gehalten. Der Schwerpunkt lag auf gemeinsamen Themen der beteiligten Fachgruppen mit Bevorzugung aktueller Fragestellungen: Objektorientierte Architekturen in Industrie und Forschung Objektorientierte Architekturen im industriellen Umfeld - aktueller Stand und Trends Analyse und Visualisierung von Objektorientierten Systemen Architektur-Metriken und Bewertung Vorhersage von Performanz und Zuverlässigkeit Architektur-Refactoring Objektorientierten Methoden für Embedded Systems Service-orientierte Architekturen Neuentwicklung und Migration Modellgetriebene Software Entwicklung Erweiterung objektorientierter Ansätze durch generative, generische und aspektorientierte Programmierung Komponentenmodelle und Architekturkonzepte als Integrationsmittel Evolutionäre Entwicklung Methoden und Erfahrungen Evolutionäre Produktlinien-Entwicklung Aufrechterhaltung der Wartbarkeit objektorientierter Systeme Virtualisierung - Softwarelösungen für den Ersatz von alternder Hardware Beherrschung von unterschiedlichen Entwicklungszyklen von Hardware und Software Update, Upgrade und Migrationsprozesse von industriellen Anlagen und Komponenten Lebenszyklusberechnung und Risikoerfassung über Technologiewechsel hinweg Vorträge Nach Begutachtung wurden 6 volle Beiträge und ein Kurzbeitrag angenommen, die Sie auf den folgenden Seiten finden. Feature-orientierte Plattformentwicklung und Verfolgbarkeit Robert Brcina, Markus Prechtel, DaimlerChrysler AG Model-Driven Integration of Business Information Systems Niels Streekmann, Ulrike Steffens, Claus Möbus and Hilke Garbe, OFFIS / Uni Oldenburg Bäumchen wechsle Dich - Tücken beim automatischen Abgleich hierarchischer Objektstrukturen - Rainer Drath, ABB Verstehen und Nutzen der Eclipse WTP Architektur - Ein Erfahrungsbericht - Jürgen Rückert, Barbara Paech, Uni Heidelberg (Kurzbeitrag) Lernen aus dokumentierten Architektur- Entscheidungen - Andrea Herrmann, Barbara Paech, Uni Heidelberg OPC UA -- Service-oriented Architecture for Industrial Applications - Stefan-Helmut Leitner, Wolfgang Mahnke, ABB Entscheidungsprozess für rationale Architekturentscheidungen Sven Wohlfarth, TU Ilmenau Teilnehmerkreis Das Ziel eines gemeinsamen Forums für Wissenschaftler, Entwickler und Anwender aus Industrie und Forschung konnte erreicht werden, indem eine Zusammensetzung der Teilnehmer zu gleichen Teilen aus Industrie und Forschung erzielt wurde. Es nahmen insgesamt knapp 40 Personen teil. Fokussierte Gruppendiskussionen Für die anschließenden Gruppendiskussionen bildeten sich Gruppen für drei Themenschwerpunkte. Die Ergebnisse dieser Gruppen und die vereinbarten weiteren Aktivitäten seien hier kurz genannt. Interessenten für eine Mitarbeit in den Gruppen sind herzlich willkommen, bitte nehmen Sie einfach Kontakt auf. Die beiden Themen Integration heterogener Systeme Vor- und Nachteile von dienstorientierten Architekturen stießen auf großes Interesse, konnten wegen der Fokussierung der Gruppen aber nicht bearbeitet werden und wurden auf ein Folgetreffen verschoben.

2 Gruppe Traceability / Evolution Fragestellungen: Evolutionäre Entwicklung wie? Wie Features beschreiben? Traceability Wie / wie weit Modelle formalisieren? Wie / wie weit Anforderungen formalisieren? Architektur-Refactoring Gruppendiskussion: eher Themensammlung als Problemlösung Tracing o Angebot, Auschreibung, Spezifikation, Modell, Code, Testfälle o Typen von Traces o Zuverlässigkeit der Traces o History, Rationale Management Querying und Visualisieren von Anforderungen und Differenzen Tool Chains, Anpassung von Tools, externe Repositories Weitere Schritte: Gründung eines Arbeitskreises "Traceability / Evolution" in der FG OOSE Kontakt über Erstes Treffen am :00 Uhr TU Ilmenau im Raum EAZ 1336 gemeinsam mit AK MDA Gruppe Architekturentscheidungen, Vorhersage von Systemqualität Fragestellungen: Wie Entscheidungen treffen / bewerten? Vorhersage von Systemqualität, Metriken Gruppendiskussion: 1. Methoden der Vorhersage von Systemqualität Analyse von Prototypen Entwicklung eines Prototypen Szenariobasiert analysieren Analogieschlüsse Vergleich zwischen Architekturen Simulation, z.b. von Zeitbedarf Analytische Lösungen Transformation Architektur in formales Modell Analyse des Modells Messen über Metriken Empirische Metriken (messbar) Analytische Metriken (vorhersagbar, validierbar) Interne Metriken, z.b. Wartbarkeit, schlecht validierbar (abh. vom Programmierer) Externe Metriken, z.b. Performance, Zeit und Durchsatz gut validierbar Mehrdeutige Testauswertung (Performancetest bestanden?) Auswertung von Trends 2. Qualität der Vorhersage 3. Test einzelner Merkmale Security, z.b. Prototyp eines Portals Performance, z.b. Auswertung von Trends (Zeitverhalten ) Zuverlässigkeit, Validierung problematisch aufgrund Vielzahl an Testfällen Ausfallsicherheit 4. Klassen an Architekturentscheidungen Langfristige, Kurzfristige Strategische, Operative Riskante, Sichere Freiheitsgrade bei der Entscheidung (streng, offen) Gestufte Entscheidungen Technische / Plattformentscheidungen Fachliche / Politische Strukturscheidungen Weitere Schritte: Weiterer Kontakt über Arbeitskreis "Bewertung von SW-Architekturen" in der FG SW-Arch Gruppe Modelle Fragestellungen: Modelle für Modellbasierte Entwicklung Methoden und Modelle für Entwicklung von Systemen, eingebettete Systemen Wie / wie weit Modelle formalisieren? Gruppendiskussion: Modelle für Anforderungen Modelle für Simulation und Generierung der Lösung Rolle von Metamodellen als Brücke zwischen Modellen und zur Implementierung Weitere Schritte: Weiterer Kontakt per Fortsetzung Viele Teilnehmer äußerten den Wunsch nach einer Fortsetzung der fruchtbaren Gespräche, so dass über die vereinbarten Zusammenarbeit der Gruppen hinaus - weitere gemeinsame Workshops der Fachgruppen vorgesehen sind, möglicherweise im Rahmen der GI- Jahrestagung Zur guten Atmosphäre der Veranstaltung hat insbesondere die ansprechende Umgebung des ABB-Forschungszentums beigetragen, in dem wir dank der Unterstützung von Dr. Zeidler zu Gast waren. Offen für Interessenten Die drei oben angeführten Gruppen sind offen für weitere Beteiligte. Bei Interesse nehmen Sie bitte Kontakt direkt oder über die Fachgruppen auf. Informationen dazu sowie zu weiteren Veranstaltungen der beteiligten Fachgruppen finden sie auf den jeweiligen Webseiten, zu erreichen über: fachbereiche/softwaretechnik-swt/ M. Riebisch,

3 Feature-orientierte Plattformentwicklung und Verfolgbarkeit Robert Brcina, IT-Designers GmbH Markus Prechtel, DaimlerChrysler AG Abstrakt Der Gewinn durch Wiederverwendung bei der Softwareentwicklung ist ein wichtiger Aspekt für Unternehmen. Dieser wird oftmals anhand von Produktlinien- oder Plattformstrategien erhöht. Charakteristisch für solche Plattformansätze ist eine hohe Anzahl von Anforderungen, da unterschiedlichste Unternehmensanwendungen unterstützt werden müssen. Die Umsetzung der daraus abgeleiten Anforderungen an die Plattform erfordert ein intensives Management der Verfolgbarkeit. Häufig genutzt werden Feature- Modelle, welche die Verfolgbarkeit der Anforderungen und Features berücksichtigen. In diesen Modellen wird allerdings oftmals die Integration von Features in Plattformen als wichtiges Glied zwischen Kunden und Entwicklungsteam nicht berücksichtigt. In dieser Arbeit werden ein erweitertes Feature-Modell und ein Konzept zur Verfolgbarkeit eingeführt, welche die Integration von Plattformen berücksichtigen. Darin wird aufgezeigt, welche Beziehungen zwischen verschiedenen Ebenen des Entwicklungsprozesses bestehen und die Auswirkungen auf Entwicklung und Test werden erörtert. 1 Einführung Die Softwareentwicklung auf Basis einer Produktlinien- oder Plattformstrategie beruht darauf, dass in verschiedenen Applikationen auftretende gleiche Teile 1 in einer Plattform integriert werden. Daraus ergibt sich ein Gewinn durch eine erhöhte Wiederverwendung. Dadurch, dass nicht alle funktionalen Plattformteile in allen Applikationen Verwendung finden müssen, setzen die meisten Applikationen einen unterschiedlichen Satz an Plattformfunktionalitäten ein. Des Weiteren sehen sich die Entwicklungsteams mit der Aufgabe konfrontiert, dass sich ständig neue Kundenanforderungen ergeben, die in bereits bestehende Plattformen integriert werden müssen. Eine langfristige Auslegung der Plattformen ist zum einen wesentlich für eine erfolgreiche Umsetzung dieses Konzepts im Unternehmen, zum anderen wird dadurch der Wiederverwendungsgewinn maximiert. Folglich muss die Softwareentwicklung sehr flexibel auf Änderungen reagieren und dennoch 1 Hierbei denke man beispielsweise an die Benutzer- Authentifizierung, die bei allen geschützten Applikationen eines Unternehmens gleich ist. die Konsistenz und Abwärtskompatibilität zu vorherigen Auslieferungen gewährleisten. Dies ist nur dann möglich, wenn gewährleistet ist, dass die im Laufe der Zeit entstandenen Anforderungen und deren Implementierung verfolgt werden können. Ein generelles Verständnis für die Notwendigkeit der Verfolgbarkeit von Anforderungen ist allgemein vorhanden, siehe [RM94]. Häufig genutzt werden Feature-Modelle, welche die Verfolgbarkeit der Anforderungen und Features berücksichtigen. Features können in Ihrer Komplexität stark variieren, zum Beispiel haben Sie Auswirkungen auf eine oder mehrere Komponenten. Feature- Modelle unterstützen an dieser Stelle die Zuordnung zwischen Anforderungen, Features und Komponenten. Diese Zusammengehörigkeit wird mit Hilfe von Traceability-Links [JM02] erreicht. In diesen Modellen wird allerdings die Integration von Features in Plattformen nicht berücksichtigt. Gerade diese sind aber ein wichtiges Glied zwischen Kunden und Entwicklungsteam, da Sie eine Brücke bauen zwischen einer externen Sicht auf das ausgelieferte Produkt im Kontext des Features und einer internen komponenentenbasierten Sicht des Entwicklungsteams. Aus diesen Gründen wird hier ein erweitertes Feature-Modell, das Plattform-Feature-Modell, und ein Konzept zur Verfolgbarkeit eingeführt, in denen die Integration von Plattformen berücksichtigt wird. Darin spielen die Beziehungen zwischen verschiedenen Ebenen des Entwicklungsprozesses eine zentrale Rolle. Diese bilden die Grundlage für die Erörterung der Auswirkungen der Feature-orientierten Entwicklung von Plattformen auf Entwicklung und Test. Durchgehend erklärt wird das Konzept am Beispiel der PAI 2 Produkte der DaimlerChrysler AG, welche ein plattformbasiertes Infrastrukturkonzept umsetzen. Zuerst wird in Kapitel 2 eine Einordnung der verwandten Begriffe gegeben. Anschließend wird das plattformbasierte Feature-Modell in Kapitel 3 erläutert und am Beispiel von PAI veranschaulicht. Das Feature-orientierte Verfolgbarkeitskonzept wird in Kapitel 4 erklärt und die Auswirkungen der Feature-orientierten Sichtweise auf den Test in Kapitel 5 vertieft. Es folgt in Kapitel 6 eine Zusammenfassung und ein Ausblick. 2 PAI Proaktive Infrastruktur

4 2 Einordnung der Begriffe 2.1 Plattformen In den meisten Fällen werden unter Plattformen die Hardware-Basis eines Computersystems, ein Betriebssystem und grundlegende Softwareprodukte oder eine Kombination dieser Elemente verstanden. Für uns ist der Begriff wie folgt definiert: Eine Plattform ist eine wiederverwendbare Basis an Technologien, Diensten und Realisierungen von Prozessen, auf denen aufbauend weitere Technologien, Dienste, Realisierungen von Prozessen und Anwendungen entwickelt werden können. Eine Plattform ist grundlegend so entworfen, dass ihre Dienste auch von sehr unterschiedlichen Softwareprodukten in Anspruch genommen und mit ihnen sehr unterschiedliche Anwendungen entworfen werden können. Die Plattformfunktionalität können die Anwender als gegeben ansehen und in den meisten Fällen dadurch schneller und kostengünstiger entwickeln. Andererseits sind sie durch die Vorgabe der Plattform eingeschränkt in der Architektur seiner Applikation. 2.2 Software Produktlinie Mit dem Begriff der Produktlinie verbindet man Produkte, die in einer Fabrik entlang einer langen Linie hergestellt werden, wobei je nach Anforderung verschiedenartige Produkte entstehen, die aber größtenteils auf der gleichen Basis aufgebaut sind. Diese Vorgehensweise lässt sich auch auf Software Produktlinien übertragen. Im Vordergrund seht, dass es Elemente gibt, Core Assets, die in allen Produkten gleich sind und davon abgeleitete Elemente, die nicht in jedem Produkt enthalten sind und je nach Kundenanforderung eingesetzt werden. Letztendlich kann der Kunde aus einer Menge von variablen Elementen innerhalb einer vordefinierten Domäne wählen [CNN01]. Pohl [PBvdL05] definiert den Begriff Software Product Line Engineering wie folgt: Software product line engineering is a paradigm to develop software applications [...] using platforms and mass customisation. Die Softwareplattform bildet eine Grundlage für die Entwicklung von Applikationen, indem sie einige Komponenten zusammenfasst und somit die Domäne der Produktlinie definiert. Dabei gibt es immer Anteile, die in allen Anwendungen der Produktlinie enthalten sind und variable Anteile. Die Produktlinie wird regelmäßig durch neue Anforderungen der Kunden innerhalb der Domäne erweitert und sie muss sich zusätzlich den Veränderungen der Domäne anpassen. 2.3 PAI und PAI Plattformen Die Proaktive Infrastruktur ist eine globale Initiative innerhalb der DaimlerChrysler AG und hat das Ziel, eine gemeinsame IT-Infrastruktur für Applikationsprojekte zur Verfügung zu stellen. PAI besteht aus mehreren Produktplattformen, die periodisch weiterentwickelt werden. Sie bilden die infrastrukturelle Basis nicht nur für großangelegte Unternehmensanwendungen. Dadurch ist es möglich, dass sich PAI Kunden, verschiedene Abteilungen und Teams innerhalb der DaimlerChrysler AG, stärker auf die Applikationsentwicklung fokusieren können. Wie in Abbildung 1 abgebildet, ergibt sich durch PAI eine klare Schicht von Plattformen, auf die Applikationen aufbauen können. Applika- tionen Portal Kompo- nente X App- Server Ohne PAI Applika- tionen Kompo- nente Y App- Server Hardware & OS Erweiterte Infrastrukturbasis Applika- tionen J2EE Zielsituation Portal Applika- tionen Directory und Security Hardware & OS Process Integration Business Info Broker Abbildung 1: The PAI approach [Rei04] links ohne, rechts mit PAI Die einzelnen PAI Plattformen entstehen durch die Integration verschiedener kommerzieller Basisprodukte. Um dies zu realisieren wird Glue Code in Form von Systemkomponenten entwickelt. Gemäß der Definition von Pohl [PBvdL05] in Kapitel 2.2 kann man einige Parallelen zwischen PAI und Produktlinien ziehen, wobei man eine PAI Plattform nicht einer Produktlinienplattform gleichsetzen kann. Auch auf einer anderen Ebene zeigen die PAI Plattformen einen gewissen Produktliniencharakter, da sie aus einer Menge an Komponenten bestehen, die zum Teil von verschiedenen Plattformen gemeinsam genutzt werden. Diese Core Assests wiederum können ebenfalls als Produktlinienplattform angesehen werden. Die Entwicklung der PAI Plattformen beginnt mit der Definition von Features, die aus den Anforderungen abgleitet werden. Dabei werden sowohl Anforderungen von Anwendern als auch Standards und Konventionen innerhalb der DaimlerChrysler AG berücksichtigt. Dadurch ergibt sich eine wichtige Rolle des Requirements Engineerings und Managements, das die Wünsche der verschiedenen Interessengruppen konsolidieren und in der Definition der Features umsetzen muss. Diese bilden die Grundlage für die Weiterentwicklung der Plattform. 3 Plattform-Feature-Modell Der Begriff Feature wird je nach Kontext verschiedenartig verwendet. Im Kontext der PAI Plattform wird ein Feature folgendermaßen definiert: Ein Feature beinhaltet funktionale oder nicht-funktionale Leistungen des Systems, die gemäß den konsolidierten Anforderungen umgesetzt werden. Ein wichtiges Merkmal eines

5 Features ist die architekturelle Einordnung in eine oder mehrere Plattformen. In Abbildung 2 ist die Einordnung eines Features beispielhaft gezeigt 3. Dabei ist ersichtlich, dass Anforderungen zu ein oder mehreren Featuren abgebildet werden und in den entsprechenden Plattformen eingeordnet sind. Daraus ergeben sich verschiedene Featuretypen. Es gibt einen festen Anteil von Komponenten, die allen Plattformen enthalten sein müssen und damit einen Core Set von Komponenten definieren. Die einzelnen Plattformen sind somit ebenso wie die darauf aufbauenden Applikationen in einen variablen und einen invariablen Teil aufgeteilt 4. Dies spiegelt sich auch im Aufbau und der Einteilung der Features wider. Innerhalb der PAI Plattformentwicklung wird zwischen den folgenden Featuretypen unterschieden: Common Features werden in alle Plattformen integriert, Plattform Features werden in mindestens eine aber nicht in allen Plattformen integriert und Shared Plattform Features werden integriert in mindestens einer PAI Shared Plattform. Der Ursprung des Feature-Modells liegt im FODA- Verfahren [KSJ + 90]. Anhand des Modells werden die Anforderungen und die dazugehörigen Features strukturiert darstellbar [MII04]. Es dient als Startpunkt für den folgenden Entwurf. Das Plattform-Feature- Modell zeigt die architekturelle Einordnung der Features und ihre Zuordnung zu Plattformen. Plattformgrenzen ermöglichen eine architekturelle Differenzierung von Features und sind Mittler zwischen Features und Komponenten. Hierbei kann es jedoch vorkommen, dass ein Feature durch die Kombination mehrerer Plattformen realisiert wird. Traceability-Links werden dann verwendet, um die Beziehungen zwischen Anforderungen, Features und Komponenten herzustellen (vgl. [MII04]). Das Feature stellt auf der einen Seite die Kundensicht dar. Auf der anderen Seite vereint es die Kundenanforderungen mit der Modularisierung von Funktionalität innerhalb von Komponenten. Die Komponenten beschreiben die Sicht der Entwickler. Ein einzelnes Feature hat in verteilten Systemen meist Einfluss auf mehrere Komponenten. Plattformen können an dieser Stelle behilflich sein, die Aufgaben der Komponenten abzugrenzen. In Abbildung 3 sind schematisch Anteile eines Features aufgezeigt am Beispiel von PAI Plattformen. 3 Das Bild ist stark vereinfacht, verschiedene Feature-Modell- Attribute wie optional Feature, required Feature oder alternative Feature nach [MII04] werden nicht benutzt. Des Weiteren fehlen die verschiedenen in PAI bestehenden Plattformprodukte. Die Traceability-Links zu den Entwurfsartefakten sind durch kleine Pfeile angedeutet. 4 Vgl. hierzu auch [MII04],wo sogenannte Core Assets definiert werden. Komponente 1 Komponente 2 Komponente 3 Komponente n Basisprodukt I Basisprodukt II Basisprodukt III Basisprodukt m Konfigurationseinstellungen PAI-Plattform A Anteile von Feature x Komponente 1 Komponente 2 Komponente 3 Komponente n Basisprodukt I Basisprodukt II Basisprodukt III Basisprodukt m Konfigurationseinstellungen PAI-Plattform B Abbildung 3: Beispiel eines Features Die Anwender sind meist die wesentlichen Initiatoren von Anforderungen. In dieser Funktion bleiben sie jedoch nicht die einzigen, da das Produktlinien- Team selbst ebenfalls Anforderungen stellt, um die Stabilität und Weiterentwicklung der Plattformen zu ermöglichen. Auch aus selbstgestellten Anforderungen ergeben sich oftmals Features. Im Laufe der Zeit entsteht besonders bei Plattformen, da diese tendenziell eher als langfristig und zumindest nach außen hin stabil angelegt werden, eine Grauzone von Anforderungen. Die in ihr enthaltenen Features müssen jedoch im Sinne der Verfolgbarkeit berücksichtigt werden. 4 Feature-orientiertes Verfolgbarkeitskonzept Anforderungen dienen als Startpunkt der Verfolgbarkeit (engl. Traceability) und bestimmen die oberste Ebene der vertikalen Verfolgbarkeit [Got95]. Das Ziel ist, zwischen den verschiedenen Verfolgbarkeitsebenen nachvollziehbare Verbindungen zu etablieren. Dadurch kann die richtige und vollständige Umsetzung der Anforderungen ermöglicht werden. Durch den Ansatz der Traceability-Ebenen ist es möglich, die verschiedenen Stufen incl. ihrer Schnittstellen im Gesamtentwicklungsprozess zu beschreiben. Der Fokus liegt dabei auf dem Entwicklungsprozess und den benötigten Traceability-Links. Die Abbildung 4 zeigt schematisch das Traceability-Konzept, aufgebaut aus den in diesem Abschnitt beschriebenen Ebenen. Ebene 0: Anforderungen. Als Ausgangspunkt dienen die vom Kunden beschriebenen Anforderungen. Dokumentiert werden sollte auf dieser Ebene, welche Kunden welche Funktionalitäten fordern. Aspekte der Konsolidierung und Priorisierung der Anforderungen werden hier bereits mit einbezogen. Im Sinne der Feature-orientierten Entwicklung sind Anwendungsfälle wichtig um klar abzugrenzen, wo die Systemgrenzen sind. Im Produktlinienkontext können hier bereits Überlegungen angestellt werden, was in der Plattform integriert wird. Die Herausarbeitung des gemeinsamen Verständnisses ermöglicht dem Entwicklungsteam darauf aufbauend die Konsolidierung

6 Anforderungen RE 1 RE 2 Kunde 1 RE 3 RE 4 Kunde 2 RE 5 RE Plattform-Feature-Modell FE 1 FE 3 FE 5 FE 1 FE 3 FE 6... FE 4 FE 1 FE 4 FE 1 FE 7... Entwurf und Implementierung Platform Platform Feature Feature Feature FE1 1 1 Architecture Architektur C1 C Cn Cn C1... Cn Component Komponenten Component Entwicklung Development Design Entwurf Design Impl. Impl. Impl. Test Test Test Plattformen Shared Plattformen Common Features Plattform Features Shared Plattform Features Abbildung 2: Plattformbasiertes Feature-Modell Anforder- ungen Features Plattform-Design Komponenten Implementation Unit CU R1 R2 R3 F1 F2 F1 F2 C1 Implementation Unit n. Implementation Unit 1 R4 F3 F3 F3 C3 Modell Klassen Test CU R5 R6. F4 F5. F5. F4 F5. F4 F5.. C2... Implementation Unit 2 Modell Klassen Test Implementation Unit 3 Modell Klassen Test CU CU RM ART PM ART TIT TET CDT ART TIT TET E0 E1 E2 E3 CDT E4 Traceability Link CU Kunde RM Requirements Manger PM Produkt Manager ART Architekturteam TIT Installationsteam TET Environmentsteam CDT Developmentteam Abbildung 4: Feature-orientiertes Verfolgbarkeitskonzept der Anforderungen zu Features. Ebene 1: Features. Die Eingangsinformationen dieser Ebene sind die überarbeiteten Kundenanforderungen. Diese werden konsolidiert, in den Kontext der Produkte bzw. Plattformen überführt und auf Features abgebildet. Die Features wiederum können präzise formuliert werden und ergeben somit die Eingangsdokumente für die nächste Ebene. Ebene 2: Plattform-Design. Auf Basis der definierten Features wird anschließend das Design der Plattform in folgenden Schritten ausgearbeitet: a) Identifikation der durch die Features betroffenen Plattformen, b) Bestimmung der Komponenten aus logischer Sicht, c) Identifizierung der funktionalen Abhängigkeiten und d) Identifizierung der Änderungen bestehender und neu benötigter Komponenten bzw. deren funktionale Abgrenzung zur bisherigen Implementierung. Aus der Konsequenz der Grauzonen-Problematik (siehe Kapitel 3) müssen neben dem Kunden noch weitere Featurequellen mit aufgenommen werden (siehe Abbildung 4). Neben den Abhängigkeiten zwischen den Plattformen und deren Komponenten müssen hier zusätzlich die Plattformversionen berücksichtigt werden. Die Sicherstellung der Abwärtskompatibilität zu den bisher bereits ausgelieferten Plattformen bzw. deren Implementierung erfordert immer auch die Berücksichtigung der bisher implementierten Features und damit die Identifizierung der betroffenen Komponenten. Ebene 3: Komponenten. Die aus dem Plattform- Design folgenden Aktivitäten werden auf dieser Ebene auf einzelne Komponenten abgebildet und nach ihrer Art unterschieden Test, Entwicklung, Dokumentation oder Build. Wesentlich für die Entwicklung ist die Unterscheidung der Reihenfolge, um eine funktionale Verknüpfung der erstellten Artefakte zu erreichen. Ebene 4: Implementation Unit. Pro Komponente werden auf Basis des Plattform-Designs Imple-

7 mentierunsaktivitäten definiert. Auf die Verfolgbarkeit von Entwicklungsaktivitäten zu Entwicklungsartefakten muss hierbei besonders geachtet werden, da die Entwicklungsarbeiten als Arbeitsanweisung in einem Verwaltungstool verwaltet werden, die Entwicklungsartefakte befinden sich dagegen in einem Versionsmanagementsystem. Durch diese Verteilung wird die Verfolgbarkeit erschwert. 5 Auswirkungen der Feature-orientierten Sichtweise auf den Test 5.1 Feature-orientierte Unit-Tests Sogenannte Units werden in Unit-Tests isoliert durch den Programmierer auf ihr Verhalten hin getestet. Änderungen an bestehendem Code sind kritisch, da das Risiko besteht, dass bestehende Funktionalität verändert wird. Bestehende Unit-Tests dienen zum einen als Absicherung von bereits implementierter Funktionalität bei Änderungen, zum anderen haben sie die Aufgabe, die Neuentwicklung einer Unit zu prüfen. Eine Code Coverage Analyse ist auf dieser Ebene hilfreich, um ein Maß für die Testabdeckung zu ermitteln und ungetestete Bereiche zu identifizieren. Existierende Maße wie zum Beispiel Line Coverage sind aus Sicht der Feature-orientierten Entwicklung kontextlos. Das heißt, es fehlen Kennzahlen welche die Testabdeckung bezogen auf den gewollten implementierten Teil eines Features berücksichtigen. 5.2 Feature-orientierte Komponententests Für einfache Features kann es bereits in dieser Ebene aus funktionaler Sicht eine eindeutige Zuordnung zwischen Feature und Funktionaltest geben. Neben dem Testen der internen Funktionalität einer Komponente ist es auch wichtig, die Komponente nach außen hin auf Basis der Komponentenschnittstelle zu testen, um die möglichen übergeordneten Abläufe zu gewährleisten. Aus Feature-orientierter Sicht ist jedoch bereits auf dieser Ebene das entsprechende Feature entscheidend. Kombiniert werden können beide Sichtwesen durch Überprüfen derjenigen Komponenten, die für das jeweilige Feature notwendig sind. Von einem Feature-orientierten Standpunkt sollten alle Testfälle durchgeführt werden, die der Spezifikation nach einen für das Feature essentiellen Ablauf darstellen. 5.3 Feature-orientierte Integrationstests Die Klassen der Komponenten und dessen Interfaces sollten bereits isoliert getestet worden sein. Darauf aufbauend steht innerhalb des Integrationtests die Interaktion der Komponenten im Vordergrund. Eine Plattform besteht zu einem wesentlichen Teil aus einer Menge an Komponenten. Im Falle von PAI kommen dabei noch Basisprodukte und Konfigurationsparameter hinzu. Das Ziel des Integrationstests ist es, die Interaktionen zwischen Komponenten innerhalb der Plattformen zu testen. Betrachtet werden hierbei hauptsächlich die Interaktionen, die für die Realisierung der Featurefunktionalitäten notwendig sind. Die Gesamtfunktionalität der Plattformen bzw. der Gesamtheit der Features ergibt sich dann aus der Integration der verschiedenen Komponenten und Basisprodukte. Basisproduktfunktionen werden beim Integrationstest ebenfalls aufgerufen, werden jedoch nur am Rande systematisch auf ihre Korrektheit überprüft. Je nach zu testendem Feature bzw. zu testender Plattform müssen bei der Installation und Konfiguration der Testumgebung Plattformabhängigkeiten und Versionseinschränkungen berücksichtigt werden. Eine wichtige Rolle beim Plattformtest spielen Testapplikationen. Diese sind an vielen Stellen notwendig, um komponentenübergreifend Funktionalitäten prüfen zu können. Dies liegt daran, dass teilweise nur unzureichend direkt auf die zur Verfügung gestellten Plattformfunktionen zugegriffen werden kann. Daraus ergibt sich der Vorteil, dass die funktionale Integration der Basisprodukte bereits aus einer der Sichtweise der Anwender relativ ähnlichen Perspektive getestet wird. Allerdings ist durch die Verwendung der Testapplikationen der Übergang von Integrations- zu Systemtests fließend. Dies wird dadurch noch verstärkt, dass die Testapplikationen auf Basis von funktional orientierten Testfällen erzeugt werden, die sich an Use Cases orientieren. Diese Szenarien bilden Abnahmekriterien ab, die auf den Featureanforderungen basieren. Im Kontext der Feature-orientierten Entwicklung werden erste Testfälle bereits in der Featurespezifikation festgehalten, wobei der Detaillierungsgrad variieren kann. Jeder geplante Testfall sollte mindestens einem Feature zuzuordnen sein, da letztlich das Testergebnis bzgl. der Features interessant ist, das heißt welche Features fehlerbehaftet sind und welche nicht. 5.4 Feature-orientierte Systemtests Bei den Systemtests existiert eine ganze Reihe weiterer Testanforderungen. Beispielsweise um die Funktionalität der Plattform gemäß den Kundenanforderungen auf verschiedenen Betriebssystemen zu testen, muss die entsprechende Infrastruktur zur Verfügung stehen. Hinzu kommen hierbei oftmals weitere Infrastrukturkomponenten 5. Der Systemtest hat zum Ziel, das Verhalten des Gesamtsystems gemäß der Spezifikation der Anforderungen zu testen. Nach [AM01] sollte in dieser Ebene das Testen von nichtfunktionalen Anforderungen im Vordergrund stehen 6. Wie in Abschnitt 3 dargestellt, können Features verschiedene Plattformen betreffen. Diese können dadurch nur auf Basis einer Kombination von verschie- 5 zum Beispiel Proxies, Firewalls, Caches, etc. 6 Dies lässt sich auch mit der Einteilung in [Lig02] in Einklang bringen, wo innerhalb eines Systemtests die Testfälle in Funktionstest, Leistungstest, Stresstest, Beta- und Regresssionstest eingeteilt werden. In dieser Sichtweise ist die Einteilung in funktional und nichtfunktional nicht mehr bestimmend.

8 denen Plattformen gestestet werden. Da immer Plattformreleases getestet werden, wird dadurch vorausgesetzt, dass die Implementierungen verschiedender Plattformen zum selben Zeitpunkt in der Testumgebung verfügbar sind, was durch die Verfügbarkeit von Hardware und Teammitgliedern begrenzt wird. Dies muss in der Planung, Architektur der Plattform und bei den System- und Integrationstests berücksichtigt werden. 6 Zusammenfassung und Ausblick Die Verfolgbarkeit von Anforderungen durch den gesamten Entwicklungsprozess kann auch bei der Plattformentwicklung anhand eines feature-orientierten Modells umgesetzt werden. Die Zuordnung von Komponenten zu Features integriert zusätzlich die Vorteile der komponentenbasierten Softwareentwicklung, ohne die Verfolgbarkeit von Anforderungen bis hin zu den Testfällen zu gefährden. Das hier vorgestellte Konzept zusammen mit dem Modell bildet die Grundlage für weitere Arbeiten an einem umfassenden Verfolgbarkeitsverständnis in einer Feature-orientierten Plattformentwicklung. Ein Nachteil der Feature-orientierten Sichtweise ergibt sich, wenn diese nicht durchgängig umgesetzt wird. Ohne eine transparente Übersicht, welche Features in welchen Plattformen enthalten sind und durch welche Kombination verschiedener Komponenten umgesetzt wird, werden Änderungen an bestehenden Featureimplementierungen sehr risikoreich. Dies liegt darin begründet, dass nicht ohne weiteres überschaut werden kann, welche Features von der jeweiligen Codeänderung betroffen sind. Derzeit fehlen noch Möglichkeiten um herauszufinden, an welchen Stellen bzw. wie stark sich der implementierte Code im Kontext des implementierten Features verändert hat und wie hoch damit das Risiko einer Änderung ist. Die zukünftige Erweiterung des Konzepts beinhaltet eine bis auf Code-Ebene bewertbare Verfolgbarkeit der Implementierungsänderungen bei neuen Anforderungen. Damit wird messbar, welcher featureabhängige Komponentenanteil verändert werden muss und welches Risiko dabei besteht bzw. welche anderen Features von den entsprechenden Komponenten abhängig sind. Aus dem Verfolgbarkeitskonzept ist ableitbar, welche Komponenten während der Entwicklung eines Features direkt oder indirekt betroffen sind. Statt einem generellen Testen der Komponenten nach Änderungen ermöglicht das Feature-orientierte Testen ein gezieltes und damit Resourcen sparendes Testen, da bei neuen Features nicht generell alle Komponenten der Plattformen verändert werden. Allerdings wird es ohne ein formales Verfahren nicht möglich sein, genaue Werte über die Größe der Änderungen und die Testüberdeckung zu erheben. Die Praxis einer entsprechenden Vorgehensweise wird in zukünftigen Arbeiten dargestellt werden. Literatur [AM01] [CNN01] [Got95] [JM02] [KSJ + 90] Alain Abran and Abraham Moore. Swebok - a project of the software engineering coordinating committee. The Institute of Electrical and Electronics Engineers, IE- EE Computer Society Press Order, ISBN , Paul Clements, Linda Northrop, and Linda M. Northrop. Software product lines: practices and patterns. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, O.C.Z. Gotel. Contribution structures for requirements traceability. Ph.D. Thesis, University of London, Sametinger J. and Riebisch M. Evolution support by homogeneously documenting patterns, aspects and traces. 6th European Conference on Software Maintenance and Reengineering, Budapest, Hungary, Computer Society Press., Kang K., Cohen S., Hess J., Novak W., and Peterson A. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-021, SEI Institute, Carnegie Mellon University, [Lig02] Peter Liggesmeyer. Software-Qualität, Testen, Analysieren und Verifizieren von Software. Spektrum, Akad. Verl., ISBN , [MII04] Riebisch M., Philippow I., and Pashov I. Integration von Feature Modellen in die evolutionäre Weiterentwicklung von Software Produktlinien Architekturen. Essen, Germany, Multi-Konferenz Wirtschaftsinformatik, [PBvdL05] Klaus Pohl, Günter Böckle, and Frank van der Linden. Software Product Line Engineering;Foundations, Principles, and Techniques. Springer-Verlag Berlin Heidelberg, [Rei04] Wilfried Reimann. Building Enterprise Applications with an Integrated Application Platform. Erfurt, Germany, September.NET.ObjectDays Conference, [RM94] Watkins R. and Neal M. Why and how of Requirements Tracing. IEEE, IC- SE 01,23rd International Conference on Software Engineering, 1994.

9 Model-Driven Integration of Business Information Systems Niels Streekmann 1, Ulrike Steffens 1, Claus Möbus 2 and Hilke Garbe 2 1 OFFIS Escherweg 2 D Oldenburg Germany {niels.streekmann, 2 Learning Environments and Knowledge Based Systems University of Oldenburg D Oldenburg Germany {claus.moebus, September 19, 2006 Abstract The integration of business information systems is an important task for enterprises, with an increasing demand on the level of integration. While most integration projects in the past concentrated on the integration of data used by different applications, today the focus is on the integration of the applications themselves. Furthermore there already is a tendency towards the integration of systems on the process and presentation level. In this paper we present the approach taken in the MINT project where a method for model-driven integration on the level of business processes that bases on the MDA approach of the OMG is proposed. 1 Introduction Enterprises are often confronted with the task of integrating legacy systems into new system landscapes or to integrate individual systems with standard software. With existing methods this is a complex and expensive challenge. In the MINT project [1] we face this challenge by the usage of model-driven methods which are expected to reduce time and costs of the development of integration solutions. Another principle that is applied in the MINT project is the usage of patterns to structure models and simplify the transformation from models to other models or code. The contribution of this paper is a critical review of the OMG proposed MDA models and process in the context of system integration. By this, the current state of the main concepts of the MINT approach are introduced. The paper is structured as follows. Section 2 gives an overview of the MINT approach. Sections 3, 4 and 5 describe further details of the major aspects of the approach. Section 6 describes the evaluation of the approach in the MINT project while section 7 concludes and points out future work planned to put the approach into practice. 2 The MINT Approach The MINT approach provides methods for the integration of business information systems and bases on OMG s Model Driven Architecture (MDA). It supports the views on the system described in [8], namely the computation independent model (CIM), the platform independent model (PIM) and the platform specific model (PSM), to specify the application to be built. While this approach is disputed and certainly only one possible form of model-driven development methods among others, in our context the distinction between these models is considered appropriate. The exact role of these models is discussed in the sequel to this introduction. The MINT approach focuses on the integration of software systems. In practice there are two different instances of integration on this level. On the one hand this regards the integration of modern software systems with existing legacy systems which are valuable for the enterprise and cannot be replaced at once by a new system. The other case is the integration of standard software with individual software specific for a domain or a certain enterprise. It is assumed that both cases can be addressed using the same methods described in the following. Figure 1 depicts the model levels of the MDA and the integration described above. It represents an overview of the procedure model of the MINT approach. 1

10 Figure 1: Procedure model of the MINT approach The integration of systems on the level of business processes is a task that requires a lot of knowledge by domain experts. This knowledge enfolds the tasks of the domain that can be facilitated by a software system. These tasks are a combination business processes to execute the business of the enterprise and domain knowledge which includes the concepts and their correlations inside the domain. In MDA these requirements are acquired in the CIM. The dashed line in figure 1 indicates that this is no automated, but rather a manual process that needs special methods and guidelines. In the MINT approach we use cognitive and domain-specific patterns to support this process. A more detailed description of these patterns is given in section 3. The CIM itself is the main source of communication between domain experts and software developers. Thus it has a special role in software development that is neglected in practical approaches to MDA. In contrast the CIM has a central role in the MINT approach due to the fact that it is the initial point for our integration approach since it includes the business processes used as a basis for the integration tasks in the following model steps. The second aspect we identified as a basis for integration of different systems that resides in the CIM, is a domain model that represents the intra- or inter-organizational understanding of the domain the application operates in. The structure of the CIM is described in section 4. Since the CIM has the purpose to acquire the requirements and serve as a source for communication it should be modelled in a language that is understandable for domain experts. One way to do this is though the usage of domain-specific languages that are a widespread object of current research [6]. Opposed to the CIM the PIM is a technical model which provides the architecture of the system. In the MINT approach we examine how the PIM can be derived from the CIM and how interfaces derived from the business processes can be combined with interfaces offered by legacy systems and standard software to describe the integration of business information systems on an architectural level. This process of architecture derivation and integration of systems in the PIM is described in section 5. The PSM specifies the realisation of the interfaces described in the PIM on a specific platform. In doing so, the interfaces that are already provided by the legacy system or standard software and their implementations have to be considered in all models. A base for this kind of consideration of integration aspects is the BALES methodology, as described in [11]. A possible platform technology for implementation of the above mentioned interfaces are web services. An example for the usage of web services in the context of integration is the application of the DUBLO pattern described in [4] where web services are used for the integration of a legacy system with a modern system architecture during the migration process from the old to the new system. The extraction of web services from systems that are not build to interoperate on this level is also part of the MINT project, but not in the focus of this paper.

11 3 Guided CIM Creation Creating the CIM is the first task in the MDA development process. It comprises the domain specific processes and tasks and has to be developed in collaboration with domain experts. The CIM has great importance for the rest of the development process, as new requirements or changesin the CIM lead to changes in the corresponding PIM and PSM. As domain experts are often not experienced in modelling processes, they have to be supported during this task. Research in our project will show whether this can be accomplished by using cognitive patterns. The term cognitive patterns refers to recurring templates that humans use during problem solving/ reasoning activities. [2] Since these patterns model natural human problem solving, it is assumed that it is easier for domain experts to express their domain knowledge using these instead of business process patterns for example. Business patterns have a different intention (e.g. workflow organization). Another benefit is mentioned by Gardner et al., who premise that the notion of cognitive patterns, applied to organizational and system processes in business, can facilitate a deeper understanding of these processes. [2] So, the use of these patterns can result in a more complete and correct model of the domain-specific processes and tasks. Existing pattern libraries are described by Gardner et al. and Schreiber et al. [9] amongst others. In MINT these libraries have to be extended with domain-specific patterns, e.g. by adoption or discovery of new patterns. A scientific goal of the MINT approach is to identify such patterns and evaluate how they can be applied to enhance the CIM. An example is the usage of these patterns as templates in the modelling language that have to be configured with application-specific values. 4 CIM Structure The structure of a CIM depends on the purpose of the system to be build. The CIM should represent all aspects of the system that are important from a domain experts point of view. Further technical details like the platforms the system runs on or details about the interfaces of the integrated systems should not be relevant on this level. Hence, as described in section 2, the languages used to model the application from a domain expert s point of view should be adapted towards their specific needs. This results from the realisation that many problems in software engineering are based on misinterpretations of requirements and misunderstandings between domain experts and software developers. MDA holds the opportunity to overcome these misunderstandings by offering views on the system in languages that are specific for every stakeholder. The PIM on the other hand should be modelled in a language understandable for software developers. Furthermore it should be usable for analyses of the system and further generation of a PSM and code. In MDA the standard modelling language is UML. This fits for technical description of the system as in the PIM and PSM, but can lead to problems in modelling the CIM, because many domain experts are not able to model their intentions in UML. A way to overcome this is the introduction of domain-specific languages (DSL) [6]. An easy way to introduce a DSL on the basis of UML is the usage of UML Profiles that restrict the usage of UML elements to simplify the language and adapt it for a certain domain. For the description of integrated business information systems we propose a structure for the CIM that consists of a business process model and a domain model. The business process model describes the processes the system is intended to support. This model is application-specific though it may be part of a larger model that includes all business processes of the enterprise. The domain model describes the domain of the system. It is intended to provide a common model for all applications throughout an enterprise. Further details about these models and the according modelling languages are given in the following subsections. 4.1 Business Process Model Business processes are a well-established in the domain of business information systems to model the tasks of such a system. Furthermore it is a good starting point for the integration of these systems, since the tasks described in a business process may be fulfilled by different systems that are already available as legacy systems or still have to be developed. We chose UML2 activity diagrams to model the business processes, because they are well researched in this context and there is a good tool support for UML and MDA. For the modelling of business processes in UML there are extensions in the form of UML Profiles that we consider to use within the scope of the MINT approach. A profile for the detailed modelling of processes is described in [7] while [5] presents a profile that can be used to describe the processes from a business perspective. I.e. it describes different types of processes, the persons in charge of the processes, deliverables and so on. Another goal of the MINT approach regarding modelling the CIM is the use of patterns to structure the model and describe transformations from the CIM to the PIM. For this purpose we will evaluate the cognitive and domain patterns mentioned in section 3 as well as business process and software engineering patterns. It is in the scope of currently ongoing research whether these patterns can be used as model templates or even to create new domain-specific languages that make it easier for domain experts to describe their requirements of a software system.

12 4.2 Domain Model The domain model is a model of the application domain. I.e. it models the enterprise-wide or domainwide concepts of the domain agreed upon by the domain experts. Such a model is of great importance for the integration of systems, because it serves as the common base for the data used in all systems. How the model is exactly used in the PIM to integrate the interfaces of different systems is described in section 5. The domain model should not be created anew for every new application or integration project. It should rather be derived from existing organisational or domain standards and then be used for all projects within the enterprise. These standards will of course differ from domain to domain and especially for applications that integrate several systems, the CIM will contain a particular domain model for each domain that is involved and of importance for the business process that is to be implemented by the system. 5 Architecture Derivation and Architectural Integration The architecture of a system and the basic architectural aspects of the integration of systems are modelled in the PIM. In practice the derivation of an architecture is a model-to-model transformation from CIM to PIM. As claimed by Gerber et al. [3] transformations are the missing link to the successful application of model-driven development. Much scientific and practical work is expended on the exploration of how such transformations should be done. However most of the work concentrates on the use of transformations to build a PSM from a PIM and how code can be generated from the PSM. I.e. the main question is how an existing architecture can be implemented on a specific platform. The focus of our work is to find a way of building that architecture from the requirements instead. Since the CIM can be seen as a structured model of the requirements in the language of domain experts, we centre on the transformation from CIM to PIM. We propose to use business process model from the CIM and the patterns used to build the CIM as a source for the transformation. The business process tasks in the CIM will be transformed to interfaces in the PIM that provide methods to fulfil the task. As can be seen here the transformations from CIM to PIM will only supply a skeleton PIM which has to be completed by software engineers. This also covers the integration aspects that contain the mapping from interfaces derived from the CIM and interfaces derived from the systems that have to be integrated and the mapping from the domain models used in the description of the last-mentioned interfaces and the domain model from the CIM. The mappings mentioned in the last paragraph implicate that some kind of adaptation may be needed if the interfaces, that are mapped to each other, differ in the implementation of methods or protocols, or in the naming or definition of concepts in the respective domain models. A source of our work in this area is the work of van den Heuvel [10] on adaptation regarding the BALES methodology. After the architecture and the integration aspects have been described in the PIM, the next steps are the realisation of the architecture on a certain platform and the generation of code for this platform. These are again done by transformations, which are model-to-model transformations in the case of PIM to PSM and model-to-text transformations in case of PSM to code. The PIM to PSM transformation employs a platform model that includes detailed information about the platform. The platform we propose to use for the integration of business information systems are web services. 6 Evaluation Current experience shows, that a model-driven software development approach is most successful in rather focused domains which are well-understood and where generated code can build on powerful libraries or frameworks. Therefore, in MINT we focus on the domain of coupling object-oriented business code with relations databases. Although this is a very specific aspect of system integration, it is rather frequent in practice, ranging from newly developed systems to software migration projects and legacy integration. While model-driven approaches for coupling object-oriented business code with relational databases are to be extended in MINT, it is important to validate these approaches in contrast to other techniques for solving the same problem. Namely, persistence frameworks (such as Spring or Containermanaged Persistence in Enterprise Java Beans) or using a high-level persistence interface, such as ADO.NET are alternative solutions. Therefore, the MINT project is concerned with discovering guidelines that will assist software architects in their decision on how to approach the coupling of object oriented business code with relational databases. This is a considerable step towards an engineering approach to software design, as in the current state of software design such decisions mainly base on experience or, worse, on intuition. Far too often, in software development, the benefits and, in particular the limitations of specific approaches are unclear. In contrast to this, the MINT approach is highly concerned to associate with its methods and tools general guidelines on the applicability of the approach, as it is also common in other engineering disciplines. By that, MINT will deliver a building block to the future engineering character of software design.

13 7 Conclusion and Future Work In this position paper we introduced the MINT approach which represents a method to integrate business information systems based on business processes and domain models. The paper highlights three major tasks needed to implement this method and proposes solutions to face them. The identified tasks are: Creation of the computation independent model. Definition of the structure of such a model with respect to integration. The derivation of a software architecture from the CIM and the description of methods towards integration based on this architecture. Future work on the approach will concern the usage of DSL and UML profiles to model the CIM and the transformation from CIM to PIM based on patterns and the involvement of domain-specific patterns to structure the CIM. The approach will be evaluated within the work of the MINT project regarding the functionality in selected scenarios and regarding non-functional properties in comparison to other generative integration approaches. 8 Acknowledgements The work presented in this paper originates from the MINT project as proposed by Ralf Reussner, who is heading the project. MINT is supported by the Federal Ministry of Education and Research in the scope of the Forschungsoffensive Software Engineering [6] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domainspecific languages. ACM Computing Surveys, 37(4): , [7] Bernd Oestereich, Christian Weiss, Claudia Schröder, Tim Weilkiens, and Alexander Lenhard. Objektorientierte Geschäftsprozessmodellierung mit der UML. Dpunkt Verlag, [8] Object Management Group (OMG). MDA guide version [9] Guus Schreiber, Hans Akkermans, Anjo Anjewierden, Robert de Hoog, Nigel Shadbolt, Walter Van de Velde, and Bob Wielinga. Knowledge Engineering and Management. The CommonKADS Methodology. MIT Press, [10] Willem-Jan van den Heuvel. Matching and adaptation: Core techniques for MDA-(ADM)-driven integration of new business applications with wrapped legacy systems. In Model-Driven Evolution of Legacy Systems, [11] Willem-Jan van den Heuvel, Wilhelm Hasselbring, and Mike Papazoglou. Top-down enterprise application integration with reference models. In EFIS, pages IOS Press and Infix, References [1] MINT project homepage. http: Last visit: [2] Karen M. Gardner, Alexander Rush, Michael K. Christ, Robert Konitzer, and Bobbin Teegarden. Cognitive Patterns: Problem-Solving Frameworks for Object Technology (Managing Object Technology Series). Cambridge University Press, [3] Anna Gerber, Michael Lawley, Kerry Raymond, Jim Steel, and Andrew Wood. Transformation: The missing link of MDA. In ICGT, pages , [4] Wilhelm Hasselbring, Ralf Reussner, Holger Jaekel, Jürgen Schlegelmilch, Thorsten Teschke, and Stefan Krieghoff. The dublo architecture pattern for smooth migration of business information systems: An experience report. In ICSE, pages , [5] Beate List and Birgit Korherr. A UML 2 profile for business process modelling. In ER (Workshops), pages 85 96, 2005.

14 Bäumchen wechsle Dich - Tücken beim automatischen Abgleich hierarchischer Objektstrukturen Rainer Drath, ABB Forschungzentrum Ladenburg Schlüsselwörter: Datenaustausch, Objektstrukturen, Workflow, Mapping, Objektorientierte Planung 1 Objektorientierte Planung in der Industrie ein zäher Weg in die Praxis 1.1 Begriffsbestimmung Die Objektorientierung ist ein in der Softwarebranche seit langem bewährtes Werkzeug zur Beherrschung von Komplexität. Dies gilt sowohl für die interne Architektur der Software selbst als auch für die dem Nutzer der Software zur Verfügung gestellte Bedienphilosophie und Datenrepräsentation. Im Folgenden wird der Begriff der Objektorientierung aus der Sicht des Planers verwendet und fokussiert sich auf objektorientierte Planungstechniken wie Datenrepräsentation und -manipulation. Microsoft Visio ist ein Beispiel für ein bekanntes Zeichenwerkzeug mit objektorientierter Bedienphilosophie. Hier wird eine Zeichnung aus Objekten zusammengesetzt, die ihrerseits durch Eigenschaften und Relationen konfiguriert werden können. Planungswerkzeuge wie ComosPT bieten zudem eine komfortable objektorientierte Datenrepräsentation in Form hierarchischer Objektbäume [Schül02]. Der Begriff des Objektes wird im Folgenden sowohl für Objektinstanzen als auch für Objekttypen verwendet, da sich Typen in einer Typbibliothek wie Objekte verhalten. Der Begriff der Vererbung ist in der Anlagenplanung sowohl auf Klassen (auch als Typen bezeichnet) als auch auf die Instanzbildung anwendbar und erweist sich dort als Schlüssel für effizientes Engineering. Klassenvariablen gelten demzufolge als Eigenschaften von Anlagenobjekten (z. B. Symbol ) und können dort sowohl geändert als auch überschrieben werden. Das Ändern eines Symbols für alle Instanzen wird so beispielsweise erheblich vereinfacht. Abbildung 1: Beispiel eines Objektbaumes als Datenmodell einer Anlage in einem modernen Planungswerkzeug 1.2 Objektorientierung in der Industrie In der Automatisierungs- oder Verfahrenstechnik hat sich die Objektorientierung als Hilfsmittel zur effizienten Planung bis heute nicht etabliert. Grund hierfür sind nur bedingt die Softwarehersteller. Gerade sie sind in der objektorientierten Denkweise längst zuhause und bieten seit Jahren objektorientierte Werkzeuge für die Verfahrens- und Automatisierungsplanung an. Doch die Akzeptanz in der Industrie ist noch immer schwer erreichbar: die gewachsenen zeichnungs- oder listenorientierten Denkweisen und Workflows sind zum Teil tatsächlich derart effizient und in den Köpfen der Ingenieure und Abwickler verankert, dass ein Wechsel zum objektorientierten Umgang mit Planungsdaten einer Revolution gleichkäme. Der Wechsel vollzieht sich trotzdem, wenn auch langsam: zum einen in Form eines schleichenden Generationswechsels bei den Ingenieuren und Entscheidern zugunsten derjenigen, die mit der objektorientierten Denkweise vertraut sind. Zum anderen passen sich die Werkzeughersteller den Nutzern an: eplan P8 [EPLAN8] beispielsweise verkleidet sich in traditionellem Gewand und verbirgt auf Wunsch seine objektorientierten Bedienkonzepte. Es emuliert die traditionell zeichnungsbasierte Denkweise so gekonnt, dass der Nutzer sich in vertrautem Umfeld wähnt. Das Umschalten zur Objektorientierung ist dabei jederzeitmöglich. Diese Trends ergänzen einander und werden den Umstieg zur Objektorientierung beschleunigen. Auch wenn auf einschlägigen Messen die Objektorientierung als modernen Nachfolger einer längst verstaubten Denkweise angepriesen wird, müssen die tatsächlichen Vorteile im industriellen Umfeld trotzdem immer wieder überzeugend vorgeführt werden. Diese fortwährende Überzeugungsarbeit ist ein Indiz dafür, dass die Objektorientierung an sich in der Industrie keinen sofort ersichtlichen revolutionären Vorteil bietet, sondern dass sich der Effizienzgewinn beim Planen komplexer Anlagen durch Methoden wie Kapselung, Vererbung und Instanziierung erst nach einer zu vollziehenden Änderung des Workflows und der Denkweise entfaltet. Die genannten Methoden sind Grundlage der Wiederverwendung ein Schlüsselkonzept für Rapid Engineering und somit keineswegs auf die Entwicklung von Softwaresystemen beschränkt. Die verbreitete Modultechnik (z. B. [Parnas72]) bietet beispielsweise seit langem Konzepte, die der

15 Kapselung und Instanzbildung sehr ähnlich sind. Bei der Projektarbeit ist es seit Jahrzehnten üblich, eine (Teil-) Zeichnung eines bereits bewährten automatisierungstechnischen Individuums (z. B. einer Motorsteuerung) wiederzuverwenden und sie in ein neues Projekt zu kopieren. Derartige Konzepte sind längst eingeführt und erst auf den zweiten Blick von dem objektorientierten Paradigma der Instanzbildung zu unterscheiden. Es genügt nicht, die Objektorientierung, wie sie in der Softwareindustrie bekannt ist, in der Industrie einfach einzuführen. Planung, Errichtung und Betrieb einer Anlage unterliegen anderen Problemstellungen und verlangen somit andere Lösungen. Typische Probleme der Industrie sind beispielsweise der Datenaustausch zwischen Werkzeugen und Gewerken, die Wahrung der Konsistenz von Daten, die Unterstützung iterativer Engineeringprozesse, Performance, Flexibilität, Einfachheit, schnelle Erlernbarkeit oder die Abbildbarkeit skizzenhafter Grobplanungen und Wahrung der vorhandenen Software-Infrastruktur. Die Vielfalt der genannten Herausforderungen soll dem Informatiker verdeutlichen, warum die Objektorientierung in der Industrie nur zögerlich eingeführt wird. Der vorliegende Beitrag ist innerhalb dieses Umfeldes einem der aktuellsten Probleme gewidmet: dem Abgleich hierarchischer Objektstrukturen in einer bestehenden Werkzeuglandschaft. 2 Typische Probleme beim Austausch zwischen Objektstrukturen Die Planung einer industriellen Anlage erfolgt üblicherweise in mehreren Phasen wie Anforderungsanalyse, Verfahrensplanung, Leittechnikplanung, Errichtung und Inbetriebnahme. Jede dieser Phasen ist charakterisiert durch die Tätigkeit von Ingenieuren unterschiedlicher Ausbildung und Denkweise einerseits und unter Verwendung spezialisierter Softwarewerkzeuge andererseits. In der Vergangenheit wurden die Phasen strikt getrennt und in großen Unternehmen sogar organisatorisch untermauert. In der Gegenwart ist zwar eine zunehmende Verwischung dieser Trennung zu beobachten, und für die Zukunft gelten gemischte Teams als Haupt-Trend zur effizienten Anlagenplanung [Fay05]: Heute jedoch herrscht eine heterogene Softwarelandschaft vor, die von proprietären und vielfältigen Datenstrukturen geprägt ist. Wie erfolgt nun der Datenaustausch zwischen derartigen Anlagenplanungs-Werkzeugen? Die klassische Vorgehensweise sieht vor, dass die Ergebnisse von Tool A in Papierform ausgedruckt, von Ingenieuren der nachfolgenden Planungsphase analysiert und in Tool B weiterverwendet werden. Ebenfalls üblich ist das Abspeichern relevanter Informationen aus Tool A in einem Zwischenformat wie Excel-Tabellen, CSV oder XML, das durch Tool B eingelesen wird. Die beschriebenen Methoden sind jedoch dann nicht ausreichend, wenn Tool A umfangreiche Anlagen-Planungsdaten in Form vernetzter Objektbäume enthält und diese mit Objektbäumen in Tool B abgeglichen werden sollen. Vor dem Austausch von Objektbäumen müssen die vorliegenden Objektwelten zunächst aufeinander abgebildet werden, d.h. Objekttypen von Tool A müssen Objekttypen in Tool B zugeordnet werden können, anderenfalls ist ein Datenaustausch nicht möglich. Je ähnlicher sich die in Tool A und Tool B verwendeten Konzepte sind, desto einfacher ist die Abbildung. Eine 1:1-Abbildung zwischen Objekten wäre ideal. Allerdings sind in der Praxis häufig Unterschiede in den Objektwelten der Werkzeuge anzutreffen. Eine Auswahl typischer auftretende Probleme wird im folgenden erläutert: Objektabbildungsprobleme Objektinstanzen bzw. Objekttypen aus Tool A müssen Objektinstanzen bzw. Objekttypen aus Tool B zugeordnet werden. Typisches Problem: n Objekte in Tool A entsprechen m Objekten in Tool B (n:m Abbildung). Attributabbildungsprobleme Attribute eines Objekttypen bzw. einer Objektinstanz aus Tool A müssen entsprechenden Attributen aus Tool B zugeordnet werden. Typische Probleme: Attribute eines Objektes in Tool A sind in Tool B anders strukturiert (andere Metrik, Datenformat, etc.). Ein oder mehrere Attribute eines Objektes aus Tool A sind in Tool B einem oder mehreren Attributen zuzuordnen. Ein oder mehrere Attribute eines Objektes aus Tool A sind in Tool B zu einem oder mehreren anderen Objekten zuzuordnen. Strukturabbildungsprobleme Neben Objekten und Attributen müssen auch die Baumstrukturen übertragen werden, d.h. Vater- Kind-Beziehungen etc. Typische Probleme: Objektstrukturen von Tool A und Tool B stimmen nicht überein. Objektstrukturen in Tool A oder Tool B werden während des iterativen Engineeringprozesses verändert. Diese Probleme sind teilweise lösbar, teilweise verhindert verlustbehaftete Datenreduktion jedoch den Rücktransport von Informationen (Bidirektionalität). Daraus leiten sich neben dem Problem des generellen Datenaustausches die Probleme der fortlaufenden zuverlässigen Synchronisation der Objektbäume sowie des dahinterliegenden Versionsmanagements ab. Allein die beschriebenen Fälle lassen erahnen, dass der Austausch hierarchischer Objektstrukturen keine triviale Aufgabe ist. Im Folgenden werden diese

16 Abbildungsprobleme kategorisiert, Lösungsvorschläge diskutiert und Grenzen der Machbarkeit aufgezeigt. 2.1 Objektabbildungsprobleme Abbildung 2 zeigt typische Fälle beim Transport von Objekten von Tool A nach Tool B. Diese werden im Folgenden näher untersucht und bewertet. a) x) b) n:1 n:m 1:1 1:1 1:n 1:n y) z) Abbildung 2: Objektabbildungsvarianten :1 und 1:n Abbildung Die Fälle a) x) bzw. b) y) stellen eine 1:1-Abbildung dar: jedes Objekt der Anlagenstruktur aus Tool A entspricht einem Objekt der Anlagenstruktur B. Die Übertragung ist in beide Richtungen möglich, Änderungen in Tool A als auch in Tool B können eindeutig erkannt und synchronisiert werden. In den Fällen a) y) und a) z) wird das Objekt B im Zielsystem in die Objekte BB1 und BB2 (bzw. zusätzlich BB3) aufgeteilt. Beispielsweise könnte ein Objekt Tank-mit-Stutzen aus dem Tool A im Zielsystem zwei getrennte Objekte für den Tank und den Stutzen erfordern. Die Datenübertragung von Tool A nach Tool B ist dann möglich, wenn in Tool B eine Objektgemeinschaft für BB1 und BB2 definierbar ist, die eindeutig dem Objekt B entspricht. Eigenschaften von B können somit auf die Objekte BB1 und BB2 gemappt und automatisch übertragen werden. Die Datenübertragung von Tool B zurück nach Tool A ist schwieriger und erfordert, dass BB1 und BB2 innerhalb von Tool B als Objektgemeinschaft erkannt und somit B zugeordnet werden können. Innerhalb von Tool A wird B1 oder B2 zum Hauptobjekt definiert, welches beim Import nach Tool B BB zugeordnet werden kann. Die Abbildung wird folglich auf 1:1 zurückgeführt. Die Daten des anderen Objektes gehen verloren oder werden über Attributabbildungen verteilt (siehe 2.2). Innerhalb von Tool A wird ein gemeinsames Merkmal beider Objekte definiert, die ihre Zusammengehörigkeit erkennen lassen. Beim Import der Daten aus Tool A wird ein Suchalgorithmus verwendet, der die zusammengehörigen Objekte regelbasiert identifiziert, z. B. über Namen oder Typzugehörigkeit. Die Zuordnung b) z) entspricht einer n:m-abbildung mit n, m > 1. Eine Abbildung dieser Art ist schwierig und lässt sich nur durch eine Kombination mehrerer der genannten Methoden erreichen. Entweder es gelingt eine Reduktion auf 1:1 oder es müssen regelbasierte Methoden eingesetzt werden. Zusammenfassend ist festzustellen, dass eine n:m- Abbildung am einfachsten gelingt, wenn eine Rückführung zu 1:1 möglich ist. Gelingt dies nicht, sind wissensbasierte oder halbmanuelle Methoden das Mittel der Wahl. Diese erschweren jedoch erheblich die Nachvollziehbarkeit für den Planer und den Datenrücktransport. Tabelle 1 fasst die beschriebenen Varianten zusammen und stellt die Realisierungsaufwand derartiger Mappings dar. 1:1 1:n n:m hin o zurück ++ + o Tabelle 1: Bewertung von Objektabbildungsvarianten (++ = sehr gut, + = benötigt spezielle Mappings, 0 = nur mit aufwändigen Mappings realisierbar, - = unmöglich) 2.2 Attributabbildungsprobleme Abbildung 3 zeigt typische Fälle beim Austausch von Attributen. Diese werden im Folgenden näher untersucht und bewertet. a) x) n:1 und n:m Abbildung In der Zuordnung b) x) wird das Objektpaar B1- B2 im Zielwerkzeug durch ein einziges Objekt BB abgebildet und entspricht somit einer 2:1-Abbildung. Diese Objektreduktion tritt in der Praxis dann auf, wenn in Tool B ein allgemeines Objekt ausreicht, um die beiden Ausgangsobjekte gemeinsam zu beschreiben beispielsweise wird ein Tank und ein Stutzen aus Tool A im Tool B nur durch einen allgemeinen Tank abgebildet. Die Abbildung ist über verschiedene Methoden möglich: b) Abbildung 3: Attributabbildungsvarianten Die Abbildung von Attributen aufeinander erscheint einfach, solange sich eine 1:1-Beziehung zwischen y) z)

17 ihnen ermitteln lässt. So könnte in Tool A ein Attribut L dem Attribut Länge in Tool B entsprechen. Durch ein 1:1-Mapping beider Attributnamen wird die Syntax beider Tools entkoppelt und somit irrelevant: reine Syntaxdifferenzen von Attributen können als gelöst betrachtet werden. Die Semantik eines Attributes hingegen, d.h. seine Bedeutung im Kontext, ist durch die Syntax nicht immer ableitbar, auch wenn die Namensgebung die Bedeutung häufig klärt. Die tatsächlich eindeutige Zuordnung von Syntax und Semantik ist eine wesentliche Aufgabe von Normierungsaktivitäten, z. B. [NE100, DIN44366]. In diesen Normen allerdings nicht adressierte Probleme sind die Attributezuordnung zu Objekten, die Attribute-Zusammenführung sowie eine denkbare Attribute-Neuverteilung beim Datenaustausch. Die Attributzuordnung zu Objekten definiert, welche Attribute zu welchen Objekten gehören. Die gegenwärtig vorliegende Wahlfreiheit erschwert den Datenaustausch. Die Attributezusammenführung tritt auf, wenn beispielsweise Tool A die geometrischen Informationen Höhe und Grundfläche eines Körpers definiert, in Tool B jedoch nur das Volumen von Interesse ist. Durch Multiplikation der Höhe und der Grundfläche ist das Volumen errechenbar. Allerdings ist bei einer Volumenänderung keine eindeutige Zuordnung zur Fläche und Höhe mehr möglich. Beim Datentransport von Tool A nach Tool B findet also eine verlustbehaftete Informationsverdichtung statt, die einen eindeutigen Rücktransport verhindert. In diesem Falle sind folgende Methoden anwendbar, um einen bidirektionalen Datenabgleich zu ermöglichen: Attributetransport von Tool A Tool B Für den Transport der Daten von Tool A nach Tool B werden Berechnungsvorschriften verwendet. Beispiel: die Attribute Grundfläche und Höhe werden in Tool B durch die Eigenschaft Volumen abgebildet. Der Datenaustausch von Tool A nach Tool B kann über eine Multiplikation automatisch erfolgen. Attributetransport von Tool B Tool A Beim oder vor dem Rücktransport der Daten von Tool B nach Tool A werden fehlende Informationen explizit erfragt (hier ist also ein aktiver Nutzereingriff in Tool B erforderlich). Vor dem Rücktransport der Daten von Tool B nach Tool A werden die problembehafteten Eigenschaften in einen Zwischenspeicher (Log-Datei, Hilfsattribut etc.) übertragen. Die Einarbeitung wird dem Nutzer von Tool überlassen (hier ist also ein aktiver Nutzereingriff in Tool A erforderlich). Für den Rücktransport der Daten werden Regeln hinterlegt, die fehlende Informationen liefern und den automatischen Rücktransport ermöglichen. Es wird ein reines Forward-Engineering definiert, das die Änderung dieser Daten in Tool B verbietet. Änderungswünsche in Tool A sind auf anderem Weg zu beantragen. Das Problem der Attribute-Neuverteilung ist besonders tückisch, weil sich die Zugehörigkeit von Attributen zu ihren Elternobjekten verändert. In den Fällen a) x) und b) y) ist ein einfaches 1:1-Mapping der Objektattribute möglich. Im Falle a) y) erfolgt eine Verteilung der Attribute a, b und c auf verschiedene Objekte von Tool B. Dies erfordert zum einen die Anwendung einer der beschriebenen Methoden der Objektabbildung sowie eine konkrete Zuordnung der Attribute zu den Zielsubobjekten. Dies ist über ein spezielles Mapping, das die Nennung der Subobjekte zulässt, möglich. Im Falle a) z) werden die Attribute nicht nur auf andere Objekte verteilt, sondern es wird zusätzlich eine Verschiebung der Attribute auf unterschiedliche Hierarchieebenen vorgenommen. Dies erfordert ein Mapping, in dem nicht nur die Subobjekte genannt, sondern auch deren relative Position definiert werden kann. Ist dies nicht definierbar, so ist die Machbarkeit generell in Frage gestellt. Falls eine Aufteilung der Attribute an bestimmte Objekttypen im Elternraum des Objektes AA1 erforderlich ist, kann nur ein Typmapping mit dynamischer Objektbaumsuche helfen. Weitere Fälle adressieren den Datentransport von zersplitterten Attributen in Tool A nach Tool B. Im Falle b) x) ist ein aufwändiges n:1-mapping zu definieren, das z. B. durch Abbildung von A1 auf AA auf eine 1:1 Mapping zurückgeführt werden kann, wobei jedoch die Attribute mit Angabe ihrer Elternobjekte zugeordnet werden müssen. Im Falle b) z) ist die Machbarkeit generell in Frage gestellt, weil die Verteilung von Objektattributen an unabhängige Vaterobjekte ein aufwändiges Regelwerk erfordert. Dies erfordert ein Mapping, in dem nicht nur die Subobjekte genannt, sondern auch deren relative Position definiert werden kann. Falls eine Aufteilung der Attribute an bestimmte Objekttypen im Elternraum des Objektes AA1 erforderlich ist, kann nur ein Typmapping mit dynamischer Objektbaumsuche helfen. Die übrigen dargestellten Fälle verschärfen die gezeigten Attributtransportprobleme noch um den Aspekt einer zusätzlichen hiearchischen Verteilung. Der Fall c) x) muss in ein 1:1 Mapping überführt werden, in dem das Objekt A1 auf AA abgebildet wird. Die entsprechenden Attributemappings erfordern die explizite Abbildung von A1.A2.c auf AA.cc. Dies lässt sich auf den Rücktransport der Attribute übertragen. Der Fall c) y) ist einfach und lässt sich auf ein 1:1-Mapping von A1 zu AA und A2 zu AA2 zurückführen. Die Strukturänderung hingegen erfordert eine zusätzliche Umstrukturierungsoperation, die im nachfolgenden Abschnitt erläutert wird. Der Fall c) z) ist wie in den vorangegangen Beispielen schwierig; die generelle Machbarkeit hängt davon ab, ob die relative Position des Objektes Unit01

18 vom Objekt AA1 definierbar ist. Falls nicht, muss eine dynamische Objektbaumsuche eingesetzt werden: technisch lösbar, aber nicht besonders elegant. X hin/zurück y hin/zurück z hin/zurück a ++/++ +/+ o/o b o/+ ++/++ o/o c +/+ ++/++ o/o Tabelle 2: Bewertung von Attributabbildungsvarianten (++ = sehr gut, + = benötigt spezielle Mappings, 0 = nur mit aufwändigen Mappings realisierbar, - = unmöglich) Tabelle 2 fasst die beschriebenen Varianten zusammen und stellt den Realisierungsaufwand derartiger Mappings dar. Soll neben den einzelnen Objekten auch deren hierarchische Struktur übertragen werden, stößt man in der Praxis häufig auf Struktur-Regeln: so dürfen Objekte innerhalb einer Objektwelt nicht beliebig angeordnet werden: beispielsweise könnte in Tool B die Regel definiert sein, dass I/O-Board-Objekte immer Kinder von Controllerobjekten oder Signalobjekte immer Kinder von Boardobjekten sein müssen. Eine universelle Form des Struktur-Transports besteht in der Ignorierung derartiger Struktur-Regeln. Alle Objekte aus Tool A werden in Tool B zunächst in einen geschützten Bereich importiert unter Wahrung der Originalstruktur aus Tool B. Innerhalb von Tool B erfolgt dann die regelkonforme Umstrukturierung, entweder manuell oder algorithmisch. Über Objekt-IDs können beim wiederholten Datenabgleich Änderungen an diesen Objekten leicht nachgeführt werden. Neue Objekte hingegen müssen bei dieser Variante jedoch aufwendig manuell wieder in die Struktur von Tool B einsortiert werden: bei tausenden Signal- oder Messstellenobjekten ist dies nicht akzeptabel. Daher besteht ein berechtigtes Interesse daran, die Strukturinformationen automatisch übertragen zu können. Die Abbildung unterschiedlicher Strukturen untereinander erfordert hierbei ein Mapping, in welchem zusätzlich Strukturabbildungsoperationen definiert werden können. Typische Strukturabbildungsoperationen sind beispielsweise: Normal: die Vater-Kind-Beziehungen in Tool A werden in Tool B übernommen. Ignore: dieses Objekt wird ignoriert, Kinder werden direkt an den Vater gehängt. IgnoreHierarchy: eine Vater-Kind-Beziehung wird aufgebrochen, das Kind wird auf der selben Ebene wie der Vater eingeordnet. OffsetPath: eine Vater-Kind-Beziehung wird aufgebrochen und eine definierte Zwischenstruktur dazwischengeschoben. Dies wird beispielsweise benötigt, wenn ein Objekt O in Tool A zwangsläufig eine ganze Substruktur in Tool B erzeugt und Kinder von O innerhalb von Tool B in tiefere Ebenen der Substruktur in Tool B eingehängt werden müssen. BreakIncludingMe: dieses Objekt nimmt am Datenaustausch teil, alle Kinder werden jedoch ignoriert. Der Zweig wird also an diesem Objekt abgeschnitten. BreakExcludingMe: dieses Objekt sowie alle Kinder dieses Objekte nehmen nicht am Datenaustausch teil. Abbildung 4 zeigt typische Umstrukturierungsbeispiele. x) 2.3 Strukturabbildungsprobleme c) Abbildung 4: Beispiele für Strukturtransformationen Der Fall c) x) wird dadurch erreicht, indem B1 BB zugeordnet und B2 ignoriert wird. Der Fall c) y) wird erreicht, indem B2 über die Operation IgnoreHierarchy eine Stufe höher gesetzt wird. Der Fall c) z) erfordert eine Kombination aus 1:n Objektabbildungsmethoden und Strukturabbildungsmethoden dar. In diesem Falle müsste B2 über die Operation IgnoreHierarchy eine Stufe höher gesetzt werden und zugleich einem Objektpaar in Tool B zugeordnet werden. Alle genannte Fälle sind kompatibel zu einem bidirektionalen Datenaustausch, solange keine neuen Objekte in Tool B erzeugt werden, die nach Tool A transportiert werden müssen. Dies wird bereits an dem Fall c) x) deutlich: würde in Tool B ein neues Objekt DD erzeugt werden, dann wäre nicht ermittelbar, an welcher Stelle dieses Objekt in der Struktur von Tool A positioniert werden muss. Tabelle 3 fasst die Machbarkeit der diskutierten Strukturtransformationsbeispiele zusammen. y) z) x hin/zurück y hin/zurück z hin/zurück c +/o +/o o/o Tabelle 3: Bewertung von Strukturabbildungsvarianten (++ = sehr gut, + = benötigt spezielle Mappings, 0 = nur mit aufwändigen Mappings realisierbar, - = unmöglich)

19 3 Schlußfolgerungen für die praktische Anwendung Die wichtigste Erkenntnis aus den beschriebenen Problemen besteht darin, dass der Datenaustausch zwischen verschiedenen Objektwelten nicht trivial und kostenfrei ist. Moderne und anpassbare objektorientierte Werkzeuge, in denen jeder Anwender seine eigenen Objekttypen definieren und ändern kann, führen zu verschiedenen oder teilweise sogar orthogonalen Objektwelten. Selbst wenn Anwender dasselbe konfigurierbare Werkzeug verwenden, ist ein Datenaustausch möglicherweise ein komplexer Vorgang: die Verwendung desselben Werkzeuges stellt aufgrund seiner freien Konfigurierbarkeit für diese Aufgabe keinen Vorteil dar. Die Idee, ein Repository außerhalb der Tools A und B einzurichten, stellt ebenfalls keine Lösung dar: die Datenaustauschprobleme würden lediglich zum Repository verlagert, zudem die Synchronisation der vorliegenden Tools A und B mit dem Repository eine zusätzliche Komplexität bedeuted. Ein zuverlässiger, kostenloser, schneller, vollständiger und vor allem automatischer Abgleich zwischen zwei unabhängig entwickelten Objektwelten ohne weiteres Zutun ist technisch folglich nicht möglich. Unkomplizierte Ex- oder Importer, wie aus der Office-Welt für den Datenaustausch mit fremden Office-Werkzeugen bekannt, sind in der objektorientierten Datenwelt nicht machbar, solange die Relationen zwischen den Objektwelten undefiniert sind. Dabei gilt: je starrer und definierter eine Objektwelt ist, desto einfacher ist der Datenaustausch. Umgekehrt gilt: die Freiheit und Flexibilität bei der Datendefinition behindert den Datenaustausch. Insbesondere iterative Änderungen der Objekttypdefinitionen wähend des Engineeringprozesses sind beim Datenaustausch äußerst schwer zu handhaben. Daher sind neben den beschriebenen technischen Lösungen Einschränkungen bei der Entwicklung von Datenaustauschszenarien hilfreich. So ist der bidirektionale Datenaustausch auf Objekt- und Strukturebene in der Industrie zwar auf den ersten Blick ausdrücklich gewünscht, wird aber bei näherem Hinsehen häufig schnell verworfen: denn die Verantwortlichkeit für Objekte und deren Informationen sind meistens entweder Tool A oder Tool B zugeordnet. Der Transport von Objekten von Tool A nach Tool B ist unumstritten sinnvoll, das Rücktransportieren von neuen oder geänderten Objekten nach Tool A jedoch mitunter gefährlich. So steht das Einfügen eines neuen Ventils in eine verfahrenstechnische Anlage in der Kompetenz des Verfahrenstechnikers, nicht jedoch in der des Automatisierungstechnikers. In diesem Falle sind andere Informationswege zu bevorzugen. Ist diese Einschränkung für beide Partner akzeptabel, vereinfacht sich der automatische Datenaustausch beträchtlich. Die Identität der Syntax von Attributen ist wie erläutert tatsächlich ohne Belang: unterschiedliche Syntax kann durch einfaches 1:1-Mapping aufeinander abgebildet werden. Zugleich wird dadurch auch die Identität der Semantik festgelegt. Insofern bleibt bezüglich der Attribute die Problematik der Datenformate, Metriken oder der verlustbehafteten Informationsverdichtung erhalten. Weiterhin ist offensichtlich, dass ähnliche Strukturen in Objektwelten den Datenaustausch erheblich vereinfachen. Gänzlich unterschiedliche Objekthierarchien lassen sich nur manuell übertragen. Alternativ kann der Datenaustausch auf die übereinstimmenden Substrukturen beschränkt werden. Die beschriebenen Objektstruktur-Abbildungsoperationen sind hilfreich, um ein gewisses Maß an Strukturtransformation zu realisieren, allerdings sind gerade Strukturreduktionen verlustbehaftet und behindern eine automatische Zurückübertragung von neu erstellten Objekten. Hier müssen bei Datenaustausch von Tool A nach Tool B zusätzlich Informationen mitgeliefert werden, die definieren, wo neue in Tool B erstellte Objekte in Tool A unterzubringen sind. 4 Zusammenfassung Der vorliegende Beitrag beschreibt typische Problemstellungen des Datenaustausches zwischen objektorientierten Planungswerkzeugen und stellt Lösungsansätze hierfür vor. Zusammenfassend lässt sich feststellen, dass die genannten Problembereiche noch viele Anknüpfungspunkte für weiterführende Forschungstätigkeiten bieten und eine künftige Konvergenz von Standardisierungen, Mappingmethoden und Prozessdefinitionen zu erwarten ist. Künftige gemischte Planungsteams werden nach Ansicht des Autors erheblich zur Vermeidung von Schnittstellen beitragen und die genannten Schnittstellenprobleme werden ihrerseits diesen Trend beschleunigen. 5 Literatur [DIN44366] [EPlan8] [Fay05] [NE100] [Parnas72] [Schül02] Vornorm DIN V Festlegung für die Darstellung von Aufgaben der Prozessleittechnik in Fließbildern und für den Datenaustausch zwischen EDV-Werkzeugen zur Fließbild-Erstellung und CAE-Systemen. Beuth Verlag, Berlin (2004). A. Fay: CAE-Werkzeuge und Integration im Engineering. Vortrag auf der Namur Hauptsitzung in Lahnstein, 10. Nov Namur Empfehlung NE100. D.L. Parnas: Communications of the ACM, Vol. 15, No. 12, December 1972 pp J. Schüler: Workflow / fachübergreifende Integration / eine Utopie?. In VDI-Berichte Nr. 1684, S VDI-Verlag Düsseldort, 2002.

20 Verstehen und Nutzen der Eclipse WTP Architektur. Ein Erfahrungsbericht Jürgen Rückert, Barbara Paech Universität Heidelberg, Fakultät für Mathematik und Informatik, Lehrstuhl Software Engineering {rueckert, Abstract. Die Zahl der Plug-Ins für die Eclipse Plattform wächst zunehmend. Die Basis einer schnellen Entwicklung von Plug-Ins sind geeignete Beschreibungen, wie beispielsweise Architekturmodelle. Architekturmodelle erlauben es wiederverwendbare Komponenten schnell zu identifizieren und Schnittstellen für gewünschte Erweiterungen auf einen Blick zu finden. In diesem Beitrag stellen wir unsere Erfahrungen mit den Architekturmodellen der Eclipse Web Tools Plattform (WTP) vor. Wir zeigen auf, inwieweit diese Beschreibungen Software-Architekten, -Designern und -Entwicklern bei der Beantwortung wichtiger architektonischer Fragen helfen. 1 Einleitung Die Eclipse Web Tools Platform (WTP) [2] erweitert die Eclipse Plattform [1] mit Funktionalität zur Entwicklung von J2EE-basierten Anwendungen [10]. Die WTP bietet eine Reihe von Navigatoren, Wizards und Editoren für HTML, JavaScript, CSS, JSP, SQL, XML, DTD, XSD und WSDL [14] an. Wir haben vor die WTP mit einem neuen Anwendungsfall zur Entwicklung von Web Services zu erweitern. Dabei möchten wir einerseits einen neuen Wizard in die WTP integrieren, andererseits möchten wir bestehende Teile der WTP im Wizard wiederverwenden. Die drei Stakeholder unseres Entwicklungsprojekts, Software-Architekt, -Designer und -Entwickler, haben in den verschiedenen Aufgabenbereichen der Entwicklung Fragen zur Architektur der WTP, die sie mit Endbenutzer-Dokumentation [3], Online-Hilfe [4], Entwickler-Dokumentation [5] und Quellcode [6] zu beantworten versuchen. In Abschnitt 2 stellen wir die damit beantwortbaren, aber auch die unbeantwortbaren Fragen vor. In Abschnitt 3 fassen wir den Beitrag zusammen. 2 Erfahrungen In diesem Abschnitt kategorisieren wir die verwendeten Beschreibungen (2.1), stellen das Meta-Modell der Eclipse Plattform vor (2.1), welches wir aus den Beschreibungen abgeleitet haben, und stellen die Erfahrungen unserer drei Stakeholder vor (2.2 bis 2.4). 2.1 Beschreibungen Die Architektur der WTP ist in [3], [4], [5] und [6] dokumentiert mit Hilfe von folgenden Beschreibungen: Online-Hilfe: Textuelle Beschreibung von Aufgaben und Anwendungsfällen für Endbenutzer. Komponenten-Diagramm: High-Level-Darstellung der Hierarchie von logischen Komponenten für Architekten. Komponenten-Beschreibungen: Textuelle Beschreibungen und Übersichten über Sub-Systeme, Features und Plug-Ins von Eclipse-Teilprojekten für Architekten und Designer. Abbildung 1: Meta-Modell der Eclipse Plattform Paketdiagramm: Darstellung von Abhängigkeiten zwischen Sub-Systemen von Eclipse-Projekten für Designer und Entwickler. Klassendiagramm: Darstellung von Abhängigkeiten zwischen Features oder von Abhängigkeiten zwischen Capabilites für Designer und Entwickler. Manifest-Dateien (XML-Dokumente): Beiträge einer Komponente (Feature, Plug-In, Capability) zur Eclipse Plattform für Designer und Entwickler. Aus der vorgestellten Dokumentation kann das Meta- Modell der Eclipse Plattform abgeleitet werden, welches in Abbildung 1 dargestellt ist. Projekte sind beispielsweise Tools, Web Tools und Test & Performance Tools [8]. Teilprojekte des WTP-Projekts sind beispielsweise WST (Web Standard Tools), JST (J2EE Standard Tools) und JSF (Java Server Faces Tools), wobei das WST-Teilprojekt aus 19 Sub-Systemen besteht, die teilweise voneinander abhängen. Die Features von Sub- Systemen stellen die kleinste Auslieferungseinheit dar, deren Plug-Ins die kleinste Entwicklungseinheit. Das WST- Teilprojekt beispielsweise besteht aus 141 Plug-Ins. Plug- Ins sind häufig so stark gekoppelt, dass eine Wiederverwendung unmöglich wird [18]. 2.2 Fragen des Architekten F.1.1 Aus welchen Komponenten besteht die WTP? Eine zuverlässige Antwort gibt die Verzeichnisstruktur des Quellcodes, die eine Namenskonvention [7] erfüllt. F.1.2 Welche Funktionalität bietet die WTP? Zur Beantwortung wird ein Nutzungs-Modell benötigt, welches Rollen, Aufgaben, Nutzungsfälle und Systemfunktionen in Beziehung setzt, welches derzeit aber nicht verwendet wird. Die Aufgaben-orientierte Softwareentwicklung [12] setzt bereits ein solche Modell ein. F.1.3 Mit welchen Komponenten der WTP wird welche Funktionalität umgesetzt? Zur Beantwortung wird ein Dienst-Modell benötigt, welches Systemfunktionen (Dienste) mit architektonischen Komponenten in Beziehung setzt. Ein solches Modell existiert derzeit nicht. F.1.4 Welche Komponenten bieten welche Schnittstellen an? Die Antwort geben die Manifeste von Features und Plug-Ins (siehe Quellcode [6]).

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle Mit Legacy-Systemen in die Zukunft Dr. Roland Schätzle Der Weg zur Entscheidung 2 Situation Geschäftliche und softwaretechnische Qualität der aktuellen Lösung? Lohnen sich weitere Investitionen? Migration??

Mehr

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena http://www.im.uni-jena.de Contents I. Learning Objectives II. III. IV. Recap

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

Support Technologies based on Bi-Modal Network Analysis. H. Ulrich Hoppe. Virtuelles Arbeiten und Lernen in projektartigen Netzwerken

Support Technologies based on Bi-Modal Network Analysis. H. Ulrich Hoppe. Virtuelles Arbeiten und Lernen in projektartigen Netzwerken Support Technologies based on Bi-Modal Network Analysis H. Agenda 1. Network analysis short introduction 2. Supporting the development of virtual organizations 3. Supporting the development of compentences

Mehr

Software development with continuous integration

Software development with continuous integration Software development with continuous integration (FESG/MPIfR) ettl@fs.wettzell.de (FESG) neidhardt@fs.wettzell.de 1 A critical view on scientific software Tendency to become complex and unstructured Highly

Mehr

XML Template Transfer Transfer project templates easily between systems

XML Template Transfer Transfer project templates easily between systems Transfer project templates easily between systems A PLM Consulting Solution Public The consulting solution XML Template Transfer enables you to easily reuse existing project templates in different PPM

Mehr

PART 3: MODELLING BUSINESS PROCESSES EVENT-DRIVEN PROCESS CHAINS (EPC)

PART 3: MODELLING BUSINESS PROCESSES EVENT-DRIVEN PROCESS CHAINS (EPC) Information Management II / ERP: Microsoft Dynamics NAV 2009 Page 1 of 5 PART 3: MODELLING BUSINESS PROCESSES EVENT-DRIVEN PROCESS CHAINS (EPC) Event-driven Process Chains are, in simple terms, some kind

Mehr

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Eine Betrachtung im Kontext der Ausgliederung von Chrysler Daniel Rheinbay Abstract Betriebliche Informationssysteme

Mehr

Software Engineering verteilter Systeme. Hauptseminar im WS 2011 / 2012

Software Engineering verteilter Systeme. Hauptseminar im WS 2011 / 2012 Software Engineering verteilter Systeme Hauptseminar im WS 2011 / 2012 Model-based Testing(MBT) Christian Saad (1-2 students) Context Models (e.g. State Machines) are used to define a system s behavior

Mehr

CHAMPIONS Communication and Dissemination

CHAMPIONS Communication and Dissemination CHAMPIONS Communication and Dissemination Europa Programm Center Im Freistaat Thüringen In Trägerschaft des TIAW e. V. 1 CENTRAL EUROPE PROGRAMME CENTRAL EUROPE PROGRAMME -ist als größtes Aufbauprogramm

Mehr

Titelbild1 ANSYS. Customer Portal LogIn

Titelbild1 ANSYS. Customer Portal LogIn Titelbild1 ANSYS Customer Portal LogIn 1 Neuanmeldung Neuanmeldung: Bitte Not yet a member anklicken Adressen-Check Adressdaten eintragen Customer No. ist hier bereits erforderlich HERE - Button Hier nochmal

Mehr

Ways and methods to secure customer satisfaction at the example of a building subcontractor

Ways and methods to secure customer satisfaction at the example of a building subcontractor Abstract The thesis on hand deals with customer satisfaction at the example of a building subcontractor. Due to the problems in the building branch, it is nowadays necessary to act customer oriented. Customer

Mehr

Wieviel Usability Engineering braucht das Software Engineering?

Wieviel Usability Engineering braucht das Software Engineering? Wieviel Usability Engineering braucht das Software Engineering? Prof. Dr. Institut für Informatik Neuenheimer Feld 348 69120 Heidelberg http://www-swe.uni-heidelberg.de paech@informatik.uni-heidelberg.de

Mehr

TMF projects on IT infrastructure for clinical research

TMF projects on IT infrastructure for clinical research Welcome! TMF projects on IT infrastructure for clinical research R. Speer Telematikplattform für Medizinische Forschungsnetze (TMF) e.v. Berlin Telematikplattform für Medizinische Forschungsnetze (TMF)

Mehr

CMMI for Embedded Systems Development

CMMI for Embedded Systems Development CMMI for Embedded Systems Development O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software Engineering Gruppe Leiter des Fachbereichs Informatik cs.uni-salzburg.at Inhalt Projekt-Kontext CMMI FIT-IT-Projekt

Mehr

Cloud Architektur Workshop

Cloud Architektur Workshop Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell

Mehr

SAP PPM Enhanced Field and Tab Control

SAP PPM Enhanced Field and Tab Control SAP PPM Enhanced Field and Tab Control A PPM Consulting Solution Public Enhanced Field and Tab Control Enhanced Field and Tab Control gives you the opportunity to control your fields of items and decision

Mehr

Wie agil kann Business Analyse sein?

Wie agil kann Business Analyse sein? Wie agil kann Business Analyse sein? Chapter Meeting Michael Leber 2012-01-24 ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define

Mehr

1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3

1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3 User Manual for Marketing Authorisation and Lifecycle Management of Medicines Inhalt: User Manual for Marketing Authorisation and Lifecycle Management of Medicines... 1 1. General information... 2 2. Login...

Mehr

Distributed testing. Demo Video

Distributed testing. Demo Video distributed testing Das intunify Team An der Entwicklung der Testsystem-Software arbeiten wir als Team von Software-Spezialisten und Designern der soft2tec GmbH in Kooperation mit der Universität Osnabrück.

Mehr

EEX Kundeninformation 2007-09-05

EEX Kundeninformation 2007-09-05 EEX Eurex Release 10.0: Dokumentation Windows Server 2003 auf Workstations; Windows Server 2003 Service Pack 2: Information bezüglich Support Sehr geehrte Handelsteilnehmer, Im Rahmen von Eurex Release

Mehr

Software-Architecture Introduction

Software-Architecture Introduction Software-Architecture Introduction Prof. Dr. Axel Böttcher Summer Term 2011 3. Oktober 2011 Overview 2 hours lecture, 2 hours lab sessions per week. Certificate ( Schein ) is prerequisite for admittanceto

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich?

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich? KURZANLEITUNG Firmware-Upgrade: Wie geht das eigentlich? Die Firmware ist eine Software, die auf der IP-Kamera installiert ist und alle Funktionen des Gerätes steuert. Nach dem Firmware-Update stehen Ihnen

Mehr

Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part II) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Mehr

A Practical Approach for Reliable Pre-Project Effort Estimation

A Practical Approach for Reliable Pre-Project Effort Estimation A Practical Approach for Reliable Pre-Project Effort Estimation Carl Friedrich Kreß 1, Oliver Hummel 2, Mahmudul Huq 1 1 Cost Xpert AG, Augsburg, Germany {Carl.Friedrich.Kress,Mahmudul.Huq}@CostXpert.de

Mehr

USBASIC SAFETY IN NUMBERS

USBASIC SAFETY IN NUMBERS USBASIC SAFETY IN NUMBERS #1.Current Normalisation Ropes Courses and Ropes Course Elements can conform to one or more of the following European Norms: -EN 362 Carabiner Norm -EN 795B Connector Norm -EN

Mehr

A central repository for gridded data in the MeteoSwiss Data Warehouse

A central repository for gridded data in the MeteoSwiss Data Warehouse A central repository for gridded data in the MeteoSwiss Data Warehouse, Zürich M2: Data Rescue management, quality and homogenization September 16th, 2010 Data Coordination, MeteoSwiss 1 Agenda Short introduction

Mehr

Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas. Mr. Niemczik, Mr. Koppatz (SuDiLe GbR)

Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas. Mr. Niemczik, Mr. Koppatz (SuDiLe GbR) Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas in cooperation with Mr. Niemczik, Mr. Koppatz (SuDiLe GbR) Our idea: Fachbereich Wirtschaft, Verwaltung und Recht Simple strategies of lifelong

Mehr

Introduction to the diploma and master seminar in FSS 2010. Prof. Dr. Armin Heinzl. Sven Scheibmayr

Introduction to the diploma and master seminar in FSS 2010. Prof. Dr. Armin Heinzl. Sven Scheibmayr Contemporary Aspects in Information Systems Introduction to the diploma and master seminar in FSS 2010 Chair of Business Administration and Information Systems Prof. Dr. Armin Heinzl Sven Scheibmayr Objective

Mehr

Introducing PAThWay. Structured and methodical performance engineering. Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt

Introducing PAThWay. Structured and methodical performance engineering. Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt Introducing PAThWay Structured and methodical performance engineering Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt Technical University of Munich Overview Tuning Challenges

Mehr

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part XI) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Mehr

Strategies for Random Contract-Based Testing

Strategies for Random Contract-Based Testing DISS. ETH NO. 18143 Strategies for Random Contract-Based Testing A dissertation submitted to ETH ZURICH for the degree of Doctor of Sciences presented by ILINCA CIUPA Dipl. Eng., Technical University of

Mehr

Understanding and Improving Collaboration in Distributed Software Development

Understanding and Improving Collaboration in Distributed Software Development Diss. ETH No. 22473 Understanding and Improving Collaboration in Distributed Software Development A thesis submitted to attain the degree of DOCTOR OF SCIENCES of ETH ZURICH (Dr. sc. ETH Zurich) presented

Mehr

(Prüfungs-)Aufgaben zum Thema Scheduling

(Prüfungs-)Aufgaben zum Thema Scheduling (Prüfungs-)Aufgaben zum Thema Scheduling 1) Geben Sie die beiden wichtigsten Kriterien bei der Wahl der Größe des Quantums beim Round-Robin-Scheduling an. 2) In welchen Situationen und von welchen (Betriebssystem-)Routinen

Mehr

Possible Solutions for Development of Multilevel Pension System in the Republic of Azerbaijan

Possible Solutions for Development of Multilevel Pension System in the Republic of Azerbaijan Possible Solutions for Development of Multilevel Pension System in the Republic of Azerbaijan by Prof. Dr. Heinz-Dietrich Steinmeyer Introduction Multi-level pension systems Different approaches Different

Mehr

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank SwissICT 2011 am Fallbeispiel einer Schweizer Bank Fritz Kleiner, fritz.kleiner@futureways.ch future ways Agenda Begriffsklärung Funktionen und Aspekte eines IT-Servicekataloges Fallbeispiel eines IT-Servicekataloges

Mehr

Exploring the knowledge in Semi Structured Data Sets with Rich Queries

Exploring the knowledge in Semi Structured Data Sets with Rich Queries Exploring the knowledge in Semi Structured Data Sets with Rich Queries Jürgen Umbrich Sebastian Blohm Institut AIFB, Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 www.kit.ed Overview

Mehr

An Open Innovation Technology Transfer Concept - R&D Cooperation for breakthrough Technologies between Academic Spin-Offs and established Industry

An Open Innovation Technology Transfer Concept - R&D Cooperation for breakthrough Technologies between Academic Spin-Offs and established Industry Diss ETH NO. 20731 An Open Innovation Technology Transfer Concept - R&D Cooperation for breakthrough Technologies between Academic Spin-Offs and established Industry A dissertation submitted to ETH ZURICH

Mehr

p^db=`oj===pìééçêíáåñçêã~íáçå=

p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for

Mehr

Service Design. Dirk Hemmerden - Appseleration GmbH. Mittwoch, 18. September 13

Service Design. Dirk Hemmerden - Appseleration GmbH. Mittwoch, 18. September 13 Service Design Dirk Hemmerden - Appseleration GmbH An increasing number of customers is tied in a mobile eco-system Hardware Advertising Software Devices Operating System Apps and App Stores Payment and

Mehr

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten 1 Qualifikation Über den Vortragenden Freiberuflicher SW-Entwickler und Berater seit 2006 Certified Scrum

Mehr

DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS

DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS Master Seminar Empirical Software Engineering Anuradha Ganapathi Rathnachalam Institut für Informatik Software & Systems Engineering Agenda Introduction

Mehr

Softwareentwicklung & Usability Software Development & Usability

Softwareentwicklung & Usability Software Development & Usability Softwareentwicklung & Usability Software Development & Usability mobile media & communication lab Das m²c-lab der FH Aachen leistet Forschungs- und Entwicklungsarbeiten für individuelle und innovative

Mehr

Scrum @FH Biel. Scrum Einführung mit «Electronical Newsletter» FH Biel, 12. Januar 2012. Folie 1 12. Januar 2012. Frank Buchli

Scrum @FH Biel. Scrum Einführung mit «Electronical Newsletter» FH Biel, 12. Januar 2012. Folie 1 12. Januar 2012. Frank Buchli Scrum @FH Biel Scrum Einführung mit «Electronical Newsletter» FH Biel, 12. Januar 2012 Folie 1 12. Januar 2012 Frank Buchli Zu meiner Person Frank Buchli MS in Computer Science, Uni Bern 2003 3 Jahre IT

Mehr

Algorithms for graph visualization

Algorithms for graph visualization Algorithms for graph visualization Project - Orthogonal Grid Layout with Small Area W INTER SEMESTER 2013/2014 Martin No llenburg KIT Universita t des Landes Baden-Wu rttemberg und nationales Forschungszentrum

Mehr

Übersicht. Normung von Software in der Medizin. Vorstellung der DKE. Vorstellung der Normungsgremien. Normen im Bereich Software.

Übersicht. Normung von Software in der Medizin. Vorstellung der DKE. Vorstellung der Normungsgremien. Normen im Bereich Software. Normung von Software in der Medizin Übersicht Vorstellung der DKE Vorstellung der Normungsgremien Normen im Bereich Software Zukunftstrends 20.09.2013/1 Vorstellung der DKE Gemeinnütziger Verband ohne

Mehr

SOA Service Oriented Architecture

SOA Service Oriented Architecture SOA Service Oriented Architecture (c) Till Hänisch 2006, BA Heidenheim [IBM] [WS] Wir haben: Prog ramm Proxy Proxy K2 K1 Plattformunabhängiger RPC Wir haben: Prog ramm Proxy Proxy K2 K1 Plattformunabhängiger

Mehr

PRESS RELEASE. Kundenspezifische Lichtlösungen von MENTOR

PRESS RELEASE. Kundenspezifische Lichtlösungen von MENTOR Kundenspezifische Lichtlösungen von MENTOR Mit Licht Mehrwert schaffen. Immer mehr Designer, Entwicklungsingenieure und Produktverantwortliche erkennen das Potential innovativer Lichtkonzepte für ihre

Mehr

Universität Dortmund Integrating Knowledge Discovery into Knowledge Management

Universität Dortmund Integrating Knowledge Discovery into Knowledge Management Integrating Knowledge Discovery into Knowledge Management Katharina Morik, Christian Hüppe, Klaus Unterstein Univ. Dortmund LS8 www-ai.cs.uni-dortmund.de Overview Integrating given data into a knowledge

Mehr

eurex rundschreiben 094/10

eurex rundschreiben 094/10 eurex rundschreiben 094/10 Datum: Frankfurt, 21. Mai 2010 Empfänger: Alle Handelsteilnehmer der Eurex Deutschland und Eurex Zürich sowie Vendoren Autorisiert von: Jürg Spillmann Weitere Informationen zur

Mehr

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Zielsetzung: System Verwendung von Cloud-Systemen für das Hosting von online Spielen (IaaS) Reservieren/Buchen von Resources

Mehr

Michael Piechotta - CASE Tools. openarchitecture Ware

Michael Piechotta - CASE Tools. openarchitecture Ware Model Driven Development Michael Piechotta - CASE Tools openarchitecture Ware Gliederung 1.Einleitung - Was ist MDD? - Wozu MDD? 2.Model Driven Development - OMG Konzepte: Modelle,Transformationen Meta-Modellierung

Mehr

Chemical heat storage using Na-leach

Chemical heat storage using Na-leach Hilfe2 Materials Science & Technology Chemical heat storage using Na-leach Robert Weber Empa, Material Science and Technology Building Technologies Laboratory CH 8600 Dübendorf Folie 1 Hilfe2 Diese Folie

Mehr

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis Der Vortrag zeigt anhand von Fallbeispielen auf, wie sich SOA durch die Kombination

Mehr

Field Librarianship in den USA

Field Librarianship in den USA Field Librarianship in den USA Bestandsaufnahme und Zukunftsperspektiven Vorschau subject librarians field librarians in den USA embedded librarians das amerikanische Hochschulwesen Zukunftsperspektiven

Mehr

Ingenics Project Portal

Ingenics Project Portal Version: 00; Status: E Seite: 1/6 This document is drawn to show the functions of the project portal developed by Ingenics AG. To use the portal enter the following URL in your Browser: https://projectportal.ingenics.de

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Role Play I: Ms Minor Role Card. Ms Minor, accountant at BIGBOSS Inc.

Role Play I: Ms Minor Role Card. Ms Minor, accountant at BIGBOSS Inc. Role Play I: Ms Minor Role Card Conversation between Ms Boss, CEO of BIGBOSS Inc. and Ms Minor, accountant at BIGBOSS Inc. Ms Boss: Guten Morgen, Frau Minor! Guten Morgen, Herr Boss! Frau Minor, bald steht

Mehr

Labour law and Consumer protection principles usage in non-state pension system

Labour law and Consumer protection principles usage in non-state pension system Labour law and Consumer protection principles usage in non-state pension system by Prof. Dr. Heinz-Dietrich Steinmeyer General Remarks In private non state pensions systems usually three actors Employer

Mehr

Working Sets for the Principle of Least Privilege in Role Based Access Control (RBAC) and Desktop Operating Systems DISSERTATION

Working Sets for the Principle of Least Privilege in Role Based Access Control (RBAC) and Desktop Operating Systems DISSERTATION UNIVERSITÄT JOHANNES KEPLER LINZ JKU Technisch-Naturwissenschaftliche Fakultät Working Sets for the Principle of Least Privilege in Role Based Access Control (RBAC) and Desktop Operating Systems DISSERTATION

Mehr

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2 ReadMe zur Installation der BRICKware for Windows, Version 6.1.2 Seiten 2-4 ReadMe on Installing BRICKware for Windows, Version 6.1.2 Pages 5/6 BRICKware for Windows ReadMe 1 1 BRICKware for Windows, Version

Mehr

Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH

Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH What is a GEVER??? Office Strategy OXBA How we used SharePoint Geschäft Verwaltung Case Management Manage Dossiers Create and Manage Activities

Mehr

ColdFusion 8 PDF-Integration

ColdFusion 8 PDF-Integration ColdFusion 8 PDF-Integration Sven Ramuschkat SRamuschkat@herrlich-ramuschkat.de München & Zürich, März 2009 PDF Funktionalitäten 1. Auslesen und Befüllen von PDF-Formularen 2. Umwandlung von HTML-Seiten

Mehr

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg "GIPS Aperitif" 15. April 2010 Referat von Stefan Illmer

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg GIPS Aperitif 15. April 2010 Referat von Stefan Illmer GIPS 2010 Gesamtüberblick Dr. Stefan J. Illmer Credit Suisse Agenda Ein bisschen Historie - GIPS 2010 Fundamentals of Compliance Compliance Statement Seite 3 15.04.2010 Agenda Ein bisschen Historie - GIPS

Mehr

Architekturen und LEGO Was wir von Kindern für Systemarchitekturen lernen können

Architekturen und LEGO Was wir von Kindern für Systemarchitekturen lernen können Architekturen und LEGO Was wir von Kindern für Systemarchitekturen lernen können Wachtberg, 2011/01/24 Dr. Frank Simon Head of SQS Research SQS Software Quality Systems AG Agenda Architekturen: (Komplexe)

Mehr

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen.

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. Stefan Topp Honeywell International SARL 16. Februar 2012 Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. 1 Agenda Hintergruende Der Auswahlprozess Ausrollen von

Mehr

BIM Forum Serviceorientierung ein wichtiger Faktor für ein erfolgreiches IT Service Management

BIM Forum Serviceorientierung ein wichtiger Faktor für ein erfolgreiches IT Service Management - ein Kooperationspartner von BIM www.futureways.ch SwissICT 2011 BIM Forum Serviceorientierung ein wichtiger Faktor für ein erfolgreiches IT Service Management Fritz Kleiner, fritz.kleiner@futureways.ch

Mehr

Business Process Management. Cloud und Mobile Computing. BPMday 2013 Köln, 13. November 2013. Enzo Favuzzi - Sales Manager WebCenter & BPM

Business Process Management. Cloud und Mobile Computing. BPMday 2013 Köln, 13. November 2013. Enzo Favuzzi - Sales Manager WebCenter & BPM Business Process Management von Cloud und Mobile Computing BPMday 2013 Köln, 13. November 2013 Enzo Favuzzi - Sales Manager WebCenter & BPM Safe Harbor Statement The

Mehr

Seminar in Requirements Engineering

Seminar in Requirements Engineering Seminar in Requirements Engineering Vorbesprechung Frühjahrssemester 2010 22. Februar 2010 Prof. Dr. Martin Glinz Dr. Samuel Fricker Eya Ben Charrada Inhalt und Lernziele Software Produktmanagement Ziele,

Mehr

The poetry of school.

The poetry of school. International Week 2015 The poetry of school. The pedagogy of transfers and transitions at the Lower Austrian University College of Teacher Education(PH NÖ) Andreas Bieringer In M. Bernard s class, school

Mehr

Safer Software Formale Methoden für ISO26262

Safer Software Formale Methoden für ISO26262 Safer Software Formale Methoden für ISO26262 Dr. Stefan Gulan COC Systems Engineering Functional Safety Entwicklung Was Wie Wie genau Anforderungen Design Produkt Seite 3 Entwicklung nach ISO26262 Funktionale

Mehr

SARA 1. Project Meeting

SARA 1. Project Meeting SARA 1. Project Meeting Energy Concepts, BMS and Monitoring Integration of Simulation Assisted Control Systems for Innovative Energy Devices Prof. Dr. Ursula Eicker Dr. Jürgen Schumacher Dirk Pietruschka,

Mehr

Mash-Up Personal Learning Environments. Dr. Hendrik Drachsler

Mash-Up Personal Learning Environments. Dr. Hendrik Drachsler Decision Support for Learners in Mash-Up Personal Learning Environments Dr. Hendrik Drachsler Personal Nowadays Environments Blog Reader More Information Providers Social Bookmarking Various Communities

Mehr

Frequently asked Questions for Kaercher Citrix (apps.kaercher.com)

Frequently asked Questions for Kaercher Citrix (apps.kaercher.com) Frequently asked Questions for Kaercher Citrix (apps.kaercher.com) Inhalt Content Citrix-Anmeldung Login to Citrix Was bedeutet PIN und Token (bei Anmeldungen aus dem Internet)? What does PIN and Token

Mehr

TomTom WEBFLEET Tachograph

TomTom WEBFLEET Tachograph TomTom WEBFLEET Tachograph Installation TG, 17.06.2013 Terms & Conditions Customers can sign-up for WEBFLEET Tachograph Management using the additional services form. Remote download Price: NAT: 9,90.-/EU:

Mehr

Praktikum Entwicklung von Mediensystemen mit ios

Praktikum Entwicklung von Mediensystemen mit ios Praktikum Entwicklung von Mediensystemen mit ios WS 2011 Prof. Dr. Michael Rohs michael.rohs@ifi.lmu.de MHCI Lab, LMU München Today Heuristische Evaluation vorstellen Aktuellen Stand Software Prototyp

Mehr

Extended Ordered Paired Comparison Models An Application to the Data from Bundesliga Season 2013/14

Extended Ordered Paired Comparison Models An Application to the Data from Bundesliga Season 2013/14 Etended Ordered Paired Comparison Models An Application to the Data from Bundesliga Season 2013/14 Gerhard Tutz & Gunther Schauberger Ludwig-Maimilians-Universität München Akademiestraße 1, 80799 München

Mehr

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz IDS Lizenzierung für IDS und HDR Primärserver IDS Lizenz HDR Lizenz Workgroup V7.3x oder V9.x Required Not Available Primärserver Express V10.0 Workgroup V10.0 Enterprise V7.3x, V9.x or V10.0 IDS Lizenz

Mehr

Handel der Zukunft Future Commerce

Handel der Zukunft Future Commerce Handel der Zukunft Future Commerce mobile media & communication lab Das m²c-lab der FH Aachen leistet Forschungs- und Entwicklungsarbeiten für individuelle und innovative Lösungen im Bereich der mobilen

Mehr

Klausur Verteilte Systeme

Klausur Verteilte Systeme Klausur Verteilte Systeme SS 2005 by Prof. Walter Kriha Klausur Verteilte Systeme: SS 2005 by Prof. Walter Kriha Note Bitte ausfüllen (Fill in please): Vorname: Nachname: Matrikelnummer: Studiengang: Table

Mehr

Stefan Mieth, AIT GmbH & Co. KG

Stefan Mieth, AIT GmbH & Co. KG Stefan Mieth, AIT GmbH & Co KG As a requirements engineer I want to use the TFS 12032015; 16:30 17:30 Requirements Engineering ist neben Testing wohl der Dauerbrenner, wenn es um gerne vernachlässigte

Mehr

IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database

IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database First European i2b2 Academic User Meeting IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database The IDRT Team (in alphabetical order): Christian Bauer (presenter), Benjamin

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Modul Strategic Management (PGM-07)

Modul Strategic Management (PGM-07) Modul Strategic Management (PGM-07) Beschreibung u. Ziele des Moduls Dieses Modul stellt als eine der wesentlichen Formen wirtschaftlichen Denkens und Handelns den strategischen Ansatz vor. Es gibt einen

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

! " #! $! % & ' ' (! " # # $

!  #! $! % & ' ' (!  # # $ ! " #! $! % & ' ' (! " # # $ Abstract Software integration testing can be divided into three sections: The static analysis, the symbolic execution and the dynamic test. While the static analysis exposes

Mehr

Delivering services in a user-focussed way - The new DFN-CERT Portal -

Delivering services in a user-focussed way - The new DFN-CERT Portal - Delivering services in a user-focussed way - The new DFN-CERT Portal - 29th TF-CSIRT Meeting in Hamburg 25. January 2010 Marcus Pattloch (cert@dfn.de) How do we deal with the ever growing workload? 29th

Mehr

An Introduction to Monetary Theory. Rudolf Peto

An Introduction to Monetary Theory. Rudolf Peto An Introduction to Monetary Theory Rudolf Peto 0 Copyright 2013 by Prof. Rudolf Peto, Bielefeld (Germany), www.peto-online.net 1 2 Preface This book is mainly a translation of the theoretical part of my

Mehr

TOGAF The Open Group Architecture Framework

TOGAF The Open Group Architecture Framework TOGAF The Open Group Architecture Ein Überblick Gesellschaft für Informatik, Regionalgruppe München Dr. Michael Bulenda München, 7.12.2009 Vorstellung Dr. M. Bulenda Seit 2001 bei Cirquent IT Management

Mehr

Toolunterstützte Validierung der Anforderungsabdeckung

Toolunterstützte Validierung der Anforderungsabdeckung Wir nehmen Kurs auf Ihren Erfolg Toolunterstützte Validierung der Anforderungsabdeckung Businessanalyse toolunterstützt DI Mag. Martin Lachkovics 1040 Wien, Operngasse 17-21 Agenda Die heikle Aufgabe der

Mehr

Porsche Consulting. Operational excellence successful processes from the automotive industry and their applications in medical technology

Porsche Consulting. Operational excellence successful processes from the automotive industry and their applications in medical technology Porsche Consulting Operational excellence successful processes from the automotive industry and their applications in medical technology Especially crucial in medical technology: a healthy company. Germany

Mehr

ITIL & TOGAF die Doppelspitze für IT Governance

ITIL & TOGAF die Doppelspitze für IT Governance 1 ITIL Day 2014 ITIL & TOGAF die Doppelspitze für IT Governance Referenten: Arif Chughtai, Matthias Gessenay 2 Referenten Arif Chughtai mail@arifchughtai.org www.arifchughtai.org Matthias Gessenay matthias.gessenay@corporatesoftware.ch

Mehr