Geschäftsprozessorientierte Anwendungsentwicklung

Größe: px
Ab Seite anzeigen:

Download "Geschäftsprozessorientierte Anwendungsentwicklung"

Transkript

1 Geschäftsprozessorientierte Anwendungsentwicklung Ein Ansatz zur Kopplung von ADONIS und Rational Rose eingereicht von: Michael Derntl DIPLOMARBEIT zur Erlangung des akademischen Grades Magister rerum socialium oeconomicarumque Magister der Sozial- und Wirtschaftswissenschaften (Mag. rer. soc. oec.) Fakultät für Wirtschaftswissenschaften und Informatik, Universität Wien Fakultät für Technische Naturwissenschaften und Informatik, Technische Universität Wien Studienrichtung: Wirtschaftsinformatik Begutachter: O. Univ.-Prof. Dr. Dimitris Karagiannis Dipl. Wi.-Inf. Harald Kühn Wien, im Oktober 2001

2 Ehrenwörtliche Erklärung Ehrenwörtliche Erklärung Ich versichere hiermit, dass ich die vorliegende Diplomarbeit selbständig verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfe bedient habe. Diese Diplomarbeit hat in gleicher oder ähnlicher Form im In- oder Ausland noch keiner Prüfungsbehörde vorgelegen. Wien, den 16. Oktober Michael Derntl Seite I

3 Vorwort Vorwort Im Zuge der Entstehung dieser Diplomarbeit sind nicht wenige Jahreszeiten gekommen und gegangen, und doch ist sie noch in einem letzten Kraftakt kurz vor Einführung der Studiengebühren fertiggestellt worden. Mein Dank gilt gleichsam - in alphabetischer Reihenfolge meinen Eltern, die mir das Studium der Wirtschaftsinformatik ermöglicht haben, meiner Freundin für die zwar fachfremde, jedoch rechtschreibtechnisch und grammatikalisch unerlässliche Durchsicht, den Herren Professor Dr. Karagiannis und Harald Kühn für richtungsgebende Anregungen, Betreuung und Verbesserungsvorschläge, sowie allen, die soweit vorgestoßen sind, diese Zeilen zu lesen. Möge diese Arbeit häufig in Literaturhinweisen auftauchen, auf dass sie nicht in der Bibliothek verstaube. Seite II

4 Inhalt Inhalt 1 Einführung Motivation Aufgabenstellung Aufbau der Arbeit Begriffe und Grundkonzepte Software-Entwicklung Begriffsbestimmung Phasen der Software-Entwicklung Unified Modeling Language (UML) Klassendiagramme Klassen Interfaces Beziehungen UseCase-Diagramme System UseCases Akteure Beziehungen Aktivitätsdiagramme Aktivitätszustand Transitionen Entscheidungsknoten Synchronsiation Swimlanes Unified Software Development Process Begriff und Hauptmerkmale Phasen CASE Geschäftsprozessmanagement Das BPMS-Paradigma Strategic Decision Process Reengineering Process Resource Allocation Process Workflow Process Performance Evaluation Process Geschäftsprozessmodellierung Werkzeuge Allgemeines zur Werkzeugunterstützung Das Geschäftsprozessmanagement-Werkzeug ADONIS Theoretische Basis Funktionalität und Einsatzszenarien Programmierschnittstellen ADLP AdoScript Das CASE-Werkzeug Rational Rose Seite I

5 Inhalt Theoretische Basis Funktionalität und Einsatzszenarien Programmierschnittstellen COM-API RoseScript Kopplungsansätze Einleitung Entscheidungsvariablen eines Kopplungsansatzes Dimensionen eines Kopplungsansatzes Bereitschaft des Kopplungsmoduls Onlinemodule Offlinemodule Kopplungsrichtung Automation der Transformation Automation der Integration Konkrete Ansätze Modellmanipulation Direkter Zugriff auf die Beschreibungssprache Indirekter Zugriff auf die Beschreibungssprache Automatische Ansätze Mapping-Scripts Integrationsregeln Integration im Offlinemodul Integration im Onlinemodul Benutzergesteuerte Ansätze Benutzergesteuerte Onlinemodule Benutzergesteuerte Offlinemodule Gemischte Ansätze Geschäftsprozesse und Anwendungsentwicklung Geschäftsprozessorientierte Anwendungen ADONIS-Standard-Anwendungsbibliothek Transformation von Modellen gleichen Typs Transformation von Modellen verschiedenen Typs Generierung von UseCase-Diagrammen aus Geschäftsprozessmodellen Generierung von Aktivitätsdiagrammen aus Geschäftsprozessmodellen Anwendungsorientierte Geschäftsprozesse Generierung von Geschäftsprozessmodellen aus UseCase- Diagrammen Zusammenfassung der Überführungsmethoden Fallstudie: AdoRose Kopplung von ADONIS und Rational Rose Realisierung Entwicklungsumgebung und Zielsystem Konzeption und Architektur ADLP-Client-Modul COM-Client-Modul Script-Parser Konvertierungsmodul Seite II

6 Inhalt Kommandozeile Benutzerschnittstelle Einsatz und Grenzen Zusammenfassung Verzeichnisse Abbildungen Literatur Abkürzungen Seite III

7 Motivation Einführung 1 Einführung 1.1 Motivation Da nicht zu übersehen ist, wie die Unified Modeling Language (UML) seit 1997 ein Standard der Object Management Group (OMG) in der objektorientierten Anwendungsentwicklung immer mehr an Bedeutung und Akzeptanz gewinnt, sind Kopplungsmechanismen zwischen organisations- und administrativ orientierten Werkzeugen einerseits, und IT-nahen Werkzeugen andererseits für eine umfassende Befriedigung der Kundenbedürfnisse unerlässlich. Gerade Unternehmen, die viele Mitarbeiter beschäftigen und eine Vielzahl konkreter und potentieller Arbeitsabläufe aufweisen, sind auf die Dokumentation und Transparenz ihrer Geschäftsprozesse angewiesen. Gute Beispiele für Unternehmen dieser Kategorie sind Banken und Versicherungen, bei deren Umstrukturierungen und Reorganisationsprojekten in der Regel mehrere hundert verschiedene Prozesse ermittelt werden können. Um diesen organisatorischen und administrativen Aufwand bewältigen zu können, wird viel Geld in Modellierungswerkzeuge investiert. Ein vor allem in Europa bedeutender Vertreter dieser Werkzeuge ist ADONIS 1, ein Geschäftsprozessmanagement- Werkzeug, das seit 1996 von der BOC Information Technologies Consulting GmbH entwickelt und weiterentwickelt wird. Auf ADONIS und seine Fähigkeiten und Einsatzmöglichkeiten wird in den Kapiteln des Hauptteils näher eingegangen (s. Kap. 3.2). Um die Automation der Geschäftsprozesse soweit als möglich zu fördern, können die Unternehmen weder auf spezialisierte, noch auf standardisierte Software verzichten. Es kommt häufig vor, dass Geschäftsprozesse auf Informationssysteme als Ressourcen zurückgreifen oder einzelne Aktivitäten vollständig durch Informationstechnologie umgesetzt werden. Da viele Software-Komponenten, vor allem betriebliche Informationssysteme, hochgradig prozess- und damit unternehmensspezifisch sind, muss das Unternehmen auf Grundlage der identifizierten Prozesse Anwendungssoftware entwickeln, die den Mitarbeitern der Ausführungsebene ermöglicht, in den Prozessen gewonnene Daten per Computer in das betriebliche Informationssystem - ohne über die reine Benutzung hinausgehende Kenntnisse - einzuspeisen. Als einfaches Beispiel hierfür könnte man die Kontoeröffnung eines neuen Kunden einer Bank anführen. Ein Ausschnitt aus diesem Prozess, der vor allem auch vom Kunden aktiv miterlebt wird, ist das übliche Frage- und Antwortspiel, bei dem die personenbezogenen Kundendaten vom Mitarbeiter in die dafür vorgesehene Eingabemaske eingetragen werden. Aus dieser Überlegung ist ersichtlich, wie eng das Geschäftsprozessmanagement und die Anwendungsentwicklung miteinander verwoben sind. Was zumindest für den Außenstehenden verborgen bleibt, um das obige Beispiel 1 ADONIS ist ein eingetragenes Warenzeichen der BOC Information Technologies Consulting GmbH. Seite 1

8 Aufgabenstellung Einführung weiterzuführen, ist der meist äußerst holprige Weg von der Prozessmodellierung bis zur fertigen und ins betriebliche Informationssystem integrierten Eingabemaske. Die Anwendungsentwickler können logischerweise aus den Geschäftsprozessmodellen nicht unmittelbar die Architektur des Softwaresystems ableiten, vor allem wie es mit bestehenden Komponenten integriert werden kann (Problematik der Legacy-Systeme). Daher ist es auch in diesem Bereich vordergründig notwendig, Modelle des Systems zu entwerfen. Die Firma Rational hat sich mit dieser Problematik intensiv auseinandergesetzt und eine Methodik entworfen, mit der iterativ und inkrementell ein Softwaresystem aus den Anforderungen entwickelt wird. Die Rede ist vom Unified Software Development Process, der ein mehrstufiges Phasenschema für die Entwicklung komplexer Software-Architekturen bereitstellt. Rational hat zur Unterstützung des Entwicklungsprozesses ein Werkzeug implementiert, das die Modellierung sämtlicher UML-Modelltypen integriert ermöglicht Rational Rose 2. Um die Einführung nicht mit technischen Details zu überladen, wird der Rational Unified Process als ein wichtiger Vertreter moderner und objektorientierter Software-Entwicklungsschemata in Kap und das CASE-Werkzeug Rational Rose in Kap. 3.3 näher beschrieben. Die Motivation dieser Arbeit lässt sich anhand obiger Ausführungen leicht formulieren. Es soll ein Konzept entworfen werden, das Ansätze zur Integration von Geschäftsprozessmodellierung und Anwendungsentwicklung liefert. Ziel ist ein methodisches Rahmenwerk, das einen einheitlichen und durchgängigen Weg von der Prozesserhebung bis zum fertigen Softwaresystem ermöglicht. Zentral ist die Realisierung eines Konzeptes zur Kopplung der beiden Werkzeuge ADONIS und Rational Rose. 1.2 Aufgabenstellung Diese Arbeit soll einerseits vorrangig konzeptionelle Ansätze zu entsprechenden Kopplungsmechanismen entwickeln, um andererseits gleichzeitig die theoretische Basis für die Realisierung eines Kopplungsmoduls der Werkzeuge ADONIS und Rational Rose zu bieten. Der Entwurf effektiver Kopplungen wirft eine Vielzahl von Fragen auf, die gründlich zu überlegen sind, unter anderem: Worauf spezialisiert sich das Geschäftsprozessmanagement-Werkzeug? Wo zeichnet es sich aus, ab wann scheint es sinnvoll, ein CASE-Werkzeug einzusetzen? Ab welchem Zeitpunkt ist es unumgänglich, mit einem CASE-Werkzeug weiterzuarbeiten? Gibt es einen Anhaltspunkt für eine gemeinsame Schnittstelle oder ein gemeinsames Metamodell? Sind etwaige Schnittstellen homogen? Welche Kopplungsansätze gibt es und welcher bringt kundenspezifisch die meisten Vorteile? 2 Rational Rose ist ein eingetragenes Warenzeichen der Rational Software Corporation. Seite 2

9 Aufbau der Arbeit Einführung Die Entwicklung eines Konzeptes zur Beantwortung dieser und anderer wesentlicher Fragen erfolgt - wie bereits oben angesprochen zuerst theoretisch, sowie anschließend konkret mittels je einem gängigen Vertreter seiner Sorte: Das Geschäftsprozessmanagement-Werkzeug ADONIS einerseits, Rational Rose als CASE-Werkzeug andererseits. Es sollen Möglichkeiten vorgestellt werden, wie Modelle zwischen den Werkzeugen ausgetauscht, also transformiert werden können. Um dies zu ermöglichen, müssen Regeln definiert werden, wie eine solche Transformation vonstatten gehen soll, wobei unterschiedliche Modelle durch ihre unterschiedliche Semantik auch individuelle Regeln erfordern. Die Transformation von UseCase-Diagrammen 3 als statische Sicht auf die Anforderungen an ein Software-System (s. Kap ) stellt andere Anforderungen als die Transformation dynamischer Modelle, wie etwa von Aktivitätsdiagrammen, die unter anderem dazu benutzt werden können, Abläufe, Objekt- und Kontrollflüsse innerhalb von UseCases zu beschreiben (s. Kap ). Ebenso wichtig sind Aussagen über grundsätzliche Ansätze der Transformation. So kann ein Kopplungsmodul über Nachrichten und individuelle Schnittstellen mit den Werkzeugen kommunizieren, oder aber einen Ansatz wählen, der über Mapping-Scripts, die Transformationsregeln beinhalten, funktioniert. Relevant ist auch die Frage nach dem Automatisierungsgrad der Kopplung: Wird der Benutzer miteinbezogen? Wenn ja, zu welchem Grad? Wird vollautomatisch transformiert? Wie hoch ist dann der Informationsverlust oder die Anzahl der Fehltransformationen? All diese Fragen werfen zahlreiche Dimensionen von Kopplungsmechanismen auf, die im Rahmen der Kopplungsansätze diskutiert werden (s. Kap. 4). Um auf eine gemeinsame begriffliche und sprachliche Basis zu gelangen, werden vorerst jene Begriffe und Grundkonzepte erläutert, die dann im Hauptstück ohne nähere Erläuterung verwendet werden. 1.3 Aufbau der Arbeit Folgende Abb. 1 zeigt die Struktur und die Zusammenhänge der Kapitel dieser Arbeit, jeweils mit kurzen Zusammenfassungen der Kapitelinhalte. Pfeile deuten auf inhaltliche, konzeptionelle oder begriffliche Abhängigkeit hin. 3 Für UseCases und UseCase-Diagramme existieren in der Literatur verschiedene Schreibweisen (u.a. "use case", "Use Case", "Use-Case"), in dieser Arbeit wird ausschließlich die Bezeichnung "UseCase" verwendet in Anlehnung an [OMG 1999]. Seite 3

10 Aufbau der Arbeit Einführung 1 Einführung Motivation, Aufgabenstellung und Aufbau der Arbeit. 2 Begriffe und Grundkonzepte Erläuterung von Konzepten und Begriffen der Software-Entwicklung allgemein, sowie der Unified Modeling Language (UML). Einführung in in Geschäftsprozessmanagement und Geschäftsprozessmodellierung. Einführungsteil 3 Werkzeuge Beschreibung von Funktionalität, Einsatzmöglichkeiten und Programmierschnittstellen des Geschäftsprozessmanagement- Werkzeugs ADONIS sowie des CASE-Werkzeugs Rational Rose. 4 Kopplungsansätze Definition der verschiedenen Dimensionen von Kopplungsansätzen, sowie Vorstellung von Möglichkeiten der Realisierung. Identifikation der Kluft zwischen Geschäftsprozessmanagement und Anwendungsentwicklung, sowie der Versuch der bidirektionalen Integration der beiden Disziplinen. 5 Fallstudie: AdoRose Vorstellung der Konzeption, Realisierung, Implementierung, Einsatzmöglichkeiten und Grenzen eines spezifischen Kopplungsansatzes zur Transformation von Modellinformationen der Werkzeuge ADONIS und Rational Rose: Das Kopplungsmodul AdoRose. Hauptteil 6 Zusammenfassung Zusammenfassung der Kernaussagen der Arbeit und Ausblick. 7 Verzeichnisse Verzeichnisse der Abbildungen, Literatur und Abkürzungen. Schlussteil Abb. 1: Kapitelstruktur der Arbeit Die Arbeit ist, wie in Abb. 1 ersichtlich, in drei wesentliche Teile gegliedert: Einführungs-, Haupt- und Schlussteil. Die durch die Pfeile dargestellte Kapitelabhängigkeit kann über mehrere Stufen führen: Da Kap. 6 von Kap. 5 inhaltlich abhängig ist, ist es auch von Kap. 3, 4 und 2 inhaltlich abhängig, wobei eine solche Abhängigkeit nicht als "Lesepflicht" zu verstehen ist, sondern die Gesamtheit der Abhängigkeiten einen Wegweiser durch die Arbeit bieten soll. Seite 4

11 Software-Entwicklung Begriffe und Grundkonzepte 2 Begriffe und Grundkonzepte 2.1 Software-Entwicklung Ein zentraler Begriff bereits in der Einleitung war die Software-Entwicklung, in dieser Arbeit auch synonym verwendet mit Anwendungsentwicklung und Software-Engineering Begriffsbestimmung Für Software-Engineering gibt es eine Menge von anderslautenden Begriffsbestimmungen, die jedoch im wesentlichen gleiches aussagen. Deshalb sei hier stellvertretend die Beschreibung des Begriffes von Sommerville [Sommerville 1995, S. 3-20] angeführt. Demnach beschäftigt sich Software-Engineering mit Methoden, Werkzeugen und Techniken des Managements, sowie der Erstellung und Entwicklung von Software-Produkten Phasen der Software-Entwicklung Da hier ein durchgängiges Konzept vom Geschäftsprozessmanagement bis zur fertigen Software-Lösung angestrebt wird, seien die wichtigsten Phasen der Software-Entwicklung angeführt. Phasenschemata des Software-Engineering haben schon seit den 60er-Jahren die Literatur beschäftigt, daher ist es auch verständlich, dass eine Vielzahl von Modellen existiert. Trotzdem können die meisten Modelle, wie beispielsweise das Wasserfallmodell [Royce 1970] oder das Spiralmodell [Boehm 1988] durch folgende Phasen charakterisiert werden [Sommerville 1995, S.10] (s. Abb. 2 4 ): Abb. 2: Phasen des Software-Engineering als Geschäftsprozessmodell 1. Anforderungsanalyse und -definition (requirements analysis and definition): In Zusammenarbeit mit den Benutzern werden Funktionalität, Einschränkungen und Ziele erhoben. Wichtig ist das gemeinsame Verständnis zwischen Entwicklern und Benutzern, die Anforderungen müssen also auch für die Benutzer verständlich repräsentiert werden, 4 Zur Erstellung sämtlicher Geschäftsprozessmodelle in dieser Arbeit, sowie für die Generierung der hier abgebildeten Grafiken von Geschäftsprozessmodellen wurde das Geschäftsprozessmanagement-Werkzeug ADONIS verwendet. Seite 5

12 Software-Entwicklung Begriffe und Grundkonzepte zum Beispiel durch einfache Modellierungstechniken wie das UseCase- Diagramm in UML (s. Kap ). 2. System- und Softwaredesign (system and software design): Die Anforderungen werden unterteilt in Hard- und Software-Anforderungen, sodass ein allgemeines Modell der Systemarchitektur entsteht. Das Softwaredesign liefert eine Vorgehensweise für die Umsetzung der Funktionalität der ausführbaren Programme. 3. Implementierung und Unit-Tests (implementation and unit testing): In dieser Phase wird die im Softwaredesign spezifizierte Funktionalität realisiert in Form eines oder mehrerer Programmmodule. Die einzelnen Module werden isoliert auf Erreichung der erwarteten Leistung getestet. 4. Integration und Systemtests (integration and system testing): Die in der vorangegangenen Phase entwickelten Programmmodule werden zu einem kompletten System integriert. Nach sorgfältiger Testung des integrierten Systems wird das Produkt an die Endbenutzer ausgeliefert. 5. Einführung und Wartung (operation and maintenance): Das System wird beim Kunden eingeführt. In früheren Zyklen nicht erkannte Fehler werden im Rahmen der Wartung ausgebessert. Die Wartung umfasst jedoch auch die Weiterentwicklung der Module und des Systems, um neuen Anforderungen gerecht zu werden. In der Regel ist dies die längste und teuerste Phase im Lebenszyklus eines Softwareprodukts Unified Modeling Language (UML) Da die Unified Modeling Language (UML) in den bisherigen Ausführungen eine Rolle gespielt hat, und auch weiterhin vor allem in Bezug auf die Modellierungswerkzeuge eine tragende Rolle spielen wird, seien hier einführend die wichtigsten Konzepte, Diagrammtypen und elemente erklärt. Aus der Tatsache, dass die UML-Spezifikation in der aktuellen Version 1.3 über 800 Seiten umfasst, lässt sich ableiten, dass hier wirklich nur äußerst kurz die für diese Arbeit relevanten Gebiete und Konstrukte der UML erläutert werden. UML ist eine grafische Modellierungssprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Softwaresystemen [OMG 1999]. UML basiert auf objektorientierten Software-Entwicklungskonzepten, die im Rahmen dieser Arbeit nicht näher erläutert werden können. Zur Einführung in objektorientierte Software-Entwicklung sei z. B. verwiesen auf [Meyer 1994]. Die UML unterscheidet Modelle und Diagramme. Modelle stellen bestimmte Aspekte eines Softwaresystems dar. Für diese Arbeit interessanter sind jedoch Diagramme. Diagramme stellen eine (grafische) Sicht auf ein Modell dar, wobei je nach Komplexität ein oder mehrere Diagramme ein Modell bilden können [Hitz et al. 1999]. In der UML-Spezifikation werden 9 verschiedene Diagrammtypen unterschieden [OMG 1999]: Klassendiagramme, Objekt- Diagramme, UseCase-Diagramme, Sequenzdiagramme, Kollaborationsdia- Seite 6

13 Software-Entwicklung Begriffe und Grundkonzepte gramme, Zustandsdiagramme, Aktivitätsdiagramme, Komponentendiagramme und Einsatzdiagramme. Für die weiteren Ausführungen relevant sind jedoch nur das Klassendiagramm, das UseCase-Diagramm und das Aktivitätsdiagramm, da diese drei im Wesentlichen als einzige sinnvolle Anhaltspunkte für eine Kopplung von Geschäftsprozess- und UML-Modellen dienen können. Diese Diagrammtypen und ihre Elemente werden nun genauer betrachtet Klassendiagramme Klassendiagramme (eigentlich static structure diagrams [OMG 1999]) gehören zur Gruppe der Strukturdiagramme, beschreiben also statische Aspekte des zu entwickelnden Systems unter Verwendung von Paketen, Klassen, Objekten, Interfaces (d.h. Schnittstellen) und deren Beziehungen Klassen Eine Klasse (s. Abb. 3 und Abb. 4) repräsentiert ein abstraktes oder konkretes Konzept aus dem Problembereich, also eine Menge von Objekten mit gemeinsamen Attributen und Operationen, wobei Attribute gemäss dem objektorientierten Konzept den Zustand, und Operationen das Verhalten eines Objektes zeigen. In der grafischen Repräsentation ist die Klasse horizontal in drei Abschnitte untergliedert. Im ersten (oberen) Abschnitt befindet sich der Name der Klasse und etwaige Einschränkungen (constraints), auf die hier nicht näher eingegangen wird. Im zweiten (mittleren) Abschnitt befinden sich die Attribute, und im dritten (unteren) Abschnitt befinden sich etwaige Operationen. Die unteren beiden Abschnitte (Attribute und Operationen) können je nach gewünschtem Detaillierungsgrad im Diagramm weggelassen werden. Abb. 3: Klasse Customer (detaillierte Notation) Interfaces Abb. 4: Klasse Customer (vereinfachte Notation) Ein Interface (deutsch "Schnittstelle", grafische Notation s. Abb. 5 und Abb. 6) ist dem Konzept einer abstrakten Klasse ähnlich; sie besitzt jedoch keine Attribute, sondern ausschließlich Operationen, die das Verhalten eines Elementes beschreiben. Interfaces können nicht instanziert werden, d.h. es können keine konkreten Objekte angelegt werden. Daher müssen alle Operationen einer Schnittstelle von einer konkreten Klasse implementiert werden, um ein Objekt mit dem beschriebenen Verhalten erzeugen zu können. Seite 7

14 Software-Entwicklung Begriffe und Grundkonzepte Abb. 5: Interface SecureInformation (detaillierte Notation) Abb. 6: Interface SecureInformation (vereinfachte Notation) Beziehungen Die wichtigsten Beziehungen innerhalb eines Klassendiagramms seien anhand eines kleinen Beispiels erläutert (s. Abb. 7). Abb. 7: Beispiel eines UML-Klassendiagramms Abb. 7 zeigt den stark vereinfachten Aufbau eines Unternehmens. Die Klasse Unternehmen ist über eine Aggregation mit der Klasse Abteilungen verknüpft. Das heißt, ein Unternehmen besteht aus mehreren Abteilungen, wobei die Abteilungen auch ohne das Unternehmen existieren können. Wären die Abteilungen vom Unternehmen existenzabhängig, so würde es sich um eine Komposition im Sinne der UML handeln. In diesem Fall wäre für die Notation anzumerken, dass die Raute am Ende der Beziehung ausgefüllt werden müsste. Seite 8

15 Software-Entwicklung Begriffe und Grundkonzepte Die Abteilung ist mit dem Angestellten über eine (binäre) Assoziation verbunden. Eine Assoziation beschreibt die gemeinsame Struktur einer Menge von Beziehungen zwischen Objekten zweier (binäre Assoziation) oder mehrerer Klassen. Sie hat in der Regel einen Namen, im dargelegten Fall ist das works in, d.h. Angestellte arbeiten in Abteilungen. An den Enden der Assoziation können nun Kardinalitäten (synonym auch Multiplizitäten) angegeben werden, welche die Anzahl der an einer Beziehung beteiligten Objekte festlegen. Typische Ausprägungen für Kardinalitäten sind 1 (genau ein Objekt), x..y (mindestens x, maximal y Objekte, z.b ). Ein Stern ( * ) deutet jeweils auf Beliebigkeit hin, was nur alleinstehend (weder Ober- noch Untergrenze), oder als beliebige Obergrenze wie in 1..* Sinn macht. Für obiges Beispiel bedeutet das, dass an einer Beziehung works in mit einer Abteilung mindestens ein Angestellter (1..*) vorkommen muss, umgekehrt es für jeden Angestellten nur eine works in -Beziehung mit einer Abteilung gibt. Umgangssprachlich formuliert: Ein Angestellter arbeitet in genau einer Abteilung, in einer Abteilung arbeitet mindestens ein Angestellter. Optional können an den Enden der Assoziationen auch die Rollen, welche die beteiligten Objekte an der Beziehung spielen, notiert werden. Die Klassen Angestellter und Kunde sind über eine Generalisierung mit der Klasse Person verbunden. Die Generalisierung stellt eine taxonomische Beziehung zwischen einer spezialisierten Klasse (Unter- oder Subklasse) und einer allgemeineren Klasse (Ober-, Basis- oder Superklasse) dar, wobei die Subklasse die Charakteristika der Superklasse erbt und weitere Merkmale hinzufügen kann [Hitz et al. 1999]. In der grafischen Notation zeigt die Generalisierung von der Subklasse über einen Pfeil mit unausgefülltem Dreieck zur Superklasse. Für das Beispiel bedeutet dies, dass sowohl Angestellte als auch Kunden (logischerweise) Personen mit Namen und anderen Eigenschaften sind. Der Kunde erweitert die geerbten Merkmale um eine Kundennummer, der Angestellte um ein Gehalt. Eine Person besitzt spezifische Personaldaten, die über die Operation "GetPersonalData" ermittelt werden können. Daraus resultiert die Abhängigkeitsbeziehung zur Klasse Personaldaten. Sie wird als gestrichelter Pfeil mit offener Spitze dargestellt. Die Klasse Personaldaten realisiert (Realisierungsbeziehung) das Interface SecureInformation, das heißt, dass die Personaldaten eine Operation zur Übertragung der Daten (Operation "Transmit") anbieten. Als alternative Notationsform dieses Beziehungstyps kann ein gestrichelter Pfeil mit geschlossener Spitze verwendet werden UseCase-Diagramme UseCase-Diagramme (deutsch auch Anwendungsfalldiagramme) beschreiben die Kernfunktionalität eines Systems und bestehen aus drei wesentlichen Bestandteilen: UseCases, Akteure (actors) und deren Beziehungen untereinander. Sie bilden einen wesentlichen Teil der Beschreibung der Anforderungen an ein System und sind durch recht einfache Notation sowohl von Entwicklern, als auch von Benutzern inhaltlich zu verstehen und bilden damit eine wichtige Austauschbasis zwischen Entwicklern und Kunden. Die Bestandteile sollen anhand eines kleinen Beispieldiagramms erklärt werden (s. Abb. 8). Seite 9

16 Software-Entwicklung Begriffe und Grundkonzepte System Abb. 8: UseCase-Diagramm Das zu entwickelnde System wird in der grafischen Notation durch ein Rechteck dargestellt, in dem die Anwendungsfälle platziert werden. Die Kanten des Rechtecks zeigen somit die Grenzen des Systems UseCases UseCases beschreiben einen Ausschnitt des Systemverhaltens. Im Beispiel oben beschreibt der UseCase Konto eröffnen jene Aktionen, die nötig sind, um ein neues Konto anzulegen. Im Allgemeinen sollte die Gesamtheit der identifizierten UseCases auch die Gesamtsystemfunktionalität dokumentieren, was sich in der Praxis bei größeren Projekten als sehr schwierig erweisen kann [Hitz et al. 1999]. Zur grafischen Notation von UseCases s. Abb Akteure Abb. 9: UseCase Kundendaten erfassen Die im Diagramm modellierten Akteure legen fest, wer mit dem System interagiert. Sie sind daher per definitionem außerhalb der Systemgrenzen platziert. Durch die Darstellung als Strichmännchen kommt die falsche Vermutung auf, dass Akteure ausschließlich menschlich sind. Es kann sich auch um Seite 10

17 Software-Entwicklung Begriffe und Grundkonzepte externe Systeme handeln, wie z.b. Datenbanken oder Mailsysteme. Menschliche Akteure befinden sich meist in der Benutzerrolle, das heißt, sie initiieren Anwendungsfälle, hingegen werden nicht-menschliche Akteure eher vom System benützt. Im Beispiel ist gut erkennbar, das Kunden und Angestellte das Eröffnen eines Kontos initiieren, die Kunden-Datenbank jedoch benützt wird, um die Kundendaten zu erfassen. Zur grafischen Notation s. Abb Beziehungen Abb. 10: Akteur Benutzer Anwendungsfalldiagramme können vier verschiedene Beziehungstypen beinhalten: Kommunikationsbeziehung (communicates relationship): Diese beschreibt eine Beziehung zwischen genau einem Akteur und genau einem UseCase und ist ungerichtet. Eine Kommunikationsbeziehung besagt entweder, dass der Akteur den UseCase initiiert (Kunde initiiert Kontoinformationen abrufen), oder dass der UseCase externe Akteure benützt (Teilnehmer verständigen benützt -System). Grafische Notation als Linie. Include-Beziehung (include relationship): Die include-beziehung ist gerichtet, verbindet genau zwei UseCases und besagt, dass der inkludierte UseCase in den inkludierenden UseCase eingefügt wird. Der inkludierte UseCase kommt zwingend im Ablauf des inkludierenden UseCases vor (Konto eröffnen inkludiert Kundendaten erfassen). Grafische Notation als Pfeil mit Beschriftung <<include>>. Extend-Beziehung (extend relationship): Die extend-beziehung besitzt eine ähnliche Semantik wie die include-beziehung, die Richtung ist jedoch umgekehrt und die zwingende Einschließung bedeutet hier eine mögliche Erweiterung (Geld abheben erweitert möglicherweise das Abrufen der Kontoinformationen). Grafische Notation als Pfeil mit Beschriftung <<extend>>. Generalisierung (generalization): Die Generalisierungsbeziehung zwischen zwei UseCases definiert, dass der erbende UseCase das gesamte Verhalten des Super-UseCases erbt und gegebenenfalls erweitern und überschreiben kann (Geschäftskonto eröffnen und Privatkonto eröffnen erben von Konto eröffnen). "Generalization between UseCases means that the child is a more specific form of the parent. The child inherits all Features and Associations of the parent, and may add new Features and Associations" [OMG 1999, Kap. 2 S. 120]. Grafische Darstellung erfolgt als Pfeil mit unausgefülltem gleichseitigen Dreieck als Spitze; zeigt vom Sub- zum Super-UseCase. Seite 11

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

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

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

Mehr

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

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

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

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

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

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

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

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

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

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

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

Geschäftsprozessanalyse

Geschäftsprozessanalyse Geschäftsprozessanalyse Prozessmodellierung weitere Begriffe: workflow business process modelling business process (re-)engineering 2 Was ist ein Prozess? Prozesse bestehen aus Aktionen / Ereignissen /

Mehr

Software-Lebenszyklus

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

Mehr

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

Klausurvorbereitung Software Engineering I @ TFH Berlin

Klausurvorbereitung Software Engineering I @ TFH Berlin Teil 1 Einführung in Software Engineering Definition: Was ist Software Engineering? Unter Software Engineering (SE) versteht man den systematischen, disziplinierten und in seiner Größe abschätzbaren Ansatz,

Mehr

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010 Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010 Objektorientierter Softwareentwurf mit UML Grundlagen Neubearbeitung 2010 PGOS2010 I Objektorientierter Softwareentwurf mit UML - Grundlagen

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

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

Dipl. Inf. Ali M. Akbarian

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

Mehr

Software Engineering 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012

Software Engineering 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering 5. UML Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering: 5. UML 2 Unified Modeling Language (UML) Standardisierte grafische Notationen um Strukturen und Abläufe eines

Mehr

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

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

Management von Anforderungen im Rational Unified Process (RUP)

Management von Anforderungen im Rational Unified Process (RUP) Management von Anforderungen im Rational Unified Process (RUP) Peter Fröhlich ABB DECRC 69115 Heidelberg Fröhlich-8/98-1 Themen: Was ist RUP? RM im RUP Core Workflows Dokumente Tools Erfahrungen RUP Objectory

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

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

9 Die Unified Modelling Language UML und der Rational Unified Process RUP / Objectory

9 Die Unified Modelling Language UML und der Rational Unified Process RUP / Objectory In diesem Kapitel: Geschichte von RUP/ROP Inkrementelle und iterative Softwareentwicklung Startphase (inception phase) Entwurfsphase (elaboration) Konstruktionsphase (construction phase) Übergangsphase

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

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

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Zusammenfassung Modul 226

Zusammenfassung Modul 226 JanikvonRotz Zusammenfassung Modul 226 Objektorientiert implementieren Copyright by Janik von Rotz Version: 01.00 Freigabe: 20.05.11 Janik von Rotz Hoheneich 4, 6064 Kerns Internet www.janikvonrotz.ch

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

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

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

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

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

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

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

Projektmanagement: Prozessmodelle

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

Mehr

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

Qualifizierung zum Business Analyst

Qualifizierung zum Business Analyst Qualifizierung zum Business Analyst Brückenbauer für Business- und IT-Organisation Informationsveranstaltung 34. Meeting der Local Group Hamburg Des PMI Frankfurt Chapter e. V. Dr. Bernhard Schröer Partner

Mehr

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

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

Mehr

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems

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

Mehr

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

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Dieses Dokument wurde verfasst von Dr. Jürgen Pitschke, BCS-Dr. Jürgen Pitschke, www.enterprise-design.eu Diese Unterlagen können frei für nicht-kommerzielle

Mehr

5 Methoden und Werkzeuge zur Prozessmodellierung

5 Methoden und Werkzeuge zur Prozessmodellierung 5 Methoden und Werkzeuge zur Prozessmodellierung Geschäftsprozess ftsprozess-management 5.1 Modellierung in ADONIS ADONIS ist ein Geschäftsprozess-Management-Werkzeug der BOC GmbH, Wien Prof. Dr. Knut

Mehr

Web Engineering-Seminar. UML Based Web Engineering (UWE)

Web Engineering-Seminar. UML Based Web Engineering (UWE) Web Engineering-Seminar UML Based Web Engineering (UWE) Christian Schlimbach Stefan Schölzel Trier, 14. Januar 2008 1 Agenda 1. Einleitung 1. Einführung und Motivation 2. Entwicklung des UWE Ansatzes 3.

Mehr

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

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

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

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

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) (Dr. Markus Nüttgens, Dipl.-Hdl. Michael Hoffmann, Dipl.-Inform. Thomas Feld, Institut für Wirtschaftsinformatik (IWi), Universität

Mehr

Inhalt: Version 1.7.5

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

Mehr

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

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

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen

Mehr

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014 Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme 11. November 2014 Überblick Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme

Mehr

Von der Prozessmodellierung zu IT-Landkarten. Prof. Dr.-Ing. Heinz Züllighoven heinz.zuellighoven@c1-wps.de www.c1-wps.de

Von der Prozessmodellierung zu IT-Landkarten. Prof. Dr.-Ing. Heinz Züllighoven heinz.zuellighoven@c1-wps.de www.c1-wps.de Von der Prozessmodellierung zu IT-Landkarten ein integrierter Ansatz in Theorie und Praxis Prof. Dr.-Ing. Heinz Züllighoven heinz.zuellighoven@c1-wps.de www.c1-wps.de Überblick C1 WPS Die Firma Anwendungslandschaften

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

Software-Engineering im Aris-Konzept als Ansatz der Integration der IT-Landschaft von Unternehmen

Software-Engineering im Aris-Konzept als Ansatz der Integration der IT-Landschaft von Unternehmen Software-Engineering im Aris-Konzept als Ansatz der Integration der IT-Landschaft von Unternehmen Martin Plümicke 25. Oktober 2002 1 These: IT im Unternehmen ist mehr als nur die Analyse von Geschäftsprozessen.

Mehr

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf Vorlesung Modelle für Geschäftsprozesse und Services Prof. Dr. Karsten Wolf Was ist ein Geschäftsprozess? Beispiele: Bearbeitung eines Schadensfalls in einer Versicherung Kreditüberprüfung in einer Bank

Mehr

Modellierung von Geschäftsprozessen (MGP / GPM) Thematische Einführung

Modellierung von Geschäftsprozessen (MGP / GPM) Thematische Einführung FHTW Berlin FB4, Wirtschaftsmathematik Modellierung von Geschäftsprozessen (MGP / GPM) Thematische Einführung Dr. Irina Stobbe STeam Service Software Sustainability Organisatorisches Thema - Überblick

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Business Process Model and Notation BPMN

Business Process Model and Notation BPMN Business Process Model and Notation BPMN BPMN ist ein Standard der Object Management Group OMG zur graphischen Notation von Geschäftsprozessen Aktueller Standard: BPMN 2.0 (http://www.omg.org/spec/bpmn/2.0/)

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

Informationsmanagement in Organisationen Überblick

Informationsmanagement in Organisationen Überblick Informationsmanagement in Organisationen Überblick Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft

Mehr

Effektive Architekturdokumentation mit arc42

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

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Bedienung von BlueJ. Klassenanzeige

Bedienung von BlueJ. Klassenanzeige Im Folgenden werden wichtige Funktionen für den Einsatz von BlueJ im Unterricht beschrieben. Hierbei wird auf den Umgang mit Projekten, Klassen und Objekten eingegangen. Abgeschlossen wird dieses Dokument

Mehr

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

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

Mehr

Geschäftsprozessmanagement. Prof. Dr. Knut Hinkelmann

Geschäftsprozessmanagement. Prof. Dr. Knut Hinkelmann Geschäftsprozessmanagement Geschäftsprozesse im Kontext Alter, Steven: Information Systems The Foundation of E-Business, 4. Auflage, Prentice Hall, New Jersey, 2002 2 Drei Gesichtspunkte auf das Unternehmen

Mehr

Software Engineering Klassendiagramme weiterführende Konzepte

Software Engineering Klassendiagramme weiterführende Konzepte Software Engineering Klassendiagramme weiterführende Konzepte Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassenattribut: static Implementierung in Java public

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

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

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

Mehr

Modellierung vonanforderungen

Modellierung vonanforderungen Modellierung vonanforderungen Dehla Sokenou GEBIT Solutions Koenigsallee 75b 14193 Berlin www.gebit.de dehla.sokenou (at) gebit.de Abstract: In der betrieblichen Anwendungsentwicklung werden in vielen

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL INGTES AG Bahnhofstr. 94 CH 5000 Aarau Tel. +4162 836 30 70 www.ingtes.com PRODUKTENTWICKLUNG NACH DEM INGTES-PROZESSMODELL 2 1 PRODUKT- ENTWICKLUNG Bei

Mehr

Softwareentwurf für Technische Systeme Kapitel 6: Erfassen und Pflege von Anforderungen

Softwareentwurf für Technische Systeme Kapitel 6: Erfassen und Pflege von Anforderungen : Softwareentwurf für Technische Systeme Kapitel 6: Erfassen und Pflege von Anforderungen Alexey Cheptsov : Kapitel 6: Anforderungsanalyse 6.1 Das Beispiel 6.2 Problembeschreibung & Risikoanalyse 6.3 Namensanalyse

Mehr

Geschäftsprozessmanagement

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

Mehr

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

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

Analyse und Entwurf objektorientierter Systeme

Analyse und Entwurf objektorientierter Systeme Analyse und Entwurf objektorientierter Systeme Teil 3 Modellbildung in der Analysephase 3.1 Statische und dynamische Notationselemente Modul WI111: Objektorientierte Programmierung Fachrichtung Wirtschaftsinformatik

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

1 Objektorientierte Software-Entwicklung

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

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

objectif / SOA /.NET Inhalt Technologien ObjectiF Beispiel Vergleich: ObjectiF Rational Rose Quellenverzeichnis 20.01.2008 Christian Reichardt 2 Technologien 20.01.2008 Christian Reichardt 3 Methodenaufruf

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Geschäftsprozesse modellieren mit Innovator Business

Geschäftsprozesse modellieren mit Innovator Business Geschäftsprozesse modellieren mit Innovator Business I N H A L T 1. Motivation und Begriffsklärung 2. Kurzeinführung in die Geschäftsprozessmodellierung 3. Anwendungsszenarien der GPM 2 Was Geschäftsprozessmodellierung

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Aufgabe 3. Assoziation

Mehr