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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mehr

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

Einführung in die SWE

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

Mehr

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

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2008/2009 PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2008/2009 FB Informatik

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

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

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

PRÜFUNG. Grundlagen der Softwaretechnik

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

Mehr

Kapitel 3 Das Projekt Bankkonto Seite 1

Kapitel 3 Das Projekt Bankkonto Seite 1 Kapitel 3 Das Projekt Bankkonto Seite 1 3 Das Projekt Bankkonto Nun wirst du dich etwas gründlicher mit dem Quelltext einer Klasse beschäftigen. Du lernst, wie zwei Objekte eine gemeinsame Aufgabe erledigen.

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

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

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

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

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

Objekt-Orientierte Programmierung

Objekt-Orientierte Programmierung Objekt-Orientierte Programmierung Ein OO-Programm modelliert eine Anwendung als eine Welt von Objekten, die miteinander in Beziehung stehen ( später). Ein Objekt kann andere Objekte erzeugen. Ein Objekt

Mehr

2.4.3 Polymorphie (Wiederholung von Alp2)

2.4.3 Polymorphie (Wiederholung von Alp2) 2.4.3 Polymorphie (Wiederholung von Alp2) Sparbuch einsparbuch = new Sparbuch(3.0); Konto einkonto; KontoDrucker = new KontoDrucker(); KontoDrucker.setzeKonto(einSparbuch); einkonto = einsparbuch; Wie

Mehr

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern Objektorientierte Programmierung mit Python Polymorphismus und Vererbung Eltern Kind Kind Kind Kind Prinzipien der objektorientierten Programmierung Vererbung Strukturierung von Klassen. Oberbegriffe beschreiben

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

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

Programmierung, Algorithmen und Techniken. von Thomas Ohlhauser

Programmierung, Algorithmen und Techniken. von Thomas Ohlhauser Programmierung, Algorithmen und Techniken von Thomas Ohlhauser 1. Begriff Programmierung Entwicklung von Programmen inklusive der dabei verwendeten Methoden und Denkweisen. Ein Programm ist eine eine Zusammensetzung

Mehr

Programmieren - Vererbung & Polymorphie

Programmieren - Vererbung & Polymorphie Programmieren - Vererbung & Polymorphie Reiner Nitsch r.nitsch@fbi.h-da.de Vererbung - Was ist das? Vererbung ist ein wichtiges Konzept zur Unterstützung der Wiederverwendbarkeit, wenn auch nicht das Wichtigste.

Mehr

Software-Entwicklung: Konzepte der Objektorientierung

Software-Entwicklung: Konzepte der Objektorientierung Software-Entwicklung: Konzepte der Objektorientierung 1 Übersicht Objektorientierte Softwareentwicklung Klasse und Objekt Attribut und Operation Schnittstelle Taxonomie und Vererbung Weitere Begriffe 2

Mehr

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

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

Mehr

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 A. Beschreibung der Projektarbeit. Welche Aufgabe haben Sie im Rahmen der Projektarbeit gelöst? 2. Mit welchen Tools bzw. Programmen (Anwendung,

Mehr

Java lernen mit BlueJ

Java lernen mit BlueJ Java lernen mit BlueJ Eine Einführung in die objektorientierte Programmierung David J. Barnes Michael Kölling 4.0 Lernen in Eigenregiegi Vorlesungen Seminare Übungen Bücher Webseiten Diskussionslisten

Mehr

einkonto.zahle(+100); //Transaktion Einzahlung einkonto.zahle(-20); //Transaktion Auszahlung einkonto.zahle(+30); //Transaktion Einzahlung

einkonto.zahle(+100); //Transaktion Einzahlung einkonto.zahle(-20); //Transaktion Auszahlung einkonto.zahle(+30); //Transaktion Einzahlung PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 28 Testklasse public class TestGirokonto { public static void main(string[] args) { // erzeuge neues Konto Girokonto einkonto = new Girokonto();

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Einführung in das Entity-Relationship-Modell

Einführung in das Entity-Relationship-Modell Einführung in das Entity-Relationship-Modell Historie Entity-Relationship-Modell kurz: ER-Modell bzw. ERM 1976 von Peter Chen vorgeschlagen Standardmodell für frühe Entwurfsphasen in der Datenbankentwicklung

Mehr

Klausurvorbereitung Software Engineering I @ TFH Berlin

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

Mehr

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

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

Vorlesung im Herbstwintersemester 2007. Autorisierte studentisch Lösungen zu Aufgabenblatt 2

Vorlesung im Herbstwintersemester 2007. Autorisierte studentisch Lösungen zu Aufgabenblatt 2 Praktische Informatik I Vorlesung im Herbstwintersemester 2007 Autorisierte studentisch Lösungen zu Aufgabenblatt 2 zusammengestellt von Iva Tsvetkova 9.10.2007 1.Präsenzaufgaben 1.1 Entwurf einer Verwaltung

Mehr

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

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

Mehr

4 Vererbung, Polymorphie

4 Vererbung, Polymorphie 4 Vererbung, Polymorphie Jörn Loviscach Versionsstand: 21. März 2014, 22:57 Die nummerierten Felder sind absichtlich leer, zum Ausfüllen beim Ansehen der Videos: http://www.j3l7h.de/videos.html This work

Mehr

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ Objektorientierte Programmierung Objektorientierte Programmierung Eine Einführung mit BlueJ stellt die Daten, ihre Struktur und ihre Beziehungen zueinander in den Vordergrund. Weniger im Blickpunkt: die

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

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

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

Übersicht. Informatik 2 Teil 3 Anwendungsbeispiel für objektorientierte Programmierung

Übersicht. Informatik 2 Teil 3 Anwendungsbeispiel für objektorientierte Programmierung Übersicht 3.1 Modell Konto 3.2 Modell Konto - Erläuterungen 3.3 Benutzer Ein- und Ausgabe mit Dialogfenster I 3.4 Benutzer Ein- und Ausgabe mit Dialogfenster II 3.5 Klassen- und Objekteigenschaften des

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

Zusammenfassung Modul 226

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

Mehr

C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung. Eltern

C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung. Eltern C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung Eltern Kind Kind Vererbung Definition von Klassen auf Basis von bestehenden Klassen. Implementierung von ist ein. bildet ein hierarchisches

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

Kurzreferenz UML. Autor: Michael Puff. Stand: 2010-05-21. http://www.michael-puff.de mail@michael-puff.de

Kurzreferenz UML. Autor: Michael Puff. Stand: 2010-05-21. http://www.michael-puff.de mail@michael-puff.de Kurzreferenz UML Autor: Michael Puff Stand: 2010-05-21 http://www.michael-puff.de mail@michael-puff.de Inhaltsverzeichnis Inhaltsverzeichnis 1 Die Modellierungssprache UML 5 1.1 Definition Klasse - Objekt......................

Mehr

Das Lehren von objektorientierter Programmierung in Java mit

Das Lehren von objektorientierter Programmierung in Java mit Das Lehren von objektorientierter Programmierung in Java mit Dr. Axel Schmolitzky Arbeitsbereich Softwaretechnik Fachbereich Informatik Universität Hamburg Überblick Kurz zu meiner Person Objektorientierung

Mehr

Softwarewiederverwendung und Patterns

Softwarewiederverwendung und Patterns Begrifflichkeiten und Beschreibungssystematik Begriffe Literatur zu Patterns Übersicht über die behandelten Konzepte Beschreibungsschema 97 Begriffe Glossar Patterns (Muster) sind ein Mittel der Wiederverwendung

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

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

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Erste Schritte in Java

Erste Schritte in Java Erste Schritte in Java Im einführenden Kapitel haben wir die Grundbegriffe der imperativen Programmierung an einem Beispiel (Algorithmus von Euklid) kennengelernt. In diesem Kapitel sehen wir uns an einem

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Invarianten und sichere Vererbung

Invarianten und sichere Vererbung Kapitel 7 Invarianten und sichere Vererbung Idee der Vererbung: class U extends O... bedeutet: Jedes U ist auch als O verwendbar, denn es hat mindestens dieselben Members im O-Subobjekt (Typkonformanz,

Mehr

1 Objektorientierte Software-Entwicklung

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

Mehr

5 Projekt Bankverwaltung

5 Projekt Bankverwaltung Kapitel 5 Bankverwaltung (Lösung) Seite 1/7 5 Projekt Bankverwaltung 5.1 Festlegen der Schnittstelle Bevor du mit der Programmierung beginnst, musst du dir einige Gedanken über die Schnittstelle zwischen

Mehr

Softwareentwicklung mit UML

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

Mehr

Vgl. Oestereich Kap 2.6 Seiten 127-133

Vgl. Oestereich Kap 2.6 Seiten 127-133 Vgl. Oestereich Kap 2.6 Seiten 127-133 4. Zustände 1 Aktivitäts- und Zustands-Diagramm werden oft verwechselt. Es ist darum wichtig zu unterscheiden, dass im Aktivitätsdiagramm die Aktionen im Zentrum

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

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

OO Softwareentwicklung

OO Softwareentwicklung OO Softwareentwicklung Objektorientierung Prof. Dr. Bernhard Schiefer 1 OO als Ansatz zur Verbesserung der Software-Qualität Modellierung der Welt als selbständig agierende Objekte. Gemeinsame Beschreibung

Mehr

Java Einführung Methoden in Klassen

Java Einführung Methoden in Klassen Java Einführung Methoden in Klassen Lehrziel der Einheit Methoden Signatur (=Deklaration) einer Methode Zugriff/Sichtbarkeit Rückgabewerte Parameter Aufruf von Methoden (Nachrichten) Information Hiding

Mehr

Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005

Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005 Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005 Hinweise: Bearbeitungszeit: 90 Minuten Erlaubte Hilfsmittel: im Anhang, sonst keine Bitte notieren Sie Ihre Antworten ausschließlich auf dem Aufgabenblatt!

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

Ü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

OO-Design. Klausur FHF * WI1 / WI2 * SS 2000 MUSTERLÖSUNG

OO-Design. Klausur FHF * WI1 / WI2 * SS 2000 MUSTERLÖSUNG OO-Design Klausur FHF * WI / WI2 * SS 2000 MUSTERLÖSUNG Aufgabe : (28 Punkte) - Ergänzen Sie zum Fallbeispiel "Seminaranmeldung" (s. Anhang) das vorgegebene Use-Case- Diagramm um die fehlenden Use Cases,

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Einleitung und Organisatorisches

Einleitung und Organisatorisches page.1 Einleitung Informatik für Elektrotechnik und Informationstechnik Benedict Reuschling benedict.reuschling@h-da.de Hochschule Darmstadt Fachbereich Informatik WS 2013/14 page.2 Willkommen an der Hochschule

Mehr

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45 Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45 7 Programmverstehen + Fehlersuche Nach einer Vorlesung von Prof. Andreas Zeller, Lehrstuhl Softwaretechnik Universität

Mehr

SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster

SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster Aufgabe 1 analytische Aufgabe Die Eigenschaften und Einsatzbereiche

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung Ein Computerprogramm besteht aus Funktionen (Programmabschnitten, die etwas tun) und Variablen (Speicherplätzen für Informationen). Werden Funktionen aktiviert, verändern

Mehr

Vorkurs C++ Programmierung

Vorkurs C++ Programmierung Vorkurs C++ Programmierung Klassen Letzte Stunde Speicherverwaltung automatische Speicherverwaltung auf dem Stack dynamische Speicherverwaltung auf dem Heap new/new[] und delete/delete[] Speicherklassen:

Mehr

SoftwareEngineering. Klausur HFU *** Wl3/4 * WS 2005/2006. (30 Punkte) Lineares Benotungsschema: 90 Punffie = Note 1, 30 Punkte = Note 4.

SoftwareEngineering. Klausur HFU *** Wl3/4 * WS 2005/2006. (30 Punkte) Lineares Benotungsschema: 90 Punffie = Note 1, 30 Punkte = Note 4. SoftwareEngineering Klausur HFU *** Wl3/4 * WS 2005/2006 Lineares Benotungsschema: 90 Punffie = Note 1, 30 Punkte = Note 4 Aufgabe 1: (30 Punkte) Zum Fallbeispiel "Theater-Online" (s. Anhang) soll ein

Mehr

Programmieren Tutorium Wintersemester 2008/2009

Programmieren Tutorium Wintersemester 2008/2009 Micha Bruns, Philipp Tölle, Markus Roth 1 Programmieren Tutorium Wintersemester 2008/2009 Markus Roth Tutorium Nr. 10 28.10.2008 Micha Bruns, Philipp Tölle, Markus Roth 2 Übersicht Organisatorisches Über

Mehr

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

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

Mehr

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm Prof. Mario Jeckle Fachhochschule Furtwangen mario@ http://www. Fachhochschule Furtwangen, Sommersemester 2004 Das Komponentendiagramm Dient Darstellung

Mehr

Sascha Schreier. Softwaretechnik: Übung 11.12.09

Sascha Schreier. Softwaretechnik: Übung 11.12.09 Sascha Schreier Softwaretechnik: Übung 11.12.09 Unklarheiten und Fragen Sascha Schreier 11.12.2009 # 2 Systementwurf: Objektentwurf + Einbettung in die Systemumgebung (Pakete, DB, GUI, ) So viele verschiedene

Mehr

5.6 Vererbung. Vererbung

5.6 Vererbung. Vererbung 5.6 Vererbung Klassen können zueinander in einer "ist ein"- Beziehung stehen Beispiel: Jeder PKW ist ein Kraftfahrzeug, jedes Kraftfahrzeug ist ein Transportmittel aber: auch jeder LKW ist ein Kraftfahrzeug

Mehr

Entity-Relationship-Modell. Ein Studierender kann (oder muss) mehrere Vorlesungen hören. Eine Vorlesung wird i.a. von mehrerer Studierenden gehört.

Entity-Relationship-Modell. Ein Studierender kann (oder muss) mehrere Vorlesungen hören. Eine Vorlesung wird i.a. von mehrerer Studierenden gehört. Beziehungen Ein Studierender kann (oder muss) mehrere Vorlesungen hören. Eine Vorlesung wird i.a. von mehrerer Studierenden gehört. Eine Vorlesung wird von genau einem Dozenten gelesen. Ein Dozent kann

Mehr