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

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

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

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

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

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

Einführung in die Wirtschaftsinformatik VO WS 2006/2007

Einführung in die Wirtschaftsinformatik VO WS 2006/2007 Einführung in die Wirtschaftsinformatik VO WS 2006/2007 Geschäftsprozessmodellierung o. Univ. Prof. Dr. Dimitris Karagiannis Inhaltsübersicht Grundlagen zur Geschäftsprozessmodellierung Definition Geschäftsprozess

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

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

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

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

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

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

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

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

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

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

Informationssystemanalyse Use Cases 11 1

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

Mehr

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

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

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

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

Objektorientierte Geschäftsprozessmodellierung mit der UML

Objektorientierte Geschäftsprozessmodellierung mit der UML Bernd bestereich Christian Weiss Claudia Schröder Tim Weilkiens Alexander Lenhard 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE43 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 3: Der Systemanalysestandard UML FH Wedel Prof. Dr. Sebastian Iwanowski

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

Oracle JDeveloper 10 g

Oracle JDeveloper 10 g Oracle JDeveloper 10 g Modellierung Evgenia Rosa Business Unit Application Server ORACLE Deutschland GmbH Agenda Warum Modellierung? UML Modellierung Anwendungsfall (Use Case)-Modellierung Aktivitätenmodellierung

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

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

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0 Für den Einsatz in der Praxis Seite 2 Überblick 1. Ziele 2. Warum das alles? 3. Was ist UML 4. Diagrammarten 5. Umfeld Seite 3 1. Ziele 1. Ziele dieses

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

Ministerium für Kultus, Jugend und Sport Baden-Württemberg

Ministerium für Kultus, Jugend und Sport Baden-Württemberg Anlage zu 45-6512-2420/31 Ministerium für Kultus, Jugend und Sport Baden-Württemberg Schulversuch 51-6624.20/100 (früher: /84) vom 26. August 2003 Lehrpläne für das berufliche Gymnasium der sechs- und

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

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

Mehr

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

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

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

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

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

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

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

Ü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

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

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

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

Software Engineering in der Praxis Praktische Übungen

Software Engineering in der Praxis Praktische Übungen Software Engineering in der Praxis Praktische Übungen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 1 / 14 1 Inhalt 2 Überblick 3 Werkzeuge 4 Aufgaben Pinte, Spisländer FAU Erlangen-Nürnberg

Mehr

Software- und Systementwicklung

Software- und Systementwicklung Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm

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

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG Produkt und Methode SIRIUSlogic 4.0 in der Praxis SIRIUS Consulting & Training AG www.sirius-consult.com SIRIUSlogic 4.0 Warum ein weiteres Prozessmanagement Werkzeug? Motivation Was muß das Tool leisten

Mehr

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes Dozent: G.Döben-Henisch (Version vom 16.April 2005) PPmP VL2 VL2: Softwareprojekt - Anforderungsanalyse Inhalt 1. Struktur eines Softwareprojektes 2. Anforderungsanalyse 1. Struktur eines Softwareprojektes

Mehr

Vorlesung "Software-Engineering"

Vorlesung Software-Engineering Vorlesung "Software-Engineering" Rainer Marrone, TUHH, Arbeitsbereich STS Vorige Vorlesung Pflichtenheft (requirements specification document) Charakterisierung von Software-Qualität Detaillierte Anforderungsanalyse

Mehr

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla BlaBla Diese Kennzeichnungen sind nur Erläuterungen und nicht Bestandteil des Diagramms Quelle: P.Grässle, H.Baumann, P.Baumann, UML projektorientiert, Galileo Verlag, 2003 21 Primäre Begriffe Kapselung

Mehr

Programmieren in Java

Programmieren in Java FG TECHNISCHE INFORMATIK V JV A00 00 TH 0 Programmieren in Java Anhang A A. Modellierung von OOP-Programmen A.. Klassenkategorien A.2. Klassembeziehungen A.3. Klassendiagramm und Sequenzdiagramm der UML

Mehr

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung ZENITY - Die Software für Ihre Unternehmens-Releaseplanung RELEASEPLANUNG HEUTE Heutige Anwendungen in in Grossunternehmen sind sind keine keine alleinstehenden alleinstehenden Insel-Applikationen Insel-Applikationen

Mehr

Fragenkatalog Geschäftsmodellierung Grundlagen

Fragenkatalog Geschäftsmodellierung Grundlagen Fragenkatalog Geschäftsmodellierung Grundlagen 1. Erläutern Sie den Begriff der Geschäftsmodellierung - Erfassung und Spezifikation von Geschäftsprozessen für die Analyse und Gestaltung betrieblicher Systeme

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

Übersicht der UML Diagramme

Übersicht der UML Diagramme Dieser Fachbeitrag ist ein Service der InfraSoft Profis für Ihre professionelle Softwareentwicklung. Übersicht der UML Diagramme Die Unified Modeling Language (UML) ist eine Sprache zur Beschreibung von

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

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

Mehr

Techniken der Projektentwicklung

Techniken der Projektentwicklung diagramme Termin 6 Denken in Schnittstellen Was nun? Einführung Bisher kennengelernt: Modellierung auf Konzeptlevel Usecase-Diagramme Domänenmodelle Jetzt: Übergang zu Spezifikation und Implementierung!

Mehr

Darstellung von Assoziationen

Darstellung von Assoziationen Darstellung von Assoziationen Wie bereit aus Kapitel 1 bekannt, beschreiben Assoziationen Beziehungen zwischen Objekten, die zwischen Klassen modelliert werden. Zunächst soll die Modellierung binärer Assoziationen

Mehr

UML - Tutorial. Hubert Baumgartner. www.inso.tuwien.ac.at

UML - Tutorial. Hubert Baumgartner. www.inso.tuwien.ac.at UML Tutorial UML - Tutorial SS 06 Hubert Baumgartner www.inso.tuwien.ac.at INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt

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

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

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

Mehr

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

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

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

Folien zum Textbuch. Kapitel 2: Planung, Entwicklung und Betrieb von IS. Teil 4: Modellierung von betrieblichen Informationssystemen

Folien zum Textbuch. Kapitel 2: Planung, Entwicklung und Betrieb von IS. Teil 4: Modellierung von betrieblichen Informationssystemen Folien zum Textbuch Kapitel 2: Planung, Entwicklung und Betrieb von IS Teil 4: Modellierung von betrieblichen Informationssystemen Textbuch-Seiten 209-245 WI Planung, Entwicklung und Betrieb von IS IS-Modellierung

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

Methodische objektorientierte Softwareentwicklung

Methodische objektorientierte Softwareentwicklung Methodische objektorientierte Softwareentwicklung Eine Integration klassischer und moderner Entwicklungskonzepte von Mario Winter 1. Auflage Methodische objektorientierte Softwareentwicklung Winter schnell

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

Reference Migration Process ReMiP

Reference Migration Process ReMiP Reference Migration Process ReMiP Ein Referenz-Prozess der Software-Migration 1 Übersicht Motivation º Gründe für Migrationen º Notwendigkeit eines generischen Referenz-Prozesses Herleitung des Referenzprozesses

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

Software Engineering in der Praxis

Software Engineering in der Praxis Inhalt Nachlese Aufgaben Literatur Software Engineering in der Praxis Praktische Übungen Inhalt Nachlese Aufgaben Literatur Marc Spisländer Dirk Wischermann Lehrstuhl für Software Engineering Friedrich-Alexander-Universität

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

Konzeption eines Vorgehensmodells für die Analyse zur Geschäftsprozessmodellierung und den Einsatz von Workflows im mittelständischen Unternehmen

Konzeption eines Vorgehensmodells für die Analyse zur Geschäftsprozessmodellierung und den Einsatz von Workflows im mittelständischen Unternehmen Torsten Neumann Konzeption eines Vorgehensmodells für die Analyse zur Geschäftsprozessmodellierung und den Einsatz von Workflows im mittelständischen Unternehmen Die 1. Phase zur Softwareentwicklung -

Mehr

Ostfalia Hochschule für angewandte Wissenschaften Fakultät Elektrotechnik

Ostfalia Hochschule für angewandte Wissenschaften Fakultät Elektrotechnik Ostfalia Hochschule für angewandte Wissenschaften Fakultät Elektrotechnik Prof. Dr.-Ing. D. Meyer Software Engineering SS 2013 Bearbeitungszeit Kurzfragenteil: 30 Minuten Hilfsmittel: keine Name Vorname

Mehr

Anforderungen und Auswahlkriterien für Projektmanagement-Software

Anforderungen und Auswahlkriterien für Projektmanagement-Software Anforderungen und Auswahlkriterien für Projektmanagement-Software Anika Gobert 1,Patrick Keil 2,Veronika Langlotz 1 1 Projektmanagement Payment Giesecke &Devrient GmbH Prinzregentenstr. 159, Postfach 800729,

Mehr

Software Engineering Analyse und Analysemuster

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

Mehr

Geschäftsabläufe und Beziehungen zwischen. (Mitarbeitende / Geschäftsobjekte)

Geschäftsabläufe und Beziehungen zwischen. (Mitarbeitende / Geschäftsobjekte) BusinessModel Geschäftsabläufe und Beziehungen zwischen Mitarbeitenden und Geschäftsobjekten: Arbeitsabläufe, Mitarbeitende, Hilfsmittel und Organisationsstruktur. Was läuft manuell, was IT-gestützt, wer

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

Vgl. Oestereich Kap 2.7 Seiten 134-147

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

Mehr

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

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Meitner, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 16 Objektorientiertes Design Matthias Meitner Marc Spisländer Lehrstuhl für

Mehr

Optimale Integration der IT-Security in Geschäftsprozesse

Optimale Integration der IT-Security in Geschäftsprozesse Optimale Integration der IT-Security in Geschäftsprozesse A Min TJOA Edgar WEIPPL {Tjoa Weippl}@ifs.tuwien.ac.at Übersicht Einleitung ROPE (S. Tjoa, S. Jakoubi) MOS³T (T. Neubauer) Security Ontologies

Mehr

Softwarearchitekturen I Softwareentwicklung mit Komponenten

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

Mehr

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

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

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

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

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

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

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

Software Engineering. 3. Analyse und Anforderungsmanagement

Software Engineering. 3. Analyse und Anforderungsmanagement Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz

Mehr

Entwicklung und Dokumentation eines Klausurorganisationssystems mit Microsoft Access

Entwicklung und Dokumentation eines Klausurorganisationssystems mit Microsoft Access Informatik Werner Schehler Entwicklung und Dokumentation eines Klausurorganisationssystems mit Microsoft Access Diplomarbeit FACHHOCHSCHULE DORTMUND FACHBEREICH WIRTSCHAFT Studiengang Wirtschaft ENTWICKLUNG

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

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

Der Rational Unified Process

Der Rational Unified Process Philippe Kruchten Der Rational Unified Process Eine Einführung Deutsche Übersetzung von Cornelia Versteegen An imprint of Pearson Education München Reading, Massachusetts Menlo Park, California New York

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

Systemdenken und Gestaltungsmethodik System-Modellierung

Systemdenken und Gestaltungsmethodik System-Modellierung Systemdenken und Gestaltungsmethodik System-Modellierung Prof. Dr.-Ing. Stefan Brunthaler TFH Wildau 2008ff Master Telematik Ausgangsbasis Es liegt ein kosten-nutzen-optimales Lösungskonzept vor. Die Architektur

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

Innovator 11 classix. Java Reverse Engineering. HowTo. Ralph Schönleber. www.mid.de

Innovator 11 classix. Java Reverse Engineering. HowTo. Ralph Schönleber. www.mid.de Innovator 11 classix Java Reverse Engineering Ralph Schönleber HowTo www.mid.de Mit Innovator Java Reverse Engineering durchführen Inhaltsverzeichnis Voraussetzungen... 2 Java Reverse Engineering... 2

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