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

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

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

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

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

Ü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

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

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

Erfolg ist programmierbar.

Erfolg ist programmierbar. 4578954569774981234656895856512457895456977498 3465689585651245789545697749812346568958561245 9545697749812346568958565124578954569774981234 6895856512457895456977498123465689585612457895 6977498123465689585651245789545697749812346568

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

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

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

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

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

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

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ü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

Ü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

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

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

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

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

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

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

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

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

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

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

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

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

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

UML (Unified Modelling Language) von Christian Bartl

UML (Unified Modelling Language) von Christian Bartl UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...

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

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

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

Lehrstuhl für Datenverarbeitung. Technische Universität München. Grundkurs C++ Objektmodellierung. Grundkurs C++

Lehrstuhl für Datenverarbeitung. Technische Universität München. Grundkurs C++ Objektmodellierung. Grundkurs C++ Grundkurs C++ Objektmodellierung Grundkurs C++ Objektmodellierung welche Objekte bzw. Klassen werden benötigt? welche Information wird benötigt, um ein Objekt zu beschreiben? welche Beziehungen bestehen

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

17 Architekturentwurf Vorgehen und Dokumentation

17 Architekturentwurf Vorgehen und Dokumentation 17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen

Mehr

Projekttitel: Auktionsplattform Projekthomepage: buecher.auf-knopfdruck.com

Projekttitel: Auktionsplattform Projekthomepage: buecher.auf-knopfdruck.com Software Engineering Labor-Übung, LVNr: 050052/2 Übungsleiter: Martin Köhler Dokument: Anforderungsanalyse und Use Case Modell I v.1.2 Projekttitel: Auktionsplattform Projekthomepage: buecher.auf-knopfdruck.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

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

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

Übungsaufgaben zum Software Engineering: Management

Übungsaufgaben zum Software Engineering: Management Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie

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

CIB DOXIMA PRODUKTINFORMATION

CIB DOXIMA PRODUKTINFORMATION > CIB Marketing CIB DOXIMA PRODUKTINFORMATION Dokumentenmanagement & Dokumentenarchivierung > Stand: Januar 2013 INHALT 1 CIB DOXIMA 2 1.1 The next generation DMS 3 1.2 Dokumente erfassen Abläufe optimieren

Mehr

Systematisches Testen der Funktionalität von Softwaresystemen. 17. Juni 2015

Systematisches Testen der Funktionalität von Softwaresystemen. 17. Juni 2015 Systematisches Testen der Funktionalität von Softwaresystemen 17. Juni 2015 Überblick Semantische Qualität von Software Teststrategien und prinzipien Testgetriebene Softwareentwicklung Welche Arten von

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

Model Sketching - Ultraleichte Modellierung. Methodenkarten

Model Sketching - Ultraleichte Modellierung. Methodenkarten Model Sketching - Ultraleichte Modellierung Methodenkarten 1 Modell-Sketching auf einen Blick 1 Konzentration Rolle: Kunde Fokus: Auftrag - Zieldefinition Elemente: Kundenziele, Kundenanforderungen Phasenergebnis:

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

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

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse

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

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

Konzept und Realisierung eines Zustandsmaschinen-Editors für Interaktionen medizinischer Bildverarbeitung mit Debug-Funktionalität

Konzept und Realisierung eines Zustandsmaschinen-Editors für Interaktionen medizinischer Bildverarbeitung mit Debug-Funktionalität Konzept und Realisierung eines Zustandsmaschinen-Editors für Interaktionen medizinischer Bildverarbeitung mit Debug-Funktionalität Daniel Stein, Marcus Vetter, Ivo Wolf, Hans-Peter Meinzer Abteilung für

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

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

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

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

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

Dokumentation, Analyse, Optimierung,

Dokumentation, Analyse, Optimierung, Dokumentation, Analyse, Optimierung, Automatisierung als gemeinsame Sprache für Business, Architektur und Entwicklung DOAG SIG BPM, Folie 1 Vortragende Software Engineer Dr. Projektleiter Folie 2 Zühlke:

Mehr

SEA. Modellgetriebene Softwareentwicklung in der BA

SEA. Modellgetriebene Softwareentwicklung in der BA SEA Modellgetriebene Softwareentwicklung in der BA MDA bei der BA Ziele/Vorteile: für die Fachabteilung für die Systementwicklung für den Betrieb Wie wird MDA in der BA umgesetzt? Seite 2 MDA bei der BA

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

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

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

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

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

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

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

4 Architektur-Perspektiven (WO)

4 Architektur-Perspektiven (WO) 4 Architektur-Perspektiven (WO) Abb. 4-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WO-Dimension des architektonischen Ordnungsrahmens. Es erläutert, auf welchen

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

Einführungsstrategien komplexer IT-Lösungen

Einführungsstrategien komplexer IT-Lösungen Innovative Systemlösungen Stand: 11/2009 Ausgangsituation Die Umwelt wird immer schnelllebiger, dadurch kommt es immer öfter zu Änderungen der Anforderungen an eine Software. Die Frage ist nicht, wie man

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

CARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH

CARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH CARM-Server Version 4.65 Users Guide APIS Informationstechnologien GmbH Einleitung... 1 Zugriff mit APIS IQ-Software... 1 Zugang konfigurieren... 1 Das CARM-Server-Menü... 1 Administration... 1 Remote-Konfiguration...

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

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

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

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Was versteht man unter Softwarequalität?

Was versteht man unter Softwarequalität? Was versteht man unter? ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareproduktes, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Was ist

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

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

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr