Softwarepraktikum WS04/05. Organisatorisches VERANSTALTER ABLAUF

Größe: px
Ab Seite anzeigen:

Download "Softwarepraktikum WS04/05. Organisatorisches VERANSTALTER ABLAUF"

Transkript

1 Softwarepraktikum WS04/05 Organisatorisches Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 1 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 2 VERANSTALTER ABLAUF Vorlesung: Thomas Santen Betreuung der praktischen Arbeiten: Es ist eine Softwareentwicklungsaufgabe von der Analyse bis zur Implementierung vollständig durchzuführen. Die Vorgehensweise ist objektorientiert. Frank Glinka Björn Kemper Martin Pyka Maraike Schellmann Suleyman Isik Andreas Gössling Jan Metzen Carsten Rhauderwieck Dominik Ullrich Es ist in Gruppen von ca. 10 Personen zu arbeiten. Bei der Implementierung müssen innerhalb der Gruppen jeweils zwei Personen zusammen arbeiten. Es besteht Anwesenheitspflicht. Die Ergebnisse werden individuell (d.h. für jede/n Teilnehmer/in gesondert) benotet. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 3 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 4

2 ABLAUF 1. Woche: Objektorientierte Analyse 2. Woche: Objektorientierter Entwurf 3. Woche: Objektorientierte Implementierung 4. Woche: Vorführung, Benotung Anfang der Woche Vorlesung (Montag Nachmittag, Dienstag), danach Durchführung des Gelernten Es werden Richtwerte angegeben, wann welche Zwischenergebnisse fertig sein sollten. Es werden je ca. drei Gruppen von zwei Betreuern betreut. Die Ergebnisse einer Woche müssen am Montag Vormittag der darauffolgenden Woche den Betreuern abgegeben (sowohl elektronisch als auch ausgedruckt) und erläutert werden. ABLAUF Die Benutzung eigener Rechner und Drucker ist willkommen. Funk-LAN-Karten können (in begrenzter Zahl) zur Verfügung gestellt werden. Gruppen, die nicht an dem ihnen zugewiesen Ort arbeiten, müssen an einem Aushang vor Raum 716 bekannt geben, wo sie zu finden sind. Alle das Praktikum betreffenden aktuellen Informationen werden im Internet bekanntgegeben, also regelmäßig reinschauen. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 5 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 6 Softwarekonstruktion Programmieren! Das Bisschen Programmieren können wir doch alleine Warum Softwaretechnik? Softwaretechnik (Balzert): Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. Zielorientiert bedeutet die Berücksichtigung z.b. von Kosten, Zeit, Qualität. Softwaresystem System, dessen Systemkomponenten und Systemelemente aus Software bestehen. Software: Programm + Dokumentation Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 7 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 8

3 WARUM REICHEN PROGRAMMIERKENNTNISSEALLEIN NICHT AUS? (Praktisch) alle Software enthält Fehler. Dies führt zu immensen volkswirtschaftlichen Verlusten und zur Gefährdung von Menschenleben. Bridges are normally built on-time, on-budget, and do not fall down. On the other hand, software never comes in on-time or on-budget. In addition, it always breaks down. Alfred Spector Warum ist das so? Welches sind neue, vielversprechende Entwicklungen? Software and cathedrals are much the same: first we build them, then we pray. Sam Redwine Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 9 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 10 STUDIE DER STANDISH-GROUP, 1995 (1998) STUDIE DES RESEARCH TRIANGLE INSTITUTE research Untersuchung von 8380 Projekten in 365 Firmen. Ergebnis: 16,2 % (26 %) erfolgreiche Projekte keine Kosten- u. Zeitüberschreitung, keine Abstriche an der Funktionalität 52,7 % (46 %) gefährdete Projekte durchschnittliche Kostenüberschreitung 89 % 31,1 % (28 %) abgebrochene Projekte Geschätzte Kosten für abgebrochene Projekte in den USA pro Jahr: 81 (75) Mrd. Dollar... im Auftrag des National Institute of Standards and Technology, Mai Transportausrüstungssektor: Benutzer finden jedes Jahr durchschnittlich 40 schwere und 70 leichte Fehler Finanzsektor: Benutzer finden jedes Jahr durchschnittlich 40 schwere und 49 leichte Fehler geschätzte, hochgerechnete Kosten für US-Wirtschaft pro Jahr: 59,9 Mrd. Dollar Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 11 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 12

4 SPEKTAKULÄRE FEHLSCHLÄGE Bestrahlungsgerät Therac-25 Tote und Verletzte durch Überdosis radioaktiver Strahlung Software developers already spend approximately 80 percent of development costs on identifying and correcting defects, yet few products of any type other than software are shipped with such high levels of errors. If Mircrosoft made cars instead of computer programs, product-liability-suits might now have driven them out of business. Absturz der Ariane-5-Rakete Schaden: 500 Millionen Dollar Gepäcktransportsystem des neuen Flughafens in Denver Kosten: $1,1 Mio pro Tag Weitere Beispiele fast jeden Monat in der Zeitung! Genauere Informationen: Peter Neumann: Computer-Related Risks, ACM Press 1995 News-Gruppe comp.risks Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 13 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 14 WARUM KANN MAN SOFTWARE NICHT GENAUSO BAUEN WIE AUTOS ODER HÄUSER? FAZIT Software ist etwas Besonderes, weil sie immateriell ist nicht durch Gebrauch verschleißt, sondern durch Änderung und Nicht-Änderung altert nicht durch physikalische Gesetze begrenzt ist leicht änderbar ist schwer zu vermessen, d.h. quantitativ zu erfassen ist kein kontinuierliches, sondern diskretes Verhalten zeigt (keine Sicherheitsmargen möglich, kleine Ursachen können große Folgen haben) Die Informatik (und damit die Softwaretechnik) ist eine sehr junge Wissenschaft. Softwareentwicklung ist nur zu einem geringen Teil Programmierung. Wegen der Besonderheit von Software sind eigene ingenieurmäßige Methoden nötig, aber noch nicht zur vollen Reife entwickelt. Es ist ein wichtiges Ziel, Software mit weniger Fehlern zu entwickeln. Hierzu gibt es vielversprechende und spannende neue Ansätze. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 15 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 16

5 DAS WASSERFALLMODELL Vorgehensmodelle Idee: jede Phase ergibt Dokument, das als Ausgangspunkt für die nächste Phase dient. Keine Rückkehr zu früheren Phasen. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 17 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 18 Die Realität sieht eher so aus: Alternativen zum Wasserfallmodell Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 19 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 20

6 DAS V-MODELL DAS PROTOTYP-MODELL Deutsche Entwicklung. Setzt Validierungs- und Entwicklungsphasen explizit in Beziehung. Gut für Systeme, deren Anforderungen nicht von Anfang an klar sind. Kann aber zu schlecht strukturierten Systemen führen. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 21 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 22 DAS TRANSFORMATIONSMODELL DAS SPIRALMODELL Ist im Prinzip eine gute Idee, die praktische Durchführung der Transformationen ist jedoch ein Problem. Inkrementelle Entwicklung, risikogesteuert. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 23 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 24

7 BEOBACHTUNG Alle Vorgehensmodelle beinhalten im Wesentlichen dieselben Phasen, die aber jeweils anders organisiert sind. Anforderungsdefinition: beschreibt, was das System tun soll. Erarbeitung derselben durch Analyse. Entwurf: definiert Architektur des Systems. Repräsentation der Systemfunktionen so, dass sie in Programme überführt werden können. Einführung in die Objektorientierung Implementierung: realisiert Entwurf durch Programmeinheiten. Validierung besteht i.a. aus Tests und Reviews, aber auch Beweise möglich. Betrieb und Wartung: Ausbau von Fehlern, Verbesserung der Funktionalität. Programmieren ist nur eine von vielen Phasen/Tätigkeiten! Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 25 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 26 OBJEKTORIENTIERUNG BEISPIEL: MÖBELSTÜCKE relativ junges Paradigma der Softwareentwicklung vorher: Funktionsorientierung Möbelstücke werden in Teile zerlegt geliefert. Für jedes Möbelstück gibt es eine Aufbauanleitung. OO funktionsorientiert OO funktionsorientiert System: dynamische Ansammlung kommunizierender Objekte Objekte haben eigenen Zustand Architektur an Daten ausgerichtet Kommunikation über Nachrichten zwischen Objekten Aktion nur mögl., wenn Objekt sie anbietet System: statische Ansammlung von Prozeduren gemeinsamer Zustand Arch. an Aktionen ausgerichtet Kommunikation über Prozeduraufruf jedes Möbelstück speichert selbst die Informationen über sich zentrale Datenbank, in der alle Daten sämtlicher Möbelstücke gespeichert sind, z.b. Größe, Farbe, Preis, Bestandteile Beschaffen von Informationen über Möbelstücke entspricht Anfrage an Datenbank Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 28

8 WARUM OBJEKTORIENTIERUNG? OO die für ein Möbelstück/Objekt relevanten Prozeduren werden als Operationen zur Verfügung gestellt, z.b. schrank.baue auf, tisch.zeige abmessungen funktionsorientiert gibt Prozeduren, die Aktivitäten steuern, z.b. baue auf(möbel), zeige abmessungen(möbel) Problem: nicht jede Prozedur muss für jedes Möbelstück sinnvoll sein bessere Beherrschung der Komplexität von Softwaresystemen Erhöhung der Wiederverwendbarkeit von Software, da Datenkapselungen erfahrungsgemäß weniger anfällig gegenüber Änderungen ihrer Umgebung sind als funktionsorientierte Zerlegungen. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 29 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 30 WICHTIGE KONZEPTE ZUR BEWÄLTIGUNG VON KOMPLEXITÄT WICHTIGE HIERARCHIEN Hierarchie Zerlegung Abstraktion ist eine Art von wird im OO-Ansatz als Generalisierung/Spezialisierung modelliert ist Teil von wird im OO-Ansatz als Aggregation modelliert Diese Konzepte finden sich alle im objektorientierten Ansatz wieder. Generalisierung/Spezialisierung bezieht sich auf die Klassenstruktur, Aggregation auf die Objektstruktur. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 31 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 32

9 OBJEKT Abstraktion eines realen Dinges, Konzeptes oder Sachverhaltes hat lokalen Zustand in Form von Attributen. Dies sind assoziierte Werte, die aus festgelegten Trägermengen (Typen) kommen. Grundbegriffe der Objektorientierung besitzt eine eindeutige Identität, d.h. Objekte, die dieselben Attributwerte haben, sind nicht unbedingt gleich. hat Verhalten in Form von Operationen gehört i.a. zu einer Klasse UML-Notation: Jan : Customer Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 33 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 34 KLASSE NACHRICHT Abstraktion einer Menge gleichartiger Objekte Schablone für Objekte (Instanzen) definiert Operationen und Attribute ihrer Objekte entspricht einem Typ Mittel zur Interaktion von Objekten besteht aus Operationsaufruf mit Parametern Client sendet Nachricht an Server UML-Notation: Customer Klassenname Server führt entsprechende Operation aus, ändert evtl. seinen Zustand und gibt Ergebnis zurück name address phone Attribute Objekte können mit sich selbst interagieren, d.h. eigene Operationen aufrufen change_address Operationen Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 35 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 36

10 GENERALISIERUNG/SPEZIALISIERUNG Hierarchie ist eine Art von UML-Notation: erlaubt Definition von Unterklassen Unterklassen erben Attribute und Operationen der Oberklassen Unterklassen können neue Attribute und Operationen hinzufügen und Shape origin move resize display Bediensteter gehalt Student matr.nr. vorhandene Operationen verändern wird programmiersprachlich realisiert durch Vererbung Rectangle Circle Polygon Tutor einfach- oder mehrfache Generalisierung/Spezialisierung möglich corner: Point radius: Float points: List Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 37 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 38 POLYMORPHIE ASSOZIATION Strukturelle Beziehung zwischen Objekten Ein Objekt einer Unterklasse kann auch als ein Objekt jeder seiner Oberklassen angesehen werden. UML-Notation: Beispielsweise kann jedes Rechteck auch als eine Gestalt angesehen werden und über die Schnittstelle der Klasse Shape angesprochen werden, also z.b. mit der Operation move verschoben werden. Person Works for Company Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 39 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 40

11 AGGREGATION KOMPOSITION Hierarchie ist Teil von Spezialfall der Assoziation UML-Notation: Company 1 Spezialfall der Aggregation Lebensdauer des Teiles ist an Lebensdauer des Ganzen gebunden Teil kann nur zu einem Ganzen gehören UML-Notation: Company * Department * Department Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 41 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 42 DIE FUSION-METHODE entwickelt bei Hewlett-Packard bietet nicht nur Notationen, sondern gibt methodische Anleitung Die Fusion-Methode unter Verwendung von UML werden eine Reihe von Modellen aufgestellt wir betrachten die Phasen OOA und OOD Voraussetzung: Ergebnis einer informellen Anforderungsermittlung liegt vor Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 43 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 44

12 ANALYSE Ziel: Erfassung und Beschreibung des äußeren Verhaltens des Systems innerhalb des Anwendungskontextes Realisierungsüberlegungen stehen nicht im Vordergrund Analysemodelle: Überblick Klassenmodell: bildet Anwendungskontext ab Beziehungen zwischen Klassen Systemoperationen zugelassene Reihenfolgen der Systemoperationen Merke: In der Fusion-Analysephase haben die Klassen (noch) keine Operationen! Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 45 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 46 ENTWURF, IMPLEMENTIERUNG Entwurf: Ziel: abstraktes Implementierungskonzept Systemoperationen werden auf das Laufzeitverhalten interagierender Objekte abgebildet Implementierung: überführt Entwurfsmodelle in ausführbaren Code Der Analyseprozess nach Fusion Systemklassenmodell Klassen der Programmiersprache Objektinteraktionen Methodenaufrufe zugelassene Reihenfolgen Kontrollstrukturen Parallel dazu: Datenlexikon, Konsistenzprüfungen Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 47 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 48

13 Ausgangspunkt: Beschreibung der Gegebenheiten und Anforderungen in natürlichsprachlicher Form mehrere Schritte, in denen jeweils ein Modell entwickelt wird. 1. Klassenmodell beschreibt Objekte und Konzepte des Problemumfeldes 2. Use-Case-Modell Funktionsgruppen des Systems 3. Szenarien Verfeinerung des Use-Case-Modells Identifikation von Systemoperationen 5. Systemklassenmodell Grenze zwischen System und Umgebung Verfeinerung des Klassenmodells 6. Lifecycle-Modell globales Systemverhalten Verhalten von Objekten 4. Operationsmodell Spezifikation der Systemoperationen als Relationen zwischen Vorher- und Nachherzuständen Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 49 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 50 DATENLEXIKON statische Aspekte des Systems: Klassenmodell Enthält alle verwendeten Namen; Organisation als Tabelle: dynamische Aspekte des Systems: Schnittstellenmodell Dieses besteht aus Use Cases Szenarien Operationsmodell Lifecycle-Modell Name Art Beschreibung Quelle Name des Klasse, Systemoperation, kurze informelle alle Modelle, in de- Elementes Attri- Beschreibung nen der Name vor- but, etc. kommt Muss während des gesamten Entwicklungsprozesses gepflegt werden! Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 51 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 52

14 BEISPIEL Name Art Beschreibung Quelle Bank Klasse Eine Bank besteht aus einer Menge von Konten Klassenmodell, Systemklassenmodell konto eröffnen Systemoperation Ein Kunde eröffnet Konto bei einer Bank ein Szenario, Operationsmodell Das Klassenmodell Konto.nummer Attribut eindeutige Kontonummer Klassenmodell eines Kontos Transaktion Ablauf- Eine Transaktion ist ent- Lifecycle- ausdruck weder eine Einzahlung, Modell eine Auszahlung oder eine Kontostandsabfrage Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 54 Software-Praktikum, MODELLIERUNG WS 2004/2005 DER STATISCHEN ASPEKTE DES ANWENDUNGSKONTEXTES T. Santen, WWU Münster 53 ASSOZIATIONEN Verschiedene Darstellungsmöglichkeiten für Klassen: denotieren Beziehungen zwischen Objekten oder oder Class Class Class a1: T1 a2 : T2 a1: T1 a2 : T2 werdem als Links notiert können mehr als zweistellig sein op1(p: T1) : T2 können Namen haben (per Konvention groß geschrieben) können Multiplizitäten haben In der Fusion-Analysephase haben Klassen nur einfache Attribute (d.h. keine können Rollennamen haben Klassenattribute) und keine Operationen! Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 55 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 56

15 BEISPIEL BEDEUTUNG DES KLASSENDIAGRAMMS Jedes Institut hat genau einen Professor, der es leitet. Professor name fachgebiet 0..2 veranstalter Hält Assoziationsname 1 Leitet 0..1 Institut name direktor Rolle Multiplizität Leserichtung Dieser heisst Direktor. Ein Professor leitet höchstens ein Institut. Ein Professor kann Vorlesungen halten, muss es aber nicht. Jede Vorlesung wird von höchstens 2 Professoren gehalten (es können auch 0 sein). Vorlesung titel * 4..6 Belegt 3..* teilnehmer Student name matrikelnr. Ein Student belegt zwischen 4 und 6 Vorlesungen. Bei diesen ist er Teilnehmer. Eine Vorlesung muss von mindestens 3 Studenten belegt werden. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 57 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 58 MEHRSTELLIGE ASSOZIATIONEN ROLLENNAMEN werden an die Enden der Assoziation geschrieben Assoziationen können auch zwischen mehr als zwei Klassen bestehen. Namen werden per Konvention klein geschrieben Student Schreibt Klausur Person 1..* kind elternteil 2 Raum Ist_Kind_von Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 59 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 60

16 gibt es m Objekte der Klasse Class MULTIPLIZITÄTEN ASSOZIATIONSKLASSEN Drücken Kardinalitätseinschränkungen von Relationen aus Für jedes Objekt der Klasse Class, Auch Assoziationen können Attribute haben. die mit ihm in Relation Rel stehen. Sinnvoll, wenn die Eigenschaften keiner der an der Assoziation beteiligten Class1 m Rel Class2 Klassen zugeordnet werden können. Notation: Student Schreibt Klausur Zahl n: genau n Objekte Bereich i j * : beliebig viele, auch 0 i : mindestens i j: höchstens j keine Angabe: bedeutet * : alle Anzahlen bis auf 2 und 5 Schreibt note Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 61 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 62 AGGREGATION UND KOMPOSITION sind spezielle Assoziationen GENERALISIERUNG/SPEZIALISIERUNG Klassen entsprechen Typen Zimmer Die Wand ist Teil des Zimmers Unterklassen entsprechen Untertypen, aber nicht Untermengen Spezialisierung ist ein, sondern verhält sich wie, ist eine Art von Wand Person PersonOID name adresse Wenn der Teil nur zu einem Ganzen gehört und nur mit diesem existieren kann, dann liegt eine Kompositionsbeziehung vor. 11 Meier Münster 22 Schulze Berlin Window oder Window Frame Kunde PersonOID funktion umsatz 11 Entwickler 500 Dozent PersonOID honorar Frame Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 63 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 64

17 CONSTRAINTS STRUKTURIERUNG VON KLASSENMODELLEN sind Bedingungen, die gelten müssn werden in geschrieben im Beispiel: bedeutet, dass es keine weiteren Unterklassen complete von Vorlesung geben kann. Bedeutung muss informell angegeben werden. Das Klassenmodell muss i.a. in verschiedene Diagramme unterteilt werden. Dabei gilt: Modellierungselemente mit demselben Namen bedeuten dasselbe Element. Gesamtheit der Attribute eines Elementes ist die Vereinigung der Attribute aller Darstellungen des Elementes. Multiplizitäten werden konjunktiv verknüpft, d.h. und ergibt. Rollennamen müssen eindeutig sein. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 65 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 66 BEISPIEL: DIAGNOSEKLINIK BEISPIEL: DIAGNOSEKLINIK 2. Ein aufgenommener Patient wird von einem Spezialisten untersucht. Niedergelassene Ärzte überweisen ihre Patienten mittels eines Überweisungsscheines an Kliniken, die die Erstellung von detailierten Diagnosen übernehmen. Die aufgenommenen Patienten verschiedenen Tests unterzogen, aber nicht behandelt. 1. Bevor Untersuchungen und Tests durchgeführt werden, müssen die Patienten zunächst in die Klinik aufgenommen werden. Falls ein Patient noch nie in der Klinik war, muss eine neue Akte angelegt werden. Andernfalls wird die alte Akte aktiviert. In jedem Fall wird jedoch ein neuer Vorgang angelegt, in dem alle Unterlagen gesammelt werden, die mit einem Klinikaufenthalt des Patienten zusammenhängen. 3. Dieser Arzt schreibt einen Untersuchungsbericht. Darin wird festgelegt, welche Tests an dem Patienten durchgeführt werden sollen. 4. Mögliche Tests sind Blutuntersuchung, Röntgen und EKG. 5. Tests werden vom Pflegepersonal durchgeführt. 6. Wenn der Patient bereits vor kürzerer Zeit schon einmal geröntgt wurde, werden die alten Ergebnisse weiterverwendet. 7. Für jeden durchgeführten Test werden die Ergebnisse in einen Testbericht eingetragen. 8. Wenn alle Tests durchgeführt worden sind, erstellt der Spezialist eine Diagnose. 9. Danach wird der Patient entlassen. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 67 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 68

18 BEISPIEL: DIAGNOSEKLINIK KLASSENMODELL FÜR DIE DIAGNOSEKLINIK Gehört_zu Niedergelassener_Arzt Ist_abfrageberechtigt Personal Überweist Patient Klinik Pflegepersonal Spezialist 10. Niedergelassene Ärzte können Anfragen an die Diagnoseklinik stellen, sofern sie zuvor eine Berechtigung hierzu erworben haben. Untersucht Überweisungsschein 1 Akte Führt Arzt 11. Sie können entweder die Gesamtdiagnose oder einzelne Testergebnisse Erstellt Vorgang des von ihnen überwiesenen Patienten abfragen. Spezialist Diagnose 0..1 Hausarzt Spezialist Führt_durch Schreibt Untersuchungsbericht Testbericht Test Legt_Fest Pflegepersonal Test Ergibt Testergebnis Röntgen EKG Blutunters. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 69 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 70 OBJEKTORIENTIERTE ANALYSE Klassenmodell statische Aspekte Schnittstellenmodell dynamische Aspekte Use-Case-Modell Szenarien Das Use-Case-Modell Operationsmodell Systemklassenmodell Lifecycle-Modell Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 71 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 72

19 VORGEHEN AKTEURE stehen außerhalb des Systems grobe Sichtweise auf das System Identifikation von Funktionsgruppen Identifiziere Akteure (Actors) Identifiziere Use Cases repräsentieren verschiedene Benutzerrollen können sowohl Menschen als auch andere Systeme sein sollen im Klassenmodell vorkommen entsprechende Klassen werden nicht implementiert Notation: Identifiziere Assoziationen zwischen Akteuren und Use Cases Bankangestellter Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 73 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 74 USE CASES BESCHREIBUNG VON AKTIONSFOLGEN sind Mengen von Aktionsfolgen müssen einen Namen haben beschreiben die Interaktion von Akteuren mit dem System Kriterium: System liefert beobachtbares Ergebnis, das für Akteur von Nutzen ist Notation: Bearbeite Kredit nötig, da Ovale für sich nichts aussagen verbal oder mit Szenarien, die als Diagramme dargestellt werden Unterscheidung von Normalfall (main flow of events) Ausnahmefälle (exceptional flow of events) Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 75 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 76

20 BEISPIEL: USE CASE AUTHENTIFIZIERE BENUTZER Normalfall: 1. System fragt Benutzer nach PIN 2. Benutzer gibt PIN ein 3. System prüft Richtigkeit Ausnahmefälle: Use-Case-Diagramme Benutzer gibt 3 Mal eine falsche PIN ein Benutzer bricht Transaktion ab Benutzer hat sich vertippt, drückt CLEAR-Taste Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 77 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 78 GENERALISIERUNGS-/SPEZIALISIERUNGSBEZIEHUNGEN GEMEINSAMES VERHALTEN KANN AUSFAKTORISIERT WERDEN sind sowohl bei Akteuren als auch bei Use Cases möglich: include-relation Ein Use Case beinhaltet explizit einen anderen. Letzterer kommt nicht allein vor, sondern dient der Vermeidung von Wiederholungen. Authentifiziere Bemuter Abhängigkeit Kunde Prüfe Passwort Taste Netzhaut ab Gib Bestellung auf <<include>> Stereotyp Firmenkunde Authentifiziere Benutzer Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 79 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 80

21 NEUE SPRACHELEMENTE Abhängigkeit: Änderung des unabhängigen Dinges (an der Pfeilspitze) bewirkt Änderung extend-relation des abhängigen Dinges. z.b. Änderung von Gib Bestellung auf ändert sich, wenn Authentifiziere Benutzer sich ändert. Gib Bestellung auf <<extend>> Gib Eil Bestellung auf Stereotypen: Erweiterung von UML um neue Grundbausteine beschreibt die o.g. Abhängigkeit zwischen Use Cases include Bei verbaler Beschreibung von Gib Bestellung auf muss auch Authentifiziere Benutzer beschrieben werden. gibt weitere Abhängigkeit mit vordefiniertem Stereotyp, nämlich extend Basis-Use-Case kann alleine vorkommen, aber in manchen Fällen wird sein Verhalten durch einen anderen Use-Case erweitert. Damit wird optionales Systemverhalten ausgedrückt. Beachte: Die Abhängigkeit ist hier andersherum als bei abhängig! include! Das optionale Verhalten ist vom Basisverhalten Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 81 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 82 LETZTER SCHRITT WEITERES BEISPIEL Benutze Assoziationen, um die Akteure mit den Use-Cases zu verbinden Zeichne Systemgrenzen ein Beispiel: Mobiltelefon Konto eröffnen <<include>> Mitarbeiter Konto schliessen Netzbetreiber Anrufen <<extend>> Konferenz schaltung Bearbeite Transaktion <<include>> Schufa Anfrage Schufa Erhalte Anruf <<extend>> Erhalte weiteren Anruf Kreditspezialist Bearbeite Kredit Bank Benutzer Terminplaner Mobiltelefon Beachte: Kreditspezialist darf auch Konten eröffnen, aber normaler Mitarbeiter darf keine Kredite bearbeiten. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 83 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 84

22 OBJEKTORIENTIERTE ANALYSE Klassenmodell statische Aspekte Schnittstellenmodell dynamische Aspekte Nächster Schritt: Beschreibung der Aktionsfolgen Use-Case-Modell Szenarien Operationsmodell Systemklassenmodell Lifecycle-Modell Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 85 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 86 SZENARIEN BEISPIEL: KONTO ERÖFFNEN Beschreiben alle in den Use Cases enthaltenen Aktionsfolgen Beschreiben Kommunikationsabläufe des Systems mit seiner Umgebung Beteiligte: System sowie Akteure gemäß Use-Case-Diagramm Notation: UML-Sequenzdiagramme Zu jedem Use Case muss es mindestens ein Szenario geben! Jedes Szenario beschreibt einen möglichen Ablauf (Normal- oder Ausnahmefall) Normalfall 1: Neuer Kunde will Konto eröffnen. Schufa-Anfrage nötig. Schufa bestätigt Bonität, Konto wird eröffnet. Ausnahmefall 1: Neuer Kunde will Konto eröffnen. Schufa-Anfrage fällt negativ aus, Kontoeröffnung wird verweigert. Ausnahmefall 2: Kunde will als neuer Kunde ein Konto eröffnen. Der Kunde ist jedoch bereits als Altkunde bekannt. Normalfall 2: Bereits vorhandener Kunde will ein weiteres Konto eröffnen. Bonität wird intern geprüft. Bonität ist gut, Konto wird eröffnet. Ausnahmefall 3: Bereits vorhandener Kunde will ein weiteres Konto eröffnen. Interne Bonitätsprüfung ist negativ, Kontoeröffnung wird verweigert. Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 87 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 88

23 SZENARIO FÜR NORMALFALL 1 MERKE: System Akteur Systemoperationen sind Pfeile von einem Akteur zum System Ausgabeereignisse sind Pfeile vom System zu einem Akteur Mitarbeiter nkto_eröffnen : Bank Schufa Ausgabeereignis Parameter werden hier noch nicht angegeben Jedes Szenario muss mit einer Systemoperation beginnen (d.h. das System tut nichts von sich aus) schufa_anfrage Systemoperation Es kann Systemoperationen ohne Ausgabeereignisse geben nkto_eröffnet bonität_ok Zeitachse I.A. enthält ein Szenario mehrere Akteure, Systemoperationen und Ausgabeereignisse Ein Ausgabeereignis geht nicht notwendig an den Akteur, der die Systemoperation aufruft Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 89 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 90 Szenario für Ausnahmefall 1: Szenario für Ausnahmefall 2: Szenario für Normalfall 2: Szenario für Ausnahmefall 3: : Bank : Bank Mitarbeiter Schufa Mitarbeiter Mitarbeiter : Bank : Bank Mitarbeiter nkto_eröffnen nkto_eröffnen akto_eröffnen akto_eröffnen schufa_anfrage bonität_schlecht nkto_nicht_eröffnet kunde_schon_vorhanden akto_eröffnet akto_nicht_eröffnet Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 91 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 92

24 METHODE OBJEKTORIENTIERTE ANALYSE Betrachte alle im Use-Case-Diagramm vorhandenen Use Cases. Klassenmodell statische Aspekte Für jeden dieser Use Cases: Erhebe alle darin enthaltenen Normal- und Ausnahmefälle Stelle für jeden dieser Fälle ein Szenario auf. Sammle die Namen aller Pfeile, die von einem Akteur zum System gehen. Dies sind die Systemoperationen, die im Folgenden näher spezifiziert werden müssen. Schnittstellenmodell Use-Case-Modell Szenarien Operationsmodell Systemklassenmodell Lifecycle-Modell dynamische Aspekte Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 93 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 94 ZWECK deskriptive Spezifikation (genau) der in den Szenarien identifizierten Systemoperationen Das Operationsmodell durch Angabe der Zustandsänderung und der Ausgabeereignisse, die sie erzeugt keine Programmierung, keine Abläufe innerhalb des Systems für jede Systemoperation muss ein Operationsschema angegeben werden Operationsmodell = Menge der Operationsschemata Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 95 Software-Praktikum, WS 2004/2005 T. Santen, WWU Münster 96

Softwaretechnik SS 2006

Softwaretechnik SS 2006 Softwaretechnik SS 2006 Basisveranstaltung im Studiengebiet SSG (Softwaretechnik und Systemgestaltung) Wie viele Beine hat der Elefant? Stefan Jähnichen Steffen Helke Marco Mosconi Softwaretechnik SS 2006

Mehr

Softwaretechnik SS 2006

Softwaretechnik SS 2006 Softwaretechnik SS 2006 Basisveranstaltung im Studiengebiet SSG (Softwaretechnik und Systemgestaltung) Siehst Du ein Gesicht, oder einen Eskimo von hinten? Softwaretechnik SS 2006 1 Stefan Jähnichen Steffen

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Eine Klasse beschreibt Objekte mit gleichen Attributen und Methoden.

Eine Klasse beschreibt Objekte mit gleichen Attributen und Methoden. Grundwissen Informatik Objekt Attribut Methoden Als Objekte bezeichnet man alle Gegenstände, Dinge, Lebewesen, Begriffe oder Strukturen unserer Welt ( Autos, Räume, Bakterien, Lehrer, Schüler, Kunden,

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

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

Client-Server-Beziehungen

Client-Server-Beziehungen Client-Server-Beziehungen Server bietet Dienste an, Client nutzt Dienste Objekt ist gleichzeitig Client und Server Vertrag zwischen Client und Server: Client erfüllt Vorbedingungen eines Dienstes Server

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

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

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

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

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

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

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

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

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

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

Software Engineering Klassendiagramme Einführung

Software Engineering Klassendiagramme Einführung Software Engineering Klassendiagramme Einführung Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Aufgabe Erstellen Sie eine Klasse Person in Java. Jede Person verfügt

Mehr

Formaler Entwurf mit Event-B Die Eventbank

Formaler Entwurf mit Event-B Die Eventbank Institut für Theoretische Informatik Anwendungsorientierte Formale Verifikation Vorlesung Anwendung Formaler Verifikation SS 2015, 9.6.15 Dr. V. Klebanov, Dr. M. Ulbrich Formaler Entwurf mit Event-B Die

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 Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Aufgabe 3. Assoziation zwischen

Mehr

Kapitel 4: Dynamische Analyse mit FUSION. SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30)

Kapitel 4: Dynamische Analyse mit FUSION. SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30) Kapitel 4: Dynamische Analyse mit FUSION SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30) Dokumente der dynamischen Analyse Analyse des Systemverhaltens (dynamischer Aspekt). Zu entwickeln sind:

Mehr

Objektorientierte Programmiersprachen

Objektorientierte Programmiersprachen Objektorientierte Programmiersprachen 1960 Algol 1970 Simula Pascal 1980 Smalltalk C Ada 1990 C++ Eiffel Eine ovale Box symbolisiert eine objektorientierte Programmiersprache. Eine rechteckige Box steht

Mehr

SEQUENZDIAGRAMM. Christoph Süsens

SEQUENZDIAGRAMM. Christoph Süsens SEQUENZDIAGRAMM Christoph Süsens DEFINITION Das Sequenzdiagramm gibt Auskunft darüber: Welche Methoden für die Kommunikation zwischen ausgewählten Objekten zuständig sind. Wie der zeitliche Ablauf von

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

Objektorientierte Programmierung OOP

Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Ronja Düffel WS2012/13 08. Oktober 2013 Objektorientierte Programmierung OOP Objektorientierte Programmierung Objektorientierte

Mehr

VBA-Programmierung: Zusammenfassung

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

Mehr

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Objekt Objekt kapselt Variablen und Routinen Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Eigenschaften jedes Objekts: Identität (identisch = mehrere

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

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {... PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8 Prof. Dr. Wilhelm Schäfer Paderborn, 8. Dezember 2014 Christian Brenner Tristan Wittgen Besprechung der Aufgaben: 15. - 18. Dezember 2014 Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung

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

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

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

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

System-Modellierung. statisches & dynamisches Modell. System Model. System Model

System-Modellierung. statisches & dynamisches Modell. System Model. System Model System Model System-Modellierung erarbeiten der: der System-UseCases des konzeptionellen Analysemodells des Architekturmodells des Designmodells Setzt auf dem BusinessModel auf Martin Jud NDS-I SWE II

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Weiteren Verlauf der Vorlesung 31.10.2011(2 Std) OO Vorgehensmodelle, UML, Teamarbeit, Gruppenbildung,. 07.11.2011(2,5Std) Projektvorstellung, Planungsphase 14.11.2011(2 Std) Angebotspräsentation,

Mehr

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

SWE5 Übungen zu Software-Engineering

SWE5 Übungen zu Software-Engineering 1 Übungen zu Software-Engineering 1) Klassen und Objekte 2) Telefonanlage 3) Objekt- und Klassendiagramme 4) Assoziationen 5) Telefonanlage (Erweiterung) 6) Fahrzeuge 7) Familien 2 Aufgabe 1: Klassen und

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

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 1 Software-Engineering Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 2 Software-Engineering Vorlesungsthemen: 1. Überblick über das Thema und die Vorlesung 2. Grundlegende

Mehr

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 -

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 - Systemanalyse - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 - Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

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

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

Kapitel 6. Vererbung

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

Mehr

4. Übung zu Software Engineering

4. Übung zu Software Engineering 4. Übung zu Software Engineering WS 2007/2008 Aufgabe 8 Erstellen Sie für den aus Aufgabe 1 bekannten Function-Point-Kalkulator ein Pflichtenheft. Bitte begrenzen Sie dessen Umfang auf maximal 2 DIN A4

Mehr

Algorithmen und Datenstrukturen 07

Algorithmen und Datenstrukturen 07 5. Dezember 2011 1 Besprechung Blatt 6 Fragen 2 Vererbung Allgemein abstract Interfaces 3 Unified Modeling Language (UML) Ablaufdiagramme Klassendiagramme Anwendungsfalldiagramme 4 Vorbereitung Blatt 7

Mehr

Code-Erzeugung aus UML-Klassendiagrammen

Code-Erzeugung aus UML-Klassendiagrammen Dominik 09.03.2009 Universität Ulm Gessenharter Inst. f. Programmiermethodik und Compilerbau Code-Erzeugung aus UML-Klassendiagrammen Theorie und Praxis Seite 2 REConf 2009 München Dominik Gessenharter

Mehr

Softwarepraktikum: Enigma

Softwarepraktikum: Enigma Softwarepraktikum: Enigma Martin Steffen Sommersemester 2003 Abschnitt I Softwareentwurf Bereiche der Softwareentwicklung 1 Softwareentwurf eigentliche Softwareentwicklung Projektmanagement Konfigurationsmanagement

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

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die "Softwarekrise"

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise im Überblick im Überblick Inhalt 1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise 1. Merkmale von Software 2. Fortlaufende Veränderungen 3. Erschwerte Rahmenbedingungen bei der

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

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

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

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

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

Kapitel 5: Das Design

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

Mehr

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

Grundbegriffe der Objektorientierung

Grundbegriffe der Objektorientierung Grundbegriffe der Objektorientierung Objekt Merkmale Zustand Verhalten Lebenszyklus Beziehungen zwischen Objekten Kategorisierung von Objekten Grundbegriffe der Objektorientierung Objekt Merkmale Zustand

Mehr

12 Anwendungsfalldiagramm

12 Anwendungsfalldiagramm 133 In Abschnitt 1.5 haben Sie gelesen, dass Anwendungssysteme in einen Unternehmenskontext eingebunden sind und dort Geschäftsprozesse unterstützen. Aus diesem Blickwinkel ist die Beschreibung der funktionalen

Mehr

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

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

Mehr

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

Objektorientierte Programmierung

Objektorientierte Programmierung Programmierkurs C++ Kapitel 7:Objektorientierte Programmierung Seite 1 Objektorientierte Programmierung If programming in PASCAL is like put in a straightjacket, then programming in C is like playing with

Mehr

SEP 114. Design by Contract

SEP 114. Design by Contract Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit

Mehr

7. Objektorientierte Softwareentwicklung/3. Informatik II für Verkehrsingenieure

7. Objektorientierte Softwareentwicklung/3. Informatik II für Verkehrsingenieure 7. Objektorientierte Softwareentwicklung/3 Informatik II für Verkehrsingenieure Überblick FOLGENDE BEGRIFFE/PRINZIPIEN SOLLTEN BEKANNT SEIN Objekte Klasse Attribute Fähigkeiten ZIEL DER HEUTIGEN LEHRVERANSTALTUNG

Mehr

Objektorientierte Modellierung (1)

Objektorientierte Modellierung (1) Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist

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

Selbstbestimmtes Lernen. Proinformatik III Objektorientierte Programmierung. Format. Inhalt. Buzzwords

Selbstbestimmtes Lernen. Proinformatik III Objektorientierte Programmierung. Format. Inhalt. Buzzwords 4.0 Proinformatik III Objektorientierte Programmierung Michael Kölling University of Kent Canterbury, UK Selbstbestimmtes Lernen Vorlesung Tutorium Übungen Buch Web-Seite Üben, üben, üben! Format Vorlesung:

Mehr

Vererbung. Vererbung von Methoden und Instanzvariablen. Vererbung als Realisierung einer is-a Beziehung.

Vererbung. Vererbung von Methoden und Instanzvariablen. Vererbung als Realisierung einer is-a Beziehung. Vererbung Unterklassen einer Klasse Vererbung von Methoden und Instanzvariablen Überschreiben von Methoden Vererbung als Realisierung einer is-a Beziehung. Informatik II: Objektorientierte SW-Entwicklung,

Mehr

1. Grundbegriffe des Software-Engineering

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

Mehr

Übung 1 Einführung, Wiederholung Methoden des Software Engineering WS 2012/13. Christian Kroiß

Übung 1 Einführung, Wiederholung Methoden des Software Engineering WS 2012/13. Christian Kroiß Übung 1 Einführung, Wiederholung Methoden des Software Engineering WS 2012/13 Christian Kroiß Inhalt heute Organisatorisches & Ablauf der Übung Auffrischung Vorlesung Softwaretechnik: Aktivitäten bei der

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

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

Assoziation und Aggregation

Assoziation und Aggregation Assoziation und Aggregation Martin Wirsing in Zusammenarbeit mit Matthias Hölzl, Nora Koch 05/03 2 Ziele Verstehen der Begriffe Assoziation und Aggregation Implementierung von Assoziationen in Java schreiben

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

24 Transformation der Anforderungsspezifikation

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

Mehr

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

Programmieren II Vererbung. Programmieren II Vererbung. Programmieren II Vererbung. Programmieren II Vererbung. Einleitende Bemerkungen

Programmieren II Vererbung. Programmieren II Vererbung. Programmieren II Vererbung. Programmieren II Vererbung. Einleitende Bemerkungen Einleitende Bemerkungen Einleitende Bemerkungen Ideen hinter der objektorientierten Programmierung Objekte (/* Instanzen einer Klasse */) im Mittelpunkt Objekte bilden Einheit aus Daten (/* Attributen,

Mehr

5.5.8 Öffentliche und private Eigenschaften

5.5.8 Öffentliche und private Eigenschaften 5.5.8 Öffentliche und private Eigenschaften Schnittstellen vs. Implementierungen: Schnittstelle einer Klasse beschreibt, was eine Klasse leistet und wie sie benutzt werden kann, ohne dass ihre Implementierung

Mehr

Klausur "OOAD" im SS 2009. Name, Vorname: Matrikel-Nr:

Klausur OOAD im SS 2009. Name, Vorname: Matrikel-Nr: Klausur "OOAD" im SS 009 Name, Vorname: Matrikel-Nr:.... Bitte tragen Sie zuerst Ihren Namen und Ihre Matrikelnummer ein. Lesen Sie jeweils vor Erarbeitung der Lösung die ganze Aufgabenstellung durch.

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Grundzüge der Programmierung. Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN

Grundzüge der Programmierung. Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN Grundzüge der Programmierung Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN Inhalt dieser Einheit JAVA ist objektorientiert! Grundbegriffe der objektorientierten Programmierung:

Mehr

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung 6. Datenintegrität Motivation Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung nur sinnvolle Attributwerte (z.b. keine negativen Semester) Abhängigkeiten

Mehr

Ersetzbarkeit, Client-Server Beziehungen

Ersetzbarkeit, Client-Server Beziehungen Ersetzbarkeit, Client-Server Beziehungen 182.132 VL Objektorientierte Programmierung Raimund Kirner Mitwirkung an Folienerstellung: Peter Puschner, basieren auf den Folien von Franz Puntigam, TU Wien Überblick

Mehr

RUP Analyse und Design: Überblick

RUP Analyse und Design: Überblick Inhaltsverzeichnis Übersicht [, 2, 8] 3. Vorgehensweise............................... 5 2 Planungsmethoden 37 2. Definitionsphase.............................. 6 3 Rational Unified Process [5, 6] und

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

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

Online Banking System

Online Banking System Online Banking System Pflichtenheft im Rahmen des WI-Praktikum bei Thomas M. Lange Fachhochschule Giessen-Friedberg Fachbereich MNI Studiengang Informatik Erstellt von: Eugen Riske Yueksel Korkmaz Alper

Mehr

VIII: Vererbung. Unterklassen einer Klasse. Vererbung von Methoden und Instanzvariablen. Überschreiben von Methoden

VIII: Vererbung. Unterklassen einer Klasse. Vererbung von Methoden und Instanzvariablen. Überschreiben von Methoden VIII: Vererbung Unterklassen einer Klasse Vererbung von Methoden und Instanzvariablen Überschreiben von Methoden Vererbung als Realisierung einer is-a Beziehung. Informatik I VIII: Vererbung 259 Beispiel:

Mehr

4. Übung zu Software Engineering

4. Übung zu Software Engineering 4. Übung zu Software Engineering WS 2009/2010 Henning Heitkötter Klassendiagramm: Projektmanagement AUFGABE 10 1 OOA-Methode von Heide Balzert 1. Klassen finden 2. Assoziationen und Kompositionen finden

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Teil D Objektorientierte Programmierung Kapitel D 2001 Prof. Dr. Rainer Manthey Informatik I 1 Teil D Grundlagen der objektorientierten Programmierung 2001 Prof. Dr. Rainer Manthey Informatik I 2 Objektorientierung

Mehr

Angewandte Mathematik und Programmierung

Angewandte Mathematik und Programmierung Angewandte Mathematik und Programmierung Einführung in das Konzept der objektorientierten Anwendungen zu mathematischen Rechnens WS 2013/14 Die Vererbung ermöglicht es, neue Klassen auf der Basis von schon

Mehr

Objektorientierte Analyse und Design

Objektorientierte Analyse und Design Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 4. Objektorientierte Analyse OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik 51 4. Objektorientierte Analyse

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

Grundlagen der Informatik für Ingenieure I

Grundlagen der Informatik für Ingenieure I 3 Einführung in das objektorientierte Programmier-Paradigma 3 Einführung in das objektorientierte Programmier-Paradigma 3.1.1 Top-down structured design 3.1.2 Data-driven design 3.1.3 Object-oriented design

Mehr

Praktikum Software Engineering

Praktikum Software Engineering Praktikum Software Engineering Verwendung von Enterprise Architect Pascal Weber, David Kulicke KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft

Mehr

Software Engineering Klassendiagramme Assoziationen

Software Engineering Klassendiagramme Assoziationen Software Engineering Klassendiagramme Assoziationen Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Lesen von Multiplizitäten (1) Multiplizitäten werden folgendermaßen

Mehr