Die Bedeutung expliziter Modellierung für die Entwicklung komplexer und langlebiger Software-Systeme

Größe: px
Ab Seite anzeigen:

Download "Die Bedeutung expliziter Modellierung für die Entwicklung komplexer und langlebiger Software-Systeme"

Transkript

1 Die Bedeutung expliziter Modellierung für die Entwicklung komplexer und langlebiger Software-Systeme Markus Pizka, Tilman Seifert TU München Marcus Peisker BMW Group Die Entwicklung von Software stellt immer eine Form von Modellierung dar: Ein Ausschnitt der realen Welt wird herausgegriffen und mit Hilfe einer formalen Beschreibungssprache, spätestens mit einer Programmiersprache, beschrieben. Der Nutzen expliziter Modellierung mit Hilfe textueller oder grafischer Modellierungssprachen ist erstaunlicherweise umstritten. Dieses Papier zeigt, warum sich der explizite Einsatz von Modellierungsmethoden für die Software-Entwicklung lohnt. 1 Einleitung Ein Modell ist eine Abstraktion eines bestimmten Ausschnittes der realen Welt oder eines anderen Modells. Es beschreibt einen bestimmten Aspekt dieses Ausschnitts präzise und abstrahiert dabei von anderen Aspekten, die zur Analyse im Moment nicht von Bedeutung sind. Software-Entwicklung ist immer Modellierung: Ein Ausschnitt unserer realen Umgebung wird in ein Software-System abgebildet und mit formalen Sprachen, d. h. Programmiersprachen, beschrieben. Ein Software-System ist nichts anderes als ein Modell der Begriffe, Objekte oder Vorgänge, für deren Verwaltung bzw. Unterstützung es entwickelt wurde. Ein einfaches Beispiel stellt die Kundenverwaltung in einem betrieblichen Informationssystem dar: Der Kunde wird modelliert, indem alle für das Unternehmen relevanten Daten des Kunden im System verarbeitet werden. Die Beziehung des Unternehmens zum Kunden wird in Form der bisher erteilten Aufträge oder eines Protokolls der bisherigen Kontakte modelliert. Im Entwicklungsprozess werden in jeder Phase, von der Anforderungsanalyse über die Implementierungsphase bis zum Testen, auf jeden Fall Modelle erstellt entweder explizit in Form von textuell oder grafisch beschriebenen Modellen, oder auch nur implizit in Form von Freitext oder auch einfach in den Köpfen der Entwickler. Im Falle von impliziten Modellen mag das unbewusst sein, dennoch entstehen Modelle, die für die Entwicklung verwendet werden. Bei der Entwicklung von großen, komplexen oder langlebigen Systemen stellt sich daher nicht die Frage, ob überhaupt modelliert werden muss, sondern nur die Frage, in welcher Form und zu welcher Zeit im Projekt welche Aspekte explizit modelliert werden, also als Modell notiert werden. Kapitel 2 klärt, was in diesem Papier genau unter Modellierung verstanden wird, was die Ziele sind und welche Eigenschaften Modelle erfüllen müssen. Kapitel 3 zeigt die Integration expliziter Modellierung in den Entwicklungsprozess und stellt die gängigsten Modellierungstechniken vor. Kapitel 4 zeigt eine Reihe von Charakteristika auf, die für viele Projekte gelten und analysiert den Bedarf an expliziter Modellierung für derartige Projekte. 2 Was ist Modellierung? Modellierung bedeutet, sich ein Bild zu machen von der Realität oder eine kondensierte Sicht auf ein abstraktes Gebilde zu schaffen. Um bestimmte Aspekte besser verstehen und erklären zu können, muss von anderen Aspekten abstrahiert werden. Modellierung bedeutet die Verein-

2 fachung von komplexen Zusammenhängen bzw. Abstraktion und dient der Konzentration auf bestimmte Eigenschaften, um diese präzise analysieren und beschreiben zu können. Bei der Zusammenarbeit von n Experten, die über ein komplexes Software-System aus m unterschiedlichen Perspektiven sprechen, sind gute Modelle unerlässlich. 2.1 Zentrale Ziele der Modellierung Die Ziele der expliziten Modellierung lassen sich wie folgt zusammenfassen: 1. Verständnis der fachlichen Anforderungen, der technischen Umgebung und der Randbedingungen der zu erstellenden Lösung schaffen oder erleichtern. Je komplexer das zu entwickelnde System ist, umso wichtiger wird die Modellierung einzelner Aspekte. 2. Kommunikation mit und Verständnis für andere durch einfache, präzise Dokumentation, die zu jedem Zeitpunkt auf dem aktuellsten Stand ist. Insbesondere für langlebige Systeme ist entscheidend, wie gut das System auch im Falle von Mitarbeiter-Fluktuation verstanden, gewartet und weiterentwickelt werden kann. 3. Automatisierung im Entwicklungsprozess, z. B. konsistente Generierung von Code, Tests und Dokumentation aus einem Modell oder automatische Konsistenz- oder Korrektheitsprüfungen. Bei großen Systemen kann mit Hilfe von Automatisierung nicht nur Mehrarbeit gespart, sondern gleichzeitig eine ganze Klasse von Fehlern ausgeschlossen werden. Um dies zu gewährleisten, ist ein hohes Maß an Präzision erforderlich; das begründet auch den Formalisierungsgrad von Syntax und Semantik von Modellen. Die Ziele sind also sowohl in der Effizienz der Entwicklung als auch in der Qualität der Software begründet. 2.2 Forderungen an Modelle Die genannten Ziele sind nur erreichbar, wenn für die Verwendung von Modellen ein gemeinsames Modellverständnis vorliegt. Daher wird von Modellen eine eindeutige Notation verlangt, die als (semi-) formale Sprache definiert ist. Dies kann eine textuelle oder eine grafische Notation sein. So wird eine eindeutige Syntax zur Darstellung definiert. Zusätzlich ist die Definition der Semantik erforderlich, damit das Modell sowohl zur Kommunikation als auch zur Automatisierung genutzt werden kann. Weiterhin fordern wir von einem Modell, dass es sich auf einen sinnvoll abgegrenzten Aspekt des Systems bezieht, um das Verständnis dieses speziellen Aspektes zu erleichtern. Modelle sollen genau den entscheidenden Aspekt isoliert beschreiben können. Dies umfasst sowohl horizontal verschiedene Sichten, also Modelle unterschiedlicher Aspekte des Systems, als auch vertikal verschiedene Sichten, also unterschiedliche Abstraktionsstufen des Systems. Ersteres ist erforderlich zur vollständigen Modellierung des Systems, letzteres zur schrittweisen Verfeinerung. Explizite Modelle sind nur dann sinnvoll, wenn dem (Zusatz-) Aufwand, der durch ihre Erstellung entsteht, ein entsprechender Nutzen gegenübersteht. Die hier genannten Forderungen zielen auf einen solchen Nutzen ab: So ist z. B. die verbesserte, eindeutige Kommunikation von Systemeigenschaften ein direkter Nutzen, denn früh erkannte Missverständnisse können einfach ausgeräumt werden später im Projektverlauf wird es deutlich teurer, wie Abbildung 1 zeigt (vgl. z. B. [5]). Dazu muss die Modellierung in den gesamten Prozess der Entwicklung und Betreuung integriert sein; diese Fragestellung wird im Abschnitt 3 untersucht. 2

3 Abbildung 1: Kosten je Fehler, abhängig vom Zeitpunkt der Entdeckung (aus [5, S. 114]) 2.3 Modelltypen Es existieren unterschiedliche Modellierungstechniken, um unterschiedliche Aspekte besonders herauszuarbeiten. Sie können etwa in die folgenden Gruppen eingeteilt werden. Darstellung statischer Strukturen: Architektur, Klassendiagramme, ER-Diagramme Darstellung von Abläufen. Hier dienen z. B. Petri-Netze, Agenten, Sequenz-Diagramme oder Use Case-Diagramme. Abbildung der Kommunikationsstruktur zwischen Sub-Systemen Weitere Aspekte, wie z. B. Darstellung von Sicherheits- oder Performance-Eigenschaften: Solche zusätzlichen, nichtfunktionalen Anforderungen können prinzipiell auf zwei Wegen gelöst werden: Durch Ergänzungen zu vorhandenen Modellierungstechniken, oder durch neue Modelltypen, die genau diesen speziellen Aspekt modellieren. Beispielsweise kann die Sicherheit (security) einer Kommunikationsverbindung zwischen zwei Systemen durch zusätzliche Angaben zur Angreifbarkeit der Verbindung modelliert werden. In der Regel werden Modelle jeder Gruppe benötigt, um ein System umfassend zu beschreiben. Dies ist die horizontale Unterscheidung verschiedener Modelle. Man unterscheidet weiterhin zwischen formalen und semi-formalen Modellierungsmethoden. Für ein formales Modell sind sowohl Syntax als auch Semantik exakt definiert; im Gegensatz dazu besitzt die Semantik eines semi-formalen Modells noch gewisse Freiheitsgrade. Daher sind semi-formale Modellierungstechniken in der Regel leichter zu entwickeln. Mathematisch formale Modelle besitzen allerdings den Vorteil, dass ihre Semantik klar ist und sie so ein eindeutiges Verständnis ohne Interpretationsspielraum ermöglichen. Zudem können sie dann auch automatisch verarbeitet werden, z. B. zur Vollständigkeits- oder Konsistenzprüfung. 3

4 Der Nutzen eines Modells in der jeweiligen Situation hängt von der Lesbarkeit eines Modells ab. Die Lesbarkeit ist unabhängig vom Grad der Formalisierung. Die Aussagekraft eines Modells hängt vor allem von der Angemessenheit der Modellierungstechnik im jeweiligen Zusammenhang ab, eventuell auch noch vom Geschick oder der Übung des Modellierers. Entscheidend ist, wie präzise ein Modell die betrachteten Aspekte beschreiben kann. Modelle können textuell oder grafisch notiert werden. Große Bedeutung haben vor allem Modelle mit grafischen Notationen, die den Vorteil besitzen, dass sie die große Bandbreite des visuellen Kanals beim Menschen und seine Fähigkeit zur assoziativen Mustererkennung ausnutzen und einen wahlfreien Zugriff gestatten. (vgl. [3] und [6]). Jedoch können grafisch notierte Modelle den Text nicht vollständig ersetzen. Für das Verständnis eines grafischen Modells ist oft noch zusätzlicher, erläuternder Text notwendig. 2.4 Bewertung von Modellierungstechniken Modellierungstechniken werden anhand folgender Kriterien bewertet: 1. Bewusste Durchführung der Modellierung: Da Modellierung in jedem Fall stattfindet, sollten Modelle bewusst entwickelt werden und die Modellierung als fester Bestandteil in den Entwicklungsprozesses integriert werden. 2. Explizite Formulierung: Explizit notierte Modelle können in Reviews beurteilt und in Folgephasen und/oder zur Dokumentation herangezogen werden. 3. Präzisionsgrad des Modells: Je nach Modellierungstechnik kann ein gewisser Interpretationsspielraum existieren. Im Umgang mit komplexen Systemen sollte dieser jedoch möglichst gering sein. Ein präzises, mathematisch formales Modell kann zudem in Folgephasen leichter weiterverwendet werden. 4. Angemessenheit der Modellierungstechnik: Für die Auswahl der geeigneten Modellierungstechnik sind der genaue Einsatzzweck und der erwartete Nutzen zu berücksichtigen. Werden die Modelle zur Kommunikation mit dem Kunden eingesetzt, sind unter Umständen andere Prioritäten zu setzen als für Modelle, die ausschließlich im Entwicklerteam bearbeitet werden. 3 Modellierung in Entwicklung und Wartung Ein guter Entwicklungsprozess unterstützt die Transparenz jedes Projektes, fördert die Kommunikation zwischen allen Projektbeteiligten und führt zu einem geplanten Vorgehen. Siehe dazu auch [10]. Aktivitäten der Modellierung müssen in den Prozess integriert sein, und die Ergebnisse (die Modelle) müssen in Folgephasen zur Weiterentwicklung, zur Erhöhung der Qualität und zur Dokumentation verwendbar sein. Dies gilt unabhängig vom verwendeten Prozess sowohl für klassische als auch für agile Prozesse. Prozesse wie z. B. der Rational Unified Process (RUP) [8] sehen die Modellierung explizit als festen Bestandteil in der Software-Entwicklung vor. Aber auch agile Verfahren können Modellierung effektiv einsetzen. Neben dem Vier-Augen-Prinzip des Pair Programming [2] spricht nichts gegen Pair Modeling. Gemeinsam ist allen Vorgehensweisen, dass Modelle, die im Nachhinein ausschließlich zu Dokumentationszwecken niedergeschrieben werden, nicht dieselbe Qualität erreichen wie Modelle, die zur Konstruktion der Software verwendet werden und deshalb ihren Zweck nur begrenzt erfüllen. 3.1 Tool-Unterstützung Entscheidend für den Nutzen der Modelle für die entwickelte Software und für die Effizienz im Projekt ist die Unterstützung durch Werkzeuge, welche Syntax und Semantik der Modelle ken- 4

5 nen und unterstützen. Eine Textverarbeitung kann nicht als universelles Modellierungswerkzeug herhalten genauso wenig wie alle Reparaturen am Auto mit nur einem Schraubenzieher durchgeführt werden könnten. Die Frage nach der einzusetzenden Methode kann deshalb nicht ohne die Frage nach dem eingesetzten Werkzeug beantwortet werden. Die Mächtigkeit der eingesetzten Werkzeugkette bestimmt, inwiefern Aktivitäten wie Modellierung oder Dokumentation als Erleichterung oder als Last empfunden werden. Abbildung 2 zeigt, dass Modell und Code nur dann ohne Zusatzaufwand konsistent gehalten werden können, wenn die eingesetzten Werkzeuge Round-Trip-Engineering unterstützen, d. h. dass Änderungen, die direkt am Code vorgenommen werden, automatisch in das Modell übernommen werden. Plattformunabhängig (PIM) Plattformspezifisch (PSM) Code Round-Trip Abbildung 2: Vom plattformunabhängigen Modell zum Code, hier am Beispiel der MDA 3.2 Die wichtigsten Modellierungstechniken Zu den bekanntesten und wichtigsten Modellierungstechniken zählen die im Folgenden aufgelisteten. Diese Liste erhebt keinen Anspruch auf Vollständigkeit. Die Auswahl ist eingeschränkt auf Techniken, die relativ bekannt sind und für die adäquate Werkzeugunterstützung existiert, damit die Relevanz für den Einsatz diskutiert werden kann. UML Die Unified Modeling Language, entwickelt von Booch, Rumbaugh und Jacobson (siehe [4] oder [7]) seit Anfang der 90er Jahre, zählt heute wohl zu den am weitesten verbreiteten Modellierungssprachen. UML kennt eine Reihe verschiedener Diagramm-Typen, die sowohl statische als auch dynamische Sichten auf ein System erlauben. Für die Modellierung mit UML sind zahlreiche Werkzeuge verfügbar, die damit werben, Code- Generierung und Round-Trip-Engineering zu unterstützen, z. B. Rational Rose oder TogetherCC. Petri-Netze modellieren das Verhalten von dynamischen Systemen mit nebenläufigen und nichtdeterministischen Vorgängen [1]. GPM Geschäftsprozessmodellierung: z. B. mit eepk (erweiterte ereignisgesteuerte Prozesskette). ERM Entity-Relationship-Modelle dienen zur Beschreibung persistenter Daten und ihre Beziehungen untereinander aus fachlicher Sicht. SDL Specification Description Language. Mit der SDL werden insbesondere Kommunikationsprozesse modelliert; sie wird als Standard ( Recommendation ) von der ITU gepflegt 5

6 [11]. Der Einsatzbereich der SDL geht aber über Telekommunikation hinaus und umfasst insbesondere eingebettete Systeme. Strichzeichnungen sind schnell an die Tafel gemalt, nicht formal festgelegt und nicht unbedingt semantisch eindeutig. Sie können als semi-formale Ad-Hoc-Modellierung durchaus hilfreich sein. 3.3 Kritik an Modellierungstechniken Beispiel UML Die Modellierungsmethoden im letzten Abschnitt werden recht kontrovers diskutiert. Insbesondere UML als wohl prominentester Vertreter hat neben einer Reihe von Befürwortern auch eine nicht zu vernachlässigende Menge an Kritikern. Sie bemängeln vor allem die unzureichende Formalisierung: Die Bedeutung von Sprachelementen wird oft nicht eindeutig definiert, sondern anhand von Beispielen erklärt. Die Forderung nach einer formal festgelegten, eindeutigen Syntax und Semantik wird nicht erfüllt. Das Ziel der Modellierung ist jedoch genau die Vermeidung von Mehrdeutigkeiten und die präzise Beschreibung eines bestimmten Aspektes. Die Diagramme benötigen in der Regel zum vollständigen Verständnis nach wie vor erklärende Texte. Für die Strukturierung dieser Erläuterungen existiert keinerlei Unterstützung, und die Konsistenz zwischen Diagramm und Text kann nicht überprüft werden. Ein weiterer Kritikpunkt ist der Umfang der UML: Wohl mit aufgrund der Kommerzialisierung der UML nimmt der Umfang immer weiter zu, und es wird immer schwieriger, auf dem aktuellsten Stand zu bleiben. Diese Einwände sind sicher berechtigt. Dem sind aber dennoch einige Vorteile für den praktischen Einsatz gegenüberzustellen: Zahlreiche Werkzeuge sind verfügbar, die in den Entwicklungsprozess eingebunden werden können. Der Bekanntheitsgrad unter den Entwicklern vereinfacht den Einsatz, da ein gemeinsames Verständnis für die Semantik bereits vorhanden ist und nicht erst das gesamte Entwicklungs-Team zur Schulung geschickt werden muss. Es ist relativ leicht, neue Entwickler hinzuzunehmen (aus anderen Projekten, neu eingestellt oder von Fremdfirmen). Da das Wissen über UML in weiteren Projekten genutzt werden kann, ist eine gewisse Investitionssicherheit gegeben (sowohl bezüglich der Werkzeuge als auch des Wissens der Entwickler). UML wird kontinuierlich weiter entwickelt. Im Moment laufen die Arbeiten zur Version UML 2.0 [9]. Immer mehr für die praktische Software-Entwicklung relevante Aspekte werden berücksichtigt, wie z. B. Echtzeitfähigkeit oder Sicherheit. 3.4 Bedeutung von expliziter Modellierung für den Entwicklungszyklus Jede Phase des Entwicklungszyklus ist gekennzeichnet durch die in ihr erstellten Ergebnisse - dies können reine Textdokumente oder Programmcode oder eben auch erstellte bzw. weiterentwickelte oder verfeinerte Modelle sein. Für die Erarbeitung der Ergebnisse ist ein exaktes Verständnis der gegebenen Problemstellung bzw. der erarbeiteten Lösung erforderlich. Beim Übergang in eine neue Projektphase müssen die Ergebnisse (z. B. im Review) auch anderen Projektbeteiligten verständlich kommuniziert werden. Die nächste Projektphase kann besonders effizient durchgeführt werden, wenn die Ergebnisse automatisch oder toolunterstützt weiterverarbeitet werden können. Diese Anforderungen decken sich genau den Zielen expliziter Modellierung (s. Abschnitt 2.1). Die Erwartungen an die einzelnen Phasen des Entwicklungsprozess führen also direkt zu der Forderung, Modellierung explizit durchzuführen. Zur Bewertung der Qualität eines Entwicklungsprozesses kann das Capability Maturity Model (CMM) [10] herangezogen werden. Das CMM prüft, ob bestimmte Teilprozesse für die Software- Entwicklung auf Projekt- und auf Unternehmensebene existieren und gelebt werden und legt so eine Metrik für die Qualität der Software-Entwicklung fest. Aus den Forderungen des CMM können als Essenz die Qualitätskriterien Kommunikation, Transparenz sowie die Einhaltung eines geplanten Vorgehens herausgearbeitet werden. Explizite Modellierung trägt dazu bei, diese Qualitätskriterien zu erfüllen: 6

7 Kommunikation: Hierbei werden zwei Aspekte angesprochen. Es geht erstens um die Kommunikation innerhalb des Entwicklerteams und zwischen Entwicklern und anderen Projektbeteiligten. Zweitens ist die Erstellung von aussagekräftiger und aktueller Dokumentation für die Weiterentwicklung des Systems von Bedeutung. Die definierte Syntax von Modellen verlangt ein einheitliches Verständnis und unterstützt so die Kommunikation zwischen den Beteiligten. Aus einem Modell können z. B. Code, Testfälle, weitere Modelle oder Dokumentation (allgemein: Artefakte) erzeugt werden; so werden verschiedene Artefakte immer konsistent und auf dem neuesten Stand gehalten. Transparenz: Die Projektziele jedes Beteiligten sowie alle Entscheidungen, die für den Projektverlauf relevant sind, sowie deren Gründe müssen allen Projektbeteiligten transparent sein. Auch wenn die Transparenz insgesamt eher ein Thema der Projektkultur ist, können explizite Modelle dazu beitragen, technische Umstände zu klären und damit technische Entscheidungen transparent und verständlich zu begründen. Geplantes Vorgehen: Es werden abprüfbare und in der nächsten Projektphase direkt nutzbare Ergebnisse verlangt. Explizite Modelle haben hier gegenüber informell formulierten Dokumenten (zumindest zum Teil) den Vorteil, dass ihre Konsistenz und Vollständigkeit automatisch überprüft werden kann und damit die Projektplanung unterstützt wird. Mit diesen Eigenschaften bieten Modellierungstechniken wenn sie mit Bedacht ausgewählt und eingesetzt werden eine gute Prozessunterstützung, unabhängig vom gewählten Prozessmodell. 3.5 Pro und Kontra Modellierung Die Vor- und Nachteile von Modellierung, die als fester Bestandteil in den Entwicklungsprozess integriert wird, werden immer wieder diskutiert. Dieser Abschnitt stellt die häufigsten typischerweise ausgetauschten Argumente kurz dar und erläutert sie Pro Modellierung schafft Überblick. Modellierung wird eingesetzt zur Beschreibung von Systemen und zur Abstraktion von bestimmten Eigenschaften. Dies kann eine Top-Down-Verfeinerung von Systemen sein: Vom Domain-Chart, das den Anwendungsbereich beschreibt, bis hin zum detaillierten Klassendiagramm, aus dem der Code (oder Teile davon) generiert werden können (vertikal unterschiedliche Sichten). Die Abstraktion kann sich dabei auf beliebige Teilaspekte des Systems beziehen, wie z. B. das Verhalten bei Nebenläufigkeit o. Ä. (horizontal unterschiedliche Sichten). Modellierung mit (semi-) formalen Methoden verbessert die Kommunikation zwischen Kunde und Auftragnehmer. Falsch verstandene Anforderungen oder Prioritäten werden teurer, je später sie bemerkt werden. Hier kann (semi-) formale Modellierung helfen, die Kommunikation zwischen Kunde und Auftragnehmer zu verbessern. Dies funktioniert genau dann, wenn die Notation exakt genug ist, um eindeutiges Verständnis zu erzielen, aber noch allgemein genug verständlich, dass nicht nur der Software-Fachmann damit zu Recht kommt. Ohnehin ist bei der Kommunikation zwischen Kunde und Auftragnehmer die Verwendung eines gemeinsamen, präzisen Vokabulars essentiell. (Semi-) formale Modellierung unterstützt dies. Steigerung von Effizienz und Qualität im Entwicklungsprozess: Modelle, die frühzeitig im Prozess erstellt werden, steigern gleichzeitig sowohl die Effizienz als auch die Qualität. Denn so können eventuelle Missverständnisse früh ausgeräumt werden, Inkonsistenzen entdeckt werden, und Code und Dokumentation entstehen aus denselben Artefakten, sind also per Konstruktion konsistent. 7

8 Langfristige Kostenersparnis: Liegt zu einem Anwendungssystem nur inkonsistente oder veraltete Dokumentation vor, so werden kostspielige Reverse-Engineering-Projekte notwendig. Fachliche Zusammenhänge werden aus vorhandenen Implementierungen herausgearbeitet. Werden jedoch schon bei der Entwicklung geeignete Modellierungstechniken eingesetzt, können solche Zusatzaufgaben vermieden werden Kontra Konsistenz von Modell und System: Ohne korrekte und umfassende Dokumentation sind große Projekte langfristig nicht wartbar, erweiterbar oder anpassbar. Dokumentation (insbesondere als freier Text) ist schwierig auf dem neuesten Stand zu halten. Ein immer wieder vorgetragenes Argument gegen explizite Modellierung besagt, dass Modell und Dokumentation oder sogar Modell und Code auseinander laufen könnten und die Pflege von unnötig vielen Artefakten erforderlich mache. Dies würde Wartung und Weiterentwicklung erheblich erschweren. In einem solchen Fall wurde eine nicht adäquate Modellierungsmethode gewählt oder es e- xistiert unzureichende Werkzeugunterstützung. Konsistenz zwischen System und Dokumentation bzw. Code ist zu erhalten, wenn Änderungen nur am Modell vorgenommen werden und daraus dann sowohl die Dokumentation als auch das System erzeugt werden. Dies setzt voraus, dass die eingesetzten Werkzeuge Round-Trip-Engineering ausreichend unterstützen. Damit wird das Argument hinfällig. Modellierung ist teuer. Soll eine explizite Modellierungsmethode eingeführt werden, ist das mit Kosten verbunden: Mitarbeiter müssen geschult werden, um die Methode nutzbringend einsetzen zu können. Entsprechende Werkzeuge müssen ausgewählt und angeschafft werden, und die Mitarbeiter müssen auch im Umgang mit diesen Werkzeugen geschult werden. Schließlich muss die Modellierung in den Prozess integriert werden, was ebenfalls Kosten nach sich zieht. Projekte stehen generell unter Kostendruck und sehen eben genannten Kostenfaktoren als zu hoch an, als dass sie im Projekt getragen werden könnten. Wenn jedoch das Kostenargument angeführt wird, ist das System über seine gesamte Lebensdauer zu betrachten, nicht das einzelne Projekt. Eventuelle Einsparungen in der Wartungs- und Weiterentwicklungsphase sind in die Kostenkalkulation mit einzubeziehen. Da die Wartung und Weiterentwicklung in der Regel die Aufwände der Ersterstellung bei weitem übersteigt [5], können die Ersparnisse allein aufgrund konsistenter Dokumentation erheblich sein. Zusätzlich ist zu berücksichtigen, dass sowohl die Weiterbildung der Mitarbeiter als auch ein verbesserter Prozess die Qualität der produzierten Software erhöhen wird. Prototypen sind besser zur Veranschaulichung als Modelle. Die typischen Probleme zwischen Kunde und Auftragnehmer können mit Oberflächen-Prototypen viel besser gelöst werden als mit umfangreichen Modellen. Für die technische Realisierung sind Durchstich-Prototypen notwendig, die jedes Element der eingesetzten Infrastruktur benutzen. Dies ist jedoch kein Argument gegen Modellierung im Entwicklungsprozess, sondern lediglich für den Einsatz von Prototypen. In der Regel ist das verbunden mit iterativer Entwicklung. Auch hier werden Modelle eingesetzt. Modelle sind unter Umständen für Reviewer schwierig zu handhaben und zu überblicken. Jeder Reviewer muss mit der Modellierungstechnik vertraut sein, um die Modelle auf Konsistenz, Korrektheit bezüglich der Anforderungen und Vollständigkeit beurteilen zu können. Abhängig von der Modellierungstechnik und der Verfügbarkeit von geschulten Mitarbeitern ist dieses Argument hinfällig. 8

9 4 Welche Modelle sind für Informationssysteme relevant Dieser Abschnitt gibt einen Überblick über die Eigenschaften typischer Informationssysteme im Industrieunternehmen. Anschließend wird anhand dieser Eigenschaften der Bedarf für Modellierung diskutiert. 4.1 Charakteristika typischer Projekte Diese Studie untersucht den Bedarf für Projekte mit folgenden Charakteristika: Systeme: Die Anwendungssysteme haben eine lange Lebensdauer, in der Regel viele Jahre bis mehrere Jahrzehnte. Entwicklungsprozess: Zusammenarbeit von eigenen Entwicklern und Fremdfirmen: Viele Entwicklungsaufgaben vor allem im Bereich der Implementierung, auch im Design, werden an Fremdfirmen vergeben. Entwickler: Sowohl der Einsatz der Mitarbeiter als auch ihr Wissen ist von Bedeutung: Die Entwickler implementieren und warten nicht immer auf demselben System. Es gibt über die System-Lebensdauer immer wieder Wechsel: Mitarbeiter wechseln zu anderen Projekten oder in andere Positionen. Die Fachdomäne ist unter den eigenen Entwicklern gut verstanden, bzw. Wissen ü- ber die Unternehmensstruktur ist vorhanden. Infrastruktur: Die Infrastruktur ist relativ konstant; sie wird im zentral festgelegt. Dadurch lässt sich mit der ebenso zentral definierten Werkzeugauswahl eine optimale Unterstützung erreichen. 4.2 Benötigte Modelleigenschaften Dies legt nahe, dass eingesetzte Modelle folgende Eigenschaften aufweisen sollten: Langlebigkeit: Die Modellierungstechnik muss erwarten lassen, dass die Werkzeugunterstützung auf absehbare Zeit gegeben ist, damit erfolgreiche und effiziente Wartung und Weiterentwicklung auf lange Sicht durchgeführt werden kann. Indikatoren dafür sind beispielsweise die aktuelle Verbreitung von Wissen über die Modellierungstechnik sowie am Markt verfügbare Werkzeuge. Integration und Prozessunterstützung: Sowohl die Werkzeuge als auch Modellierungstechnik als auch die erzeugten Modelle müssen sich in den Entwicklungsprozess des Unternehmens eingliedern und in die Werkzeugkette integrieren. Vielseitigkeit von Methoden und Werkzeugen: Die Modellierungstechniken sind in verschiedenen Projekten und für verschiedene Systeme anwendbar, um das Wissen der Mitarbeiter an vielen Stellen nutzen zu können. 4.3 Erreichbarer Nutzen Durch den konsequenten Einsatz von expliziter Modellierung im Entwicklungsprozess sehen wir die Chance, die Ziele Verbesserung des Verständnisses und der Kommunikation sowie Automatisierung zu erreichen. 9

10 Oft wird angenommen, dass sich die Ziele Kosteneinsparung und Qualitätssteigerung widersprechen dies ist nicht unbedingt richtig. Wird konstruktiv bessere Qualität erreicht, führt das (mindestens mittel- und langfristig, oft aber sogar schon kurzfristig) zu Kosteneinsparungen. In den frühen Phasen können Einsparungen realisiert werden, weil alle Projektbeteiligten ein gemeinsames Verständnis erreichen; in den späteren Phasen, weil Folgephasen die Ergebnisse der vorhergehenden Phasen besser weiterverarbeiten können. Die so vermiedene Mehrarbeit schließt gleichzeitig zusätzliche Fehlerquellen aus. Auf lange Sicht wird gleichzeitig die Dokumentation verbessert, was Wartungs- und Weiterentwicklungsprojekten besser planbar macht. Damit wird nicht nur die Höhe, sondern auch die Unsicherheit von Weiterentwicklungskosten reduziert. 5 Verwandte Arbeiten und Abgrenzung Zum Teil wurde diese Diskussion schon in Verbindung mit agilen Methoden geführt. Siehe dazu z. B. [2]. In unserem Zusammenhang steht aber nicht die Optimierung der für die erstmalige Systemerstellung benötigten Zeit im Vordergrund. Der Fokus liegt vielmehr auf der langfristigen Wartung und Weiterentwicklung der Systeme, ausgedrückt durch langfristig niedrige Wartungsund Erweiterungskosten. Dieses Papier beschäftigt sich mit Informationssystemen. Inwieweit die Ergebnisse dieses Papiers im Speziellen auch auf eingebettete Systeme übertragbar sind, bleibt noch zu prüfen. 6 Zusammenfassung und Ausblick Mit der expliziten Modellierung von Software-Systemen werden im Wesentlichen die drei Ziele Verbesserung des Verständnisses und der Kommunikation sowie die Unterstützung von Automatisierung im Entwicklungsprozess verfolgt. Modellierungstechniken werden anhand von vier Kriterien bewertet: Die Modellierung kann bewusst oder unbewusst erfolgen; Modelle können implizit verwendet oder explizit notiert und eingesetzt werden; sie unterscheiden sich im Grad der Präzision; und schließlich ist immer zu untersuchen, ob die gewählte Modellierungstechnik adäquat ist. Langlebige und komplexe Informationssystemen erfordert Modellierungstechniken, die langfristig und vielseitig einsetzbar sind, über die entsprechende Tool-Unterstützung verfügen und sich so in den Entwicklungsprozess eingliedern. Anhand der Kriterien zur Bewertung von Modellierungstechniken und der Charakteristika der Projekte sind nun geeignete Modelle auszuwählen und in den Entwicklungsprozess zu integrieren. Projekte und Prozesse sind kritisch zu überprüfen, ob mit den aktuell eingesetzten Tools alle Möglichkeiten optimal ausgenutzt werden. 10

11 Literatur [1] Balzert, Helmut: Lehrbuch der Software-Technik: Software-Entwicklung. Spektrum Verlag, [2] Beck, Kent: Extreme Programming Explained Embrace Change. Addison-Wesley, [3] Bergner, Klaus: Spezifikation großer Objektgeflechte mit Komponentendiagrammen. Doktorarbeit, Technische Universität München, [4] Booch, Grady, James Rumbaugh und Ivar Jacobson: The Unified Modelling Language User Guide. Addison-Wesley, [5] Ebert, Christof und Reiner Dumke (Herausgeber): Software-Metriken in der Praxis: Einführung und Anwendung von Software-Metriken in der industriellen Praxis. Springer, [6] Endres, Albert: Werkzeuge in der Programmentwicklung. Skript zur gleichnamigen Vorlesung im WS 95/96 an der TU München, [7] Hitz, Martin und Gerti Kappel: Work: Von der Analyse zur Realisierung. dpunkt.verlag, [8] Kruchten, Philippe: The Rational Unified Process. An Introduction. Addison-Wesley, [9] Object Management Group: UML Specification. April [10] Paulk, Mark C., Charles V. Weber, Bill Curtis und Mary Beth Chrissis: The Capability Maturity Model: Guidelines for Improving the Software Process. Addison- Wesley, [11] SDL Forum Society. April

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

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

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

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

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

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

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

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

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

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

Inhaltsverzeichnis. Literatur. 4 Rational Unified Process [JBR98, Kru03] und UML [BRJ02, FS00, Bal01]

Inhaltsverzeichnis. Literatur. 4 Rational Unified Process [JBR98, Kru03] und UML [BRJ02, FS00, Bal01] Inhaltsverzeichnis 1 Einleitung 4 1.1 CVS (Concurrent Version System) [Pru03, Zee02, Ced05]....... 5 1.2 Eclipse als Java Entwicklungsumgebung................. 22 2 Planungsmethoden 29 2.1 Definitionsphase..............................

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Model Driven Architecture

Model Driven Architecture Model Driven Architecture Wilhelm Stephan Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Julian Kunkel SommerSemester

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

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

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

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

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

Prozessdokumentation und -darstellung

Prozessdokumentation und -darstellung Prozessdokumentation und -darstellung Methoden und Ansätze zur praxisorientierten Dokumentation Unsere Leistungen Interims- und Projektmanagement Test- und Dokumentationsmanagement Prozess- und Organisations-Consulting

Mehr

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

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

Mehr

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

Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06

Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06 Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06 Kapitel 0: Vorlesungsüberblick Prof. Dr. Mario Winter SP2-0 FH Köln SP-2 (WI3) Vorlesungsüberblick 1. Softwaretechnik

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 2 Grundbegriffe

Mehr

Notationen zur Prozessmodellierung

Notationen zur Prozessmodellierung Notationen zur Prozessmodellierung August 2014 Inhalt (erweiterte) ereignisgesteuerte Prozesskette (eepk) 3 Wertschöpfungskettendiagramm (WKD) 5 Business Process Model and Notation (BPMN) 7 Unified Modeling

Mehr

Ergänzung zum Modulhandbuch

Ergänzung zum Modulhandbuch Ergänzung zum Modulhandbuch des Bachelor- und Masterstudiengangs Angewandte Informatik zu den Prüfungs- und Studienordnungen von 2007 und 2008 Institut für Informatik an der Universität Bayreuth (Version

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

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

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

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

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

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

Mehr

Model Driven Development im Überblick

Model Driven Development im Überblick Model Driven Development im Überblick Arif Chughtai Diplom-Informatiker (FH) www.digicomp-academy, Seite 1 September 05 Inhalt Motivation Überblick MDA Kleines Beispiel Werkzeuge www.digicomp-academy,

Mehr

Software Factories SS 2016. Prof. Dr. Dirk Müller. 3 Modellgetriebene Softwareentwicklung

Software Factories SS 2016. Prof. Dr. Dirk Müller. 3 Modellgetriebene Softwareentwicklung Software Factories 3 Modellgetriebene Softwareentwicklung Prof. Dr. Dirk Müller Übersicht Einordnung im Lebenszyklus Ziele Hebung des Abstraktionsniveaus Model Driven Architecture (MDA) Domänenspezifische

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

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

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

Mehr

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

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

Mehr

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

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

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

Mehr

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus Softwarepraktikum SS 2005 Inhalt - VL 10 1 Softwaretechnik 2 Anforderungsanalyse 3 Systemmodelle Softwaretechnik Technische Disziplin, mit dem Ziel, kosteneffektiv Softwaresysteme zu entwickeln Techniken

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Kundenanforderungen dokumentieren

Kundenanforderungen dokumentieren Requirements Engineering Kundenanforderungen dokumentieren Bereich Anforderungen Aktivität Kunden-Anforderungen erheben Ziele Gesteigerte Kundenzufriedenheit Dokumentation der genauen Erwartungen des Kunden

Mehr

Erfolg ist programmierbar.

Erfolg ist programmierbar. 4578954569774981234656895856512457895456977498 3465689585651245789545697749812346568958561245 9545697749812346568958565124578954569774981234 6895856512457895456977498123465689585612457895 6977498123465689585651245789545697749812346568

Mehr

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

Mehr

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Anne Thomas TU Dresden Dr. B. Demuth Pre Press GmbH (Dresden) T. Reuter Gliederung Einleitung Vorgehensweise Kontext

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

Mehr

Requirements Dokumentation Seminar- Requirements Engineering. Manoj Samtani Oliver Frank

Requirements Dokumentation Seminar- Requirements Engineering. Manoj Samtani Oliver Frank Requirements Dokumentation Seminar- Requirements Engineering Manoj Samtani Oliver Frank 24.07.2007 TU Berlin SS 2007 Inhaltsübersicht Ziel des Dokumentierens Dokumentation vs. Spezifikation Qualitätskriterien

Mehr

Bewertung. Vorgespräch. Interne Vorbereitung. Zertifizierungsaudit. Wiederholungsaudit. Überwachungsaudit

Bewertung. Vorgespräch. Interne Vorbereitung. Zertifizierungsaudit. Wiederholungsaudit. Überwachungsaudit Bewertung,62=HUWLIL]LHUXQJ Vorgespräch Interne Vorbereitung 0RQDWH Zertifizierungsaudit Wiederholungsaudit DOOH-DKUH Überwachungsaudit MlKUOLFK Wenn eine Organisation ein,62ãã=huwlilndw anstrebt, so muss

Mehr

Gliederung des Vortrages

Gliederung des Vortrages Gliederung des Vortrages Unified Modeling Language Rational Rose Sergej Schwenk Oktober 1999 0. Einführung 1. Historie 2. Der Entwicklungsprozeß 3. UML 3.1 Anwendungsfalldiagramme 3.2 Klassendiagramme

Mehr

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??

Mehr

Assembly Technology. des Entwicklungsprozesses

Assembly Technology. des Entwicklungsprozesses FRAUNHOFER-institut für produktionstechnologie IPT projektgruppe entwurfstechnik mechatronik Requirements Engineering Assembly Technology Ovidemporion porum quiae nemporro cone venderferia coris dio officia

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

BPMN vs. EPK & Co. oder auf was es wirklich ankommt

BPMN vs. EPK & Co. oder auf was es wirklich ankommt BPMN vs. EPK & Co. oder auf was es wirklich ankommt Sebastian Adam, Norman Riegel 15. Mai 2012, St. Augustin Die Fraunhofer-Gesellschaft e.v. Benannt nach: Rolle der FraunhoferGesellschaft: Größe: Forschungsvolumen:

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

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

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

Mehr

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

Phasen. Gliederung. Rational Unified Process

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

Mehr

Anforderungsanalyse, Requirements Engineering

Anforderungsanalyse, Requirements Engineering Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

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

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

Mehr

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

Einführung in das Software-Qualitätsmanagement

Einführung in das Software-Qualitätsmanagement Roland Petrasch Einführung in das Software-Qualitätsmanagement ^oyoc; 0 Einleitung 9 1 Qualitätsmanagement in der Software-Entwicklung 11 1.1 Entwicklung von Software-Produkten 11 1.1.1 Begriffsbestimmung

Mehr

Lohnt sich Requirements Engineering?

Lohnt sich Requirements Engineering? Lohnt sich Requirements Engineering? Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss Oleksandr Kazandzhi Gliederung Einleitung Messen

Mehr

Aufgabe 1: Beschreibung des Forschungsgebietes der Wirtschaftsinformatik

Aufgabe 1: Beschreibung des Forschungsgebietes der Wirtschaftsinformatik Übungsblatt 01 / 2011 Datum: 5. Mai 2011 Aufgabe 1: Beschreibung des Forschungsgebietes der Wirtschaftsinformatik Beschreiben Sie das Lehr- und Forschungsgebiet der Wirtschaftsinformatik und zeigen Sie

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

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement Basierend auf einem zentralen SOA-Projekt wird die Integration von Änderungsmanagement aus dem ApplicationLifeCycle

Mehr

Softwaretechnik (Medieninformatik) Überblick

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

Mehr

Martina Seidl Marion Brandsteidl Christian Huemer Gerti Kappel. UML @ Classroom. Eine Einführung in die objektorientierte Modellierung

Martina Seidl Marion Brandsteidl Christian Huemer Gerti Kappel. UML @ Classroom. Eine Einführung in die objektorientierte Modellierung Martina Seidl Marion Brandsteidl Christian Huemer Gerti Kappel UML @ Classroom Eine Einführung in die objektorientierte Modellierung Martina Seidl seidl@big.tuwien.ac.at Marion Brandsteidl brandsteidl@ifs.tuwien.ac.at

Mehr

Reviews von Entwicklungsartefakten durchführen

Reviews von Entwicklungsartefakten durchführen Testen Reviews von Entwicklungsartefakten durchführen Bereich Evaluation Ziele Fehler und Probleme frühzeitig finden Wissenstransfer ermöglichen Teamzusammenhalt fördern Lösungen erarbeiten Aktivität Reviews

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

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

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003 Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen

Mehr

Requirements Engineering I

Requirements Engineering I Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Kompetenz. rund um. Ihren. Entwicklungsprozess. Über uns. Technische Software. Modellbasierter Test. Prüfplätze. Automatisierung.

Kompetenz. rund um. Ihren. Entwicklungsprozess. Über uns. Technische Software. Modellbasierter Test. Prüfplätze. Automatisierung. Kompetenz rund um Ihren Entwicklungsprozess Modellieren für den Test - Segen oder Fluch? Firmenpräsentation auf der embeddedworld 2010 Dipl. Ing. (Univ) Gerhard Baier Bereichsleiter Marketing und Vertrieb

Mehr

CMM Mythos und Realität. Forum Forschungsförderung BITKOM / ViSEK 2003 17. Oktober 2003. Tilman Seifert, TU München

CMM Mythos und Realität. Forum Forschungsförderung BITKOM / ViSEK 2003 17. Oktober 2003. Tilman Seifert, TU München CMM Mythos und Realität Forum Forschungsförderung BITKOM / ViSEK 2003 17. Oktober 2003, TU München Agenda Das CMM Ziele und Aufbau Prozessverbesserung nach CMM Bewertung des CMM Mythen Thesen Kritik Zusammenfassung

Mehr

12. Vorgehensmodelle Softwaretechnik (CNAM)

12. Vorgehensmodelle Softwaretechnik (CNAM) 12. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2011 / 2012 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Einordnung in den gesamten Kurs 1. Einführung 2. Analyse: Anforderungen

Mehr

Teil VII. Software Engineering

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

Mehr

J.2 Objektorientiertes Modellieren mit UML

J.2 Objektorientiertes Modellieren mit UML Modellieren mit UML Objektorientiertes Modellieren mit UML 2002 Prof. Dr. Rainer Manthey Informatik II 1 UML: Übersicht in den 1980er Jahren: Entstehen einer Vielzahl objektorientierter Entwurfsmethoden

Mehr

Software Engineering

Software Engineering Software Engineering Grundlagen, Menschen, Prozesse, Techniken von Jochen Ludewig, Horst Lichter 1. Auflage Software Engineering Ludewig / Lichter schnell und portofrei erhältlich bei beck-shop.de DIE

Mehr

Grundlagen des Software Engineering

Grundlagen des Software Engineering Grundlagen des Software Engineering Teil 2: SW-Qualitätssicherung Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Motivation Syntax-, Konsistenz- und Vollständigkeitsprüfungen

Mehr

Software Systems Engineering

Software Systems Engineering Software : SoSe 08 Prof. Dr. Klaus Schmid Software Produktlinien Ein neues Programm soll erstellt werden. Das habe ich doch schon mal programmiert, oder? Alter Code passt aber nicht ganz! Wird passend

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

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

Einführung in die Modellierung

Einführung in die Modellierung Einführung in die Modellierung Christian Huemer Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna,

Mehr

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz ISIS Das Navigationssystem für angemessene Qualität und hohe Effizienz Inhalt Softwarequalität und Prozessqualität ISIS: das Ziel Messen der Prozessqualität Der Werkzeugzoo Die Wirkung Maßnahmen zur Prozessoptimierung

Mehr

Objektorientierte Analyse und Design

Objektorientierte Analyse und Design Folien basieren auf folgendem Buch: Objektorientierte Analyse und Design Kernziele: Strukturen für erfolgreichen SW-Entwicklungsprozess kennen lernen Realisierung: Von der Anforderung zur Implementierung

Mehr

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de

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

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

Modellierung von Arbeitsprozessen

Modellierung von Arbeitsprozessen Informatik II: Modellierung Prof. Dr. Martin Glinz Kapitel 9 Modellierung von Arbeitsprozessen Universität Zürich Institut für Informatik Inhalt 9.1 Grundlagen 9.2 Ereignisgesteuerte Prozessketten (EPK)

Mehr

Systemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 -

Systemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 - Systemanalyse - Seminar für AI/DM 3 im Wintersemester 2004/05 - Prof. Dr. Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern,

Mehr