Prozessorientierte Konstruktion von Benutzeroberflächen

Größe: px
Ab Seite anzeigen:

Download "Prozessorientierte Konstruktion von Benutzeroberflächen"

Transkript

1 Oberflächlich mit System Prozessorientierte Konstruktion von Benutzeroberflächen Jan Christian Krause, Kai Benjamin Joneleit Die POC-UI-Methode ist ein leichtgewichtiges Verfahren zur softwaretechnischen Strukturierung von grafischen Oberflächen. Sie ist in Java- Projekten des Teams Trading & Plant Employment von Vattenfall Europe Information Services GmbH entwickelt worden und ergänzt die bestehenden Architekturmuster für grafische Benutzeroberflächen um einen Entwurfsprozess. Mit Hilfe dieser Vorgehensweise konnte bei der Vattenfall Europe Information Services GmbH die Effizienz des Entwicklungsprozesses spürbar optimiert werden. Einführung Die Entwicklung moderner Softwaresysteme ist häufig durch E hohe Komplexität und hohe Kosten geprägt. Beides steht oft in proportionalem Verhältnis zueinander. Erfahrungsgemäß tragen die Aufwände zur Entwicklung grafischer Benutzeroberflächen signifikant zur Kostenentwicklung eines Projektes bei. Dieser Artikel stellt mit der POC-UI-Methode (Process Oriented Construction of User Interfaces) einen Konstruktionsleitfaden für den software-technischen Entwurf grafischer Benutzeroberflächen vor. Ziel ist es, den Entwurfsprozess von Oberflächen durch Konventionen zu standardisieren und dadurch Entwicklungs- und Wartungskosten zu senken. Die POC-UI-Methode ist in Java-Projekten des Teams Trading & Plant Employment von Vattenfall Europe Information Services GmbH über anderthalb Jahre entwickelt und in mehreren Projekten international erfolgreich angewandt worden. Vattenfall Europe Information Services ist IT-Full-Service-Anbieter für die Energiewirtschaft. Das Leistungsspektrum reicht von der strategischen Beratung, der Konzeption von IT-Systemen, der Entwicklung und Implementierung von IT-Lösungen bis hin zum Outsourcing der gesamten IT-Infrastruktur. Bestehende Ansätze zur software-technischen Konstruktion von Oberflächen Grafische Oberflächen werden je nach Kunden und Organisationsform des Projektes auf verschiedene Arten, wie z. B. durch Anwendungsfälle, grafische Skizzen oder Story- bzw. Taskcards spezifiziert. Bei fehlenden Konventionen unterscheiden sich die Implementierungen derselben Spezifikation oft nach Erfahrungen, Vorlieben und fachlichem Verständnis der Entwickler. Dies kann zu wiederkehrenden hohen Einarbeitungs- und Wartungsaufwänden für Programmierer führen. Meist existieren Konventionen in Projekten auf hohen technischen Detailebenen, z. B. für Methoden- bzw. Klassenbezeichner oder Klammersetzungen. Jedoch zeigt die Praxis, dass der Entwurf und die Struktur von Klassenmodellen selten vollständig durch Konventionen definiert sind. Dieses Problem ist unabhängig von den verwendeten Grafikbibliotheken (z. B. das Standard Widget Toolkit [SWT], Swing usw.) oder speziellen Oberflächen-Editoren (z. B. [Jigloo], [Matisse] usw.). In der Literatur finden sich diverse software-technische Architekturvorschläge für grafische Oberflächen, aus denen sich Klassenmodelle ableiten lassen. Fowler identifiziert vier verschiedene Architekturtypen und grenzt diese anhand der Lokalisierung des Codes für Layout, Daten und Logik sowie für den Datenfluss voneinander ab [Fowl06]. Bei allen Vorschlägen wird die Software-Komplexität auf den beiden technischen Ebenen Steuerelement (hoher Detailgrad) und Formular/Bildschirm (niedriger Detailgrad) behandelt. Ebenen zwischen beiden Extrema sind mit technisch-orientierter Argumentation unscharf abgrenzbar. Züllighoven et al. zerlegen die Formular-/Bildschirm-Ebene deshalb anhand von fachlichen Kriterien rekursiv in Teil-Formulare (Prinzip Teileund-Herrsche ) [Züll98]. Diese Abgrenzung orientiert sich an den fachlichen Objekten, die in der jeweiligen Teil-Oberfläche bearbeitet werden. Teil-Oberflächen werden als Werkzeuge zur Bearbeitung der Objekte verstanden. Jedoch bleibt die Frage unbeantwortet, wie ein Entwickler aus Spezifikationen wie Anwendungsfällen, grafischen Skizzen usw. die jeweilige Architektur ableiten kann und welche Rollen an diesem Prozess beteiligt sind. Züllighoven et al. beschreiben die Identifikation von Werkzeugen anhand fachlicher Szenarien in Textform. Dieses Vorgehen impliziert jedoch viel kreative Entwurfsarbeit seitens des Entwicklers. Zudem definiert keiner der Architekturtypen die verschiedenen Zustände der beteiligten Komponenten sowie deren Übergänge ineinander (z. B. einer View in einer Model-View-Controller-Architektur). In der Praxis ist ein definierter Lebenszyklus sehr nützlich, beispielweise bei der Eingrenzung von Fehlern oder bei der Auswahl einer geeigneten Stelle für Erweiterungen im Quelltext. Standardisierter Oberflächenentwurf mit der POC-UI-Methode Die POC-UI-Methode wird anhand eines einfachen Beispiels erläutert: eine grafische Oberfläche ist in das bestehende Kundenverwaltungssystem eines Energieversorgers zu implementieren. Die Oberfläche dient der Anzeige der Vertragsdaten (u. a. Bankverbindung, Stromtarif), der Anschrift und des Bemerkungstextes zu einem Privatkunden. Ein Kunde wird über seine Kundennummer oder seinen Namen gefunden (Vor- oder Nachname als Volltextsuchkriterium). Das Anklicken des Kunden in der Trefferliste führt zum Visualisieren der zugehörigen Kundendaten. Sollte der Kunde nicht im System vorhanden sein, so wird dem Mitarbeiter ein Fehler angezeigt. Aus Platzgründen wird in diesem Artikel kein Quelltext diskutiert. Eine Implementierung dieses Beispiels in Java/Swing steht auf der Internetseite von POC-UI zum Download bereit [POC-UI]. Beschreibung des Entwurfsprozesses Die POC-UI-Methode ist ein software-technischer Konstruktionsleitfaden für grafische Oberflächen. Sie hilft Architekten und Kunden bzw. Fachabteilungen beim Entwurf eines Benutzungsmodells sowie Programmierern bei der Strukturierung des Quelltextes auf dessen Basis. Abbildung 1 zeigt den Entwicklungsprozess nach der POC- UI-Methode. Insgesamt sind drei Rollen an dem Prozess beteiligt: der Kunde/die Fachabteilung, der Architekt und der Programmierer. Ausgangspunkt des Prozesses ist die Spezifikation NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: 27

2 ändert der Kunde zunächst die Spezifikation. Anschließend wird der Prozess in Phase 1 fortgesetzt. Fehlerhafte Implementierungen werden vom Programmierer gemäß Spezifikation korrigiert (Phase 2). Definition des Benutzungsmodells Abb. 1: Entwurfsprozess nach der POC-UI-Methode des Kunden. Da der Entwurfsprozess nicht auf eine bestimmte Form der Kundenspezifikation ausgerichtet ist, kann die POC- UI-Methode problemlos in verschiedene Vorgehensmodelle wie das Wasserfallmodell, das V-Modell oder agile Ansätze wie Scrum, XP usw. integriert werden. Der Entwurfsprozess gliedert sich nach klassischer iterativer Vorgehensweise in drei Phasen: Phase 1: Definition des Benutzungsmodells Zunächst definiert der Architekt gemeinsam mit dem Kunden das Benutzungsmodell der zu implementierenden Oberfläche. Dieses besteht aus: H einem Prozessmodell, welches die fachlichen Aufgaben enthält, die mit der Oberfläche bearbeitet werden können. Ferner definiert es die logische Ausführungsreihenfolge der Aufgaben. H einer Spezifikation des Layouts, der zu verwendenden Steuerelemente (Knöpfe, Tabellen, Checkboxes,...) und deren Interaktion. Das Prozessmodell und die Layoutspezifikation werden in direkter Wechselwirkung erstellt. Phase 2: Implementierung des Benutzungsmodells Anschließend leitet der Programmierer aus dem Benutzungsmodell ein Klassenmodell ab und programmiert das Layout sowie das Verhalten der Oberfläche. Phase 3: Verifikation des Benutzungsmodells Abschließend prüft der Kunde, ob die Implementierung seinen Bedarf deckt. Sollten Änderungen an der Implementierung erforderlich sein, die nicht aus der Spezifikation hervorgehen, Das Benutzungsmodell ist das Bindeglied zwischen Spezifikation und Implementierung (s. Abb. 2). Es transformiert die fachliche Spezifikation der Anforderungen in explizite Vorgaben zur Implementierung. Die Erfahrung zeigt, dass diese Transformation in der Praxis meist implizit durch den Programmierer vorgenommen wird. Während dieser Phase treten häufig erst sehr viel später erkannte Missverständnisse auf, die zur negativen Beeinflussung der Entwicklungskosten beitragen. Die dargestellte Dreiteilung hat sich beim Entwurf von Datenmodellen für Datenbanken bewährt und ist auf den Entwurf grafischer Oberflächen übertragbar (Aufteilung in konzeptuelles, logisches und physisches Modell). Das Benutzungsmodell besteht aus einem Prozessmodell und einer Layoutspezifikation. In der Layoutspezifikation legen Kunde und Architekt die zu verwendenden Steuerelemente und deren Anordnung fest. Das Prozessmodell enthält die Aufgaben, welche über die Oberfläche bearbeitet werden können, sowie deren logische Reihenfolge. Aufgaben, die durch das Backend oder den Benutzer allein ausgeführt werden, sind nicht enthalten. Aufgaben können in Teilaufgaben aufgespalten werden (repräsentiert durch Subprozesse). Diese Aufgabenspezifikation bildet die Grundlage des Klassenmodells. Der Programmieraufwand kann zwischen den Aufgaben aus dem Prozessmodell variieren. Aus diesem Grund muss der Architekt software-technisch komplexe Aufgaben erkennen und deren fachliche Zerlegung in Teilaufgaben gemeinsam mit dem Kunden herbeiführen. Ebenso muss er den Kunden vor der, aus software-technischer Sicht, zu detaillierten Formulierung von Aufgaben bremsen. Der Hauptzweck des Prozessmodells ist die fachliche Reduktion der Aufgabenkomplexität durch den Kunden. Es beschreibt deshalb unter anderem nicht alle möglichen Durchläufe des Benutzers durch die Oberfläche oder Rücksprünge zwischen den Aufgaben. Für detaillierte Entwurfsleitlinien wird auf die POC-UI-Internetseite verwiesen [POC-UI]. Das Prozessmodell für das vorab erläuterte Beispiel ist in Abbildung 3 enthalten. Als Notation wird die Business Process Modelling Notation (kurz BPMN) verwendet, welche sich insbesondere aufgrund der Notationselemente Pool und Lane sehr gut für das Modellieren der Prozesse nach der POC-UI-Methode eignet. Diese repräsentieren jeweils die Applikation und den Container einer Oberfläche. Grundsätzlich sind aber auch andere Notationen wie UML-Aktivitätsdiagramme nutzbar. Abb. 2: Einordnung des Benutzungsmodells Abb. 3: Prozessmodell für die Beispielanwendung 28 NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt:

3 Ableitung des Klassenmodells aus dem Benutzungsmodell Aus dem Prozessmodell des Benutzungsmodells leiten sich die beteiligten Klassen und ihre Beziehungen untereinander ab. Die beteiligten Klassen lassen sich in drei verschiedene Kategorien einteilen: H Container repräsentieren den äußeren Rahmen einer Oberfläche, z. B. als einfacher Dialog, Seite eines Assistenten oder ViewPart. Über Container werden die Oberflächen in die umgebende Applikation integriert. H Composites kapseln das Layout und das Verhalten der Oberfläche (Benennung nach dem Kompositum-Muster, s. [GoF95]). H Selections repräsentieren den fachlichen Zustand eines Composites. Dieser Zustand ist die Aggregation der Zustände aller enthaltenen Steuerelemente und Sub-Composites. Die Bezeichnung Selection ist in Anlehnung an den Begriff Selektion (eines Elements aus dem Wertebereich des Steuerelements) gewählt worden. Eine Oberflächen-Implementierung nach der POC-UI-Methode besteht im einfachsten Fall aus einem Container, einem Composite und einer Selection. Durch die Trennung von Container und Composites wird der Austausch von Containern ermög licht. So können Composites ohne die Applikation über Testcontainer gestartet und manuell getestet werden. Dies minimiert den Zeitaufwand für Compile-Debug-Zyklen erheblich. Der View- Begriff der Model-View-Controller- und Model-View-Presenter-Architekturen sieht diese Unterscheidung nicht vor. Die POC-UI-Methode definiert, dass für jede Aufgabe aus dem Prozessmodell ein korrespondierendes Composite mit eigenem Selection-Typ existiert. So ergibt sich aus der Aufgabenhierarchie im Prozessmodell eine analoge Composite-Hierarchie im Klassenmodell. Eine Composite-Klasse kapselt alle zu einer Aufgabe minimal benötigten Steuerelemente und Sub- Composites. Die zu verwendenden Steuerelemente sind in der Layoutspezifikation definiert. Abbildung 4 zeigt alle am Beispiel beteiligten Composites und ihre Aggregation. Da Container zu Testzwecken austauschbar sein sollen, dürfen sie selbst kein Verhalten der Oberfläche implementieren. Folglich kann der Container nur genau ein Composite referenzieren, welches die gesamte Oberfläche kapselt. Diese Überlegung spiegelt sich in der Aufgabenhierarchie des Prozessmodells wider, weil diese immer ein Baum mit einer Wurzel-Aufgabe bzw. einem Wurzel-Composite ist. Hier wird die Erstellung des Prozessmodells als eine software-technische Modellierungsleistung des Architekten deutlich erkennbar. Lebenszyklus eines Composites Grundsätzlich durchläuft ein Composite zunächst die Initialisierungs-, dann die Nutzungs- und abschließend die Finalisierungsphase. Die Klasse AbstractComposite der Beispielimplementierung realisiert diesen Lebenszyklus als Superklasse jedes Composites [POC-UI]. Sie definiert die Methoden für die Übergänge zwischen den Zuständen. Der Composite-Lebenszyklus wird durch das Zustandsdiagramm in Abbildung 5 gezeigt. Da vor allem Initialisierungsmethoden sehr lang und unübersichtlich werden können, wird die Initialisierungsphase in die Layout-, die Verhaltens- und die Wertinitialisierung unterteilt. So ist die semantische Eindeutigkeit der einzelnen Methoden gewährleistet und der Programmierer kann exakt zuordnen, welcher Code in welcher Methode zu platzieren ist. Die einzelnen Initialisierungsmethoden werden dadurch kürzer und übersichtlicher. Tabelle 1 gibt einen kurzen Überblick über die Semantik der Methoden. Abb. 5: Lebenszyklus eines Composites Abb. 4: Analogie zwischen Aufgabenhierarchie und Composite-Hierarchie NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: 29

4 Methodenname void initgui() void initlistener() void setselection (ISelection selection) void cleanup() Kurzbeschreibung In initgui() werden Layout, Steuerelemente und Sub-Composites instanziiert In der Methode initlistener() werden alle Beobachter instanziiert, z. B. für Steuerelemente oder Sub- Composites Über diese Methode werden Selections an das Composite übergeben und auf dessen Steuerelemente und Sub-Composites abgebildet. Dies ist die einzige Stelle im Composite, an der Datenübergaben an Steuerelemente oder Sub-Composites implementiert sind Diese Methode repräsentiert die Finalisierung des Composites, z. B. wenn dessen Container geschlossen worden ist. Hier werden z. B. Beobachter von den Steuerelementen und Sub-Composites wieder abgemeldet Tabelle 1: Kurzübersicht wichtiger Methoden der Klasse AbstractComposite Fehlerkategorie Layoutfehler Falsch angezeigte Werte Unerwartetes Verhalten Finalisierungsfehler In jeder der hier abgebildeten Phasen können spezifische Fehlersituationen auftreten, welche sich in Kategorien einteilen lassen. Die zugehörigen Methoden der Zustandsübergänge bieten Einstiegspunkte in den Code, wodurch es dem Programmierer möglich wird, Fehler schnell einzugrenzen. Es ist dabei irrelevant, welcher Programmierer den Quelltext geschrieben hat, da der Methodenaufbau und der Lebenszyklus bei allen Composites auf dieselbe Weise definiert sind. Tabelle 2 enthält identifizierte Fehlerkategorien und die jeweilige Einstiegsmethode zur Fehlerlokalisierung. Modellierung des Datenflusses Einstiegsmethode initgui() setselection() initlistener cleanup() Tabelle 2: Fehlerkategorien und Einstiegsmethoden in der Klasse AbstractComposite Die POC-UI-Methode definiert, dass sich alle technischen Zustände eines Composites ausschließlich aus der zugehörigen Selection ableiten müssen. Der Datenfluss folgt immer demselben Schema: H Schritt 1: Zuweisung neuer Werte an die Selection-Instanz. H Schritt 2: Übergabe der Selection-Instanz an das Composite mittels Aufruf von setselection(). In der Methode setselection() ist die Zuweisung der Selection- Attribute auf die einzelnen Steuerelemente und Sub-Composites implementiert. So wird beim Aufruf dieser Methode die gesamte Sub-Composite-Hierarchie je nach Bedarf aktualisiert. Es ist irrelevant, ob die Selection Composite-intern (z. B. durch einen ModifyListener eines Textfeldes) oder Composite-extern durch ein hierachisch übergeordnetes Composite verändert worden ist. Gemäß der Composite-Hierarchie melden Super-Composites an ihren Sub-Composites Beobachter an. Die Beobachter werden benachrichtigt, sobald eine modellierte Aufgabe abgeschlossen ist. Abbildung 6 zeigt dieses Prinzip anhand der Aufgabe Öffne Kundendatensatz aus dem Prozessmodell des Beispiels in Abbildung 3. Nachdem der Benutzer den Namen eines Kunden eingegeben hat, klickt er auf den Knopf Suchen. Dadurch ist eindeutig definiert, dass die Aufgabe Erfasse Suchkriterium abgeschlossen ist. Das Composite Erfasse Suchkriterium feuert das entsprechende Ereignis (Schritt 1). Das hierarchisch nächsthöhere Composite hat jeweils einen Beobachter an seinen Sub-Composites registriert und kann so auf deren Zustandsänderungen reagieren. Sobald ein Suchkriterium erfasst ist, startet dieser Beobachter die Kundensuche und setzt die gefundenen Kunden in die Selection des Öffne Kundendatensatz -Composites. Der anschließende Aufruf von setselection() führt dazu, dass beide Sub-Composites, falls notwendig, aktualisiert werden (Schritt 2). Das Benutzungsmodell des Beispiels definiert, dass die Aufgabe Öffne Kundendatensatz erst abgeschlossen ist, wenn ein gefundener Kunde aus der Trefferliste selektiert worden ist. Aus diesem Grund wird das Ereignis nicht weiter nach oben in der Hierarchie propagiert. Während der Erstellung des Prozessmodells definiert der Architekt gemeinsam mit dem Kunden für jede Aufgabe, nach welchen Ereignissen diese abgeschlossen ist. Das Sequenzdiagramm in Abbildung 7 zeigt das skizzierte Beispiel im Detail. Composites feuern Ereignisse ausschließlich nach Abschluss einer modellierten Aufgabe. Diesen software-technischen Aspekt muss der Architekt beim Entwurf des Prozessmodells berücksichtigen. Sobald mehrere Ereignistypen notwendig werden, liegt erfahrungsgemäß ein Modellierungsproblem im Prozessdiagramm vor. Durch den einheitlichen Lebenszyklus Abb. 6: Datenfluss während der Kundensuche in der Beispielanwendung Abb. 7: Datenfluss zur Suche eines Kunden im Beispiel 30 NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt:

5 und die daraus resultierenden einheitlichen Schnittstellen sind Composites als in sich geschlossene Komponenten zu verstehen. Bei Programmerweiterungen oder bei der Fehlersuche können diese Komponenten als Blackboxes betrachtet werden und damit die Komplexität des zu betrachtenden Quelltextes reduzieren. Außerdem sind die Komponenten in verschiedenen Oberflächen wiederverwendbar. Erfahrungen mit der POC-UI-Methode Über die vergangenen anderthalb Jahre konnten Erfahrungen in den Planungs-, Entwicklungs- und Wartungsphasen verschiedener Projekte der Vattenfall Europe Information Services GmbH gesammelt werden. In der Planungsphase wird über das Benutzungsmodell explizit definiert, wie die zu implementierende Oberfläche in fachlich und software-technisch identisch strukturierte Teilprobleme zu zerlegen ist. Auf diese Weise entstand bei allen Beteiligten ein gemeinsames Verständnis und daraus resultierend eine weniger aufwändige, dafür präzisere Kommunikation. Entwickler konnten Aufwandschätzungen für einzelne Teilprobleme abgeben, die vom Projektleiter gemäß der Aufgabenhierarchie des Prozessmodells aggregiert wurden. Der Aufwand für die so abgegrenzten Teilprobleme konnte einfacher und meist auch präziser als für die gesamte Oberfläche geschätzt werden. Während der Entwicklungsphase wurden spürbare Produktivitätsgewinne erzielt. Aufgrund des klar strukturierten Prozessund Klassenmodells arbeiteten mehrere Entwickler zeitgleich an einem Dialog. Dies geschah praktisch ohne Integrationsaufwand durch z. B. Merge-Konflikte in der Versionskontrolle. Des Weiteren wurde viel Entwurfszeit gespart, da kein Entwickler ein umfangreiches Klassenmodell inklusive Lebenszyklus der Komponenten und deren Datenfluss neu konzipieren musste. In der Wartungsphase machten sich das iterativ dokumentierte Benutzungs- und Klassenmodell, der definierte Lebenszyklus und das Datenflusskonzept bezahlt. Entwickler fanden sich sowohl in eigenem als auch in fremdem Quelltext sehr schnell zurecht. So wurde die verfügbare Zeit größtenteils in die Lösungsimplementierung und weniger in das Verständnis, beispielsweise des Klassenmodells, investiert. Durch strukturierten Quelltext und Lebenszyklen waren Seiteneffekte durch Änderungen an fremdem Quelltext für Entwickler abseh- und eingrenzbarer. Dies ist ein nicht zu unterschätzender Gewinn, da viele Entwickler vor Änderungen an fremdem Code gehemmt sind. Der durch diese Hemmungen verursachte Zeitverlust wird durch den Einsatz der POC-UI-Methode minimiert. Außerdem führte der Einsatz der POC-UI-Methode meist automatisch zu einfacher zu bedienenden Oberflächen, da alle Steuerelemente und Sub-Composites zur Bearbeitung einer fachlichen Aufgabe in einem eigenen Composite zusammengefasst werden. Dies impliziert, dass diese nah beieinander in der Oberfläche platziert sind. Nach dem Gesetz der Nähe aus der Gestaltpsychologie ist es für den Benutzer so einfacher, einen inhaltlichen Bezug zwischen den Komponenten herzustellen [Wert23]. Dies bedeutet aber auch, dass die Steuerelemente und Sub-Composites nicht völlig frei auf dem Bildschirm platziert werden können, ohne die Konventionen zu verletzen. Einige Entwickler bevorzugen Systeme mit wenigen, dafür aber längeren Klassen. Es muss jedoch erwähnt werden, dass die POC-UI-Methode ungeeignet für diese Entwickler ist. Ihr Einsatz führt meist zu mehreren kürzeren Klassen. Des Weiteren wird der Mehrwert durch Einsatz der POC-UI-Methode in eingespielten Teams mit ähnlich umfassenden Konventionen gering sein. Hier bietet es sich an, einzelne POC-UI-Konzepte bei Bedarf in die bestehende Menge an Konventionen zu übernehmen. Fazit Dieser Artikel stellt mit der POC-UI-Methode ein leichtgewichtiges Verfahren zur software-technischen Strukturierung von grafischen Oberflächen vor. Sie ergänzt die bestehenden Architekturmuster um einen Entwurfsprozess, welcher die fachliche Zerlegung der Oberfläche in Komponenten vorgibt und zeigt, wie diese in eine einheitlich strukturierte Implementierung überführt werden können. Ferner führt ein definierter Lebenszyklus der Komponenten zur schnelleren Lokalisierung von Fehlern und geeigneten Stellen für Erweiterungen im Quelltext der Oberfläche. Durch den Einsatz dieser Vorgehensweise konnte bei Vattenfall Europe Information Services die Effizienz des Entwicklungsprozesses spürbar optimiert werden. Die POC-UI-Methode wird durch eine sehr kleine Klassenbibliothek für Java/Swing unterstützt (für Download siehe [POC-UI]). Die Methode ist im Kern von der Technologie unabhängig und lässt sich mit geringem Zeitaufwand portieren. Neben den hier beschriebenen Aspekten bietet sie Konventionen für den Umgang mit Ressourcen (Bilder, Farben usw.), die Integration von Containern in die Applikation und die Kapselung von Geschäftslogik. Als zukünftige Entwicklungsperspektiven sind die Portierung auf andere Programmiersprachen sowie die stärkere Integration der Applikation und der eventuell vorhandenen Server in die POC-UI-Methode zu nennen. Literatur und Links [Fowl06] M. Fowler, GUI Architectures, 2006; [GoF95] E. Gamma, et al., Design Patterns Elements of Reuseable Object-Oriented Software, Addison-Wesley, 1995 [Jigloo] Jigloo SWT/Swing GUI Builder for Eclipse and WebSphere, [Matisse] Matisse GUI Editor, [POC-UI] Sourceforge-Projekt Process-Oriented-Construction of User Interfaces, [SWT] The Standard Widget Toolkit, [Wert23] M. Wertheimer, Untersuchungen zur Lehre von der Gestalt, in: Psychologische Forschung: Zeitschrift für Psychologie und ihre Grenzwissenschaften 4, Seite , 1923 [Züll98] H. Züllighoven, et al., Das objektorientierte Konstruktionshandbuch nach dem Werkzeug & Material-Ansatz, dpunkt Verlag, 1998 Jan Christian Krause ist Diplom-Wirtschaftsinformatiker (FH) und Berater beim Hamburger Consulting- Haus AKRA GmbH. Er verfügt über umfangreiche Erfahrungen im Bereich der Rich-Client-Entwicklung, insbesondere auf Basis der Eclipse RCP. Neben dem Engagement in Projekten verfasst er seine Dissertation im Kontext serviceorientierter Architekturen und maschineller Sprachverarbeitung an der Universität Hamburg. Kai Benjamin Joneleit ist Diplom-Medieninformatiker (FH) und arbeitet als Berater bei der CS Consulting AG in Hamburg. Er hat langjährige Erfahrung in der Entwicklung von Enterprise-Applikationen, insbesondere in der GUI-Entwicklung im Java-Umfeld. NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: 31

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Überblick 1.Einfürung in die Multi-Tier Architektur 2.Ausgangspunkt und Probleme 3.Rundgang durch die Architektur 4.Architektur

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS)

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) BPM und egpm Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) C1 WPS GMBH //// Vogt-Kölln-Str. 30 //// 22527 HAMBURG

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

3.9 Grundelemente einer Benutzeroberfläche

3.9 Grundelemente einer Benutzeroberfläche 92 3 Grundlagen einer ios-anwendung 3.8.4 Target-Actions Einer der häufigsten Anwendungsfälle bei einer Oberfläche ist das Betätigen einer Schaltfläche durch einen Anwender, woraufhin eine bestimmte Aktion

Mehr

Anwendungspraktikum aus JAVA Programmierung im SS 2006 Leitung: Albert Weichselbraun. Java Projekt. Schiffe Versenken mit GUI

Anwendungspraktikum aus JAVA Programmierung im SS 2006 Leitung: Albert Weichselbraun. Java Projekt. Schiffe Versenken mit GUI Anwendungspraktikum aus JAVA Programmierung im SS 2006 Leitung: Albert Weichselbraun Java Projekt Schiffe Versenken mit GUI 1. Über den Autor: Name: Marija Matejic Matrikelnummer: 9352571 E-mail: marijamatejic@yahoo.com

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Agile Softwareentwicklung und Usability Wie mit Best Practices eine Brücke geschlagen werden kann

Agile Softwareentwicklung und Usability Wie mit Best Practices eine Brücke geschlagen werden kann Agile Softwareentwicklung und Usability Wie mit Best Practices eine Brücke geschlagen werden kann UIG-Frühjahrstagung 2015 15. März 2015, Mannheim Dominik Magin, Hartmut Schmitt 1 Agile Entwicklungsvorgehen

Mehr

Architektur iterativ auf Basis von OSGi entwickeln

Architektur iterativ auf Basis von OSGi entwickeln Architektur iterativ auf Basis von OSGi entwickeln Ein Vortrag von Sven Jeppsson (syngenio AG) und Karsten Panier (Signal Iduna Gruppe) 1 Inhalt Motivation Architektur Architektur Evolution OSGi Refactoring

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen * Grid Computing Einführung Marc Lechtenfeld Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen Übersicht 1 Problematik 2 Systemanforderungen 3 Architektur 4 Implementation 5 Projekte

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Das Rollenmuster. Rollenmuster

Das Rollenmuster. Rollenmuster Rollenmuster Zweck Modelliere die verschiedenen Blickwinkel eines fachlichen Gegenstands in eigenen Objekten, den sog. Rollenobjekten. Diese Rollenobjekte können dynamisch zu Kernobjekten hinzugefügt und

Mehr

Seminararbeit Ruby Uno Kartenspiel

Seminararbeit Ruby Uno Kartenspiel Seminararbeit Ruby Uno Kartenspiel Autor: Fabian Merki Fabian Merki 05.11.2006 1 von 10 Inhaltsverzeichnis Einleitung... 3 Die Idee... 4 Design und Implementierung in Ruby... 5 Testing... 7 Startbefehle...

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Entwurfsmuster (Design Pattern) ETIS SS05

Entwurfsmuster (Design Pattern) ETIS SS05 Entwurfsmuster (Design Pattern) ETIS SS05 Gliederung Motivation Pattern allgemein Proxy-Pattern Zusammenfassung 2 Motivation I Wie gut sind eure Programme strukturiert? Wartbarkeit? - Verständlichkeit

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

Einführung in die Informatik: Programmierung und Software-Entwicklung, WS 11/12. Kapitel 7. Grafische Benutzeroberflächen

Einführung in die Informatik: Programmierung und Software-Entwicklung, WS 11/12. Kapitel 7. Grafische Benutzeroberflächen 1 Kapitel 7 Ziele 2 (Graphical User Interfaces) als Anwendungsbeispiel für die objektorientierte Programmierung kennenlernen Benutzung von Vererbung zur Erstellung individueller GUI-Klassen durch Erweiterung

Mehr

Usability, Workflow und Software- Architektur. Usability, Workflow und Software- Architektur

Usability, Workflow und Software- Architektur. Usability, Workflow und Software- Architektur Usability, Workflow und Software- Architektur Vortrag auf dem World Usability Day 2007 in Hamburg Prof. Dr. Jörg Raasch raasch@informatik.haw-hamburg.de www.informatik.haw-hamburg.de/raasch.html users.informatik.haw-hamburg.de/~use-lab/

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems Michael Gebhart (1), Jürgen Moßgraber (2), Thomas Usländer (2), Sebastian Abeck (1) (2) (1) Cooperation & Management, Karlsruher Institut

Mehr

Effizienzsteigerung durch Komplexitätsreduktion

Effizienzsteigerung durch Komplexitätsreduktion Effizienzsteigerung durch Komplexitätsreduktion Die Herausforderung Kosten schon kleine Änderungen in den Abläufen Ihres Unternehmens Unsummen? Haben Sie Schwierigkeiten, alle notwendigen Änderungen schnell

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

Mehr

Modellgetriebene Softwareentwicklung

Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung 30.10.2008 Dr. Georg Pietrek, itemis AG Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 2 Vorstellung IT-Dienstleister Software-Entwicklung

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 sverzeichnis Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im

Mehr

Das Lehren von objektorientierter Programmierung in Java mit

Das Lehren von objektorientierter Programmierung in Java mit Das Lehren von objektorientierter Programmierung in Java mit Dr. Axel Schmolitzky Arbeitsbereich Softwaretechnik Fachbereich Informatik Universität Hamburg Überblick Kurz zu meiner Person Objektorientierung

Mehr

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN)

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN) Geschäftsprozessmanagement: in»business Process Modelling Notation«(BPMN) Eugen Labun Fachhochschule Gießen-Friedberg Fachbereich MNI Institut für Softwarearchitektur Serviceorientierte Architekturen bei

Mehr

Software-Engineering und Optimierungsanwendungen in der Thermodynamik

Software-Engineering und Optimierungsanwendungen in der Thermodynamik Software-Engineering und Optimierungsanwendungen in der Thermodynamik Software-Engineering 4 Entwurfs-, Implementierungs- und Abnahmephase Prof. Dr. Rolf Dornberger OPTSWE_SWE: 4 Entwurfs-, Implementierungs-

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Gunter Grieser, Simon Spielmann, Guido Schuh, Boris Kötting, Ralf Leonhard AGENDA Das Projekt Unser

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Durchgängig IT-gestützt

Durchgängig IT-gestützt Beschaffung aktuell vom 03.09.2012 Seite: 026 Auflage: 18.100 (gedruckt) 10.253 (verkauft) 18.032 (verbreitet) Gattung: Zeitschrift Supplier Lifecycle Management Durchgängig IT-gestützt Obwohl die Identifizierung,

Mehr

Softwarewiederverwendung und Patterns

Softwarewiederverwendung und Patterns Begrifflichkeiten und Beschreibungssystematik Begriffe Literatur zu Patterns Übersicht über die behandelten Konzepte Beschreibungsschema 97 Begriffe Glossar Patterns (Muster) sind ein Mittel der Wiederverwendung

Mehr

Prozessautomatisierung Vom Geschäftsprozess zum IT-Prozess Benjamin Brunner SOA Architect OPITZ CONSULTING Bad Homburg GmbH

Prozessautomatisierung Vom Geschäftsprozess zum IT-Prozess Benjamin Brunner SOA Architect OPITZ CONSULTING Bad Homburg GmbH Prozessautomatisierung Vom Geschäftsprozess zum IT-Prozess Benjamin Brunner SOA Architect OPITZ CONSULTING Bad Homburg GmbH Agenda Warum Prozessautomatisierung? Prozessautomatisierung in einer SOA Von

Mehr

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE CO-MAT-TECH 2004 14-15 October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Einführung eines agilen Vorgehensmodells auf der Basis von Werkzeugen und eines Leitbildes

Einführung eines agilen Vorgehensmodells auf der Basis von Werkzeugen und eines Leitbildes Einführung eines agilen Vorgehensmodells auf der Basis von Werkzeugen und eines Leitbildes Andreas Romahn Leipzig, 28.09.2010 InMediasP GmbH Neuendorfstraße 18 a 16761 Hennigsdorf www.inmediasp.de gestalten

Mehr

IT-Organisation Superuser und Local Support

IT-Organisation Superuser und Local Support IT-Organisation Superuser und Local Support Inhalt VORWORT... 2 DEFINITION DER VORAUSSETZUNGEN... 3 ORGANISATION... 4 DEFINITION DES SUPERUSERS... 5 KOMPETENZABGRENZUNG... 6 AUFGABEN DES SUPERUSERS...

Mehr

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 CODESYS a trademark of 3S-Smart Software Solutions GmbH Agenda 1 Warum

Mehr

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests Automatisierte Akzeptanztests mit FIT Einleitung Dieses beschreibt, wie man Tests aus Anwender-/Kundensicht mit dem Open-Source-Werkzeug FIT beschreibt und durchführt. Das ist für Kunden, Anwender und

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008 Traceability-Modell als Erfolgsfaktor für Process Enactment Einführung Referent Paul-Roux Wentzel Unternehmen method park Software AG 2008 method park Software AG Slide 2 Leistungsportfolio Training &

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

DESIGN'PATTERN'2011. November. Abstract Factory & Factory Method BEARBEITET VON INHALT [1] Christoph Süsens

DESIGN'PATTERN'2011. November. Abstract Factory & Factory Method BEARBEITET VON INHALT [1] Christoph Süsens November DESIGN'PATTERN'2011 INHALT Intent Motivation Applicability Structure Consequences Implementation Sample Code [1] BEARBEITET VON Christoph Süsens Abstract Factory & Factory Method Inhaltsverzeichnis

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Christian Kurz SWT Projekt WS 07/08

Christian Kurz SWT Projekt WS 07/08 Christian Kurz SWT Projekt WS 07/08 1. Allgemeine Aspekte der generativen GUI- Entwicklung 2. Entwicklung mit Hilfe von GUI-Designern 3. Entwicklung mit Hilfe deklarativer GUI- Sprachen 4. Modellgetriebene

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Open Source IDE - eclipse ETIS SS04

Open Source IDE - eclipse ETIS SS04 Open Source IDE - eclipse ETIS SS04 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung 2 Motivation

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA Im Vortrag werden die Vor- und Nachteile von Geschäftsprozessen in der öffentlichen

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Individuelle Software für Ihr Unternehmen

Individuelle Software für Ihr Unternehmen Individuelle Software für Ihr Unternehmen Maßgeschneidert passt besser logisch, werden Sie sagen und an einen auf den Leib geschneiderten Anzug denken. Aber haben Sie sich schon einmal überlegt, wie gut

Mehr

Solution for Business Intelligence. MID Insight 2013

Solution for Business Intelligence. MID Insight 2013 Solution for Business Intelligence MID Insight 2013 A G E N D A 1. Solution für Business Intelligence (BI) 2. Die Gründe und Hintergründe 3. Die Methode 4. Vorteile MID GmbH 2013 2 Solution für Business

Mehr

Leichtgewichtige API-Verträge Ein Paradoxon?

Leichtgewichtige API-Verträge Ein Paradoxon? Leichtgewichtige API-Verträge Ein Paradoxon? Jan Christian Krause (AKRA GmbH) Gastbeitrag zur Vorlesung Semantische Sprachverarbeitung im SS 2012 Agenda 1) Motivation 2) Metaphern Vertrag, Stille und Rauschen

Mehr

Gute Modelle Wie bewerten Sie die Ergebnisse von Modellierungsprojekten?

Gute Modelle Wie bewerten Sie die Ergebnisse von Modellierungsprojekten? Gute Modelle Wie bewerten Sie die Ergebnisse von Modellierungsprojekten? Präsentation bei MID Insight 2012 Nürnberg, 20. November 2012 Dr. Jürgen Pitschke BCS Dr. Jürgen Pitschke www.enterprise-design.eu

Mehr

Umsetzung des OrViA-Frameworks mit ARIS

Umsetzung des OrViA-Frameworks mit ARIS Umsetzung des OrViA-Frameworks mit ARIS Sebastian Stein sebastian.stein@ids-scheer.com IDS Scheer AG PROJEKTTRÄGER Agenda Motivation Kurzüberblick SOA Strukturierte Anforderungsanalyse mit ARIS Validierung

Mehr

Semester: -- Workload: 300 h ECTS Punkte: 10

Semester: -- Workload: 300 h ECTS Punkte: 10 Modulbezeichnung: Modulnummer: BWIT IT Management Semester: -- Dauer: Minimaldauer 1 Semester Modultyp: Wahlpflicht Regulär angeboten im: WS, SS Workload: 300 h ECTS Punkte: 10 Zugangsvoraussetzungen:

Mehr

www.triton.at White Paper Testfallgewinnung mit dem Portfolio-Manager Gewinnung effizienter Testfälle und -daten

www.triton.at White Paper Testfallgewinnung mit dem Portfolio-Manager Gewinnung effizienter Testfälle und -daten www.triton.at White Paper Testfallgewinnung mit dem Portfolio-Manager Gewinnung effizienter Testfälle und -daten Inhaltsverzeichnis Testfall-Gewinnung bei Triton... 3 Ebenen der Testfall-Definition...

Mehr

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

tfacet: Hierarchisch-facettierte Exploration semantischer Daten mit Hilfe bekannter Interaktionskonzepte

tfacet: Hierarchisch-facettierte Exploration semantischer Daten mit Hilfe bekannter Interaktionskonzepte IVDW-Workshop 2011, Berlin (6. Oktober) Institut für Visualisierung und Interaktive Systeme tfacet: Hierarchisch-facettierte Exploration semantischer Daten mit Hilfe bekannter Interaktionskonzepte Philipp

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

Teil VII. Software Engineering

Teil VII. Software Engineering Teil VII Software Engineering Überblick 1 Einführung 2 Der Softwareentwicklungsprozess 3 Methoden und Werkzeuge Eike Schallehn Grundlagen der Informatik für Ingenieure 2008/2009 7 1 Einführung Die Softwarekrise

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

Mehr

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

LEGO-Mindstorms-Roboter im Informatikunterricht 1 - mit Java-

LEGO-Mindstorms-Roboter im Informatikunterricht 1 - mit Java- Eckart Modrow LEGO-Mindstorms-Roboter S. 1 LEGO-Mindstorms-Roboter im Informatikunterricht 1 - mit Java- Benutzung in einer Programmierumgebung Für die LEGO-Roboter stehen unter allen gängigen Betriebssystemen

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr