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

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Übungen Softwaretechnik I

Übungen Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 2: Vorgehensmodelle IAS-Vorgehensmodell Motivation Probleme Die

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

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

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

Mehr

EINFÜHRUNG 06.06.2013 IOZ AG 1

EINFÜHRUNG 06.06.2013 IOZ AG 1 BPMN BPMN2.0 EINFÜHRUNG 06.06.2013 IOZ AG 1 EINFÜHRUNG GESCHÄFTSPROZESSMODELLIERUNG Was ist Geschäftsprozessmodellierung? Darstellung von geschäftlichen Abläufen und deren Interaktion Was wird inhaltlich

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

Vorlesung Programmieren

Vorlesung Programmieren 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

Flexibilität im Prozess mit Oracle Business Rules 11g

Flexibilität im Prozess mit Oracle Business Rules 11g Flexibilität im Prozess mit Oracle Business Rules 11g Michael Stapf ORACLE Deutschland GmbH Frankfurt Schlüsselworte: Geschäftsregeln, Business Rules, Rules Engine, BPEL Process Manager, SOA Suite 11g,

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

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

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Software Engineering und Projektmanagement

Software Engineering und Projektmanagement Software Engineering und Projektmanagement Motivation! Fachliche Sicht trifft auf technische Realisierung Entwurf 2009W - 5. November 2009 Andreas Mauczka Email: andreas.mauczka@inso.tuwien.ac.at Web:

Mehr

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

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

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

Ü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

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

JAVA PROJEKT. Schiffe Versenken mit GUI. Projektheft

JAVA PROJEKT. Schiffe Versenken mit GUI. Projektheft Anwendungspraktikum aus JAVA Programmierung SS 2006 Leitung: Dr. Albert Weichselbraun JAVA PROJEKT Schiffe Versenken mit GUI Projektheft Marija Matejic Matrikelnummer: 9352571 E-mail: marijamatejic@yahoo.com

Mehr

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

Mehr

Best Practice. Prozessmodellierung für behördenübergreifende. pm-bpmn 1.0.0. Bundesverwaltung: Ergebnis der AG BEST PRACTICE BPMN.

Best Practice. Prozessmodellierung für behördenübergreifende. pm-bpmn 1.0.0. Bundesverwaltung: Ergebnis der AG BEST PRACTICE BPMN. Prozessmodellierung für behördenübergreifende Verfahren der mittelbaren Bundesverwaltung: BEST PRACTICE BPMN Best Practice pm-bpmn 1.0.0 Ergebnis der AG Kurzbeschreibung In diesem Dokument werden die Best-Practice-

Mehr

Kapitel 5: Das Design

Kapitel 5: Das Design Nach der Analyse kommt... Kapitel 5: Das Design SoPra 2008 Kap. 5: Das Design (1/20) Kapitel 5.1: Überblick Was ist Design? Ergebnis der Analyse: abstrakte Definitionen Objektmodell: Klassen, Assoziationen,

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

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

Benutzeroberflächen. Java Teil 4

Benutzeroberflächen. Java Teil 4 Benutzeroberflächen Java Teil 4 Einleitung Eine grafische Benutzeroberfläche (Graphical User Interface) ermöglicht dem Benutzer die Interaktion mit dem Computer über grafische Symbole. Die GUI haben in

Mehr

Architekturleitfaden. Definieren Sie fachliche Komponenten und implementieren Sie Ihre Aufgaben in technischen Schichten

Architekturleitfaden. Definieren Sie fachliche Komponenten und implementieren Sie Ihre Aufgaben in technischen Schichten Architekturleitfaden Definieren Sie fachliche und implementieren Sie Ihre Aufgaben in technischen Schichten Illustration: Designed by Freepik.com Zwei Architektursichten prägen den Bau von Software-Systemen

Mehr

Erfolg ist programmierbar.

Erfolg ist programmierbar. 4578954569774981234656895856512457895456977498 3465689585651245789545697749812346568958561245 9545697749812346568958565124578954569774981234 6895856512457895456977498123465689585612457895 6977498123465689585651245789545697749812346568

Mehr

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs Java TV Seminar Medientechnik 23.06.2003 Übersicht Einleitung Umgebungen Java TV API - Kategorien Service- und Selektions-APIs Definitionen Packages Service Selection API Application Lifecycle APIs (Xlets)

Mehr

Sind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar?

Sind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar? Sind Prozessmanagement-Systeme auch eingebettete Systeme einsetzbar? 12. Symposium Maritime Elektrotechnik, Elektronik und Informationstechnik, 8.-12. Oktober 2007 Rostock, Deutschland Rostock, Deutschland

Mehr

R&I-Fließbilder in PLANEDS

R&I-Fließbilder in PLANEDS in PLANEDS Planetenfeldstr. 97 D - 44379 Dortmund Fon: +49 (0) 231 555 783 0 Fax: +49 (0) 231 555 783 111 Mail: info@planets-software.de Web: www.planets-software.de Inhalt: 1 Motivation...3 2 Symbolbearbeitung...4

Mehr

Geschäftsprozesse modellieren mit BPMN. Nürnberg, 10.11.2009

Geschäftsprozesse modellieren mit BPMN. Nürnberg, 10.11.2009 Geschäftsprozesse modellieren mit BPMN Nürnberg, 10.11.2009 I N H A L T 1. Warum noch ein Notation? 2. Grundlegende BPMN-Elemente 3. Prozess versus Interaktion 4. Services 5. Fazit Warum noch eine Notation?

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

Grafische Benutzeroberfläche mit Glade und Python

Grafische Benutzeroberfläche mit Glade und Python Grafische Benutzeroberfläche mit Glade und Python Grundsätzliches Die grafische Benutzeroberfläche (GUI) wird getrennt von dem Programm erstellt und gespeichert. Zu dieser GUI-Datei wird ein passendes

Mehr

Übung 6: Feinentwurf. Prof. Dr. Dr. h.c. Manfred Broy Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter

Übung 6: Feinentwurf. Prof. Dr. Dr. h.c. Manfred Broy Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter Prof. Dr. Dr. h.c. Manfred Broy Sommersemester Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter Einführung in die Softwaretechnik Übung 6: Feinentwurf Aufgabe 17: Entwurfsmuster

Mehr

Model View Controller Pattern

Model View Controller Pattern Christian Vogt HAW Hamburg 19. Dezember 2011 Inhaltsverzeichnis 1 Prolog Einleitung Entwurfsmuster andere Muster 2 Model-View-Controller Hintergrund Konzept Umsetzung 3 Beispiele Überblick Beispiel in

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

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

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

Semtation GmbH SemTalk

Semtation GmbH SemTalk Semtation GmbH SemTalk Christian Fillies Was ist SemTalk? Prozessmodellierung mit Visio2003 Viele Methoden (EPK, PROMET, FlowChart, KSA ), einfach an Kundenbedürfnisse anzupassen und zu erweitern HTML

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Mufid Sulaiman mufidsulaiman@web.de

Mufid Sulaiman mufidsulaiman@web.de Mufid Sulaiman mufidsulaiman@web.de Überblick Frameworks Applikationsentwicklung mit Frameworks Komponentenbasierte Frameworks Einführung in Enterprise JavaBean Einführung in SanFrancisco Vergleich Enterprise

Mehr

Softwaretechnik. Fomuso Ekellem

Softwaretechnik. Fomuso Ekellem WS 2011/12 Inhalt Entwurfsphase Systementwurf Software Architektur Entwurf Software Komponenten Entwurf Struktur Verhalten OO Entwurf (OOD) 2 Entwurfsphase 3 Entwurfsphase Lernziele Aufgaben der Entwurfsphase

Mehr

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des

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

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

Abschnitt 16: Objektorientiertes Design

Abschnitt 16: Objektorientiertes Design Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen

Mehr

24 Transformation der Anforderungsspezifikation

24 Transformation der Anforderungsspezifikation 271 24 Transformation der Anforderungsspezifikation 24.1 Einleitung Bei der Softwarespezifizierung wird die Anforderungsspezifikation überarbeitet, weiter strukturiert und präzisiert, um eine Basis für

Mehr

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 18. Dezember 2014 Rekapitulation Der Gang der Argumentation 1. Der Rohstoff:

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

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

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

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

Softwarearchitekturen I Softwareentwicklung mit Komponenten

Softwarearchitekturen I Softwareentwicklung mit Komponenten Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem

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

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

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

Anwendungsfall- Modellierung

Anwendungsfall- Modellierung Anwendungsfall- Modellierung SE1-3-AF-Modellierung 1 Erinnern Sie sich??? SE1-3-AF-Modellierung 2 Der OEP SE1-3-AF-Modellierung 3 Bestandsaufnahme

Mehr

Architektur und Qualität. Tjard Köbberling

Architektur und Qualität. Tjard Köbberling Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur

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

Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen. OOP München, 26.01.2011

Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen. OOP München, 26.01.2011 Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen OOP München, 26.01.2011 I N H A L T 1. SOA das erste Projekt 2. Prozesse Ergebnisse aus dem Fachbereich 3. Der Business Analyst und BPMN

Mehr

Aspektorientierte Programmierung (aspect-oriented programming, AOP)

Aspektorientierte Programmierung (aspect-oriented programming, AOP) Aspektorientierte Programmierung (aspect-oriented programming, AOP) Abstract Die aspektorientierte Programmierung ist ein neues Programmierparadigma, das die Probleme und Nachteile, die aus der prozeduralen

Mehr

Drucken, GUI, Design Pattern,... PDF, Usability, Observer Pattern, MVC

Drucken, GUI, Design Pattern,... PDF, Usability, Observer Pattern, MVC Drucken, GUI, Design Pattern,... PDF, Usability, Observer Pattern, MVC Progwerkstatt Philipp Güttler, Christoph Schied, Nicolai Waniek 01.12.2008 Seite 2 Drucken Drucken ist eigentlich ganz einfach...

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

ACCESS das Datenbankprogramm. (Aufbau) DI (FH) Levent Öztürk

ACCESS das Datenbankprogramm. (Aufbau) DI (FH) Levent Öztürk ACCESS das Datenbankprogramm Vom Microsoft (Aufbau) DI (FH) Levent Öztürk Inhalt Projektentwicklung Planung einer Datenbank Implementierung einer Datenbank Testen der Datenbank Formulare Berichte SQL-Abfragen

Mehr

Mit unserer Webshop-Schnittstelle können Sie Ihre Webshop-Bestellungen direkt in orgamax einlesen und weiter verarbeiten.

Mit unserer Webshop-Schnittstelle können Sie Ihre Webshop-Bestellungen direkt in orgamax einlesen und weiter verarbeiten. 1. Einführung Mit unserer Webshop-Schnittstelle können Sie Ihre Webshop-Bestellungen direkt in orgamax einlesen und weiter verarbeiten. orgamax stellt Ihnen eine interaktive Kommunikations-Schnittstelle

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

Error-Hospital für Oracle SOA Suite

Error-Hospital für Oracle SOA Suite Error-Hospital für Oracle SOA Suite Markus Lohn esentri AG Ettlingen Schlüsselworte Fusion Middleware, SOA, SOA Suite Einleitung Die Entwicklung von Services mit der SOA Suite erfolgt überwiegend deklarativ

Mehr

Grundlagen der Programm- und Systementwicklung

Grundlagen der Programm- und Systementwicklung Grundlagen der Programm- und Systementwicklung Technische Universität München Institut für Informatik Software & Systems Engineering Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. Maria Spichkova

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

INDIVIDUELLE SOFTWARELÖSUNGEN CUSTOMSOFT CS GMBH

INDIVIDUELLE SOFTWARELÖSUNGEN CUSTOMSOFT CS GMBH 01 INDIVIDUELLE SOFTWARELÖSUNGEN 02 05 02 GUMMERSBACH MEHRWERT DURCH KOMPETENZ ERIC BARTELS Softwarearchitekt/ Anwendungsentwickler M_+49 (0) 173-30 54 146 F _+49 (0) 22 61-96 96 91 E _eric.bartels@customsoft.de

Mehr

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress BPM im Kontext von Unternehmensarchitekturen Konstantin Gress Agenda 1 Worum geht s BPM, EA und SOA im Überblick 2 Link zwischen EA und BPM 3 Link zwischen SOA und BPM 4 Wie spielt das zusammen? 5 Q&A

Mehr

Vorlesung Software-Engineering I

Vorlesung Software-Engineering I Vorlesung Software-Engineering I im 3. und 4. Semester 05. Basiskonzepte Sichten auf das Produkt PD-TES/Hoyer, Frank-Michael SWE1: 05. Basiskonzepte - Sichten 16. Juli 2010 geändert: 4. Oktober 2013 SW-Architektur

Mehr

Bekannte Lösungen für bekannte Probleme benutzen. Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen

Bekannte Lösungen für bekannte Probleme benutzen. Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen Michael Saecker Bekannte Lösungen für bekannte Probleme benutzen Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen Gemeinsames Vokabular für Designer 2 http://www.clickpix.de/sommer/architektur.jpg

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

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

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

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Modellierungstechniken im Softwaredesign Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Was ist Modellierung? Modell = Ein Modell ist eine Repräsentation eines Systems von Objekten,

Mehr

Konzeption und Entwicklung eines sicheren Cloudbasierten Internetbanking-Systems mit

Konzeption und Entwicklung eines sicheren Cloudbasierten Internetbanking-Systems mit Konzeption und Entwicklung eines sicheren Cloudbasierten Internetbanking-Systems mit anschließender Sicherheitsanalyse auf Basis von Business Process Mining im SoSe 2011 & Prof. Jan Jürjens, Dr. Holger

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

Vgl. Oestereich Kap 2.7 Seiten 134-147

Vgl. Oestereich Kap 2.7 Seiten 134-147 Vgl. Oestereich Kap 2.7 Seiten 134-147 1 Sequenzdiagramme beschreiben die Kommunikation/Interaktion zwischen den Objekten (bzw. verschiedenen Rollen) eines Szenarios. Es wird beschrieben, welche Objekte

Mehr

Software - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 1) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Besonderheiten und Eigenschaften von Software; Interne und Externe Eigenschaften 1 Aufgabe 1.1 Software

Mehr

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit EMF ist ein eigenständiges Eclipse-Projekt (Eclipse Modeling Framework Project) EMF ist ein Modellierungsframework und Tool

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

Modellbasierte Softwareentwicklung mit EMF

Modellbasierte Softwareentwicklung mit EMF Softwaretechnik I, WS 2009/10 Modellbasierte Softwareentwicklung mit EMF Übungsblatt 5 13. November 2009 Organisatorisches Zur Bearbeitung der Übungsaufgabe stehen Ihnen die folgenden 3 Wochen (Kalenderwochen

Mehr

ImplementIerung von ClICKAnDBuY

ImplementIerung von ClICKAnDBuY Implementierung von CLICKANDBUY Inhaltsverzeichnis 1 2 3 4 5 6 7 Einführung: ClickandBuy Premiumlinks... 2 ClickandBuy URL Mapping... 3 Premiumlink Implementierungsoptionen... 4 3.1. Sessionlink... 4 3.2.

Mehr

Einführung. Informationssystem als Abbild der realen Welt

Einführung. Informationssystem als Abbild der realen Welt Was ist ein Datenbanksystem? Anwendungsgrundsätze Betrieb von Datenbanksystemen Entwicklung von Datenbanksystemen Seite 1 Informationssystem als Abbild der realen Welt Modellierung (Abstraktion) Sachverhalte

Mehr

Lösungsvorschlag zu Übungsblatt 1 mit Korrekturhinweisen

Lösungsvorschlag zu Übungsblatt 1 mit Korrekturhinweisen Universität Karlsruhe (TH) Fakultät für Informatik Lehrveranstaltung Informatik II Sommersemester 2008 Prof. Dr. K. Böhm Dipl.-Wirtsch.-Inf. C. Kühne Lösungsvorschlag zu Übungsblatt 1 mit Korrekturhinweisen

Mehr

Ereignisbehandlung 21

Ereignisbehandlung 21 Ereignisbehandlung 21 3 Ereignisbehandlung Dieses Kapitel beschäftigt sich mit der Ereignisbehandlung, d.h. der Reaktion eines Programms auf Eingaben durch benutzende Personen. Nach einigen ersten Beispielen

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

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

BIF/SWE - Übungsbeispiel

BIF/SWE - Übungsbeispiel BIF/SWE - Übungsbeispiel Arthur Zaczek Feb 2015 1 Allgemein 1.1 Ziele Ziele dieses Übungsbeispieles ist es: GUI: Implementierung einer grafischen Oberfläche mit JavaFX oder WPF UI-Komponente: Implementierung

Mehr

Business Continuity Management (BCM) als Managementaufgabe Ein prozessorientierter Ansatz für den IT-Sicherheitsprozess

Business Continuity Management (BCM) als Managementaufgabe Ein prozessorientierter Ansatz für den IT-Sicherheitsprozess Business Continuity Management (BCM) als Managementaufgabe Ein prozessorientierter Ansatz für den IT-Sicherheitsprozess, Projektmanager und Sales Consultant, EMPRISE Process Management GmbH Das Gesetz

Mehr