DOKTORANDENSYMPOSIUM DER SOFTWARE ENGINEERING 2012 PROCEEDINGS

Transkript

1 Faculty of Mathematics, Natural Sciences and Computer Science Institute of Computer Science COMPUTER SCIENCE REPORTS Report 01/12 February 2012 DOKTORANDENSYMPOSIUM DER SOFTWARE ENGINEERING 2012 PROCEEDINGS PETRA HOFSTEDT CLAUS LEWERENTZ

2 Computer Science Reports Brandenburg University of Technology Cottbus ISSN: Send requests to: BTU Cottbus Institut für Informatik Postfach D Cottbus

3 Petra Hofstedt, Claus Lewerentz (Eds.) Doktorandensymposium der Software Engineering (SE) 2012 Proceedings Computer Science Reports 01/12 February 2012 Brandenburg University of Technology Cottbus Faculty of Mathematics, Natural Sciences and Computer Science Institute of Computer Science

4 Computer Science Reports Brandenburg University of Technology Cottbus Institute of Computer Science Head of Institute: Prof. Dr. Hartmut König BTU Cottbus Institut für Informatik Postfach D Cottbus Research Groups: Computer Engineering Computer Network and Communication Systems Data Structures and Software Dependability Database and Information Systems Programming Languages and Compiler Construction Software and Systems Engineering Theoretical Computer Science Graphics Systems Systems Distributed Systems and Operating Systems Internet-Technology Headed by: Prof. Dr. H. Th. Vierhaus Prof. Dr. H. König Prof. Dr. M. Heiner Prof. Dr. I. Schmitt Prof. Dr. P. Hofstedt Prof. Dr. C. Lewerentz Prof. Dr. K. Meer Prof. Dr. D. Cunningham Prof. Dr. R. Kraemer Prof. Dr. J. Nolte Prof. Dr. G. Wagner CR Subject Classification (1998): D.2, D.2.1, D.2.2, D.2.9, D.2.10, D.2.11, H.1.2, H.4.1, J.1, K.4.3 Printing and Binding: BTU Cottbus ISSN:

5 Vorwort Der vorliegende Tagungsband enthält die Beiträge des Doktorandensymposiums (DS-SE) der Software-Engineering SE 2012, das am 29. Februar 2012 an der Technischen Universität Berlin stattfindet. Im Rahmen des Doktorandensymposiums stellen promovierende junge Wissenschaftlerinnen und Wissenschaftler ihr Forschungsvorhaben auf dem Gebiet der Softwaretechnik und ggf. erste Ergebnisse vor. Das Symposium soll die Teilnehmer unterstützen, Kontakte zu anderen Forscherinnen und Forschern zu knüpfen, deren Arbeiten kennen zu lernen und sich auszutauschen. Sie erhalten von erfahrenen Forscherinnen und Forschern und anderen Doktorandinnen und Doktoranden außerhalb ihrer Forschungsgruppe konstruktive Rückkopplung zu ihren Dissertationsvorhaben. Im Doktorandensymposium steht die Diskussion der Arbeiten im Vordergrund. Darüber hinaus enthält das Programm zwei themenübergreifende Vorträge: Prof. Walter Tichy (KIT, Universität Karlsruhe) (Eingeladener Vortrag): "Forschungsmethodik in der Softwaretechnik Prof. Claus Lewerentz (BTU Cottbus): "Schreiben einer Dissertation: Traum oder Albtraum?" Zum Abschluss findet eine Podiumsdiskussion zum Thema "Promovieren in der Softwaretechnik" statt. Wir möchten uns ganz herzlich bei den Autoren der Beiträge, unserem eingeladenen Vortragenden und den Teilnehmern der Podiumsdiskussion, aber auch bei den Mitgliedern des Programmkomitees und den Reviewern bedanken. Wir wünschen allen Teilnehmern ein erfolgreiches Doktorandensymposium DS-SE 2012! 22. Februar 2012 Petra Hofstedt und Claus Lewerentz Organisation Petra Hofstedt, Claus Lewerentz Brandenburgische Technische Universtiät Cottbus Programmkomitee: Jürgen Ebert (Universität Koblenz-Landau) Gregor Engels (Universität Paderborn) Petra Hofstedt (Brandenburgische Technische Universität Cottbus) Jens Knoop (Technische Universität Wien) Claus Lewerentz (Brandenburgische Technische Universität Cottbus) Horst Lichter (Rheinisch-Westfälische Technische Hochschule Aachen) Alexander Pretschner (Karlsruher Institut für Technologie KIT) Andreas Winter (Universität Oldenburg) Heinz Zuellighoven (Universität Hamburg)

6 DS-SE vi

7 Programm Beiträge 1 Automatische Generierung von Beschriftungsvorschlägen für Aktivitäten in Geschäftsprozessmodellen Jan Christian Krause 7 Ein Ansatz zur Anpassung von Software Engineering Methoden im laufenden Projekt Silke Geisen 13 Organisatorische Einflussfaktoren und sozialer Kontext im Architekturdesign Frederik Schulz und Johannes Meißner 19 Model-based Multilateral Optimizing for Service-Oriented Architectures Focusing on Compliance Driven Security Stephan Faßbender 25 Supporting the Development and Documentation of Trustworthy ICT Systems according to Security Standards through Patterns and Security Requirements Engineering Approaches Kristian Beckers Vorträge 31 Forschungsmethodik in der Softwaretechnik (Eingeladener Vortrag) Walter F. Tichy 55 Schreiben einer Dissertation: Traum oder Albtraum? Claus Lewerentz 67 Index der Autoren DS-SE vii

8 DS-SE viii

9 Automatische Generierung von Beschriftungsvorschlägen für Aktivitäten in Geschäftsprozessmodellen Jan Christian Krause AKRA GmbH Domstraße Hamburg Abstract: Semi-formale Prozessmodelle beschreiben häufig, wie Software-Systeme den zugrunde liegenden Geschäftsprozess unterstützen. Dabei kommt den Beschriftungen von Modellelementen eine wichtige Rolle für das Verständnis des Gesamtmodells zu. Dieses Dokument motiviert einen Software-Assistenten, welcher Vorschläge für Beschriftungen von Aktivitäten auf Basis linguistischer Analysen erstellt. In die Vorschlagsgenerierung gehen sowohl das Prozessmodell selbst, als auch die Dokumentation der referenzierten Software-Systeme ein. So unterstützt der Assistent den Modellierer beim Formulieren von einfach verständlichen und konsistenten Beschriftungen. Auf diese Weise optimierte Prozessmodelle können zur Vermeidung von Missverständnissen und somit zur Senkung von Entwicklungs- und Wartungskosten beitragen. 1 Einleitung Das Themengebiet Business Process Management (BPM) und damit verbunden semiformale Modelle von Geschäftsprozessen sind ein aktives Forschungsfeld in Wirtschaft und Wissenschaft. Ziel ist es unter anderem, Geschäftsprozesse in Organisationen zu identifizieren, zu dokumentieren und zu optimieren [Wes07]. Zunehmend werden dabei auch die an den Prozessen beteiligten Software-Systeme betrachtet. Prozessmodelle dienen, auch in Zeiten agiler Softwareentwicklung, als wichtige Kommunikationsgrundlage zwischen den Projektbeteiligten. Aus diesem Grund sind Präzision und Verständlichkeit zwei wichtige Qualitätskriterien für derartige Modelle. Im industriellen Umfeld haben sich semi-formale Notationen für Prozessmodelle durchgesetzt, wie beispielsweise erweiterte ereignisgesteuerte Prozessketten (eepk) [KNS92] oder die Business Process Modelling Notation (BPMN) [OMG11]. Neben standardisierten grafischen Elementen spielen durch den Modellierer ergänzte Beschriftungen eine entscheidende Rolle für das Verständnis des Modells. Dies gilt insbesondere für die Beschreibungen von Aktivitäten oder Funktionen des modellierten Prozesses. Im Gegensatz zur Verwendung grafischer Elemente ist die Nutzung natürlicher Sprache in derartigen Modellen bisher kaum Forschungsgegenstand gewesen. DS-SE 1

10 Abbildung 1: Prozessmodell für die Bestellannahme eines Buchversandhandels Ein Beitrag zur Schließung dieser Forschungslücke besteht in der Untersuchung grundlegender Muster bei der Verwendung natürlicher Sprache in Prozessmodellen. Auf Basis dieser Untersuchung soll ein Assistenzsystem entwickelt werden, welches den Modellierer bei der Beschriftung von Aktivitäten unterstützt, die durch ein Softwaresystem implementiert werden. Als zusätzliche Wissensquelle wird dafür die natürlichsprachliche API- Dokumentation (Application Programming Interface) dieses Systems herangezogen. 2 Forschungsziele und Herangehensweise Der zu entwickelnde Assistent unterstützt den Modellierer sowohl a priori als auch a posteriori bei der Formulierung von Beschriftungen für Aktivitäten. Sein Einsatzgebiet befindet sich innerhalb eines Editors für Geschäftsprozessmodelle. Zur Repräsentation von Software-Operationen werden Web Services verwendet. Für Web Services spricht neben ihrer Verbreitung in der Praxis auch das potentiell breite Einsatzgebiet durch ihre Unabhängigkeit von einer konkreten Programmiersprache. A priori besteht die Unterstützung im Vorschlag einer Beschriftung für eine Aktivität, nachdem diese mit einer Web Service- Operation verknüpft worden ist. Sobald der Modellierer eine Beschriftung für diese Aktivität formuliert hat, analysiert der Assistent a posteriori die Beschriftungen bereits existierender Aktivitäten. Gegebenenfalls formuliert er neue Vorschläge für deren Beschriftungen. DS-SE 2

11 2.1 Forschungsfragen Nach der groben Darstellung des Anwendungskontextes folgt die Beschreibung der Forschungsfragen anhand eines detaillierteren Beispiels. Betrachtet wird das in Abb. 1 dargestellte Prozessmodell (in BPMN). Die Aktivitäten des Prozesses sind als graue, beschriftete Rechtecke dargestellt. Im gegebenen Prozessmodell können vier verschiedene Modellierungsanomalien aufgezeigt werden, welche bei der Formulierung von Beschriftungen auftreten können (dargestellt in violetter Farbe): 1. Synonym-Anomalie: Verwendung verschiedener Verben für denselben Vorgang (hier: Erzeugung eines digitalen Dokuments). 2. Semantische Mehrdeutigkeit: Zwei identische Beschriftungen für verschiedene fachliche Aktivitäten (hier: Prüfung der Kundenbonität anhand des Zahlungsverhaltens bei Bestandskunden und anhand der Anschrift bei Neukunden). 3. Überspezifikation: Beschriftungen sind zu detailliert für den Einsatzzweck des Modells (hier: Dateiformat des Dokuments) 4. Unterspezifikation: Beschriftungen sind unvollständig für den Einsatzzweck des Modells (hier: Quelle der Kundendatensätze ist nicht definiert) Leopold et al. beschreiben eine weitere Form der Mehrdeutigkeit von Beschriftungen, die hier als grammatikalische Mehrdeutigkeit bezeichnet werden soll [LSM11]. Anders als im obigen Beispiel könnte eine Beschriftung demnach grammatikalisch auf zwei verschiedene Weisen interpretierbar sein. (Beispiel: Plan Data Transfer könnte interpretiert werden als to transfer plan data oder to plan the data transfer ). Es ist anzunehmen, dass alle genannten Anomalien die Verständlichkeit des Modells negativ beeinflussen. Daher sind folgende grundlegenden Forschungsfragen zu beantworten: 1. Semantisches Beschreibungsschema: Nach welchem allgemeinen semantischen Schema können Aktivitäten und Web Service Operationen beschrieben werden? Welche Charakteristika der Aktivität muss dieses Schema berücksichtigen? 2. Unterstützung bei der API-Dokumentation: Wie können technische Autoren beim Dokumentieren von Web Service-Operationen auf Basis eines solchen Schemas unterstützt werden? 3. Extraktion semantischer Charakteristika: Wie können die vom allgemeinen Schema geforderten Charakteristika automatisiert aus der API-Dokumentation der verknüpften Web Service Operation extrahiert werden? 4. Generierung von Beschriftungen: Nach welchem Algorithmus werden die Charakteristika in die Beschriftung einbezogen? Gibt es Beziehungen zwischen den Charakteristika, die deren Auftreten beeinflussen? 5. Repräsentation im Prozessmodell: Wie können die einzelnen Charakteristika einer Aktivität im Prozessmodell dargestellt werden? Welche Erweiterungen der Modellierungsnotation sind erforderlich? DS-SE 3

12 2.2 Herangehensweise Mendling und Reijers haben beobachtet, dass Aktivitäten in Geschäftsprozessmodellen meist durch ein finites oder substantiviertes Verb beschrieben werden [MR08]. In der Linguistik gilt es als anerkannt, dass Verben eine zentrale Rolle für die Bedeutung eines Satzes spielen. Sie werden dabei durch weitere sprachliche Argumente in ihrer Bedeutung spezifiziert. Diese Argumente werden als thematische Rollen bezeichnet. Die formale Zuordnung von thematischen Rollen zu einem Verb erfolgt über ein thematisches Raster [Dow89] [Gru65] [Fil68]. Thematische Raster können relevante Rückschlüsse beispielsweise auf verwendete Ressourcen wie Speicher liefern (thematische Rolle SOURCE bzw. DESTI- NATION). Voraussetzung für diesen Ansatz ist die Verwendung von Verben in Bezeichnern für Web Service Operationen. Diese Annahme ist auf Basis eines repräsentativen Korpus von Web Services zu prüfen. Zusätzlich ist die Eignung existierender thematischer Raster als semantische Beschreibungsschemata zu untersuchen (Forschungsfrage 1). Gegebenenfalls müssen neue thematische Rollen und Raster für Aktivitäten und Web Services identifiziert werden. Zur Unterstützung bei der API-Dokumentation erscheint die Entwicklung eines weiteren Assistenten sinnvoll (Forschungsfrage 2). Dieser soll Autoren beim Verfassen von API- Dokumentation auf Basis thematischer Raster unterstützen. Diese Dokumentation stellt die Grundlage für die Generierung der Beschriftungsorschläge dar. Die Extraktion thematischer Rollen aus API-Dokumentationen kann als Problem der Informationsextraktion betrachtet werden (Forschungsfrage 3). In dieser Arbeit wird der Ansatz verfolgt, auf Basis linguistischer Regeln die Belegungen der thematischen Rollen aus der natürlichsprachlichen API-Dokumentation zu extrahieren. Für die Generierung von Beschriftungen wird eine Hierachie definiert, die verschiedene Detaillierungsebenen für die einzelnen thematischen Rollen innerhalb eines Rasters unterscheidet (Forschungsfrage 4). Zusätzlich wird untersucht, ob und in welchen Beziehungen thematische Rollen zueinander stehen und sich ggf. gegenseitig beeinflussen. Die Repräsentation der identifizierten thematischen Rollen wird prototypisch für die BPMN 2.0 als Notation umgesetzt. Dazu werden die existierenden Notationselemente auf ihre Eignung zur Repräsentation thematischer Rollen untersucht und bei Bedarf erweitert (Forschungsfrage 5). 2.3 Relevanz der Problemstellung An der Schnittstelle zwischen Business Process Management und Software Engineering haben Assistenzsysteme für Beschriftung und Dokumentation eine hohe Relevanz für industrielle Software-Projekte. Fach- und IT-Abteilung können bei der Spezifikation, der Implementierung und der Wartung von derartigen Werkzeugen profitieren. Es kann erwartet werden, dass sich die Qualität von Geschäftsprozessmodellen auf diese Weise durch DS-SE 4

13 maschinelle Unterstützung ohne bzw. mit sehr geringer Bindung menschlicher Arbeitskraft optimieren lässt. Bei der Spezifikation neuer Systemfunktionalitäten leisten qualitativ hochwertige Prozessmodelle einen wichtigen Beitrag in der Kommunikation zwischen IT- und Fachabteilung - beispielsweise durch die Vermeidung von Missverständnissen und Aufdeckung von Spezifikationslücken. Durch generierte Beschriftungen ist die Semantik von Web Services auch für Fachabteilungen interpretierbar. So könnten Web Services aus Repositories direkt in die Modellierungsumgebung eingebunden, beschriftet und letztendlich verwendet werden. Diese erheblich vereinfachte Einbindung von technischen Web Service Schnittstellen in die Modellierungsumgebung für Geschäftsprozesse ermöglicht die Konsistenzprüfung des Prozessmodells zu einem sehr frühen Zeitpunkt der Entwicklung. Während der Implementierung können Prozessmodelle mit einem hohen technischen Detailgrad als ausführbare Spezifikation genutzt werden. Desweiteren dient die mit dem Dokumentationsassistenten erstellte API-Dokumentation als präzise Implementierungsvorgabe für den Programmierer. Im Betrieb und in der Wartung des Systems dient das Geschäftsprozessmodell als fachliche Dokumentation der Systemfunktionalität. Im Kontext der Dokumentation sind qualitativ hochwertige und konsistente Beschriftungen vor allem vor dem Hintergrund langlebiger Prozesse bzw. Systeme besonders interessant. 3 Bisherige Ergebnisse und aktueller Stand des Projektes Als semantisches Beschreibungsschema wird der Ansatz thematischer Raster für Aktivitäten und Web Service Operationen verfolgt (Forschungsfrage 1). Die Verwendung von englischen Verben in den Bezeichnern von Web Service Operationen konnte auf Basis eines Korpus von Web Service Operationen für 88% der Operationen nachgewiesen werden [Kra10]. Auf Basis dieses Korpus sind 17 thematische Raster und 31 thematische Rollen zur Beschreibung von Web Services aus einer Stichprobe von 300 Operationen ermittelt worden. Diese Systematik wird in laufenden Entwicklungsprojekten der AKRA GmbH eingesetzt und gegebenenfalls ergänzt. Bei der Erstellung von API-Dokumentation wird der Entwickler durch das Programm idocit! unterstützt (Forschungsfrage 2). idocit! ist ein Editor für API-Dokumentation auf Basis thematischer Raster, welcher als Plugin für die Entwicklungsumgebung Eclipse implementiert ist [Kra11]. idocit! steht unter der Apache Lizenz 2.0 als Open Source- Projekt zur Verfügung und wird bei der AKRA GmbH im Rahmen dieses Dissertationsprojektes entwickelt. idocit! basiert auf den ermittelten thematischen Rastern und Rollen. In der aktuellen Implementierung unterstützt idocit! die Dokumentation von Javaund WSDL-Interfaces (Web Service Description Language). Der zukünftige Forschungsschwerpunkt liegt in der Konzeption einer Probandenstudie zum Nachweis gesteigerter API-Dokumentationsqualität mit thematischen Rastern. DS-SE 5

14 4 Zusammenfassung und Ausblick Dieses Dokument motiviert die Erforschung natürlichsprachlicher Muster in Prozessmodellen. Durch die Unterstützung der beschriebenen Assistenten bei der Formulierung von Beschriftungen für Aktivitäten kann die Verständlichkeit und Konsistenz der Modelle verbessert werden. Von verständlichen und konsistenten Prozessmodellen können viele Software-Entwicklungsprojekte in ihren Spezifikations-, Implementierungs- und Wartungsphasen profitieren. Der zukünftige Forschungsschwerpunkt in diesem Projekt wird in der Extraktion von Textteilen aus natürlichsprachlicher API-Dokumentation auf Basis thematischer Raster, sowie deren Repräsentation in Geschäftsprozessmodellen liegen. Literatur [Dow89] [Fil68] [Gru65] D.R. Dowty. Properties, Types and Meaning: Semantic issues, Kapitel On the Semantic Content of the Notion of the Thematic Role. Studies in linguistics and philosophy. Kluwer Academic Publishers, Charles Fillmore. The Case for Case. In Emmon Bach und R. Harms, Hrsg., Universals in Linguistic Theory. Holt, Rinehart, and Winston, New York, Jeffrey S. Gruber. Studies in Lexical Relations. Dissertation, MIT, Cambridge, MA, [KNS92] G. Keller, M. Nüttgens und A.-W. Scheer. Semantische Prozeßmodellierung auf der Grundlage ÄûEreignisgesteuerter Prozeßketten (EPK). Bericht, Institut für Wirtschaftsinformatik, Universität des Saarlandes, Saarbrücken, [Kra10] [Kra11] Jan Christian Krause. Using Thematic Grids to Document Web Service Operations. In M.A. Karim Sadiq, Dan Tamir und Peraphon Sophatsathit, Hrsg., Proc. 4th Int. Conf. on Software Engineering Theory and Practice, Seiten ISRST, Jan Christian Krause. Stille und Rauschen in Dokumentation - Ein Werkzeug zur Vervollständigung natürlichsprachlicher API-Dokumentation. Objekt SPEKTRUM, (03):14 19, [LSM11] Henrik Leopold, Sergey Smirnov und Jan Mendling. Recognising Activity Labeling Styles in Business Process Models. Enterprise Modeling and Information Systems Architectures, Vol. 6:16 29, March [MR08] Jan Mendling und Hajo Reijers. The Impact of Activity Labeling Styles on Process Model Quality. In W. Hesse und A. Oberweis, Hrsg., Proc. of the Third AIS SIGSAND European Symposium on Analysis, Design, Use and Societal Impact of Information Systems, Seiten , Marburg, Germany, [OMG11] Object Management Group OMG. Business Process Model and Notation (BPMN) Version 2.0, January [Wes07] Matthias Weske. Business Process Management: Concepts, Languages, Architectures. Springer, DS-SE 6

15 Ein Ansatz zur Anpassung von Software Engineering Methoden im laufenden Projekt Silke Geisen s-lab Software Quality Lab Universität Paderborn Zukunftsmeile 1, Paderborn Abstract: Um die erfolgreiche Entwicklung einer Software zu gewährleisten, wird die Software Engineering Methode (SEM) zu Beginn eines Projektes auf die Projektsituation abgestimmt. Doch gerade Änderungen an der Projektsituation oder mangelnde Qualität während der Durchführung machen eine dynamische Anpassung der SEM nötig. Mit bekannten Verbesserungs- bzw. Anpassungsverfahren wie Six Sigma oder dem Deming Cycle, ist dies nur schwer oder gar nicht möglich. Ansätze aus dem Autonomic Computing beobachten selbstständig Systeme über Feedbackschleifen und passen das System gegebenenfalls an. Diese Arbeit beschäftigt sich mit der Idee, wie sich eine solche Feedbackschleife für die dynamische Anpassung von Software Engineering Methoden nutzen lässt. 1. Einleitung und Motivation Effiziente, effektive und qualitativ hochwertige Software-Entwicklung wird in der heutigen Zeit immer wichtiger. Um ein Projekt zum Erfolg zu führen und eine Software erfolgreich zu entwickeln, gibt es die verschiedensten Vorgehensmodelle bzw. Software- Entwicklungsprozesse und Methoden. Hier wird der Begriff Software Engineering Methode [ES10] verwendet. Als eine Software Engineering Methode (SEM) wird die relevante Menge an Elementen verstanden, welche benötigt werden, um ein Software- Projekt in allen wichtigen Aspekten zu beschreiben. Die SEM beinhaltet also nicht nur den Software-Entwicklungsprozess an sich und seine Aktivitäten, sondern zusätzlich alle Artefakte, Rollen und Aufgaben die durchgeführt werden müssen um die Meilensteine zu erreichen, sowie die Werkzeuge und Techniken die für die Umsetzung der SEM benötigt werden. Doch gibt es nicht die eine Software Engineering Methode, welche für jedes Projekt passt, die one-size-fits-all Methode [Br96]. Typischerweise wird eine SEM vor Beginn des Projektes entweder entsprechend zurechtgeschnitten (Tailoring [LL10]) oder eine Software Engineering Methode wird eigens für die Situation im Projekt entwickelt. Um eine solche situationsbezogene, eigene SEM zu entwickeln, wird das Situational Method Engineering [Br96, HR10] angewandt. DS-SE 7

16 Obwohl eine SEM eigens für ein Projekt entwickelt worden ist, kann es dennoch in der Praxis zu Problemen kommen, bedingt durch Veränderungen im Projektumfeld oder mangelnde Qualität bei der Projektdurchführung. Einige Beispiele aus Projekten des s- lab Software Quality Labs 1 in Paderborn sind: In einem Scrum-Projekt [EG09] wurden nicht-funktionale Anforderungen durch fehlende Einträge im Product-Backlog nicht betrachtet. Beim Kunden traten anschließend Performanz-Probleme auf. Um die Betrachtung der nichtfunktionalen Anforderungen in einem Entwicklungsprozess frühzeitig sicherzustellen, musste die SEM angepasst werden. Während eines großen und langlaufenden Projektes wächst die Team-Größe. Die Verwaltungs-Strukturen für beispielsweise Dokumente und Tools zur Unterstützung müssen im laufenden Projekt eingeführt oder angepasst werden. Projektressourcen ändern sich beispielsweise durch eine Fusion oder eine Umstrukturierung. Das betrifft auch laufende Projekte, welche nicht abgebrochen und neu gestartet werden können. Diese Beispiele zeigen, dass es notwendig ist, eine SEM dynamisch im laufenden Projekt anzupassen, um unmittelbar auf problematische Situationen reagieren und den Erfolg sowie die Qualität des Projektes weiterhin gewährleisten zu können. Der Zeitpunkt und die Dauer der Anpassung sind dabei ein wichtiger Faktor. Es gibt bereits verschiedenste Möglichkeiten, um eine Methode anzupassen bzw. sie zu verbessern. Bekannte Vorgehensweisen zur Verbesserung sind beispielsweise Six Sigma [KA06], der Deming-Cycle [De86] oder das bereits genannte Situational Method Engineering [HR10]. Das Situational Method Engineering findet wie beschrieben vor Projektbeginn statt. Bei Six Sigma und dem Deming-Cycle finden Verbesserungen typischerweise nach einem Projekt für zukünftige Projekte statt und nicht für das aktuelle Projekt. Die Dauer der Anpassung können dabei u.u. mehrere Wochen und länger dauern. Einflüsse von außen für ein aktuelles Projekt, wie beispielsweise eine Umstrukturierung, werden nicht betrachtet. Eine verzögerungsfreie und dynamische Änderung während des laufenden Projektes ist mit diesen Verfahren nur schwer oder gar nicht möglich. Eine erste Verbesserung bieten Agile Methoden [Co02] und insbesondere Scrum [SB02]. Diese benutzen verschiedene Inspektionspunkte um mögliche unerwünschte Abweichungen (Produkt- und Entwicklungsprozessabweichungen) zu entdecken [SS12]. Wird eine Abweichung festgestellt, die außerhalb der akzeptablen Grenze liegt, soll so schnell wie möglich eine Anpassung des Arbeitsgegenstandes oder des Prozesses vorgenommen werden. Interessant ist dabei die Retrospektive. Sie ist eine Gelegenheit für das Scrum Team, sich selbst zu untersuchen, und einen Plan für Verbesserungen aufzustellen [SS12]. Damit ist die Retrospektive das wichtigste Ereignis innerhalb von Scrum, welches auf Inspektion und Adaption des gesamten Entwicklungsprozesses fokussiert ist. 1 DS-SE 8

17 2. Ziel der Arbeit und Lösungsansatz Diese Dissertation beschäftigt sich mit der dynamischen und zeitnahen Anpassung von Software Engineering Methoden (SEM). Das Ziel der Arbeit ist, einen Ansatz zu entwickeln, der es möglich macht, nicht nur kritische Änderungen im Projekt und Projektumfeld, Schwierigkeiten oder eine schlechte Qualität von SEM s rechtzeitig zu erkennen, sondern zusätzlich schnellstmöglich und zeitnah die Methode im laufenden Projekt dynamisch anzupassen. In einem ersten Schritt für die Entwicklung eines solchen Vorgehens muss die dynamische Anpassung selbst verstanden und daraus müssen Anforderungen hergeleitet werden. Um eine SEM dynamisch anpassen zu können, muss nicht nur ein Prozess zur Anpassung selbst erstellt werden, sondern es muss zunächst möglichst strukturiert erarbeitet werden, was alles zu einer Methode gehört. Darauf aufbauend kann anschließend erarbeitet werden, an welchen Stellen der Methode notwendige Änderungen ablesbar sind und wo diese Änderungen erfolgen können bzw. sollen. Um herauszufinden, was die Anforderungen an eine dynamische Anpassung sind bzw. wie ein solches Vorgehen aussehen kann, wurden in einem ersten Schritt verschiedene existierende Vorgehensweisen zur Verbesserung und Projekte aus der eigenen Praxis betrachtet, u.a. die vorher bereits genannten Situational Method Engineering, Six Sigma, der Deming-Cycle und die Agile Methoden. Allen Ansätzen ist gemeinsam, dass sie in einem immer wieder kehrenden Kreislauf eine Methode auf Schwächen untersuchen, eine Verbesserung planen, diese durchführen und anschließend einen neuen Durchlauf starten und die Methode erneut untersuchen. Nachteile sind wie in Kapitel 1 beschrieben, dass der Zeitpunkt der Anpassung entweder vor oder erst nach den Projekten, aber nicht im aktuellen Projekt selbst stattfinden. Wenn doch, sind diese nur punktuell und nicht kontinuierlich. Ferner sind die Anpassungszeiten mit 90 Tagen [Ka06] und länger zu lang. Teamübergreifende Veränderungen oder Einflüsse von außen auf ein aktuelles Projekt werden bei allen Vorgehensweisen gar nicht oder nur bedingt betrachtet. Aus der Betrachtung der verschiedenen Ansätze hat sich ergeben, dass es wichtig ist, den oben genannten Kreislauf zu nutzen und gleichzeitig den Zeitfaktor mit einzubeziehen. Daraus ergeben sich als erste Anforderungen für die dynamische Anpassung einer SEM: A1. Die SEM, insbesondere ihre Qualität, sowie externe Einflüsse müssen durchgehend in Hinblick auf eine notwendige Anpassung beobachtet werden. A2. Die Qualität der laufenden SEM und Resultate, sowie Einflüsse von außen müssen analysiert und schnell beurteilt werden können. A3. Eine unmittelbare Anpassung während des laufenden Projektes muss unter Betrachtung der vorher definierten Qualitätsziele geplant und durchgeführt werden können. A4. Die Anpassung soll schnellstmöglich und zeitnah, sowie möglichst automatisch erfolgen. DS-SE 9

18 Wie die erste Anforderung beschreibt, ist es wichtig, ein kontinuierliches Feedback vom Einsatz der Methode zu bekommen. Dieses Feedback muss innerhalb eines Kreislaufs (einer Feedback-Schleife) ausgewertet werden. Anhand der Auswertung soll eine Beurteilung der Methode erfolgen, ob sie angepasst werden muss. Aufgrund der Beurteilung sollte eine weitere Planung für die Anpassung der Methode folgen, welche anschließend zurück in das aktuelle Projekt überführt werden muss. Diese Anpassung und Überführung sollen nicht nur während des Projektes selbst stattfinden, sondern so schnell wie es geht, wenn möglich sogar automatisiert. Die Idee einer solchen Feedback -Schleife und der Auswertung des Feedbacks in einem laufenden System ist nicht neu. Diese Feedback-Schleifen [Do06, Br09] kommen heute insbesondere im Bereich Autonomic Computing [KC03] zum Einsatz. Eine der bekanntesten Feedbackschleifen ist in diesem Bereich die MAPE-K-Feedbackschleife [IBM06] MAPE steht dabei für die verschiedenen Phasen Monitor Analyze Plan Execute. Das K bezeichnet dabei eine Wissensbasis, die Knowledge Base, auf der die vier MAPE Phasen agieren. Ein solcher Autonomic Manager mit der integrierten MAPE-K Feedback-Schleife ist in Abbildung 1 zu sehen. In einem Autonomic Manager wird ein sogenanntes Managed Element, welches ein laufendes System abbildet, kontinuierlich durch Sensoren überwacht. Diese Daten werden aufbereitet, anschließend analysiert und wenn diese nicht den definierten Werten entsprechen, Abbildung 1 MAPE-K [KC03] wird eine Anpassung geplant und über Effektoren ausgeführt. Für die Durchführung der verschiedenen Phasen wird das Wissen aus einer sogenannten Wissensbasis genutzt, welche durch hinzugewonnenes Wissen fortlaufend erweitert werden kann. Lösungsansatz: Software Engineering kombiniert mit MAPE-K Im Rahmen meiner Dissertation möchte ich die Frage klären, wie eine Software Engineering Methode kontinuierlich überwacht, sowie möglichst dynamisch und automatisch angepasst werden kann. Um dies zu erreichen, ist die Idee, den Ablauf des MAPE-K als Basis zu nutzen und auf Software Engineering Methoden zu übertragen. Dadurch soll ein Rahmenwerk bzw. eine Vorgehensweise für die dynamische Anpassung entwickeln werden. Dafür müssten folgende Punkte betrachtet werden: Das Managed Element wäre in diesem Fall dann die Software Engineering Methode selbst. Im Rahmen meiner Dissertation will ich klären, was alles genau zu diesem Managed Element und der SEM gehört. Die Sensoren müssten Daten messen, aufgrund derer entschieden werden kann, ob eine Methode angepasst werden muss oder nicht. Dies könnten beispielsweise verschiedene Qualitätsmetriken sein oder andere Einflüsse aus der Projektumgebung. DS-SE 10

19 Insbesondere möchte ich in dem Rahmen dann die Frage klären, welche Metriken für die Messung der Prozessqualität geeignet sind und wie anschließend die verschiedenen Sensoren konzipiert sein bzw. was sie genau in einer SEM messen müssten. Die gemessenen Daten werden in der Monitoring-Phase aufgezeichnet, aufbereitet und in die Wissensbasis geschrieben. In der Analyse-Phase werden die Daten anschließend ausgewertet. Falls vorher definierte Werte überschritten werden, wird die Planungsphase angestoßen, so dass die SEM möglicherweise angepasst werden muss. Die Auswertung geschieht mit Hilfe der Wissensbasis. Es muss jetzt zum Einen herausgefunden werden, was sich alles in der Wissensbasis befinden muss. Zum Anderen muss genauer erarbeitet werden, was alles in der Analyse-Phase geschieht. Hat die Analyse-Phase ergeben, dass die Methode angepasst werden muss, wird in der Plan-Phase geplant, wie die Anpassung aussehen muss. Zusätzlich muss nun ermittelt werden, was alles zur Planung gehört, u.a. müsste hier die Methode neu zusammen gesetzt werden. Es ist herauszuarbeiten, was sonst noch alles betrachtet werden muss, um eine korrekte und konsistente Anpassung zu gewährleisten. Als letztes wird im MAPE-K die Anpassung in der Execute-Phase über Effektoren ausgeführt. Das führt nun zu den Fragen, wie die Anpassung der Methode in das aktuelle Projekt überführt wird und wie dann die Effektoren konzipiert sein müssten. Ferner ist die Frage zu klären, inwiefern sich die einzelnen Phasen automatisieren lassen. 3. Stand der Arbeit und weitere Schritte Bisher wurde im Rahmen der Arbeit ein erster Stand der Technik analysiert und resultierend daraus wurde eine Idee für eine Vorgehensweise zur dynamischen Anpassung einer Software Engineering Methode angelehnt an den MAPE-K entwickelt. Damit eine solche Vorgehensweise durchgeführt werden kann, ist es besonders wichtig, die entsprechenden Sensoren zu konzipieren und die gemessenen Daten anschließend auszuwerten. Ist es nicht oder nur schwer möglich, eine Einstufung bzw. Bewertung der SEM-Qualität vorzunehmen, ist es kaum möglich zu bestimmen, ob eine Anpassung notwendig ist. Deswegen möchte ich mich in meiner Dissertation auf die entscheidenden Punkte der Entwicklung von Sensoren anhand von Qualitätsmetriken, sowie die Messung der Daten in der Monitoring-Phase und deren Auswertung in der Analyse- Phase fokussieren. Dabei sind folgende Herausforderungen/ Aufgaben zu bearbeiten: Die Agilen Methoden haben erste Ideen zur dynamischen Anpassung geliefert. Insbesondere die Ideen aus der empirischen Prozess-Steuerung (Scrum) Inspektion und Adaption sollen vertieft und weiter ausgearbeitet werden. Als Grundlagen müssen herausgearbeitet werden, was eine SEM (Meta-Modell), und ein Qualitätsmodell beinhalten. Ein Qualitätsmodell für die dynamische Anpassung soll entwickelt werden. Dazu gehören o Qualitäts-Metriken für SEM-/Prozess-Qualität zu erarbeiten DS-SE 11

20 o o Bestehende Qualitäts-Modelle und Metriken müssen auf ihre Nutzung untersucht und ggf. erweitert und angepasst werden Das Qualitätsmodell muss auf Vollständigkeit überprüft werden Es müssen Regeln zur Bewertung des Ergebnisses der Qualitätsmetriken für die Analsysephase erarbeitet werden. Dazu muss herausgefunden werden, ob Bewertungsschemata entwickelt werden können und wie diese aussehen. Im Rahmen der Arbeit soll die Betrachtung zunächst auf bestimmte SEM s beschränkt werden. Dabei möchte ich Scrum als Vertreter der Agilen Methoden, RUP sowie das V- Modell betrachtet. Abschließend ist die Überlegung wie eine prototypische Umsetzung insbesondere der ersten beiden Phasen anhand von Tool-Unterstützung aussehen könnte. Literaturverzeichnis [Br96] Brinkkemper, S.: Method engineering: engineering of information systems development methods and tools. In: Information and Software Technology, Number 38, 1996; pp [Br09] Brun, Y. et. al.: Engineering Self-Adaptive Systems through Feedback Loops. In: Software Engineering for Self-Adaptive Systems, Lecture Notes in Computer Science, Volume 5525/2009, Springer Verlag, Heidelberg 2009; pp [Co02] Cockburn, A.: Agile Software Development. The Agile Software Development Series; Pearson Education, Inc [De86] Deming, W.E.: Out of the crisis. Center for Advanced Engineering Study, MIT, Cambridge, MA, [Do06] Dobson, S. et al.: A survey of autonomic communications. In: ACM Transactions Autnomous Adaptive Systems (TAAS) 1(2), 2006, pp [EG09] Engels, G., Geisen, S., Sauer, S., Port, O.: Sicherstellen der Betrachtung von nichtfunktionalen Anforderungen in SCRUM-Prozessen durch Etablierung von Feedback. In S. Fischer, E. Maehle, R. Reischuk (eds.): Informatik Im Focus das Leben. Gesellschaft für Informatik (GI) (Bonn), Lecture Notes in Informatics, vol. 154, 2009, [ES10] pp. 458 Engels, G., Sauer, S.: A Meta-Method for Defining Software Engineering Methods. In: Nagl Festschrift, LNCS 5765, Springer-Verlag Berlin Heidelberg, 2010; pp [HR10] Henderson-Sellers, B.; Ralyté, J.: Situational Method Engineering: State-of-the-Art Review. Journal of Universal Computer Science,vol. 16, no. 3, 2010; pp [IBM06] IBM Corporation: An architectural blueprint for autonomic computing. White Paper 4th edn., IBM Corporation [KA06] Kwak, Y.H.; Anbari, F.T.: Benefits, obstacles, and future of six sigma approach. In: Technovation, Volume 26, Issues 5-6, May-June 2006; pp [KC03] Kephart, J.O., Chess, D.M.: The vision of autonomic computing. In: IEEE Computer 36(1), 2003, pp [LL10] Ludewig, J.; Lichter, H.: Software Engineering Grundlagen, Menschen, Prozesse, Techniken, dpunkt.verlag, Heidelberg, [SB02] Schwaber, K.; Beedle, M.: Agile Development with Scrum. Prentice Hall, [SS11] Schwaber, K., Sutherland, J.: The Scrum Guide, the official rule book. Current Version: October (last visitited: ) DS-SE 12

21 Organisatorische Einflussfaktoren und sozialer Kontext im Architekturdesign Frederik Schulz, Johannes Meißner Lehrstuhl für Softwaretechnik Friedrich-Schiller-Universität Jena Ernst-Abbe-Platz Jena frederik.schulz@uni-jena.de johannes.meissner@uni-jena.de Abstract: Etablierte Softwarearchitekturmethoden fokussieren die Umsetzung von qualitativen und funktionalen Anforderungen. Organisatorische oder soziale Strukturen und Einflussfaktoren werden jedoch meist als Design Constraints gekapselt und anschließend nur periphär behandelt. Organizational Patterns dagegen widmen sich gerade den Zusammenhängen zwischen den Strukturen von Organisationen und Softwarearchitekturen, bieten jedoch keine formale Beschreibung oder eine Einbettung in Designmethoden. Unser Ziel ist die Entwicklung eines formalen Goal-Modells, mit welchem sich auch der organisatorische Kontext zur Entwicklungszeit, also Organisationsstruktur, Mitarbeiterqualifikationen, geographische Verteilung etc., erfassen lässt, um daraus Anforderungen an Architektur und Organisation abzuleiten. Wir möchten dabei die Kräfte, die zwischen Architektur und dem organisatorischen Kontext wirken, formalisieren und untersuchen. Analog zum Goal-Solution-Scheme sollen diese Anforderungen mit der Methode ADD auf eine konzeptuelle Architektur abgebildet werden. 1 Motivation Beim Softwarearchitekturentwurf muss neben qualitativen und funktionalen Anforderungen auch der organisatorische Rahmen der Umsetzung beachtet werden: Welche Organisationsstruktur umgibt das Projekt während der Entwicklung? Welche Qualifikationen besitzen die Mitarbeiter? Welche Risiken bringen einzelne Teilprojekte mit sich? Welche Intentionen und Nebenziele haben die verschiedenen Stakeholder? Gerade in komplexen Umgebungen wie großen Verbundprojekten oder Projekten mit hohem Forschungsanteil müssen diese Faktoren beachtet werden, um die Durchführbarkeit des Projekts zu sichern. Ein Softwarearchitekturentwurf, der potentielle Risiken und Änderungen im sozialen Bereich einbezieht, kann robust gegenüber diesen Störfaktoren und äußeren Einflüssen sein. Die Qualitätsattribute des entstehenden Systems, wie beispielsweise Wartbarkeit und Evolvability, können optimiert werden. Aber nicht nur die Softwarearchitektur, sondern auch der organisatorische Kontext selbst kann optimiert werden, um eine Durchführung von hoher Qualität sicher zu stellen: Das System kann zum Beispiel gemäß der geographischen DS-SE 13

22 Verteilung der Entwicklerteams zerlegt werden. Unsere Arbeit soll diese Wechselwirkungen zwischen Softwarearchitektur und Organisation untersuchen und eine Methodik hervorbringen um diese strukturiert in den Softwarearchitekturentwurf einfließen zu lassen. Im Rahmen des Verbundprojektes Adaptive Planung und sichere Ausführung Mobiler Prozesse (MOPS) konnten wir reichhaltige Praxiserfahrungen in diesem Bereich sammeln. Das Ziel des Projektes war die Entwicklung eines Systems zur Planung und Koordination von Arbeitsprozessen für Außendienstmitarbeiter beliebiger Fachdomänen, die über mobile Endgeräte in die Ausführung dieser Prozesse integriert werden. Dazu wurde ein Konsortium, bestehend aus acht Partnern des Softwareindustriebereichs mit geographischer Verteilung auf mehrere Standorte gebildet. Jeder dieser Partner steuerte dem Projekt eigene Technologien, Qualifikationen und Zieldefinitionen bei. Mit dem zwischen den Teilprojekten variierenden Forschungsanteil ergaben sich zudem unterschiedliche Risikolevel. Die im Projekt erarbeitete Softwarearchitektur weist einen signifikanten Einfluss dieser Kontextinformationen auf: Das System (Abb. 1, linke Seite) ist in mehrere Teilsysteme zergliedert, denen unterschiedliche Technologien und Frameworks der Projektpartner zugrunde liegen. Zudem ist die Zerlegung kongruent mit deren geographischer Verteilung. Jedes Teilsystem besitzt Interfaces, welche Technologie und interne Funktionsweise als Blackbox kapseln. Zur Veranschaulichung setzen wir dem eine hypothetische Architektur (Abb. 1, rechts) gegenüber, wie sie ohne einen derart komplexen Verbund hätte entstehen können. Hier hätten die Teilsysteme auf einem Framework konsolidiert werden können, so dass eine einfach Struktur aus einem Guss entstanden wäre. Abbildung 1: Das System (vereinfacht), wie es im komplexen Projektverbund entstanden ist (links) und ein hypothetisches gleichartiges System, wie es als Resultat eines Einzelprojekts wahrscheinlich wäre (rechts). 2 State of the Art und Related Work Gängige Architekturentwurfsmethoden behandeln organisatorische und soziale Faktoren nur nebensächlich. Organizational Patterns und Social Modeling fokussieren dagegen auf DS-SE 14

23 den sozialen Kontext der Anwendung, verbinden diesen jedoch nicht mit Entwurfsmethoden. Die Globale Analyse (GA) [HNS00] erfasst alle architekturrelevanten Anforderungen in organisatorischen, technologischen und produktspezifischen Einflussfaktoren. Jeder Einflussfaktor wird auf Variabilität und Flexibilität analysiert, in Faktorentabellen notiert und schließlich in Architekturthemen gruppiert. Allerdings fehlt hier die formale Ableitung einer Architekturlösung. Der Ansatz Attribute Driven Design (ADD) [WBB + 06, BKB01] dekomponiert das System rekursiv und bildet im Zuge dessen qualitative und funktionale Anforderungen auf Architekturkomponenten ab. Das Ergebnis ist eine konzeptuelle Architektur. Zu unseren Zielen gehört, Einflüsse des organisatorischen Kontextes in die Konstruktion mit ADD einfließen zu lassen. Das Goal Solution Scheme (GSS) [Bod11] kombiniert Goal-orientierte Ansätze mit den Methoden GA und ADD um eine formale Transformation des Problemraums in den Lösungsraum herzustellen. Allerdings konzentriert sich GSS nicht auf die organisatorischen Einflussfaktoren oder die organisatorische Struktur. Die Organizational Patterns [CH09] erfassen den organisatorischen und sozialen Kontext und bieten für wiederkehrende Problemstellungen Lösungsmuster für Softwarearchitektur und Organisationsstruktur. Jedes Pattern enthält Informationen über das Umfeld, in welchem es angewendet werden kann, eine Definition der Ziele, die mit ihm erreicht werden sollen sowie einen Lösungsteil mit passenden Strategien. Die Patterns sind in Textform festgehalten, eine Formalisierung oder eine strukturierte Methode für das Architekturdesign werden nicht gegeben. Wir legen in unserer Arbeit dagegen besonderen Wert auf eine formale Modellierung von Kontext, Anforderungen und Lösungen und deren Zusammenhängen. In Social Modeling for Requirements Engineering [YGMM11] werden soziale Kontextdaten in Form von Akteuren, Rollen und Intentionen im i*-framework modelliert und ausgewertet. Die Methoden sind jedoch auf das Anforderungsmanagement beschränkt und betrachten nur das Umfeld zur Anwendungszeit. 3 Offene Fragen Unser Ziel ist die Integration der oben genannten Methoden und deren konzeptuelle Erweiterung. Wir möchten ein formales Modell aufbauen, mit welchem sich der organisatorische Kontext während der Entwicklungszeit erfassen lässt, um Anforderungen abzuleiten und in den Architekturentwurf einfließen zu lassen. Unsere Arbeit soll Antworten auf die folgenden Fragen liefern: Welche Interdependenzen existieren im Allgemeinen zwischen Softwarearchitekturen und ihrem organisatorischen Kontext bei Analyse und Design? Wie lässt sich der organisatorische Kontext in einem formalen Modell erfassen und auswerten? Wie können aus diesem Modell signifikante Anforderungen an die Struktur der Softwarearchitektur, aber auch an die Organisation des Entwicklungsumfeldes abgeleitet werden? Welche Abhängigkeiten existieren zwischen diesen Anforderungen? Wie lassen sich diese DS-SE 15

24 in der Designphase umsetzen und wie können etablierte Entwurfsmethoden dabei verwendet werden? Welche Konflikte können dabei entstehen und wie lassen sich diese Konflikte methodisch lösen? 4 Herangehensweise und Zielsetzung Als Grundlage für unsere Ansätze soll das Goal Solution Scheme (GSS) [Bod11] dienen. Das GSS bildet die Zuordnung von Goals über deren Verfeinerung (Subgoals) auf allgemeine Lösungsprinzipien und schließlich auf konkrete Lösungen ab. Eine analoge, schrittweise Transformation des Problemraums auf den Lösungsraum soll auch Basis unserer Ansätze sein. Die nachfolgenden Abschnitte geben einen detaillierteren Einblick in die einzelnen Schritte (siehe Abb. 2). Erfassung des Problemraums und formale Modellierung. Zunächst muss definiert werden, was mit dem Begriff organisatorischer Kontext umfasst werden soll. In der Global Analysis [HNS00] werden alle architekturrelevanten produktbezogenen, technischen und organisatorischen Einflussfaktoren erfasst und bezüglich der Parameter Variabilität (wie verändert sich der Faktor im Laufe der Zeit?) und Flexibilität (wie stark ist der Faktor verhandelbar?) analysiert. Dazu werden fünf Kategorien von organisatorischen Einflussfaktoren vorgeschlagen: 1. Management, 2. Qualifikationen, Interessen, Stärken und Schwächen, 3. Prozess- und Entwicklungsumfeld, 4. Zeitplan und 5. Budgetplan. Diese bewerteten Einflussfaktoren sollen uns als Eingabe für die weitere Modellierung des organisatorischen Kontextes dienen. In [CH09] werden zusätzlich auch organisatorische Strukturen und Kommunikationswege in Form von Sociograms und Interaction Grids mit einbezogen und visuell aufbereitet. Im Bereich Requirements Engineering erfasst [YGMM11] zudem die strategischen Interessen und Abhängigkeiten von Stakeholdern im i*-framework. Wir möchten diese Goal-orientierte Methode verwenden, um die bei der Global Analysis ermittelten Einflussfaktoren und die organisatorische Struktur zur Entwicklungszeit, so wie die Zusammenhänge zwischen beidem einheitlich zu erfassen. Eines unserer Ziele ist dabei die Übertragung der Parameter Variabilität und Flexibilität aus der Global Analysis auf die Goal-orientierte Notation. Ableitung von relevanten Anforderungen. Aus dem formalen Kontextmodell sollen architekturrelevante Anforderungen in Form von Goals abgeleitet werden. Diese entsprechen in ihrer Bedeutung den in [HKN + 07] eingeführten Architecturally Significant Requirements (ASR). Als Beispiel sei die Nutzung bereits vorhandener Entwickler-Skills genannt. Copliens Organizational Patterns enthalten jedoch nicht nur Vorlagen für die Anpassung der Softwarearchitektur an den Kontext, sondern vice versa auch Muster für die Adaption des Kontextes an das zu entwickelnde System. Um beides abzudecken, möchten wir als Goals daher auch Organizational Significant Requirements aus dem Kontextmodell ableiten, also wichtige organisationsrelevante Anforderungen. Hier stellt sich die Frage, ob bei Konflikten die Softwarearchitektur dem organisatorischen Rahmen angepasst wird oder umgekehrt? Wir möchten in unserer Arbeit untersuchen, welche Kräfte dabei zwischen beiden wirken. Als Schlüsselfaktoren vermuten wir dabei vor allem die Flexibilität und Variabilität der Einflussfaktoren und werden diese Wechselwirkungen analysieren. DS-SE 16

25 Abbildung 2: Übersicht des Architekturanalyse- und Architekturentwurfsprozesses. Realisierung. Im GSS wird die Methode ADD verwendet, um die konzeptuelle Architektur zu konstruieren und dabei qualitative Anforderungen umzusetzen. ADD dekomponiert die Teilsysteme rekursiv und bildet dabei die Architekturanforderungen auf konzeptuelle Lösungen ab. Dazu werden alle erhobenen Anforderungen bezüglich ihrer Relevanz für das aktuell unter Betrachtung stehende Teilsystem gewichtet und priorisiert. An dieser Stelle sollen auch unsere in der vorhergehenden Phase aus dem organisatorischen Kontextmodell abgeleiteten Goals eingebracht werden. Aus der Gesamtmenge der Anforderungen werden nun jene mit der höchsten Wichtigkeit ausgewählt, es entsteht eine Liste von Architectural Drivers. Im nächsten Schritt werden mögliche konzeptuelle Architekturlösungen in Form von Patterns und Taktiken gesammelt, die diese Architectural Drivers erfüllen können. Beispielsweise fordert der Lösungsteil des Organizational Patterns Subsystem by Skill die Partitionierung in Komponenten gemäß der Qualifikationen der Entwickler. In ADD werden schließlich die Anwendbarkeit der Lösungen und die Wechselwirkungen zwischen ihnen analysiert. Wir möchten insbesondere die Abhängigkeit einer Architekturlösung vom organisatorischen Kontext untersuchen: Verhindert eine Anforderung an den Kontext (OSR) die Anwendung einer Architekturlösung oder müssen sogar neue Anforderungen an den Kontext hinzugefügt werden? 5 Abgrenzung In Bezug auf die Global Analysis soll sich unsere Arbeit auf die Untersuchung der organisatorischen Einflussfaktoren beschränken. Produktbezogene und technische Einflussfaktoren hängen mit diesen zwar zusammen, sollen aber nicht im Fokus stehen. Unser Ziel ist, die Behandlung des organisatorischen Kontextes thematisch herauszulösen und orthogonal zu bestehenden Entwurfsmethoden wie ADD, QASAR [Bos00] oder anderen zu betrachten. Kern unserer Bemühungen ist ein Modell zur Erfassung des Kontextes und eine Methode zu dessen schrittweiser Transformation auf Anforderungen und Lösungen so wie die Auswertung von Abhängigkeiten zwischen diesen. Statt einer vollständigen Neuentwicklung einer eigenständigen Architekturentwurfsmethode möchten wir die Anwendbarkeit unseres organisatorischen Kontextmodells innerhalb etablierter Methoden erreichen. Zum Beispiel soll die ausgereifte Methode ADD genutzt werden, um die Anforderungen aus dem organisatorischen Kontext in einer Architektur umzusetzen und dabei entstehende Wechselwirkungen mit anderen Anforderungen und Lösungsmustern zu analysieren. DS-SE 17

26 6 Aktueller Stand der Arbeiten und weiteres Vorgehen Das MOPS-Projekt, das wir als Fallbeispiel angeführt haben, befindet sich bereits kurz vor dem Abschluss. Unser nächster Schritt ist die Erarbeitung des formalen, Goal-orientierten Kontextmodells, mit dem wir die organisatorischen Einflussfaktoren, die Organisationsstruktur, Intentionen von Stakeholdern etc. abbilden können. Dabei sollen Konzepte entwickelt werden, um die Variabilität und die Flexibilität von Einflussfaktoren in dieses Modell zu übertragen. Darauf aufbauend muss eine Vorgehensweise entwickelt werden, um aus diesem Modell Anforderungen an Softwarearchitektur und Kontext abzuleiten und die wechselseitigen Abhängigkeiten zwischen diesen Anforderungen zu analysieren. Im Anschluss muss die Zuordnung möglicher Lösungen mit Hilfe von Organizational Patterns betrachtet werden. Wir werden eine Methode entwickeln, um diesen Prozess zu formalisieren und zu strukturieren. Diese Arbeiten bilden die Grundlage für eine tiefere Untersuchung der Zusammenhänge und der Kräfte zwischen Organisation und Architektur so wie der Effekte von Variabilität und Flexibilität der Einflussfaktoren auf diese. Zeitgleich möchten wir die Integration unseres Anforderungsmodells in Entwurfsmethoden am Beispiel ADD exerzieren. Die Anwendbarkeit unserer Ergebnisse und die Qualität möchten wir begleitend mit dem exemplarischen Einsatz in mindestens zwei realen Fallbeispielen sicherstellen. Die Evaluierung unserer Resultate stellt den Abschluss unserer Arbeit dar. Literatur [BKB01] [Bod11] [Bos00] [CH09] [HKN + 07] Len Bass, Mark Klein und Felix Bachmann. Quality Attribute Design Primitives and the Attribute Driven Design Method. In 4th Conference on Product Family Engineering, Seiten Springer-Verlag, Stephan Bode. Quality Goal Oriented Architectural Design and Traceability for Evolvable Software Systems. Dissertation, TU Ilmenau, Jan Bosch. Design and use of software architectures: adopting and evolving a productline approach. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, James O. Coplien und Neil B. Harrison. Organizational Patterns of Agile Software Development. Pearson Prentice Hall, Christine Hofmeister, Philippe Kruchten, Robert L. Nord, Henk Obbink, Alexander Ran und Pierre America. A general model of software architecture design derived from five industrial approaches. J. Syst. Softw., 80: , January [HNS00] Christine Hofmeister, Robert Nord und Dilip Soni. Applied software architecture. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, [WBB + 06] Rob Wojcik, Felix Bachmann, Len Bass, Paul Clements, Paulo Merson, Robert Nord und Bill Wood. Attribute-Driven Design (ADD), Version 2.0. Bericht, Software Engineering Institute, [YGMM11] Eric Yu, Paolo Giorgini, Neil Maiden und John Mylopoulos. Requirements Engineering. MIT Press, Social Modeling for DS-SE 18

27 Model-based Multilateral Optimizing for Service-Oriented Architectures Focusing on Compliance Driven Security Stephan Faßbender Abstract: When talking about modern software architectures, SOA are an often mentioned paradigm. As nowadays business applications are process oriented, the IT infrastructure needs to be very flexible and modular to keep up with process changes. As a result SOA is one best practice approach to deal with these challenges. But when talking about business, there are some issues and open questions. Most of them occur in the fields of compliance and security. These areas got more and more attention over time as some incidents in the nearer past drew attention from the public and the legislators. And they even more complicate the finding of an optimal architecture and the optimal selection and composition of services to implement it. This paper takes a look at a software engineering process for SOA and at the gaps which have to be bridged to build a optimal SOA for a given problem, which is compliance and security aware. 1 Introduction Nowadays Service Oriented Architectures (SOA) as part of Service Oriented Computing (SOC) are a well known paradigm with raising importance [PRFS08, PTD + 06]. The subject of SOC is vast and enormously complex as SOC is based on many concepts which have their origin in diverse disciplines. SOA and software engineering (SE) for SOA are among the most important research fields for SOC [PTD + 06]. Various definition of SOA exist, as the SOA concept spans a wide field of research areas and technologies. However there is a common sense about some core characteristics of SOA. Summarizing, SOA can be characterized as a process driven [DD04, AGA + 08, PRFS08], modular [DD04, PTD + 06, PRFS08], technology-independent [PTD + 06, DD04], dynamic [PTD + 06] and distributed system [PTD + 06, DD04, RFMP07], which relies on reusable [PRFS08, PTD + 06, AGA + 08], autonomous [DD04, PTD + 06, PRFS08], loosely coupled [PTD + 06] and coarse-grained [DD04] services. Still there are some open issues when dealing with SOA. One of them is security [RFMP07, PTD + 06]. Assurance of security of a SOA is much more complicated than for other architectural styles. The single services used are normally distributed and loosely coupled over the Internet, there have to be standardized protocols for link-up [DD04]. Those protocols were often not designed to enforce security in the first place. Another field for security issues is the fact that in common SOA scenarios, not a single person or company controls all infrastructure and services which are orchestrated [RFMP07, PTD + 06]. Hence when DS-SE 19

28 dealing with security for SOA, multilateral settings with many stakeholders in a distributed environment have to be considered, which even more complicates finding a solution. Security issues existed since the very beginning of IT systems, but somehow only in specific areas they are prioritized high enough when planning new IT products or systems [RFMP07]. A general reason is the complexity of security problems. For companies there are some additional reasons to neglect security in their products. The two most important are cost and usability. In most cases security measures have a negative impact on both. But as cost and usability are key features for the success of a product, companies try to find a balance between security, usability and costs, often with a result that neglects security. But this practice has an negative impact on the basic rights, wealth and security of societies. Therefore many legislators decided to enact different laws, which all enforce legal and natural persons to deal more carefully with IT systems and related processes and activities [OA07]. Moreover many industries formed up standards and certificates for IT systems. To observe all these different regulations make up the field of IT compliance. And as the field of compliance is multilateral and international, it is also very complex, but the most powerful driver for IT security in companies nowadays [Jun06]. 2 Problem description In general, the basic problem when engineering a SOA is to develop a solution which fulfills the requirements of all stakeholders and therefore solves the original problem. In most cases searching for a solution does not mean to search for any sufficient solution but to search for the (nearly) optimal solution. So the main problem to be solved is to answer the question What has to be done to obtain the optimal solution when engineering a SOA?. The meaning of optimal in this case is bound to the dimension of the problem. Examples for a dimension are performance, security, or usability. But there are much more. So to define when a solution is optimal means to define, which dimensions are of relevance. The selection of dimension and their weighting is heavily dependent on the stakeholders of the problem. In common SOA scenario many stakeholders, which have influence on the solution, have to be considered. Hence, the desired solution is a multilateral one. Multilateral in this case means that the optimization has to be done for more than one stakeholder and dimension. Thus, defining what is optimal regarding a given problem is already part of the problem. When the dimensions and their weight for the solution are known some more things have to be achieved. For example, optimizing performance of a SOA may be straight forward. But when adding another dimension like security it gets more complicated. These two dimensions are not independent. For example, adding asymmetric encryption to raise the security level will have negative impacts on the performance. A perfect secure SOA which neglects usability, performance and cost will hardly succeed [PTD + 06]. So, it has to be discovered which correlations between dimensions exist. These correlations have to be DS-SE 20

29 reflected when optimizing. Another complexity lies within the SOA paradigm itself. A SOA spans different layers [PTD + 06, AZE + 07]. The first layer is the business domain layer, which represents the real world. It consists of organizations, the structure and actors, and their relations to each other. The second layer is business process layer. To run the business certain processes are executed. These processes are supported by business services. They form the the business service layer. A business service encapsulates a business function, which corresponds to a process activity. Business services are built upon infrastructure services, which form the fourth layer. The infrastructure services offer the technical functions needed for the business services. These technical functions are implemented especially for ta SOA or expose interfaces from the operational systems used in an organization. These operational systems, like databases or legacy systems, are part of the last SOA layer. Each of the presented layers in isolation is complex, optimization is not trivial, and a field for research. But to achieve a SOA, which is optimal at all layers, means to develop an integrated optimization method. Such an integrated method is one great challenge in the field of SOA research [PTD + 06]. The last problem when optimizing are the prerequisite for doing the optimization. In general the quality of an optimization relies on the input. This input is a collection of information about the problem and the setting. Such an information can be simple like the costs for invoking an service. But can also be complex, e.g. the average run-time of a service in the past for a special process structure. To elicit this information it must be clear, which input is need for an optimization, in which form it is needed, where and how to retrieve it. The quality of the information has also to be checked and ensured, as the quality of the optimization can only be as good as the input. So methods are needed to rate the quality of the input and to detect noise or corrupted data. So part of an optimization method is also the information retrieval and quality optimization. Summarizing, for optimizing a SOA one has to consider the stakeholders involved, the dimensions to be optimized, its complexity, and the prerequisite for optimization. Thus, the original question What has to be done when engineering a SOA to obtain the optimal result? can be refined to Who are the stakeholder of the SOA and what is optimal for them?, How are the relevant dimensions related and how to optimize them simultaneously?, Which SOA layers are affected by an optimization?, and What input do i need to have a reasonable optimization. 3 Focusing the Work For a dissertation there needs to be a focus on certain aspects as the described problem space and solution vision comprise a large field for research. The author plans to sharpen his work and aim for a subset of the aforementioned problems. The first major decision is to investigate only model based software engineering. First, models provide the capability to integrate experts from different domains, like security and compliance. Those experts are not cross-disciplinary experts, which means they are DS-SE 21

30 not software engineers. Models express important information in a comprehensible way. The integration of experts from different fields is essential for the success of a method which has to consider knowledge from diverse fields like business processes, IT landscape, security or compliance [BHTV03]. Second, models provide a documentation and can be checked for coherence with other artifacts. For example, when using UML [OMG11b] the artifacts of all layers can be represented within one model. So using models seems to be reasonable as they ease interdisciplinary work, documentation, and coherence. Hence, models provide desirable characteristics for information retrieval and quality optimization. The second major decision is to focus on composition and choreography of business and infrastructure services for a SOA SE method. How to compose services to realize a SOA is an open research field with vital importance [PTD + 06, PRFS08]. And as for a SOA there are different options e.g. for one service or for the sequence of process steps, optimization is necessary. For a SOA these optimizations are not limited to the design time. Available services and the processes to be executed change dynamically so optimization and adaption has to be done continuously [PTD + 06, PRFS08]. The third mayor decision is to focus on dimensions, which are of emerging importance and where solutions sparsely exist. Focusing in this case means not to neglect other dimensions, but to rely on existing solutions for them. A first important optimization dimension arises from the compliance regulations. In most cases the regulations are not directly enacted for IT systems but for the processes and data handling, which are partly run by IT systems. As SOA is meant to support business processes in a direct way, compliance has to be considered as a direct input when building a SOA [PTD + 06]. A second important optimization arises from the security issues. For SOA, security is a problem by design in the first place. Communication is done over vulnerable communication channels and parts of a SOA change dynamically and are not under control of the user of the SOA. This flexible, dynamic, open and distributed architecture renders many classic security tools and methods useless [PTD + 06]. Resulting a optimization method for SOA has to identify the ideal solution under given security constrains. The last mayor decision is to focus on the early development phases of a SOA. The reason is that the upper bound of the quality of an optimization is always the quality of the input and optimizations done before. So it is crucial to have introduce optimization already in the requirements and design phase. 4 Roadmap to a Comprehensive Result The first step is to analyze existing optimization methods from the fields of operations research, mathematics and informatics. It has to clarified, which input they need, which problem class they can solve and which results they can provide. One has to consider more generic approaches like linear programming, genetic algorithms, and neuronal networks, and SOA specific optimization methods. The result of this analysis should be the fit of methods to steps within the SOA life cycle, the requirements which have to be fulfilled to DS-SE 22

31 use a methods and the capability to combine a method with other methods. This analysis sharpens the view on the SOA life cycle and the gaps to be filled to introduce optimization to the life cycle. While the goal is a optimal solution for a SOA which is compliant and secure, the regulations dealing with IT and processes are very generic and not enforcing special solutions. So regulations can be seen as a set of possible requirements. In most cases regulations define non-functional requirements. Many of those non functional requirements deal with security, but in a implicit way. Moreover compliance requirements do not aim at the IT systems in a direct way, but the processes that are supported by a IT system or assets which are processed in or supported by a system. At this point research on patterns, which describe SOA settings considering compliance and security should be done. Such an approach would enhance a RE method for a compliant and secure SOA and provide the first input for a SOA specific optimization. The last step of the requirements phase is the reconciliation of the gathered requirements. Reconciliation means that the known requirements are checked for consistency and conflicts. This step is an important one for a compliance- and security-aware method. For classical requirements there can be conflicting requirements like cost and quality or functionality and usability, but in most cases they do not tend to contradict each other. This is not true for compliance and security requirements. Such requirements contradict other requirements, and a trade off is often not possible. As result there is a need for methodologies for finding inconsistencies and conflicts, as well as for processes for conflict solving. One approach for conflict solving could be an optimization algorithm which finds the best set of requirements under given constraints. After the set of relevant requirements is selected, the design phase takes place to refine the requirements to a software architecture. For a SOA there are typically three major things are to be shaped: The business processes, which are to be run, the services, which support or execute certain activities and the components, which are used to form a service. For modeling the processes different inputs are needed. First of all, there has to be a selection of requirements, which describe or demand a process or process step. Normally not the IT systems are modeled into a business process, but the resources and restrictions for a business process. For such a modeling there are already well defined notations like UML 2 activity diagrams [OMG11b] or the BPMN 2.0 [OMG11a]. But these notions lack of the capability to express SOA, security- and compliance-specific requirements, elements and constraints. There are already some extensions for SOA (e.g. SOAML [OMG09]) and security (e.g. SecureUML [LBD02]), but they should be analyzed for missing parts. For compliance there are hardly any proposals at the moment. For all approaches it is true that they focus only on one part, so there is a need to harmonize the existing solutions and additions to have a comprehensive notation for SOA, security and compliance. When the business processes are specified, there is typically an analysis and refinement step, in which the models are checked for activities, which should be decomposed, for process defects and for optimization potential. While for economic needs there already exist best practice solutions, for security and compliance there are hardly any. So research needs to be done for methods, which are enable the analysis and optimization of a business process considering security and compliance. DS-SE 23

32 When the processes are defined, they are analyzed for activities which are IT-related. These activities are mapped to services, which are able to execute an activity. Moreover requirements which aim directly at the service level are considered. The resulting services are refined, coupled and composed right after the selection. The research fields are almost the same as for the process modeling described before. So there is a need for modeling notation extensions, which directly address a SOA, security and compliance and optimization algorithms. References [AGA + 08] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Gariapathy, and K. Holley. SOMA: a method for developing service-oriented solutions. IBM Systems Journal, 47(3), [AZE + 07] Ali Arsanjani, Liang-Jie Zhang, Michael Ellis, Abdul Allam, and Kishore Channabasavaiah. Design an SOA solution using a reference architecture [BHTV03] Luciano Baresi, Reiko Heckel, Sebastian Thöne, and Dániel Varró. Modeling and validation of service-oriented architectures: application vs. style. In ESEC / SIGSOFT FSE, [DD04] Remco M. Dijkman and Marlon Dumas. Service-Oriented Design: A Multi-Viewpoint Approach. International Journal on Cooperative Information Systems, 13(4), [Jun06] Ernst & Jung. Global Information Security Survey, [LBD02] [OA07] Torsten Lodderstedt, David A. Basin, and Jürgen Doser. SecureUML: A UML-Based Modeling Language for Model-Driven Security. In Proceedings of the 5th International Conference on The Unified Modeling Language, UML, London, UK, UK, Springer-Verlag. Paul N. Otto and Annie I. Antón. Addressing Legal Requirements in Requirements Engineering. In RE, [OMG09] Service oriented architecture modeling language Beta 2, dec [OMG11a] Business Process Model and Notation (BPMN) 2.0, jan [OMG11b] Unified Modeling Language superstructure specification 2.4.1, aug [PRFS08] [PTD + 06] Mikhail Perepletchikov, Caspar Ryan, Keith Frampton, and Heinz W. Schmidt. Formalising Service-Oriented Design. Journal of Software, 3(2), Michael P. Papazoglou, Paolo Traverso, Schahram Dustdar, Frank Leymann, and Bernd J. Krämer. Service-Oriented Computing: A Research Roadmap. Dagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss Dagstuhl, Germany, [RFMP07] Alfonso Rodríguez, Eduardo Fernández-Medina, and Mario Piattini. A BPMN Extension for the Modeling of Security Requirements in Business Processes. IEICE Transactions, 90-D(4), DS-SE 24

33 Supporting the Development and Documentation of Trustworthy ICT Systems according to Security Standards through Patterns and Security Requirements Engineering Approaches Kristian Beckers paluno - The Ruhr Institute for Software Technology - University of Duisburg-Essen, Germany Kristian.Beckers@paluno.uni-due.de Abstract: Assessing the trustworthiness of an ICT system is a challenging task, because of the increasing complexity and distribution of these systems. For example, cloud computing systems are distributed over numerous continents and host a variety of different software and hardware parts. We provide easy-to-use patterns that can be instantiated for specific systems, e.g., clouds, on the one hand. On the other hand, we create patterns for the elements of trustworthiness: security, risk management, privacy, and law. The instantiations of these patterns are used to support the development and documentation of ICT systems according to security standards. In addition, we define relations between security standards and security requirements engineering approaches. 1 Motivation and Background Aligning information and communication (ICT) systems with security standards, e.g., the well-known ISO series of standards, is difficult, due to the sparse descriptions these standards provide. For example, the input required for the scope and boundaries definition of the ISO standard is simply defined as all information about the organization relevant to the information security risk management context [ISO08, p. 1]. Security requirements engineering (SRE) methods, on the other hand, provide structured elicitation and analysis of security requirements [FGH + 10]. SRE methods can be part of the early phases of a given software development process. However, we propose not to limit SRE methods to software development. The structured elicitation and analysis of security requirements of SRE methods is also useful in the context of security standards. We proposed to use SRE methods to support the establishment and documentation of secure ICT systems [BFH + 12]. However, SRE methods are often limited to the requirements phase of a given software engineering process. Hence, these have only a very limited support for the software design and development phases. In addition, these support only parts of security standards, DS-SE 25

34 because these were not developed for this purpose specifically. Gamma et. al [GHJV94] presented significant work in the area of pattern for software architectural and design patterns. These patterns show expert knowledge in software development in a re-usable way. They can be instantiated to support the development of given system. Heyman et al. [HSHJ08] present an overview of patterns specifically for secure software engineering. We are proposing to adapt the concept of patterns specifically for security standards. Documentation of a system is a fundamental requirement for certification of an ICT system according to a security system, e.g., the common criteria [ISO09]. Patterns that support the documentation of system according to the standard can ease the effort. The related work for the ISO series of standards offers little support in establishing and documenting systems. Calder [Cal09] and Kersten et al. [KRS11] provide advice for an ISO realization. In addition, Klipper [Kli10] focuses on risk management according to ISO The author also includes an overview of the ISO series of standards. However, none of these works consider to use security requirements engineering methods. Cheremushkin et al. [CL10, LCAS11] present a UML-based meta-model for several terms of the ISO 27000, e.g., assets. These meta-models can be instantiated and, thus, support the refinement process. However, the authors do not present a holistic approach to information security. The work mostly constructs models around specific terms in isolation. Furthermore, we want to research a structured method that uses existing SRE methods and security patterns to analyze if the security requirements of a system are correctly identified and the correct measures are implemented. In addition, security standards, e.g. ISO series and common criteria, demand a identification of legal and privacy requirements. We aim to support the identification of privacy and legal requirements for security standards, as well as the identification of mechanisms that fulfill these in our approach. 2 An Example of Previous Work We developed a pattern-based approach to support the context establishment and asset identification in the scope of cloud computing systems for the ISO [ISO08] standard [BKFS11]. Our work shows a cloud system analysis pattern and different kinds of stakeholder templates serve to understand and describe a given cloud development problem. We illustrated our support using an online banking cloud scenario, presented in in Fig. 1. Our cloud system analysis pattern in Fig. 1 that provides a conceptual view on cloud computing systems and serves to systematically analyse stakeholders and requirements. The notation used to specify the pattern is based on UML 1 notation, i.e. the stick figures represent roles, the boxes represent concepts orientates of the real world, the named lines represent relations (associations) equipped with cardinalities, the unfilled diamond represents a part-of relation, and the unfilled triangles represent inheritance. 1 Unified Modeling Language: DS-SE 26

35 Indirect System Environment Direct System Environment Legislator Germany Legislator EU Legislator US Domain Finance Has IsMonitoredBy 1..* 1..* 1..* Provides 1..* Cloud * Service 1..* 1..* Virtual IsComplementedBy Webserver, Machine 1..* 1..* * Application * Server, etc. UsedBy * Cloud IsComplementedBy Online Programming Interface 1..* * Banking * Software 1..* UsedBy * Online IsComplementedBy Transaction Banking 1..* * Data Service * BuiltAndCustomizedBy Bank Institute BuiltBy * 1..* 1..* WorkFor * * Has Hulda 1..* Owns 1..* 1..* Pool IsBasedOn 1..* Data Center Server Network and Virtualization Software Internal Development Unit 1..* InputBy/OutputTo * Bank Customer Figure 1: Cloud System Analysis Pattern A Cloud is embedded into an environment consisting of two parts, namely the Direct System Environment and the Indirect System Environment. The Direct System Environment contains stakeholders and other systems that directly interact with the Cloud, i.e. they are connected by associations. Moreover, associations between stakeholders in the Direct and Indirect System Environment exist, but not between stakeholders in the Indirect System Environment and the cloud. Typically, the Indirect System Environment is a significant source for compliance and privacy requirements. The Cloud Provider owns a Pool consisting of Resources, which are divided into Hardware and Software resources. The provider offers its resources as Services, i.e. IaaS, PaaS, or SaaS. The boxes Pool and Service in Fig. 1 are hatched, because it is not necessary to instantiate them. Instead, the specialised cloud services such as IaaS, PaaS, and SaaS and specialised Resources are instantiated. The Cloud Developer represents a software developer assigned by the Cloud Customer. The developer prepares and maintains an IaaS or PaaS offer. The IaaS offer is a virtualised hardware, in some cases equipped with a basic operating system. The Cloud Developer deploys a set of software named Cloud Software Stack (e.g. web servers, applications, databases) into the IaaS in order to offer the functionality required to build a PaaS. In our pattern PaaS consists of an IaaS, a Cloud Software Stack and a cloud programming interface (CPI), which we subsume as Software Product. The Cloud Customer hires a Cloud Developer to prepare and create SaaS offers based on the CPI, finally used by the End Customers. SaaS processes and stores Data DS-SE 27

36 in- and output from the End Customers. The Cloud Provider, Cloud Customer, Cloud Developer, and End Customer are part of the Direct System Environment. Hence, we categorise them as direct stakeholders. The Legislator and the Domain (and possibly other stakeholders) are part of the Indirect System Environment. Therefore, we categorize them as indirect stakeholders. The cloud system analysis pattern instance in Fig. 1 helps, e.g., identifying assets by considering the instantiated boxes and the associations between the direct stakeholders and the cloud. The associations indicate the flow of information into and out of the cloud and therefore helps to analyze the information assets processed and stored in the cloud. Furthermore, the associations help to find out about the asset owner, as the standard requires. 3 Future Work In the future we will extend this approach to support the documentation and development of trustworthy ICT systems. We define trustworthiness as a system that fulfills security, risk management, privacy and legal requirements. We present ideas of how we plan to address all these elements of trustworthiness. Clouds are socio- technical systems with a high number of different kinds of stakeholders. Moreover, they are often geographically distributed, process critical data, and support sensitive IT processes. Hence, it makes for a relevant example of our work. We will work on privacy patterns based upon the work from Nissenbaum s model of informational privacy in terms of contextual privacy [Nis09]. The model considers the context of a given situation, the kind of information, the relation of the information to the context, the role of agents receiving the information, their relationship to information subjects; on what terms the information is shared by the subject and the terms of further distribution. For example a patient sharing information about her physical condition with a physician is appropriate, but not vice versa. Nissenbaum further describes that contextual privacy norms have three different sources. These are laws, culture, and the history of a stakeholder. Moreover, aligning ICT systems to meet compliance regulations is an even more challenging task. We proposed to use specific law analysis patterns to identify relevant laws for a given software system[bkfs12]. In addition, we will extent our work with a structured method that derives legal requirements for clouds, using the cloud system analysis pattern as an input for our legal analysis pattern. Moreover, we work on an approach to elicit software requirements from legal requirements. Heyman et al. [HSHJ08] present an overview of patterns for secure software engineering. We will compare the patterns presented here and in other surveys with the existing SRE methods to identify possible gaps in SRE methods that these patterns can cover. In addition, we will investigate risk management patterns. We will also investigate meta models for security standards, e.g., Sunyaev [Sun11] and meta models for risk management standards, e.g., Fenz [FEN11]. Each of these meta DS-SE 28

37 models has relations to multiple standards. We will define relations between these meta models. Hence, we will be able to relate our work to all the standards that are already related to these meta models. Our work on pattern-based support for developing and documenting trustworthy ICT systems according to security standards, e.g., ISO series and Common Criteria. Our approach comprises the following main benefits: Systematic pattern-based development and documentation of a ICT systems Specific-patterns for the elements of trustworthiness: laws, privacy, security and risk management. Ease the burden of implementing security standards Improve the outcome of security standards implementations by perfecting the steps involved Furthermore, we are planning to develop a tool that contains patterns for security standards. The tool will support the documentation of ICT systems in accordance with the demands of security standards. In addition, the tool will verify if all necessary elements of security patterns are instantiated and it will offer support to adapt the patterns for specific kinds of systems, e.g., clouds. The output of the tools are system documentations that can be used for certification according to specific security standards, e.g., ISO References [BFH + 12] Kristian Beckers, Stephan Faßbender, Maritta Heisel, Jan-Christoph Küster, and Holger Schmidt. Supporting the Development and Documentation of ISO Information Security Management Systems Through Security Requirements Engineering Approaches. In Proceedings of the International Symposium on Engineering Secure Software and Systems (ESSoS), LNCS. Springer, to be published. [BKFS11] Kristian Beckers, Jan-Christoph Küster, Stephan Faßbender, and Holger Schmidt. Pattern-Based Support for Context Establishment and Asset Identification of the ISO in the Field of Cloud Computing. In Proceedings of the International Conference on Availability, Reliability and Security (ARES), pages IEEE Computer Society, [BKFS12] Kristian Beckers, Jan-Christoph Küster, Stephan Faßbender, and Holger Schmidt. A Pattern-Based Method for Identifying and Analysing Laws. In REFSQ, to be published. [Cal09] [CL10] Alan Calder. Implementing Information Security based on ISO 27001/ISO 27002: A Management Guide. Haren Van Publishing, Dmitry V. Cheremushkin and Alexander V. Lyubimov. An application of integral engineering technique to information security standards analysis and refinement. In Proceedings of the international conference on Security of information and networks, SIN 10, pages ACM, DS-SE 29

38 [FEN11] Stefan Fenz, Andreas Ekelhart, and Thomas Neubauer. Information Security Risk Management: In which security solutions is it worth investing? Communications of the Association for Information Systems, 28(1): , [FGH + 10] Benjamin Fabian, Seda Gürses, Maritta Heisel, Thomas Santen, and Holger Schmidt. A Comparison of Security Requirements Engineering Methods. Requirements Engineering Special Issue on Security Requirements Engineering, 15(1):7 40, [GHJV94] Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1 edition, [HSHJ08] [ISO08] [ISO09] [Kli10] Thomas Heyman, Riccardo Scandariato, Christophe Huygens, and Wouter Joosen. Using Security Patterns to Combine Security Metrics. In Proceedings of the International Conference on Availability, Reliability and Security (AReS), pages IEEE Computer Society, ISO/IEC. Information technology - Security techniques - Information security risk management. ISO/IEC 27005, International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), ISO/IEC. Common Criteria for Information Technology Security Evaluation. ISO/IEC 15408, International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), Sebastian Klipper. Information Security Risk Management mit ISO/IEC 27005: Risikomanagement mit ISO/IEC 27001, und Vieweg+Teubner, [KRS11] Heinrich Kersten, Jürgen Reuter, and Klaus-Werner Schröder. IT- Sicherheitsmanagement nach ISO und Grundschutz. Vieweg+Teubner, [LCAS11] Alexander Lyubimov, Dmitry Cheremushkin, Natalia Andreeva, and Sergey Shustikov. Information security integral engineering technique and its application in ISMS design. In Proceedings of the International Conference on Availability, Reliability and Security (ARES), pages IEEE Computer Society, [Nis09] [Sun11] Helen Nissenbaum. Privacy in Context: Technology, Policy, and the Integrity of Social Life. Stanford, 1st edition, Ali Sunyaev. Health-Care Telematics in Germany: Design and Application of a Security Analysis Method. Gabler Verlag, 1st edition, DS-SE 30

39 Forschungsmethodik in der Softwaretechnik Wie schreibe ich eine Dissertation in der Software-Forschung? Walter F. Tichy IPD Tichy, Fakultät für Informatik KIT die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) Inhalt! Teil I: Ratschläge für eine schlechte Dissertation! Mit schamlosen Anleihen (4 Folien) bei David Patterson: How to have a Bad Career in Research/Academia Teil II: Wie weiß ich, dass ich einen Fortschritt erreicht habe?! Experiment! Analyse von Software-Depots! Benchmark 2 DS-SE 31

40 Teil I: Ratschläge für eine schlechte Dissertation 3 Schlechte Entscheidung #1: Mach es kompliziert!! Bestes Kompliment für einen Forscher: Es ist so kompliziert, dass ich die Idee nicht verstehe.! Komplexität macht s einfacher für weitere Beiträge: Wenn s niemand versteht, wer kann einem dann widersprechen?! Von was Kompliziertem fällt es leichter, kleine Inkremente zu publizieren.! Falls etwas einfach wäre, wie könnten andere Wissenschaftler deine Brillanz, Intellekt, Tiefgang und Detailwissen erkennen und bewundern? 4 Quelle: David Patterson DS-SE 32

41 5 Schlechte Entscheidung #2: Lass dich nie widerlegen!! Vermeide Erfolgskriterien, Implementierung! Vermeide quantitative Experimente! Bei guter Intuition braucht man keine Versuche!! Warum sollte man Kritikern Munition liefern?! Versuche dauern zu lange. Lieber mehr Ideen generieren.! Niemand erwartet quantitative Ergebnisse.! Vermeide Benchmarks! Warum mit anderen vergleichen? Wir wissen, was richtig ist.! Wenn es ein verrückter Student doch implementiert und testet, dann sag:! Ist nicht für deine Anwendung/Kontext! Wird erst in 20 Jahren wichtig (gibt dir 19 sichere Jahre) Quelle: David Patterson! Benchmarks führen in die falsche Richtung. Jede Menge super Ideen werden vernichtet, nur weil sie jemand ausprobiert. Schlechte Entscheidung #3: Benutze die Software-Wissenschaftsmethode! Überholte wiss. Methode Hypothese Folge von Experimenten ändere 1 Parameter/Experiment Bestätige/widerlege Hypothese Dokumentiere, damit andere replizieren können. Software-Wissenschaftsmethode Ahnung 1 Fallstudie ändere alle Parameter auf einmal Wegwerfen, falls Ahnung nicht bestätigt Warum Zeit verschwenden? Wir kennen die Ergebnisse Können mehr Ideen generieren, wenn niemand reproduzieren muss. 6 Quelle: David Patterson DS-SE 33

42 Schlechte Entscheidung #4; Lass Dich nicht ablenken! (vermeide Rückkopplung!) 7! Sprich nicht mit Kollegen. Deren Probleme zu diskutieren kosten dich nur Zeit.! Lies nur, was Dein Chef vorschlägt (wenn überhaupt).! Verliere keine Zeit und Geld mit Konferenzen.! Verschwende keine Zeit mit dem Polieren von Veröffentlichungen oder Vorträgen (missionarischer Eifer).! Lass Dich nicht durch Nutzer oder Industrie verderben.! Misstraue Deinem Doktorvater. Der hat nur seine eigene Karriere im Sinn.! Arbeite nur die Stunden, für die du bezahlt wirst. Lass dich nicht von der herrschenden Klasse ausnützen.! (aber Studenten muss man richtig ran nehmen.) Quelle: David Patterson Und was wären gute Entscheidungen?! Natürlich das genaue Gegenteil!! Für Begründung, siehe David Patterson, How to have a Bad Career in Research/Academia Auch als Video erhältlich! Sehr empfehlenswert! 8 DS-SE 34

43 Teil II: Wie weiß ich, dass ich einen Fortschritt erzielt habe? 9 Was wird in einer Dissertation eigentlich verlangt? Unbekannte Welt Tiefe P r o m o ti o n Originärer Beitrag (nicht die Weltformel) Haupt-/Masterstudium Grund-/Bachelorstudium Breite des Wissens 10 DS-SE 35

44 Doktorandensymposium der Software Engineering 2012, Berlin, 29. Februar 2012 Softwareforscher bei der Arbeit Ewig gleiche Grundfragen: 1. Wie kann man SW besser konstruieren (schneller, günstiger)? 2. Wie kann man bessere Software konstruieren (zuverlässiger, sicherer, brauchbarer, etc.)? 3. Und wie zeigt man, dass man 1. oder 2. erreicht hat? Quelle: American Scientist 6/ Das kontrollierte, randomisierte Experiment variiere unabhängige Variablen Beobachte abhängige Variablen kontrolliere Störvariablen 12 DS-SE 36

45 Einige Ergebnisse aus Experimenten! Entwurfsmuster funktionieren wie beworben.! Vererbungstiefe ist schlechter Prediktor für Wartungsaufwand.! Paarprogrammierung hilft nur Anfängern.! Paarprogrammierung kann durch Einzelprogrammierung mit Reviews ersetzt werden (bei Anfängern).! Test-getriebene Entwicklung bringt nichts.! UML bringt für die Wartung nichts. Beachte: alles Prozessexperimente, Erlernen geht rasch. Kaum Werkzeugentwicklung nötig. 13 Wann benutzt man das Experiment?! Vorteile:! Kann Ursache-Wirkungs-Zusammenhang identifizieren! Experimentelle Methodik exzellent entwickelt (Statistik, Kontrolle)! Nachteile:! Aufwändig, teuer! Professionelle Teilnehmer sind schwierig zu kriegen! Experimente dauern lange (1 Jahr pro Experiment)! Negative Ergebnisse sind häufig! Nur brauchbar, wenn Methodik/Werkzeug ausgereift und Erlernbarkeit kurzfristig möglich.! Welche empirische Methode soll man nehmen, wenn eine Technik erst noch entwickelt und verbessert werden soll? Dafür ist ein Experiment meist zu teuer. 14 DS-SE 37

46 Ex post facto Studien: Analysieren von Software-Depots! Untersuche die Versionshistorie von Software in Verbindung mit Fehlermeldung! Beispiel: Können Softwaremetriken fehleranfällige Komponenten vorhersagen? Nagappan, Ball, Zeller: Mining Metrics to Predict Component Failures, ICSE 2006 Zimmermann et al: Cross-project Defect Prediction, ESEC/FSE High level description 16 DS-SE 38

47 Projects researched! Internet Explorer 6! IIS Server! Windows Process Messaging! DirectX! NetMeeting >1,000,000 Lines of Code! DS-SE 39

48 Metrics and their Correlation with Post-Release Defects 19 Do metrics correlate with failures? Project A B C D E Metrics correlated w/ failure #Classes and 5 derived almost all all except MaxInheritanceDepth only #Lines (software was refactored if metrics indicated a problem) #Functions, #Arcs, Complexity 20 DS-SE 40

49 Do metrics correlate with failures? Project Metrics correlated w/ failure A #Classes and 5 derived YES! B almost all C all except MaxInheritanceDepth D only #Lines E #Functions, #Arcs, Complexity 21 But only within a project Is there a set of metrics that fits all projects? Project A B C D E Metrics correlated w/ failure #Classes and 5 derived almost all all except MaxInheritanceDepth only #Lines #Functions, #Arcs, Complexity 22 DS-SE 41

50 Is there a set of metrics that fits all projects? Project Metrics correlated w/ failure A NO! B C D E #Classes and 5 derived almost all all except MaxInheritanceDepth only #Lines #Functions, #Arcs, Complexity 23 Wann eignet sich die Analyse von Software?! Vorteile! Große Datenmengen verfügbar! Analyse automatisierbar! Kein Kontakt mit menschlichen Subjekten nötig!! Nachteile! Man kann nur analysieren, was gegeben ist wenn z.b. kein Paarprogrammieren durchgeführt wurde, kann man es auch nicht analysieren.! Ihre neueste Technik kennt noch keiner, daher gibt s dafür auch keine Daten.! Man erhält Korrelationen, aber keinen sicheren Ursache-Wirkungs- Zusammenhang. 24 DS-SE 42

51 Analyse von Software-Depots variiere unabhängige Variablen Beobachte abhängige Variablen kontrolliere Störvariablen 25 Was gibt s denn noch? Empirische Forschungsmethoden Deskriptive Forschung beschreibt Phänomene, Ereignisse, Situationen Experimentelle Forschung Beschreibt Ursache-Wirkung, ist quantitativ Quantitative Studie Qualitative Studie Umfrage Korrelations-Studie Ex post facto Studie Langzeit- und Querschnittsstudie Naturalistische Beobachtung Meta-Studie Fallstudie Ethnographie Phänomenologie Laborexperiment Feldexperiment Simulation Benchmark 26 DS-SE 43

52 Was sind die Probleme der heutigen SW-Empirie?! Fortschritt ist zu langsam, Kosten zu hoch.! Ergebnisse sind nicht konstruktiv.! Der typische Informatiker will etwas konstruieren, nicht nur analysieren.! Wie kann man nachweisen, dass/ob neue Softwaretechniken besser sind,! Softwaretechniken weiter verbessern (nachweislich),! und das schneller als bisher? 27 Vorschlag: Benutze Benchmarks!! Benchmarks sind Mengen von Problemen mit einer Qualitätsmetrik für Lösungen.! Unabhängige Forschungsgruppen wenden ihre automatisierten Werkzeuge an und vergleichen ihre Ergebnisse mit denen von anderen.! Verbesserungen können ohne große Verzögerung implementiert werden, gehen in richtige Richtung.! Benchmarks haben einen riesigen Vorteil gegenüber Versuchen mit menschl. Teilnehmern: Sie können beliebig oft wiederholt werden.! Benchmarks müssen weiterentwickelt werden, um Überanpassung zu vermeiden. 28 DS-SE 44

53 Benchmarks treiben Forschung vorwärts.! Rechnerarchitektur: Benchmarks werden seit Dekaden zum Leistungsvergleich benutzt.! Standard Performance Evaluation Corporation (SPEC) publiziert eine Reihe von Benchmarks (CPU, Web server, Mail Server, AppServer, power consumption, etc.)! Benchmarks und Simulation haben Rechnerarchitektur quantitativ gemacht.! Jede Prozessoreigenschaft muss sich an Benchmarks bewähren. 29 Wo Benchmarks regieren:! Databanken: Transaction Processing Performance Council (TPC)! Spracherkennung: große Mengen von Sprachproben werden benutzt, um Spracherkenner zu trainieren und zu vergleichen (Fehlerraten)! Sprachübersetzung: genauso. 30 DS-SE 45

54 Doktorandensymposium der Software Engineering 2012, Berlin, 29. Februar 2012 Autonome Fahrzeuge: DARPA Herausforderungen 2007 DARPA Urban Challenge 31 Autonome Fahrzeuge: DARPA Herausforderungen In all diesen Fällen haben Benchmarks zu raschen und substanziellen Fortschritten geführt. Erfolgreiche Techniken wurden von anderen Teams rasch aufgegriffen und verbessert. Wie könnten wir vergleichbares Tempo in der Softwareforschung erzielen? 2007 DARPA Urban Challenge 32 DS-SE 46

55 Software-Forschung könnte mehr Benchmarks benutzen! Benchmarks können überall da angewandt werden, wo Softwareprozesse automatisiert werden.! Beteilige dich an der Entwicklung brauchbarer Benchmarks, damit! die Arbeit auf mehrere Schultern verteilt wird,! bessere Werkzeuge gebaut werden können,! die besten Techniken herausgefiltert werden,! der Fortschritt beschleunigt wird.! Beispiele ungewöhnlicher Benchmarks in der SWT folgen. 33 Beispiel: Verarbeitung natürlichsprachlicher Anforderungen 34! Problem: übersetze sprachliche Anforderungen in UML Modelle (und zurück).! Über 70% der Anforderungen sind in uneingeschränkter, natürlicher Sprache geschrieben.! Benchmarks: Echte Anforderungen sind erstaunlich schwierig zu finden:! Lehrbücher enthalten wenige Beispiele, die die Autoren selbst erfunden haben, oder von anderen kopiert haben, die sie auch erfunden haben.! Firmen wollen keine freigeben (Qualität oft peinlich).! Mit Beispielen könnten wir ein Problem nach dem anderen anpacken.! Unsere Sammlung: DS-SE 47

56 Ansatz: Thematische Rollen Einige für SW-Ingenieure interessante Rollen:! agens (AG) der Handelnde. patiens (PAT) der Behandelte. actus (ACT) die Handlung (für Tätigkeitsverben und deren Nominalisierungen) Peter AG wirft ACT einen Ball PAT. Peter AG tätigt einen Wurf ACT des Balls PAT.! instrumentum (INSTR) das Hilfsmittel Peter streicht die Wand mit einem Pinsel INSTR. 35! status (STAT) der Zustand (für Zustandsverben und deren Nominalisierungen) Peter wohnt STAT in Bonn. (Gelhausen2007) Abbildung thematischer Rollen! Peter AG streicht ACT die Wand PAT mit einem Pinsel INSTR.! Wir hätten auch schreiben können: Die Wand PAT wird von Peter AG gestrichen ACT, und zwar mittels eines Pinsels INSTR. AG PAT INSTR Peter Wand Pinsel ACT streicht(pat: Wand, instr: Pinsel) PAT INSTR (Gelhausen2007) 36 DS-SE 48

57 Abbildung von Zustandsverben! Peter AG wohnt STAT in Bonn LOC. AG STAT LOC Peter Bonn wohnt Beispiel für eine einfache Relation. (Gelhausen2007) 37 Thematische Rollen! Einige für SW-Ingenieure interessante Rollen:! Donor (DON) der, der etwas gibt! Recipient (RECP) der Empfänger einer Sache.! Habitum (HAB) etwas, das gegeben oder gehabt wird. Peter DON schenkt Frank RECP eine Uhr HAB. (Gelhausen2007) 38 DS-SE 49

58 Abbildung auf Beziehungen! Peter DON schenkt Frank RECP eine Uhr HAB. DON RECP Peter Frank gib(hab: Uhr,recp: Frank) DON RECP nimm(hab: Uhr, don: Peter) HAB Uhr HAB übergebe(don: Peter, recp: Frank) Beispiel für eine mehrstellige Relation. (Gelhausen2007) 39 Etwas komplexeres Beispiel Whois Protokoll! Eine Spezifikation [ #A WHOIS_server {AG,RECP} listens STAT #on TCP_port_43 PAT #for requests HAB #from WHOIS_clients DON ] [ [ #The WHOIS_client {AG,DON} makes ACT #a text_request {HAB} #to RECP ] SUM #then AG replies ACT #with text_content OPUS ] [ PAT #are terminated ACT #with { ASCII_CR AND #then ASCII_LF } INST ] Quelle: IETF WHOIS Protocol Specification, RFC 3912, Ch. 2, Protocol Specification (Gelhausen2007) 40 DS-SE 50

59 Etwas komplexeres Beispiel Whois Protokoll annotiert! Annotationssprache SAL E Relation Kommentar (1 Wort) Rolle(n) [ #A WHOIS_server {AG,RECP} listens STAT #on TCP_port_43 PAT #for requests HAB #from WHOIS_clients DON ] [ [ #The WHOIS_client {AG,DON} makes ACT #a Referenz auf vorhergehende Instanz text_request {HAB} #to RECP ] SUM #then AG replies ACT #with text_content OPUS ] [ PAT #are terminated ACT #with { ASCII_CR AND #then ASCII_LF } INST ] Quelle: IETF WHOIS Protocol Specification, RFC 3912, Ch. 2, Protocol Specification (Gelhausen2007) 41 DS-SE 51

60 42 Whois Protokoll: Übersetzung in UML mit SAL E mx output connection ASCII_CR closed: boolean requests finished(): void HAB treminated(instr: ASCII_CR,instr: ASCII_LF): void HAB ASCII_LF TCP_port_43 POSS WHOIS_server listen(pat: TCP_port_43): void text_content replies(): text_content closes(pat: connection): void WHOIS_client RECP DON makes(): void DON RECP HAB end response HAB POSS line morethanone Qualitätsmetrik: Ausbeute, Präzision QUALII QUAL text (Gelhausen2007) DS-SE 52

61 Beispiel: Auto-Parallelisierungs-Benchmark! Um zu zeigen, dass automatische Parallelisierungstechniken funktionieren, stellen wir ebenfalls einen Benchmark zusammen.! Besteht aus Paaren: seq. Implementierung und handparallelsierte Version (oder Versionen)! Daran kann man z.b. das Konzept der Autofutures oder andere Muster testen. 43 Zusammenfassung! Der Gebrauch von Benchmarks in der Werkzeugentwicklung in der Softwaretechnik könnte deutlich höher sein.! Mit realistischen Benchmarks bekäme man zuverlässige und vergleichbare Ergebnisse.! Benchmarks beschleunigen den Fortschritt: sie sondern die schlechteren Ansätze aus, lenken die Aufmerksamkeit auf das Wichtige.! Benchmarks formen ein Gebiet: es wird genau das verbessert, was in den Benchmarks repräsentiert ist.! Wenn die Werkzeuge ausgereift sind, dann erst überprüfe Brauchbarkeit mit Menschen (dem teuren Experiment). 44 DS-SE 53

62 45 DS-SE 54

63 Schreiben einer Dissertation: Traum oder Albtraum? Claus Lewerentz Brandenburgische Technische Universität Cottbus Lehrstuhl Software-Systemtechnik Claus Lewerentz, BTU Cottbus Writing a Dissertation is state of the art problems tools ideas experiments theories evaluation Claus Lewerentz, BTU Cottbus DS-SE 55 1

64 Writing a Dissertation is Claus Lewerentz, BTU Cottbus Let s share our Writing Experiences: Claus Lewerentz, BTU Cottbus DS-SE 56 2

65 Elements of a structured writing process from Peg Boyle Single: Demystifying Dissertation Writing (2009) Claus Lewerentz, BTU Cottbus Interactive Reading and Note Taking /1 reading papers / books reserve reading time 2-pass-reading get structure and annotate re-read and take notes summarize ideas identify most relevant references collect notes not articles! Claus Lewerentz, BTU Cottbus DS-SE 57 3

66 Interactive Reading and Note Taking /2 the reading / sharing group (bi)weekly meeting to discuss papers present each paper in 5 min what are the main ideas? what do I like? research method? structure / style / patterns of writing? Claus Lewerentz, BTU Cottbus Citable Notes create structured and annotated bibliography keep notes and quotations with the bibliographic references use appropriate tool support for creating and maintaining bibliographies EndNote store PDF sources store web links BibTeX (Word ) Claus Lewerentz, BTU Cottbus DS-SE 58 4

67 Focusing on Focus Statement short statement (4 sentences) to keep you focused state the very essence of the dissertation research question / problem statement intended outcome / results constraints / context theory / research methodology data sources written in first person active voice C 3 = clear, concise, compelling write several versions / revisions take time it is extremely important! Claus Lewerentz, BTU Cottbus Example focus statement [Noack 2007] Surprising results can be obtained by applying some established clustering and layout algorithms to a trade network of seven European and three American countries: Not Europe is separated from America, but Sweden is separated from the rest of the world. Indeed, this separation is optimal but with respect to the wrong criteria. This work is about criteria for identifying closely interlocked countries in international trade, groups of friends in social networks, subject areas in hypertexts, and cohesive modules in software systems; about criteria for identifying what researchers from Herbert Simon [Sim62] to Mark Newman [New03] have observed to be ubiquitous in real-world systems: weakly interacting groups of strongly interacting elements. Part I introduces, validates, and unifies quality measures for groupings, i.e. measures that quantify to what degree a given grouping clusters strongly interacting system elements and separates weakly interacting system elements. Part II applies these measures to evaluate design quality and identify design problems in software systems. Claus Lewerentz, BTU Cottbus DS-SE 59 5

68 Some Guiding Questions What is you dissertation about? Why are you conducting this dissertation project? Why are you enthusiastic about it? Why should anyone care about your subject? What is the big picture, the context that it makes it important for you? When are you finished with this project, what is the one point you that you want to leave with your readers? Which theories or methods will you use to research? Why? What data, sources, objects are most appropriate to work with? What will be the implications of your dissertation? Claus Lewerentz, BTU Cottbus One Page Outline framing your work skeleton of your dissertation viewing the dissertation as a whole title your name goals (include focus statement) table of content your commitment the outline is not a corset but a dynamic tool Claus Lewerentz, BTU Cottbus DS-SE 60 6

69 The Thesis Proposal Claus Lewerentz, BTU Cottbus Examples of Dissertation Outlines Dirk Beyer 2003 new method and tool Andreas Noack 2007 unifying theory and application Jens Heidrich 2008 excellent empirical study Roland Neumann 2010 new method and systematic validation Claus Lewerentz, BTU Cottbus DS-SE 61 7

70 Developing a Regular Writing Routine plan for regular (daily) writing time when can you write best? don t wait for large blocks of exclusive writing time (they don t come) 20 min time slots ( less is more ) don t wait for inspiration or the right mood writing may trigger inspiration have a silent hour every day have a designated writing space get unplugged from the net (no , phone, SMS, news, chat, ) have a clean desk go to library or other room Claus Lewerentz, BTU Cottbus How to write? stick to your long outline write in the outline document draft text (creative mode) block out the internal critics use colloquial style revise the text (analytical mode) Claus Lewerentz, BTU Cottbus DS-SE 62 8

71 The Role of Revision the single source principle don t scatter your writing over many documents use revision control tools write revise re-write incremental cyclic refinement process solicit feedback through peer reviews Claus Lewerentz, BTU Cottbus Overcoming Writer s Block /1 perfectionism major trap for bright students write shitty first drafts try talking text ( build dialogue situations) make bad texts brilliant later relax / accept imperfection accept deadlines listen to your supervisor(s) remember: THEY award you the doctoral degree Claus Lewerentz, BTU Cottbus DS-SE 63 9

72 Overcoming Writer s Block /2 procrustination you wait for inspiration or large blocks of time you do all-nighters you clean kitchen / cook meals for friends / help your fellow students/ install new tools / instead of working on your dissertation set priorities and routine unplug / be ascetic / work continuously in small chunks get incentives for completing tasks establish social control team up with writing partner define and meet reasonable milestones and deadlines Claus Lewerentz, BTU Cottbus Overcoming Writer s Block /3 impatience you want things get done to quickly not enough pre-writing done you start writing when you are not ready to write you work on to many things at the same time control your projects plan for breaks stick to the 24-hour-rule only accept new tasks after 24 hour re-think time be patient and forgiving with yourself Dissertation writing is not for sprinters but for marathon runners Claus Lewerentz, BTU Cottbus DS-SE 64 10