Objekt-Orientierte Analyse - Klassendiagramme -
|
|
- Liese Hertz
- vor 8 Jahren
- Abrufe
Transkript
1 Objekt-Orientierte Analyse - Klassendiagramme - Software Engineering 1 WS 2011/2012 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (mit Folien von Prof. B. Rumpe)
2 Systemmodellierung Analyse (system analysis) Anforderungs- Ermittlung (requirements elicitation) Anforderungs- Spezifikation (Lastenheft) Systemmodellierung (system modelling) Systemspezifikation (Pflichtenheft) Entwurf! Präzise Beschreibung der Systemfunktionen Was ist zu realisieren, ohne das Wie vorherzubestimmen Dr. Ina Schaefer Software Engineering 1 Seite 2
3 Systemmodellierung Abstrakte Modellierung der zu lösenden fachlichen Aufgabe (fachliches Modell, domain model) Kleines Team Aufgabe: Strukturierung des Aufgabengebiets Schaffung einheitlicher Terminologie Auffinden von Grundkonzepten Grundregeln: Zusammenhang mit Anforderungsspezifikation sichern Implementierungsaspekte ausklammern Annahme perfekter Technologie Funktionale Essenz des Systems Datenhaltung, Benutzungsoberfläche im allgemeinen zurückstellen Dr. Ina Schaefer Software Engineering 1 Seite 3
4 Objektorientierte Analyse (OOA) Grundidee: Modellierung der fachlichen Aufgabe durch kooperierende Objekte. Statisches Modell! Klassen: Eigenschaften und Aufgaben von Objekten Beziehungen zwischen Klassen (bzw. Objekten) Dynamisches Modell! Nachweis der Bewältigung typischer Anwendungsfälle Zustände und Verhalten von Objekten OOA-! Modell! beschreibt! "Gesellschaft"! kooperierender! Objekte! Dr. Ina Schaefer Software Engineering 1 Seite 4
5 Zwei grundlegende Varianten der Objektorientierten Analyse Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Szenarien prüfen Klassenkandidaten finden und Verhalten zuordnen Assoziationen und Aggregationen finden Attribute finden Vererbungsstrukturen finden Datenorientierte Vorgehensweise z.b. OMT Objekt-Lebenszyklen erstellen Operationen spezifizieren Strukturen überprüfen Paket-Struktur finden Verhaltensorientierte Vorgehensweise z.b. OOSE Dr. Ina Schaefer Software Engineering 1 Seite 5
6 Zwei grundlegende Varianten der Objektorientierten Analyse Datenorientierte Vorgehensweise z.b. OMT Verhaltensorientierte Vorgehensweise z.b. OOSE Beide haben gleiche Resultate, aber Reihenfolge der Erstellung anders: zuerst die Klassen zuerst Abläufe (Szenarien) wenn die Komplexität... in den Daten... in den Abläufen Dr. Ina Schaefer Software Engineering 1 Seite 6
7 Überblick Objekt-orientierte Analyse nach OOSE (Jacobsen, 1992) Object-oriented Software Engineering Verhaltensorientiertes Vorgehen Ausgehend von Use Cases Objekt-orientierte Analyse nach OMT Object Modeling Technique (Rumbaugh et al., 1991) Datenorientiertes Vorgehen Dr. Ina Schaefer Software Engineering 1 Seite 7
8 Von Anwendungsfällen zum Analysemodell Anwendungsfall: Beschreibung einer Klasse von Aktionsfolgen, die ein System ausführen kann, wenn es mit externen Akteuren interagiert. Szenarien liefern beispielhafte Beschreibung des Verhaltens Gesamtsystem als Einheit gesehen ("von außen") Analysemodell (Klassendiagramm): Modellierung des Systemverhaltens auf abstraktem Niveau. Allgemeine schematische Beschreibung des Verhaltens! Interne Struktur des Systems ("von innen")! Kollaboration (collaboration): Beschreibung des Austauschs von Nachrichten zwischen Objektinstanzen zur Erreichung eines bestimmten Ziels.! innere Zusammenhänge beschrieben im Sequenzdiagramm! "von außen" beschrieben mit Kollaborationsmuster, Rollen! Muster Rolle 1 Rolle 2 Dr. Ina Schaefer Software Engineering 1 Seite 8
9 Realisierung von Anwendungsfällen (nach Ivar Jacobson, OOSE) Jeder Anwendungsfall muss durch eine Kollaboration zwischen den System-Objekten realisiert werden. Use Case XY <<trace>> Kollaboration XY Beispiel: Die <<trace>>-abhängigkeit beschreibt, dass ein Modellelement aus einem anderen entstanden ist und dasselbe Konzept auf andere Weise beschreibt. Anmeldung prüfen Anmeldung prüfen Kunde Buchungswunsch Aus den Szenarien eines Anwendungsfalls lassen sich Kandidaten für beteiligte Klassenrollen finden (siehe nächste Folie). Aus den Klassenrollen werden im weiteren Verlauf manchmal Klassen, aus anderen Operationen. Dr. Ina Schaefer Software Engineering 1 Seite 9
10 Arten von Analyseklassen Verschiedene Stereotypen von Klassenrollen (bei Identifikation aus Szenarienbeschreibung): Dialog-Klasse (boundary class): Erwähnung von Benutzerinteraktion und deren Inhalt Steuerungs-Klasse (control class): Beschreibung von Vorgängen und Reihenfolgen Entitäts-Klasse (entity class): Beschreibung von Gegenständen mit dauerhafter Existenz Beispiel: Szenariotext: "Prüfung eines Buchungswunsches: Darstellung mit speziellen Icons: 1. Es wird anhand der Kundennummer geprüft, ob der Kunde dem System bekannt ist. 2. Es wird überprüft, ob der Kunde schon für eine Veranstaltung des angegebenen Seminartyps gebucht ist. Welche Klassentypen haben wir in diesem Beispiel? Dr. Ina Schaefer Software Engineering 1 Seite 10
11 Sequenzdiagramme für Szenarien Beteiligte Objekte haben zunächst Klassenrollen Identifikation erster Operationen ("Zuständigkeit" entscheiden) Identifikation von Bekannschaftsbeziehungen :Buchungswunsch :Prüfungsvorgang :Kunde :Buchung :Veranstaltung prüfen bekannt? gebucht? typ? typ? Ableitbare Bekanntschaftsbeziehungen: Kunde Buchung Veranstaltung Dr. Ina Schaefer Software Engineering 1 Seite 11
12 Überlagerung verschiedener Szenarien Schritt für Schritt alle Anwendungsfälle und alle Szenarien untersuchen Wo möglich, vorhandene Klassenrollen wiederverwenden Bekanntschaftsbeziehungen zu erstem Entwurf des Klassendiagramms ausbauen Buchungswunsch Prüfungsvorgang Kunde Seminartyp Stornierungswunsch Stornierungsvorgang Buchung Veranstaltung Dozent Absagewunsch Absagevorgang Dr. Ina Schaefer Software Engineering 1 Seite 12
13 Funktionalität zu Klassen zuordnen Steuerungsklassen können oft (aber nicht immer) aufgelöst und als Operationen anderen Klassen zugeordnet werden. Lokalitätsprinzip: Da zuordnen, wo geeignete lokale Information zur Verfügung steht. Beispiel: Buchungswunsch Prüfungsvorgang Seminartyp Kunde Stornierungswunsch Stornierungsvorgang Buchung Veranstaltung Dozent Absagewunsch Absagevorgang Dr. Ina Schaefer Software Engineering 1 Seite 13
14 Objektifizierung von Funktionalität Manchmal ist es sinnvoll, Steuerungsklassen in der Implementierung beizubehalten Vermeidung zu großer Implementierungsklassen Austauschbarkeit von alternativen Vorgängen durch eine Vererbungshierarchie von Steuervorgängen Speicherbarkeit von Zwischenzuständen lang andauernder Vorgänge Wiederverwendbarkeit derselben Vorgangsklasse für unterschiedliche Implementierungen Objektifizierung von Funktionalität bringt Flexibilität in der Implementierung Entkopplung Aber: Organisatorischer Zusatzaufwand und sollte daher nur eingesetzt werden, wenn sinnvoll begründbar! Dr. Ina Schaefer Software Engineering 1 Seite 14
15 Umgang mit Dialogklassen Kriterien für Klassen: Es gibt Operationen Es gibt Attribute Es gibt Assoziationen Manche Dialogklassen erweisen sich als wichtige Modellbestandteile. Manchmal will man Dialogklassen in eine separate Einheit legen (Dialogschnittstelle). Triviale Dialogklassen können auch entfernt werden. Buchungswunsch prüfen() Kunde Seminartyp Stornierungswunsch Buchung stornieren() Veranstaltung absagen() Dozent Absagewunsch Dr. Ina Schaefer Software Engineering 1 Seite 15
16 Klassendiagramm Vervollständigung des Klassendiagramms: Attribute Vererbungsbeziehungen Person name adresse telefon Kunde Seminartyp Dozent umsatz name stundensatz Buchungswunsch kundennummer veranstcode datum prüfen() Buchung status stornieren() Veranstaltung datum absagen() Dr. Ina Schaefer Software Engineering 1 Seite 16
17 Pakete finden Ein Paket ist eine Gruppe von Klassen UML: "Subsystem" als spezielles Paket (Architektureinheit) Ein Paket: ist für sich allein verständlich hat eine wohldefinierte Schnittstelle zur Umgebung ermöglicht Betrachtung des Systems aus einer abstrakteren Sicht Ziel: Starke Bindung innerhalb des Pakets Einheitlicher Themenbereich Aggregation und Vererbung soweit wie möglich nur innerhalb des Pakets Ziel: Schwache Kopplung zwischen Paketen Möglichst wenig Assoziationen über Paketgrenzen hinweg Faustregeln für ein sinnvolles Paket: UML: Klassen 1 DIN A4 Seite für ein Diagramm Dr. Ina Schaefer Software Engineering 1 Seite 17
18 Pakete: Beispiel Personal- und Kundenverwaltung Seminarverwaltung Person Seminartyp Mitarbeiter Dozent Veranstaltung Kunde Buchung Buchungswunsch Wohin? à Es gibt Modellierungsalternativen. Dr. Ina Schaefer Software Engineering 1 Seite 18
19 Entkopplung von Paketen Personal- und Kundenverwaltung Seminarverwaltung Dozent Seminartyp Veranstaltung Starke Kopplung Wichtigste Möglichkeit zur Entkopplung: Fachliche Zusammengehörigkeit sicherstellen Weitere Möglichkeiten zur Entkopplung (schon entwurfsnah): Dozentenklasse splitten in Personal- und seminarbezogene Information "Stellvertreter"-Klassen einführen (Proxy) Schnittstellen-Objekte einführen (z.b. PersonalverwaltungsAPI) Dr. Ina Schaefer Software Engineering 1 Seite 19
20 Zusammenfassung: OOA nach OOSE Verhaltensorientiertes Vorgehen: von Szenarien zur Klassenstruktur Szenarien prüfen Klassenkandidaten finden und Verhalten zuordnen Assoziationen und Aggregationen finden Attribute finden Vererbungsstrukturen finden Dr. Ina Schaefer Software Engineering 1 Seite 20
21 OOA nach OMT (Rumbaugh et al. 1991) OOA nach OMT (Rumbaugh et al. 1991) Ziel: Von den Anforderungen zu einem Modell der fachlichen Aufgabe Iteration Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden OMT: Datenorientierte Vorgehensweise Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 21
22 OOA nach OMT (Rumbaugh et al. 1991) Iteration Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 22
23 Klassen und Objekte in der Analyse Definition: Ein Objekt ist ein elementarer Bestandteil des betrachteten Fachgebiets. Ein Objekt wird erzeugt und behält eine unveränderliche Objektidentität bis zu seiner Löschung. Definition: Eine Klasse ist eine Beschreibung gleichartiger Objekte. Jedes Objekt gehört zu (ist Instanz von) genau einer Klasse. Notation: K! O : K! Beispiele: ar12: Teambesprechung! Teambesprechung! : Teambesprechung! Dr. Ina Schaefer Software Engineering 1 Seite 23
24 Beispiel: Termin-Klasse und Termin-Objekte AR-12: Teambesprechung Figaro: Theaterbesuch AR-13: Teambesprechung Termin Geschäftstermin Privater Termin Teambesprechung Kundenbesuch Theaterbesuch Instanz einer Klasse (hier redundant wg. Typangabe) Generalisierung / Vererbung Dr. Ina Schaefer Software Engineering 1 Seite 24
25 OOA nach OMT (Rumbaugh et al. 1991) Iteration Klassen finden Assoziationen und Aggregationen finden OK Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 25
26 Assoziation in der Analyse Definition: Eine (binäre) Assoziation AS zwischen zwei Klassen K1 und K2 beschreibt, dass die Instanzen der beiden Klassen in einer fachlich wesentlichen Beziehung zueinander stehen. Semantik: Für jedes Objekt O1 der Klasse K1 gibt es eine individuelle, veränderbare und endliche Menge AS von Objekten der Klasse K2, mit dem die Assoziation AS besteht. Analoges gilt für Objekte von K2. Notation: K1 AS K2 Beispiel: Teambesprechung Teilnahme Teammitglied Dr. Ina Schaefer Software Engineering 1 Seite 26
27 Leserichtung und Assoziationsenden Für Assoziationsnamen kann die Leserichtung angegeben werden. Es ist möglich, mehrere Namen für eine Assoziation anzugeben. Teambesprechung findet statt in ist Ort von Besprechungsraum Ein Name für ein Assoziationsende bezeichnet die Assoziation (evtl. zusätzlich) aus der Sicht einer der teilnehmenden Klassen. Teambesprechung Veranstaltungsort Besprechungsraum Dr. Ina Schaefer Software Engineering 1 Seite 27
28 Semantik (bidirektionaler) Assoziationen Eine Assoziation ist ähnlich zu einer Tabelle: Teilnahme-Assoziation Teambesprechung ar12 ar12 pbx1 pbx1 Teammitglied Dr. Ina Schaefer Software Engineering 1 Seite 28 tm1 tm3 tm1 tm2 Von einem beteiligten Objekt aus betrachtet, gibt eine Assoziation eine Menge von assoziierten Objekten an: Objekt ar12:teambesprechung Teammitglied-Objekte in Teilnahme-Assoziation: {tm1, tm3} Objekt tm1:teammitglied Teambesprechung-Objekte in Teilnahme-Assoziation: {ar12, pbx1} Beide Sichtweisen sind gleichberechtigt und äquivalent.
29 Multiplizität bei Assoziationen Definition: Die Multiplizität einer Klasse K1 in einer Assoziation AS mit einer Klasse K2 begrenzt die Anzahl der Objekte der Klasse K2, mit denen ein Objekt von K1 in der Assoziation AS stehen darf. Notation: AS K1 K2 Mult Multiplizität Mult: n (genau n Objekte der Klasse K2) n..m (n bis m Objekte der Klasse K2) n1, n2 (n1 oder n2 Objekte der Klasse K2) Zulässig für n und m : Zahlenwerte (auch 0) Beispiel: * (d.h. beliebiger Wert, einschließlich 0) Teambesprechung * 2..* Teilnahme Teammitglied Dr. Ina Schaefer Software Engineering 1 Seite 29
30 Aggregation Definition: Ein Spezialfall der Assoziation ist die Aggregation. Regel: Wenn die Assoziation den Namen "besteht aus" tragen könnte, handelt es sich um eine Aggregation. Eine Aggregation besteht zwischen einem Aggregat und seinen Teilen. Die auftretenden Aggregationen bilden auf den Objekten immer eine transitive, antisymmetrische Relation (einen gerichteten zyklenfreien Graphen). Mit der Aggregation sind oft gemeinsame Lebensdauer der Teile mit dem Aggregat impliziert. Umhängen ist allerdings erlaubt (Beispiel: Reifen eines Autos) Notation: Beispiel: K1! K2! Team! Teammitglied! Dr. Ina Schaefer Software Engineering 1 Seite 30
31 Komposition Definition: Ein Spezialfall der Aggregation ist die Komposition. Eine Komposition besteht zwischen einem Kompositum und seinen Komponenten. Ein Objekt kann Komponente höchstens eines Kompositums sein. Das Kompositum hat die alleinige Verantwortung für Erzeugung und Löschung seiner Komponenten. Wenn ein Kompositum gelöscht wird, werden alle seine Komponenten gelöscht. Es herrscht also eine starke auch zeitliche Bindung. Beispiel: Fahrgestell eines Autos Notation: Aggregat! Kompositum! Teil! Komponente! Aggregation! Komposition! Dr. Ina Schaefer Software Engineering 1 Seite 31
32 OOA nach OMT (Rumbaugh et al. 1991) Iteration Klassen finden Assoziationen und Aggregationen finden OK OK Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 32
33 Attribute Definition: Ein Attribut A einer Klasse K beschreibt ein Datenelement, das in jedem Objekt der Klasse vorhanden ist. Jedes Objekt der Klasse K trägt für jedes Attribut A von K einen individuellen und veränderbaren Attributwert. Notation: A1!...! An! K! Beispiel: Teambesprechung! titel! beginn! dauer! ar12: Teambesprechung titel = "12.Abteilungsrunde" beginn = :00 dauer = 60 Dr. Ina Schaefer Software Engineering 1 Seite 33
34 Datentypen für Attribute Definition: Eine Klasse K kann für ein Attribut A einen bestimmten Datentyp vorschreiben. In allen Objekten der Klasse K sind dann die Attributwerte von A von diesem Datentyp. Die Syntax für Datentypen ist in UML nicht festgelegt. Häufig verwendete Datentypen sind: Einfache Standard-Datentypen (z.b. Boolean, Char, Int) Klassennamen (Dann ist der Attributwert eine Objektreferenz.) Notation: A!!!!oder!!!A : Typ!!!oder!!!A : Typ = Anfangswert Beispiel: Teambesprechung! titel: String! beginn: Date! dauer: Int = 60! Dr. Ina Schaefer Software Engineering 1 Seite 34
35 Klassenattribute Ein Klassenattribut A beschreibt ein Datenelement, das genau einen Wert für die gesamte Klasse annehmen kann. (Gewöhnliche Attribute heißen auch Instanzattribute, weil sie für jede Instanz individuelle Werte annehmen.) Notation: Unterstreichung A : Typ Beispiel: Teambesprechung titel: String beginn: Date dauer: Int anzahl: Int Aber: Klassenattribute verursachen sehr(!) viel Test- und Wartungsprobleme. Deshalb soweit wie möglich vermeiden! Dr. Ina Schaefer Software Engineering 1 Seite 35
36 Klassenkandidaten und Attribute Jede Klasse sollte mindestens ein sinnvolles Attribut tragen oder in mindestens einer Assoziation angebunden sein. Beispiel: Attribut "Reservierungsdatum" für eine Raumreservierung wird benötigt (z.b. um Konflikte aufzulösen). Die Klasse "Reservierung" wird in die bestehende Assoziation eingefügt und "zerlegt" sie in zwei neue Assoziationen. Besprechungsraum 0..1?! 1 VeranstOrt * Teambesprechung Besprechungsraum VeranstOrt * Reservierung Zeitraum Reservierungsdatum 0..1 für 1 Teambesprechung Dr. Ina Schaefer Software Engineering 1 Seite 36 1
37 OOA nach OMT (Rumbaugh et al. 1991) Iteration Klassen finden Assoziationen und Aggregationen finden OK OK Attribute finden OK Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 37
38 Operation Definition: Eine Operation einer Klasse K ist die Beschreibung einer Aufgabe, die jede Instanz der Klasse K ausführen kann. In der Beschreibung der Klasse wird der Name der Operation angegeben. Notation: Klasse Attribut_1... Attribut_n Operation_1... Operation_m Beispiel: Teambesprechung titel beginn dauer raumfestlegen() einladen() absagen() Zur besseren Unterscheidung von Attributnamen werden meist Klammern hinter Operationsnamen gesetzt, auch wenn über die Parameterliste noch keine Aussagen gemacht werden sollen. Dr. Ina Schaefer Software Engineering 1 Seite 38
39 Parameter und Datentypen für Operationen Detaillierungsgrad: Analysephase: meist Operationsname ausreichend Parameternamen und Datentypen können angegeben werden (manchmal auch Parametername ohne Datentyp) Später (Entwurfsphase) sind vollständige Angaben nötig. Notation: Operation (Parameter:ParamTyp,...): ResultTyp Beispiele (Klasse Teambesprechung): raumfestlegen (wunschraum: Besprechungsraum): Boolean absagen (grund: String); Dr. Ina Schaefer Software Engineering 1 Seite 39
40 Klassenoperation Definition: Eine Klassenoperation A einer Klasse K ist die Beschreibung einer Aufgabe, die nur unter Kenntnis der aktuellen Gesamtheit der Instanzen der Klasse ausgeführt werden kann. Gewöhnliche Operationen heißen auch Instanzoperationen. Notation: Unterstreichung analog zu Klassenattributen. Beispiel: Besprechungsraum raumnr kapazität reservieren() freigeben() freienraumsuchen() Dr. Ina Schaefer Software Engineering 1 Seite 40
41 Konstruktor Definition: Ein Konstruktor C einer Klasse K ist eine spezielle Klassenoperation, die eine neue Instanz der Klasse, d.h. ein neues Objekt, erzeugt und initialisiert.! Ergebnistyp von C ist immer implizit die Klasse K. Ein Konstruktor ohne Parameter wird implizit für jede Klasse angenommen. Explizite Konstruktoren können mit "<<constructor>>" markiert werden. Beispiel: raumnr kapazität Besprechungsraum reservieren() freigeben() freienraumsuchen() Besprechungsraum (raumnr, kapazität) <<constructor>> Dr. Ina Schaefer Software Engineering 1 Seite 41
42 Beispiel: Seminar-Organisation Termin Besprechungsraum raumnr kapazität reservieren() freigeben() freienraumsuchen() 0..1 Ort name Team Privater Termin beschreibg beginn dauer ort wegzeit verschieben() * Teambesprechung titel beginn dauer anzahl raumfestlegen() einladen() absagen() verschieben() * leitet Teilnahme 1 * 2..* * für 1 1..* 1 Leiter Teammitglied name abteilung terminbestätigen() genehmigen() Dr. Ina Schaefer Software Engineering 1 Seite 42
43 Zuordnung von Operationen Zweifelsfälle: freienraumsuchen(): Operation von "Besprechungsraum" oder von "Teambesprechung"? genehmigen(): Operation von "Privater Termin" oder von "Teammitglied"? Prinzipien: Möglichst intensive Ausnutzung der Datenzuordnung: da zuordnen, wo am besten von lokaler Information Gebrauch gemacht werden kann Notwendigkeit zur Objektinteraktion möglichst minimieren Möglichst Gebrauch von vorhandenen Operationen machen bzw. Operationen in verschiedenen Kontexten wiederverwenden. Dr. Ina Schaefer Software Engineering 1 Seite 43
44 OOA nach OMT (Rumbaugh et al. 1991) Iteration Iterationen sind wichtig zur Verbesserung/ Erweiterung des entwickelten Modells! Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen OK OK OK OK Vererbungsstrukturen finden Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 44
45 OOA nach OMT (Rumbaugh et al. 1991) OK Iteration Klassen finden OK Assoziationen und Aggregationen finden OK Attribute finden OK Operationen finden Szenarien finden und prüfen OK Vererbungsstrukturen finden Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 45
46 Vererbung Definition: Eine Vererbungsbeziehung von einer Klasse K1 zu einer Klasse K2 ist eine Beschreibung der Tatsache, dass alle Objekte der Klasse K2 zusätzlich zu den in der Klasse K2 beschriebenen Eigenschaften auch alle Eigenschaften der Klasse K1 haben. 'Eigenschaften' sind hier die Liste der Attribute die Teilnahme an Assoziationen, Aggregationen und Kompositionen die Liste der Operationen. Notation: Klasse_1! Umgangssprachlich: Klasse_2! Jedes Klasse_2 ist ein Klasse_1. Klasse_2 ist Spezialfall von Klasse_1. Dr. Ina Schaefer Software Engineering 1 Seite 46
47 Polymorphie Termin... verschieben(neu: Date): Boolean Privater Termin verschieben() Teambesprechung verschieben() :Privater Termin :Teambesprechung verschieben (neu= :00) Die gleiche Nachricht führt zu unterschiedlichen Rechenvorschriften, abhängig vom Empfänger (dynamische Bindung). Dr. Ina Schaefer Software Engineering 1 Seite 47
48 Abstrakte und konkrete Klassen Definition: Eine Klasse kann als abstrakt deklariert werden. In diesem Fall ist es nicht zulässig, Instanzen der Klasse zu bilden. Abstrakte Klassen dienen als "Schema" in der Vererbung und als Gruppierungsmittel, zum Beispiel für gemeinsame Funktionalität. Eine Klasse, von der Instanzen gebildet werden können, heißt konkret. Notation: Beispiel: Klasse! {abstract}!...!...! Termin! {abstract}!...!...! Termin!...!...! Dr. Ina Schaefer Software Engineering 1 Seite 48
49 Abstrakte und konkrete Operationen Definition: Eine Operation OP ist abstrakt, wenn sie keine Implementierung besitzt. Abstrakte Operationen treten nur in abstrakten Klassen auf. Das Verhalten von OP muss dann in Unterklassen definiert werden. Notation: Klasse! {abstract}!...! Operation {abstract}! Beispiel: Termin! {abstract}!...! verschieben() {abstract}! veröffentlichen()!...! Termin! verschieben () veröffentlichen()! Dr. Ina Schaefer Software Engineering 1 Seite 49
50 Zusammenfassung: OOA nach OMT Datenorientierte Vorgehensweise nutzt Klassendiagramme als primäres Modell Iteration ist notwendig, um optimale Beschreibung zu erhalten Es fehlen noch: Szenarien Zustandsdiagramme Operationsspezifikationen Iteration Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Zustandsdiagramme erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Dr. Ina Schaefer Software Engineering 1 Seite 50
51 Muster in der objektorientierten Analyse OOA-Muster (Pattern) helfen gleichartige Situationen in der Analyse zu identifizieren und gleichartig zu modellieren. Wichtige Universelle Muster: Abstrakte Oberklasse Komposition Exemplare und Beschreibung Rollen/Wechselnde Rollen Koordinator Spezifische Muster Dr. Ina Schaefer Software Engineering 1 Seite 51
52 Muster: Abstrakte Oberklasse Universelles Muster (nach Balzert 96) Problem: Klassen enthalten Gruppen identischer Attribute und Operationen. Lösung: Separieren der identischen Bestandteile in einer abstrakten Oberklasse. Klasse A Attributgruppe 1 Attributgruppe 3 Operat.gruppe 1 Operat.gruppe 3 Klasse B Attributgruppe 2 Attributgruppe 3 Operat.gruppe 2 Operat.gruppe 3 Klasse C {abstract} Attributgruppe 3 Operat.gruppe 3 Klasse A Attributgruppe 1 Operat.gruppe 1 Klasse B Attributgruppe 2 Operat.gruppe 2 Dr. Ina Schaefer Software Engineering 1 Seite 52
53 Muster: Komposition Universelles Muster (nach Gamma et al. 95) Andere Namen: Composite (engl.), Stückliste (Heide Balzert) Problem: Tiefe und evtl. veränderliche Hierarchie von Aggregationen Lösung: Abstrakte Oberklasse mit verschiedenen Blattklassen sowie einer Kompositklasse als Unterklassen. {abstract}! Komponente! *! Blatt! Kompositum! Komposition ist ein sehr häufig angewandtes Muster: Bäume, Teile-Ganzes-Hierarchien etc. sind damit realisierbar. Dr. Ina Schaefer Software Engineering 1 Seite 53
54 Muster: Exemplar und Beschreibung Universelles Muster (nach Coad et al. 95) Engl. Name: Item-Item Description Problem: Manche Attribute nehmen bei vielen Instanzen immer wieder die gleichen Kombinationen von Werten an (Attribut- Abhängigkeit). Lösung: Einführung einer neuen Klasse und einer Aggregation. ExemplarUndBeschreibung Attribute mit Abhängigkeiten Exemplar unabh. Attribute 0..* 1 Beschreibung separierte Attribute Dr. Ina Schaefer Software Engineering 1 Seite 54
55 Muster: Rollen Universelles Muster (angelehnt an Heide Balzert 99) Problem: Es bestehen zwei oder mehr verschiedene Einsatzarten einer gegebenen Klasse. Unterklassenbildung würde "überlappende" Vererbung und damit Mehrfachzugehörigkeit von Objekten in Klassen erfordern. Lösung: Einführung einer Assoziation zu einer "Rollen"-Klasse mit Multiplizität entsprechend der Einsatzarten. Zuordnung von Attributen der Einsatzarten zu den Rollenklassen. Klasse A Klasse A 1..2 Rolle Klasse A1 attr11 attr12 Klasse A2 attr21 attr22 Rolle R1 attr11 attr12 Rolle R2 attr21 attr22 Dr. Ina Schaefer Software Engineering 1 Seite 55
56 Muster: Wechselnde Rollen Universelles Muster (nach Heide Balzert 99) Problem: Ein Objekt einer Unterklasse A1 einer Oberklasse A kann in eine andere Unterklasse A2 von A wechseln. Lösung: Einführung einer abstrakten Rollenklasse. Variante des Musters Rolle mit dynamischem Auswechseln des Rollen-Objekts Klasse A Klasse A Klasse A1 Klasse A2 1 Rolle {abstract} Rolle A1 Rolle A2 Dr. Ina Schaefer Software Engineering 1 Seite 56
57 Muster: Koordinator Universelles Muster (nach Heide Balzert 99, Balzert 96) Problem: Eine (zwei- oder mehrstellige) Assoziation besitzt Attribute, die zu keiner der beteiligten Klassen gehören. Lösung: Einführung einer eigenen Koordinator-Klasse Klasse A Y Klasse K X Klasse B Assoziationsattribute Dr. Ina Schaefer Software Engineering 1 Seite 57
58 Koordinator: Beispiel Kunde hat gebucht 0..* 0..* Veranstaltung ort datum discuss Buchungsdatum? Buchungsstatus? ein wesentliches Merkmal dieses Musters ist die beidseitige Kardinalität 0-*, die es verhindert Attribute der ein oder anderen Klasse zuzuordnen. Typisch für Koordinatorklassen ist, dass sie selbst nur wenige Attribute und Operationen besitzen, und mit mehreren Klassen in Verbindung stehen. Dr. Ina Schaefer Software Engineering 1 Seite 58
59 Kombination von Musteranwendungen animated UML-Repräsentation eines Musters Exemplar und Beschreibung Beschreibung Seminartyp seminartitel preis vorkenntnisse Koordinator Exemplar 1 Kunde hält Koordinator für 0..* Buchung 0..* Datum Status 0..* Veranstaltung ort datum Dr. Ina Schaefer Software Engineering 1 Seite 59
60 Wiederverwendung mit Musterkatalogen Ein Muster ist eine schematische Lösung für eine Klasse verwandter Probleme. Muster beschreiben Erfahrungswissen. Darstellung eines Musters Name, evtl. Synonyme Problem Motivation, Anwendungsbereich Lösung(en) Struktur (Klassendiagramm) Bestandteile (schematische Klassen- und Objektnamen) Beschreibung, evtl. Abläufe, z.b. Sequenzdiagramm Diskussion Vor- und Nachteile, Abhängigkeiten, Einschränkungen Beispielanwendungen Verwandte Muster (Ähnlichkeiten) Dr. Ina Schaefer Software Engineering 1 Seite 60
61 Klassifikation von Mustern Modellierungs- Muster Muster... Organisations- Vorgehens- Muster Muster (Process Pattern) Universelle Muster Muster für spezifische Aktivitäten Analysemuster Architekturmuster Entwurfsmuster (Design Pattern) Sprach- Idiome Testmuster Weitere Unterteilung: Allgemein anwendbare Muster (z.b. Komposition) Domänenspezifische Muster (z.b. Kontostruktur im Finanzbereich) Dr. Ina Schaefer Software Engineering 1 Seite 61
62 Zusammenfassung: Objektorientierte Analyse Ziel: Objektorientierte Systemmodellierung Objektorientierung bietet Strukturierungsmöglichkeiten zur Wiederverwendung (Inheritance) und Vorteile bei Änderungen. Anbindung an Anforderungen durch Anwendungsfälle (Use Cases) Verschiedene Vorgehensweisen: Verhaltensorientiert (OOSE) Datenorientiert (OMT) Verschiedene Sichten und Detaillierungsebenen Kernstück: Klassendiagramme ergänzend: Zustandsdiagramme, Sequenzdiagramme, Aktivitätsdiagramme Verwendung bestimmter Analysemuster Dr. Ina Schaefer Software Engineering 1 Seite 62
Systemanalyse und Systemmodellierung - Objekt-orientierte Analyse -
Systemanalyse und Systemmodellierung - Objekt-orientierte Analyse - Software Engineering 1 WS 2011/2011 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von Prof.
3. Objektorientierte Analyse
3. Objektorientierte Analyse 3. Systemanalyse Witzfrage (nach Booch 9): Welches ist der älteste Beruf: Arzt, Bauingenieur oder Systemanalytiker? Anforderungsanalyse Analyse Anforderungs- Ermittlung Anforderungs-
Objekt-Orientierte Analyse - Klassendiagramme -
Objekt-Orientierte Analyse - Klassendiagramme - Software Engineering 1 WS 2012/2013 Prof. Dr. Ina Schaefer, Dipl.-Math, Dipl.-Inf. Joachim Steinmetz Institut für Softwaretechnik und Fahrzeuginformatik
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
Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer
Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Klassendiagramme Ein Klassendiagramm dient in der objektorientierten Softwareentwicklung zur Darstellung von Klassen und den Beziehungen,
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
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
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:
a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. 1 zeigt eine mögliche Lösung. * * * Aufbau 1..
Software Engineering I Musterlösungen zur Klausur vom 3.7.2004 Aufgabe a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. zeigt eine mögliche Lösung. Turnier sportart
Objektorientierte Programmierung
Objektorientierte Programmierung 1 Geschichte Dahl, Nygaard: Simula 67 (Algol 60 + Objektorientierung) Kay et al.: Smalltalk (erste rein-objektorientierte Sprache) Object Pascal, Objective C, C++ (wiederum
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:
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
Seite Objektorientierte Analyse. Methodik der Objektorientierten Analyse. Operation
3. Objektorientierte Analyse 3.1 Systemanalyse 3.2 Statische Modellierung mit UML 3.3 Weitere UML-Diagramme in der Analyse 3.4 Realisierung von UML-Klassen mit Java 3.5 Dynamische Modellierung mit UML
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
Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny
Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny 3. UML Klassendiagramm Nachtrag 3.1 Einführung UML UML ist eine standardisierte Sprache zur Modellierung von Systemen. In UML werden graphische
3. Objektorientierte Analyse
3. Objektorientierte Analyse 3.1 Systemanalyse Softwaretechnologie, Prof. Uwe Aßmann 1 Obligatorische Literatur Zuser, Kap. 7-9 oder Pfleeger, Kap. Requirements Analysis Prof. Uwe Aßmann, Softwaretechnologie
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
Arbeiten mit UMLed und Delphi
Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf
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
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)
Vorlesung Programmieren
Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)
Systemanalyse und Systemmodellierung - Objekt-orientierte Analyse (2) -
Systemanalyse und Systemmodellierung - Objekt-orientierte Analyse (2) - Software Engineering 1 WS 2011/2011 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von
4. AuD Tafelübung T-C3
4. AuD Tafelübung T-C3 Simon Ruderich 17. November 2010 Arrays Unregelmäßige Arrays i n t [ ] [ ] x = new i n t [ 3 ] [ 4 ] ; x [ 2 ] = new i n t [ 2 ] ; for ( i n t i = 0; i < x. l e n g t h ; i ++) {
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
Klassendiagramm. (class diagram)
: Klassendiagramm http:///topic95.html Klassendiagramm (class diagram) Klassendiagramm Objektdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Einstieg Paketdiagramm Aufbau
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/
UML Klassendiagramm. Igor Karlinskiy, Mikhail Gavrish
UML Klassendiagramm Igor Karlinskiy, Mikhail Gavrish Agenda Wichtigste Eigenschaften Syntaktische Elemente mit entsprechendem C++ Code Analysemodell Designmodell Quellen 2 Klassendiagramm gibt die Möglichkeit,
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
Objektorientierte Programmierung OOP
Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Ronja Düffel WS2012/13 08. Oktober 2013 Objektorientierte Programmierung OOP Objektorientierte Programmierung Objektorientierte
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
Einführung in. Logische Schaltungen
Einführung in Logische Schaltungen 1/7 Inhaltsverzeichnis 1. Einführung 1. Was sind logische Schaltungen 2. Grundlegende Elemente 3. Weitere Elemente 4. Beispiel einer logischen Schaltung 2. Notation von
Java Kurs für Anfänger Einheit 4 Klassen und Objekte
Java Kurs für Anfänger Einheit 4 Klassen und Ludwig-Maximilians-Universität München (Institut für Informatik: Programmierung und Softwaretechnik von Prof.Wirsing) 13. Juni 2009 Inhaltsverzeichnis klasse
4. BEZIEHUNGEN ZWISCHEN TABELLEN
4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe
Software-Engineering SS03. Zustandsautomat
Zustandsautomat Definition: Ein endlicher Automat oder Zustandsautomat besteht aus einer endlichen Zahl von internen Konfigurationen - Zustände genannt. Der Zustand eines Systems beinhaltet implizit die
Analysemuster. Marc Monecke monecke@informatik.uni-siegen.de
Analysemuster Marc Monecke monecke@informatik.uni-siegen.de Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D-57068 Siegen 2. Mai 2003 Inhaltsverzeichnis Grundlagen
Datenbankmodelle 1. Das Entity-Relationship-Modell
Datenbankmodelle 1 Das Entity-Relationship-Modell Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle ER Modell - 2 Was kann modelliert werden?
Kapitel 3: Hörsaalbeispiel Klassendiagramm (Analysesicht)
Kapitel 3: Hörsaalbeispiel Klassendiagramm (Analysesicht) Anforderungen In einer Hochschulverwaltung sind mehrere Personengruppen tätig. Die Hochschule hat Angestellte, die Professoren, Labor-Ingenieure,
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
1 Mathematische Grundlagen
Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.
Übungen zu Einführung in die Informatik: Programmierung und Software-Entwicklung: Lösungsvorschlag
Ludwig-Maximilians-Universität München WS 2015/16 Institut für Informatik Übungsblatt 9 Prof. Dr. R. Hennicker, A. Klarl Übungen zu Einführung in die Informatik: Programmierung und Software-Entwicklung:
Übungsblatt 5 - Lösungshilfe
Übungen zur Vorlesung Softwaretechnologie - Wintersemester 2015/16 - Dr. Günter Kniesel Übungsblatt 5 - Lösungshilfe Aufgabe 1. Domain Object Modell(12 Punkte) Stellen Sie Sich vor, Sie sollen für die
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
WhiteStarUML Tutorial
WhiteStarUML Tutorial Autor: Simon Balázs, BME IIT, 2015. Übersetzung: Kovács Márton, 2015. Installation Herunterladen und installieren Sie das WhiteStarUML: http://sourceforge.net/projects/whitestaruml/
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
Lösungsvorschlag für Übungsblatt 6 Software Engineering 1 (WS 2012/13)
Prof. Ina Schaefer Institut für Softwaretechnik und Fahrzeuginformatik TU Braunschweig Lösungsvorschlag für Übungsblatt 6 Software Engineering 1 (WS 2012/13) Ausgabe: 12. Januar 2013 Abgabe: 25. Januar
Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf
Softwareentwicklungspraktikum Sommersemester 2007 Grobentwurf Auftraggeber Technische Universität Braunschweig
Requirements Engineering I
Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen
Objektorientierte Konzepte und Notation in UML. Objekt Klasse Attribut Operation
Objektorientierte Konzepte und Notation in UML Objekt Klasse Attribut Operation Objekt Wodurch zeichnet sich ein Objekt aus? - Zustand - Verhalten - Identität Objektdiagramm - Notationsregeln :Kuh Elsa:Kuh
Würfelt man dabei je genau 10 - mal eine 1, 2, 3, 4, 5 und 6, so beträgt die Anzahl. der verschiedenen Reihenfolgen, in denen man dies tun kann, 60!.
040304 Übung 9a Analysis, Abschnitt 4, Folie 8 Die Wahrscheinlichkeit, dass bei n - maliger Durchführung eines Zufallexperiments ein Ereignis A ( mit Wahrscheinlichkeit p p ( A ) ) für eine beliebige Anzahl
1 topologisches Sortieren
Wolfgang Hönig / Andreas Ecke WS 09/0 topologisches Sortieren. Überblick. Solange noch Knoten vorhanden: a) Suche Knoten v, zu dem keine Kante führt (Falls nicht vorhanden keine topologische Sortierung
Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.
1 2 3 4 Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg. Gerade beim Einstig in der Programmierung muss kontinuierlich
Professionelle Seminare im Bereich MS-Office
Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion
Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin)
Übungsblatt 4 Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Die Saartal Linien beauftragen Sie mit dem Entwurf der Datenstrukturen für ein Informationssystem. Dieses soll zur Verwaltung
Grundlagen der Theoretischen Informatik, SoSe 2008
1. Aufgabenblatt zur Vorlesung Grundlagen der Theoretischen Informatik, SoSe 2008 (Dr. Frank Hoffmann) Lösung von Manuel Jain und Benjamin Bortfeldt Aufgabe 2 Zustandsdiagramme (6 Punkte, wird korrigiert)
Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers
Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des
EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.
EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG
Erstellen von x-y-diagrammen in OpenOffice.calc
Erstellen von x-y-diagrammen in OpenOffice.calc In dieser kleinen Anleitung geht es nur darum, aus einer bestehenden Tabelle ein x-y-diagramm zu erzeugen. D.h. es müssen in der Tabelle mindestens zwei
2. Tutorium zu Softwaretechnik I
2. Tutorium zu Softwaretechnik I Lastenheft, Durchführbarkeitsuntersuchung und Klassendiagramme Michael Hoff 06.05.2014 INSTITUT FÜR PROGRAMMSTRUKTUREN UND DATENORGANISATION KIT Universität des Landes
Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07
Software Engineering 3. Anforderungsanalyse Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering: 3. Anforderungsanalyse 2 Definitionen Anforderungen (Requirements): Beschreibung aller
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als
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
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
Speicher in der Cloud
Speicher in der Cloud Kostenbremse, Sicherheitsrisiko oder Basis für die unternehmensweite Kollaboration? von Cornelius Höchel-Winter 2013 ComConsult Research GmbH, Aachen 3 SYNCHRONISATION TEUFELSZEUG
Nicht kopieren. Der neue Report von: Stefan Ploberger. 1. Ausgabe 2003
Nicht kopieren Der neue Report von: Stefan Ploberger 1. Ausgabe 2003 Herausgeber: Verlag Ploberger & Partner 2003 by: Stefan Ploberger Verlag Ploberger & Partner, Postfach 11 46, D-82065 Baierbrunn Tel.
Datenbanken Kapitel 2
Datenbanken Kapitel 2 1 Eine existierende Datenbank öffnen Eine Datenbank, die mit Microsoft Access erschaffen wurde, kann mit dem gleichen Programm auch wieder geladen werden: Die einfachste Methode ist,
Software-Engineering 2. Übungen zur Wiederholung. IT works. Metris GmbH 27.01.2009 1
Übungen zur Wiederholung IT works. Metris GmbH 27.01.2009 1 Ein Kunde beauftragt Sie mit der Erstellung eines neuen betrieblichen Informationssystems für seine Firma. Welche UML-Diagrammformen würden Sie
egovernment für das Open Source CMS Contao
egovernment für das Open Source CMS Contao egovernment - Leistungsbeschreibung - Seite 1 von 10 Allgemeines Lizenz Die Lizenz gilt für eine Domain. Es steht Ihnen frei das Modul einmalig einem Kunden zur
Einführung in die Java- Programmierung
Einführung in die Java- Programmierung Dr. Volker Riediger Tassilo Horn riediger horn@uni-koblenz.de WiSe 2012/13 1 Wichtig... Mittags keine Pommes... Praktikum A 230 C 207 (Madeleine + Esma) F 112 F 113
7DVWH.HOOQHU. Kassensystem SANYO (X&D6RIWKapitel 42
7DVWH.HOOQHU Sie befinden sich im Dialog 5DXP%LOG Sie Tippen auf die Taste.HOOQHU Sie gelangen danach in den Dialog.HOOQHU/RJLQ. Alle Handlungen, die YRQ,KQHQ durchgeführt werden können sind schwarz dargestellt.
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
teamsync Kurzanleitung
1 teamsync Kurzanleitung Version 4.0-19. November 2012 2 1 Einleitung Mit teamsync können Sie die Produkte teamspace und projectfacts mit Microsoft Outlook synchronisieren.laden Sie sich teamsync hier
Objektorientierte Programmierung für Anfänger am Beispiel PHP
Objektorientierte Programmierung für Anfänger am Beispiel PHP Johannes Mittendorfer http://jmittendorfer.hostingsociety.com 19. August 2012 Abstract Dieses Dokument soll die Vorteile der objektorientierten
5. Abstrakte Klassen. Beispiel (3) Abstrakte Klasse. Beispiel (2) Angenommen, wir wollen die folgende Klassenhierarchie implementieren:
5. Abstrakte Klassen Beispiel 5. Abstrakte Klassen 5. Abstrakte Klassen Beispiel Beispiel (3) Angenommen, wir wollen die folgende Klassenhierarchie implementieren: Probleme des Implementierungsvorschlags:
Grundbegriffe der Informatik
Grundbegriffe der Informatik Einheit 15: Reguläre Ausdrücke und rechtslineare Grammatiken Thomas Worsch Universität Karlsruhe, Fakultät für Informatik Wintersemester 2008/2009 1/25 Was kann man mit endlichen
Einführung in die Programmierung
Technische Universität München WS 2003/2004 Institut für Informatik Prof. Dr. Christoph Zenger Testklausur Einführung in die Programmierung Probeklausur Java (Lösungsvorschlag) 1 Die Klasse ArrayList In
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
Primzahlen und RSA-Verschlüsselung
Primzahlen und RSA-Verschlüsselung Michael Fütterer und Jonathan Zachhuber 1 Einiges zu Primzahlen Ein paar Definitionen: Wir bezeichnen mit Z die Menge der positiven und negativen ganzen Zahlen, also
Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java
Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte
Einführung in die Algebra
Prof. Dr. H. Brenner Osnabrück SS 2009 Einführung in die Algebra Vorlesung 13 Einheiten Definition 13.1. Ein Element u in einem Ring R heißt Einheit, wenn es ein Element v R gibt mit uv = vu = 1. DasElementv
Objektorientierter Entwurf (OOD) Übersicht
Übersicht Das Ziel des OO-Designs (OOD) ist es, die endgültige Architektur festzulegen durch Teil 1: Anbindung der Fachklassen an weitere Systeme: Benutzeroberfläche (mit MVC) Datenhaltung (Datenbank-Lösung
Anleitung über den Umgang mit Schildern
Anleitung über den Umgang mit Schildern -Vorwort -Wo bekommt man Schilder? -Wo und wie speichert man die Schilder? -Wie füge ich die Schilder in meinen Track ein? -Welche Bauteile kann man noch für Schilder
Rhetorik und Argumentationstheorie. [frederik.gierlinger@univie.ac.at]
Rhetorik und Argumentationstheorie 1 [frederik.gierlinger@univie.ac.at] Ablauf der Veranstaltung Termine 1-6 Erarbeitung diverser Grundbegriffe Termine 7-12 Besprechung von philosophischen Aufsätzen Termin
Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
Vererbung & Schnittstellen in C#
Vererbung & Schnittstellen in C# Inhaltsübersicht - Vorüberlegung - Vererbung - Schnittstellenklassen - Zusammenfassung 1 Vorüberlegung Wozu benötigt man Vererbung überhaubt? 1.Um Zeit zu sparen! Verwendung
Klausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
Fachhochschule Bonn-Rhein-Sieg University of Applied Sciences Fachbereich Informatik Prof. Dr. Peter Becker Klausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung.
Siehe auch Heide Balzert: Lehrbuch der Objektmodellierung. 9. Analyse Muster 1 Der Unterschied von Analyse und Design Pattern besteht auch in der zeitlichen Abfolge. Analyse Muster werden in der Analyse
BEISPIELKLAUSUR Softwareentwicklung:
Prof. Dr. Andreas Fink Institut für Informatik Fakultät für Wirtschafts- und Sozialwissenschaften Helmut-Schmidt-Universität / Universität der Bundeswehr Hamburg BEISPIELKLAUSUR Softwareentwicklung: Objektorientierte
Anleitung zum neuen Überaumbuchungssystem der Hochschule für Musik und Tanz Köln
Anleitung zum neuen Überaumbuchungssystem der Hochschule für Musik und Tanz Köln Dieses System wird im Sommersemester 2015 getestet und gilt nur für das Übehaus. Das Üben in Räumen des Haupthauses wird
Computeranwendung und Programmierung (CuP)
Computeranwendung und Programmierung (CuP) VO: Peter Auer (Informationstechnologie) UE: Norbert Seifter (Angewandet Mathematik) Organisatorisches (Vorlesung) Vorlesungszeiten Montag 11:15 12:45 Freitag
Große Übung Praktische Informatik 1
Große Übung Praktische Informatik 1 2005-12-08 fuessler@informatik.uni-mannheim.de http://www.informatik.uni-mannheim.de/pi4/people/fuessler 1: Announcements / Orga Weihnachtsklausur zählt als Übungsblatt,
Softwarepraktikum: Enigma
Softwarepraktikum: Enigma Martin Steffen Sommersemester 2003 Abschnitt I Softwareentwurf Bereiche der Softwareentwicklung 1 Softwareentwurf eigentliche Softwareentwicklung Projektmanagement Konfigurationsmanagement
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:
Software Engineering. Zur Architektur der Applikation Data Repository. Franz-Josef Elmer, Universität Basel, HS 2015
Software Engineering Zur Architektur der Applikation Data Repository Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering: Mit acht bewährten Praktiken zu gutem Code 2 Schichtarchitektur
Kapitel 4 Die Datenbank Kuchenbestellung Seite 1
Kapitel 4 Die Datenbank Kuchenbestellung Seite 1 4 Die Datenbank Kuchenbestellung In diesem Kapitel werde ich die Theorie aus Kapitel 2 Die Datenbank Buchausleihe an Hand einer weiteren Datenbank Kuchenbestellung
Lizenzierung von SharePoint Server 2013
Lizenzierung von SharePoint Server 2013 Das Lizenzmodell von SharePoint Server 2013 besteht aus zwei Komponenten: Serverlizenzen zur Lizenzierung der Serversoftware und CALs zur Lizenzierung der Zugriffe
Um die Rücklagen ordnungsgemäß zu verbuchen, ist es wichtig, Schritt-für-Schritt vorzugehen:
Software WISO Hausverwalter 2014 Thema Eingabe von Rücklagenbuchungen Version / Datum V 1.2 / 28.05.2013 Um die Rücklagen ordnungsgemäß zu verbuchen, ist es wichtig, Schritt-für-Schritt vorzugehen: Schritt
MORE Profile. Pass- und Lizenzverwaltungssystem. Stand: 19.02.2014 MORE Projects GmbH
MORE Profile Pass- und Lizenzverwaltungssystem erstellt von: Thorsten Schumann erreichbar unter: thorsten.schumann@more-projects.de Stand: MORE Projects GmbH Einführung Die in More Profile integrierte
OECD Programme for International Student Assessment PISA 2000. Lösungen der Beispielaufgaben aus dem Mathematiktest. Deutschland
OECD Programme for International Student Assessment Deutschland PISA 2000 Lösungen der Beispielaufgaben aus dem Mathematiktest Beispielaufgaben PISA-Hauptstudie 2000 Seite 3 UNIT ÄPFEL Beispielaufgaben
GEZIELT MEHR SICHERHEIT MIT 4I ACCESS SERVER & 4I CONNECT CLIENT
Seite 1/7 GEZIELT MEHR SICHERHEIT MIT 4I ACCESS SERVER & 4I CONNECT CLIENT ZENTRAL LOKALE MANAGEMENT-PLATTFORM FÜR EINE W ELTWEIT SICHERE INDUSTRIELLE KOMMUNIKATION. Seite 2/7 Auf den folgenden Seiten
Hilfe Bearbeitung von Rahmenleistungsverzeichnissen
Hilfe Bearbeitung von Rahmenleistungsverzeichnissen Allgemeine Hinweise Inhaltsverzeichnis 1 Allgemeine Hinweise... 3 1.1 Grundlagen...3 1.2 Erstellen und Bearbeiten eines Rahmen-Leistungsverzeichnisses...