Nr. 1 L-Aufgabe
|
|
- Mareke Michel
- vor 5 Jahren
- Abrufe
Transkript
1 Nr. 1 L-Aufgabe a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Daher verzichten wir auf Klassen, die zwar der Problemwelt entstammen, aber für die Lösung der geforderten Aufgabe und zur Beantwortung der vom Auftraggeber genannten Anfragen nicht erforderlich sind. In diese Kategorie fallen Klassen wie "Produktgruppe", "Warenkorb", "Produktliste", "Kasse", "Einkauf", "Zahlung", "Kreditkarte", "Preis", "Kundenkonto", "Buchung" usw. Zur Lösung der Aufgabenstellung reicht das nachfolgende Klassendiagramm aus. Wichtig ist, dass bei der Bestellung von Waren deren Preis festgehalten wird und dass eine Bestellung auch mit Produkten verbunden sein kann, die nicht mehr im Sortiment sind. Daher definieren wir ein Attribut imsortiment in der Klasse Produkt und ein Attribut bestellpreis in der Klasse Einzelposten. b) Die erste folgende Abbildung zeigt das Objektdiagramm vor der Ausführung des Bezahlvorgangs, die nächste zeigt das Objektdiagramm danach. Objektdiagramm 11
2 Objektdiagramm (danach) c) Es gibt mehrere Möglichkeiten, die beschriebenen Vorgänge als Anwendungsfälle zu modellieren. Die nachfolgende Abbildung zeigt eine davon. 2
3 Nr. 2 Aufgabe _09 a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Daher verzichten wir auf Klassen wie Sofortkauf, Bewertung oder Benachrichtigung. Abb. 1 zeigt eine mögliche Lösung. Ein Kunde kann als Verkäufer eine Auktion initiieren, als Käufer einen Kauf tätigen und als Bieter ein Gebot abgeben. Im ersten Fall ist keine Zusatzinformation notwendig, daher wird eine einfache Assoziation initiiert modelliert. Im zweiten und dritten Fall ist Zusatzinformation notwendig, die durch Attribute der Klassen Kauf und Gebot modelliert wird. Die Realisierung dieser Klassen ist jedoch unterschiedlich, weil es zu jedem Paar (Kunde, Auktion) nur eine Kauf-Instanz, aber mehrere Gebot-Instanzen geben kann. Da zwei Objekte über eine Assoziation nicht mehrfach verbunden sein können, kann nur die Klasse Kauf als Assoziationsklasse modelliert werden, während Gebot eine eigenständige Klasse sein muss. 33
4 b) Abb. 2 zeigt ein Objektdiagramm des Online-Auktionssystems. c) Anwendungsfallspezifikation für den Anwendungsfall "Auktion beenden": use case Auktion beenden actors Systemuhr precondition Bei einer Auktion wurde der Versteigerungs-Endzeitpunkt überschritten. main flow Das System ermittelt das höchste Gebot. Das System registriert einen Kauf des versteigerten Artikels durch den Höchstbietenden. Der Verkäufer und alle Bieter werden über den Ausgang der Versteigerung informiert. postcondition Für die Auktion können keine Gebote mehr abgegeben werden. exceptional flow keine Gebote vorhanden Der Verkäufer wird informiert, dass der Artikel nicht ersteigert wurde. postcondition Für die Auktion können keine Gebote mehr abgegeben werden. end Auktion beenden. 4
5 Nr. 3 L-Aufgabe a) Die nachfolgende Abbildung zeigt eine Lösung für ein Klassendiagramm, das die Anforderungen der Aufgabenstellung erfüllt. b) Für die in a) gezeigten Vereinfachungen sprechen folgende Gründe: Die Information, ob es sich bei einer Schülergruppe um eine Klasse oder einen Kurs handelt, kann einfacher in einem Attribut festgehalten werden. Gleiches gilt für die Jahrgangstufe einer Klasse oder eines Kurses. Da sich das Verhalten dieser Klassen nicht (oder nur sehr geringfügig) unterscheidet, können sie nach Heuristik H 25.5 zusammengefasst werden. Die Information, ob eine Schülergruppe zur Ober-, Mittel- oder Unterstufe gehört, lässt sich aus der Jahrgangstufe entnehmen und braucht daher nicht extra modelliert zu werden. Die Angabe des Wochentags ist nicht für alle Unterrichtsstunden, sondern nur für reguläre Unterrichtsstunden erforderlich. Bei Vertretungsstunden ist der Wochentag durch das Datum gegeben. Für die Angabe des Wochentags ist keine eigene Klasse erforderlich, daher wurde die Klasse Wochentag durch ein Attribut Wochentag in der Klasse ReguläreStunde ersetzt. Die Assoziation GibtUnterricht ist zu stark generalisiert: Sie enthält sowohl Stunden aus dem Lehrerstundenplan (reguläre Stunden) als auch Vertretungsstunden. Da der Lehrerstundenplan und der Vertretungsplan in der Anwendungsdomäne separat gehandhabt werden, ist es sinnvoll, die Assoziation GibtUnterricht in der Aufgabenstellung durch die Assoziationen Lehrerstundenplan und Vertretungsplan zu ersetzen (s. obige Abbildung). 55
6 Nr. 4 L-Aufgabe a) und c) Die folgende Abbildung zeigt ein Klassendiagramm, das die Anforderungen der Aufgabenstellung erfüllt. Verbessertes Klassendiagramm zur Reservierungsverwaltung b) Für die in a) gezeigten Vereinfachungen sprechen folgende Gründe: Zu der Klasse Theater existiert in der Anwendung nicht mehr als eine Instanz. Daher wird die Klasse gemäß Merkregel R19.6 aus dem Diagramm entfernt. Das Attribut anzahlsitze ist überflüssig, es kann aus der Anzahl der Instanzen der Klasse Sitz berechnet werden. Die Klassen Parkett und Loge besitzen das gleiche Verhalten und werden gemäß Heuristik H25.5 mit Hilfe der Attribute bezeichnung und preis der Klasse Kategorie modelliert. Die Attribute titel, datum und beginn der Klasse Ticket sind redundant und werden aus dem Modell entfernt. Das Attribut anzverkauftetickets der Klasse Premiere ist redundant und wird entfernt. Die Klasse Premiere wird gemäß Heuristik H25.5 als Attribut der Klasse Vorstellung modelliert. Da der Kunde bei Einzelreservierungen nicht relevant ist, wird die Assoziation der Klasse Kunde zur Klasse Reservierung entfernt und durch eine Assoziation zur Klasse Jahresabonnement ersetzt. Da die Klasse Reservierung kein Attribut und keine Assoziation mehr besitzt wird sie aus dem Modell entfernt. Die Klasse Bankverbindung ist statt mit der Klasse Jahresabonnement nun mit der Klasse Kunde assoziiert, da zu einem Kunden gleichzeitig nur höchstens eine Bankverbindung existiert und so Redundanz vermieden wird. Anm. zu c) Nur bei neu hinzu gekommenen, korrekten Assoziationen wurden Punkte vergeben. 6
7 Nr. 5 L-Aufgabe Die folgende Abbildung zeigt das Zustandsdiagramm des mobilen Roboters: Nr. 6 L-Aufgabe A Zustandsdiagramm für den mobilen Roboter In dieser Aufgabe sollten Sie ein Zustandsdiagramm für die Klasse Steuerung einer einfachen Fahrstuhlsteuerung entwickeln. a) Zustandsdiagramm für die Fahrstuhlsteuerung 77
8 Aus Gründen der Übersichtlichkeit ist bei den Aktionen (Operationsaufrufen) das Ziel nicht angegeben. So wäre z.b. die Aktion stop() an dem Übergang vom Zustand "Fahrt" in den Zustand "WartendTürOffen" präzise als Aufzugmotor.stop() zu schreiben. b) Die folgende Abbildung zeigt das Klassenmodell der Fahrstuhlsteuerung nach der Transformation. Nr. 7 L-Aufgabe A a) Die Abbildung auf Seite 9 stellt das Anwendungsfalldiagramm des Fahrkartenautomaten dar. b) Textuelle Spezifikation des Anwendungsfalls "Fahrkarte kaufen": use case Fahrkarte kaufen actors Kunde main flow Der Kunde wählt die Fahrkarte aus (include "Fahrkarte wählen). Der Automat zeigt den zu zahlenden Fahrpreis an. Der Kunde bezahlt den Fahrpreis (include "Fahrpreis bezahlen"). Der Automat gibt die Fahrkarte aus. exceptional flow Abbruch Der Kunde drückt die Abbruch-Taste. Die Auswahl der Fahrkarte wird aufgehoben und keine Fahrkarte ausgegeben. 8
9 exceptional flow TimeOut Die vollständige oder unvollständige Auswahl der Fahrkarte wird aufgehoben, wenn nicht innerhalb eines bestimmten Zeitraums die Bezahlung des Fahrpreises erfolgt. Es wird in diesem Fall keine Fahrkarte ausgegeben. exceptional flow Bezahlung fehlgeschlagen Die Bezahlung ist nicht erfolgreich. Die Auswahl der Fahrkarte wird gelöscht und keine Fahrkarte ausgegeben. end Fahrkarte kaufen Nr. 8 L-Aufgabe a) Die folgende Abbildung zeigt den Mechanismus des Anwendungsfalls "Video ausleihen" für den Grobentwurf. 99
10 Sequenzdiagramm zum Szenario c) Nein. Sequenzdiagramme unterstützen die Darstellung von alternativen Abläufen nur unzureichend. 10
11 Nr.9 Aufgabe _09 a) Ein Iterator ist ein Objekt, das die Elemente eines Behälterobjekts aufzählen kann und zu diesem Zweck die Operationen hasnext():boolean und next():object anbietet. b) Abb. 4 zeigt das Sequenzdiagramm für den Ablauf der Operation tostring() der Klasse HashSet. c) Die Variable index hat den Wert 1, weil an der Indexposition 1 das erste gültige Element liegt. d) Die Operation muss nur einmal aufgerufen werden, weil sie das nächste verwendete (=gültige) Element sucht. e) Abb. 5 zeigt das verfeinerte Sequenzdiagramm für den Ablauf der Operation tostring() der Klasse HashSet. f) Wenn dem HashSet neue Elemente hinzugefügt werden, werden diese an irgendwelchen (von der Hashfunktion abhängigen) Stellen in das Array hashtable eingefügt. Der Iterator wird die neu eingefügten Elemente ausgeben, sofern sie im Array hinter der Stelle index liegen. Mit anderen Worten: Die nachträglich eingefügten Elemente werden "vielleicht" ausgegeben. Anmerkung: Eine gute Iterator-Implementierung sollte im Fall von nachträglichen Veränderungen der durchlaufenen Datenstruktur entweder eine Fehlermeldung liefern oder ein anderes, klar definiertes Verhalten zeigen. 1111
12 12
13 Nr. 10 L-Aufgabe A a) Die folgende Abbildung zeigt das Sequenz-Diagramm für den Fall, dass ein Dienstnutzer die Operation hinzufügenkunde() eines Kundenordners aufruft. b) Die folgende Abbildung zeigt das Kollaborationsdiagramm für den Fall, dass ein Dienstnutzer einen Kundenbrowser erzeugt. 1313
14 Nr. 11 L-Aufgabe a) Die echten Ganzes-Klassen sind C und D. b) Die folgende Abbildung zeigt das Feinentwurfs-Klassendiagramm. Feinentwurfs-Klassendiagramm Alternative Verfeinerung der Assoziation zwischen Klasse A und D bzw. B und D: 14
15 Nr. 12 L-Aufgabe _09 a) Es sind fünfverbindungen erforderlich, vgl. Abb. 7. b) Die Objekte b1, b2, d1, d2 und f1 sind von Instanzen anderer Klassen aus erreichbar. c) Von den Klassen B und D ist jede Instanz erreichbar. d) Die Klassen A, C, E, F, G, H, und I sind Echte Ganzes-Klassen. e) Echte Ganzes-Klassen sind genau die Klassen, für die im Entwurf auf jeden Fall ein Ordner vorgesehen werden muss, da sonst nicht alle Instanzen erreichbar sind. 1515
Nr. 1 L-Aufgabe
Nr. 1 L-Aufgabe 1.2004 a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. 1 zeigt eine mögliche Lösung. Klassendiagramm für den Tunierveranstalter Zwischen Team und
MehrSoftware Engineering I. Musterlösungen zur Klausur vom Aufgabe 1
1 Software Engineering I Musterlösungen zur Klausur vom 3.8.2002 Aufgabe 1 a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Daher verzichten wir auf Klassen, die zwar der
MehrAuktion name adresse pseudonym emailadresse /bewertungszahl. Gebot. höhe zeitpunkt bieter. initiiert
Software Engineering I Musterlösungen zur Klausur vom 2.8.2003 Aufgabe a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Daher verzichten wir auf Klassen wie Sofortkauf,
Mehra) Abb. 1 zeigt das Domänen-Klassendiagramm für das Verwaltungssystem. Kunde vorname: String nachname: String geburtstag: Datum adresse: String
Software Engineering I Musterlösungen zur Klausur vom 29.3.2003 Aufgabe a) Abb. zeigt das Domänen-Klassendiagramm für das Verwaltungssystem. Kunde Trainer Jahresvertrag vertragsabschluss: Datum vertragsbeginn:
MehrStudientage in Hagen Kurs /18
Nr. 1 Aufgabe 1.2002 In dieser Aufgabe sollen Sie ein Domänen-Klassendiagramm, zwei Objektdiagramme und ein Anwendungsfalldiagramm erstellen. Ein Versandhandel möchte ein Warenbestellsystem erstellen,
MehrKurs 1793 Software Engineering I - Grundkonzepte der OOSE Klausur am 29.3.2003
Kurs 793 Software Engineering I - Grundkonzepte der OOSE Seite: Wintersemester 2002 Hinweise zur Bearbeitung der Klausur zum Kurs 793 Software Engineering I - Grundkonzepte der OOSE Wir begrüßen Sie zur
MehrKurs 1793 Software Engineering I - Grundkonzepte der OOSE Klausur am
Seite: 1 Sommersemester 2003 Hinweise zur Bearbeitung der Klausur zum Kurs 1793 Software Engineering I - Grundkonzepte der OOSE Wir begrüßen Sie zur Klausur "Software Engineering I". Bitte lesen Sie sich
Mehra) Einen Mechanismus für den AF "Vergehen erfassen" zeigt die Abb. 1. Vergehen erfassen Vergehen erfassen «include» VergehenErfassenK «use» Vergehen
Software Engineering I Musterlösungen zur Klausur vom 3.8.2005 Aufgabe a) Einen Mechanismus für den AF "Vergehen erfassen" zeigt die Abb.. Sachbearbeiter Vergehen erfassen «include» Delikt auswaehlen Vergehen
MehrAufgabe 1 (Anwendungsfalldiagramm)
Studientag in Hagen Kurs 1793 11.01.2014 Aufgabe 1 (Anwendungsfalldiagramm) In dieser Aufgabe soll ein Anwendungsfalldiagramm für die im Folgenden beschriebenen Abläufe bei dem Kauf einer Fahrkarte an
Mehra) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. 1 zeigt eine mögliche Lösung.
Software Engineering I Musterlösungen zur Klausur vom 2.8.2006 Aufgabe a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. zeigt eine mögliche Lösung. Kunde name vorname...
MehrAufgabe 1 (Anwendungsfalldiagramm)
Studientag in Hagen Kurs 1793 08.07.2012 Aufgabe 1 (Anwendungsfalldiagramm) In dieser Aufgabe soll ein Anwendungsfalldiagramm für die im Folgenden beschriebenen Abläufe bei dem Kauf einer Fahrkarte an
MehrKurs 1793 Software Engineering I - Grundkonzepte der OOSE Klausur am
Seite: 1 Sommersemester 2005 Hinweise zur Bearbeitung der Klausur zum Kurs 1793 Software Engineering I - Grundkonzepte der OOSE Wir begrüßen Sie zur Klausur "Software Engineering I". Bitte lesen Sie sich
MehrPRÜ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: 03.03.2011 Prüfungsdauer:
MehrÜbungsaufgaben Softwaretechnologie
HTW Dresden Fakultät Elektrotechnik Übungsaufgaben Softwaretechnologie Gudrun Flach February 21, 2017 - Aufgaben aus : Übungen zur Vorlesung Softwaretechnologie (WS 2014/15), Uni Bonn Aufgabe 1 (Klassendiagramm)
MehrDepot id guthaben. Bestand. Position stueckzahl /aktwert. * Enthaltenes. Wertpapier. Wertpapier. wpkn. Gelistete Wertpapiere Handelsverlauf
Software Engineering I Aufgabe Kunde name vorname geburtsdatum Inhaber Depot id guthaben Bestand Optionsschein fälligkeit typ bezugsverhältnis basis Bezogen Auf Aktie unternehmen dividende nennwert Handelsinfo
MehrNr. 1 Aufgabe 1.2004. Studientage in Hagen Kurs 01793 2011-07-16/17
Nr. 1 Aufgabe 1.2004 Ein Ausrichter großer Sportveranstaltungen möchte ein System entwickeln, das ihn bei den Tätigkeiten unterstützt, die im Rahmen der Durchführung internationaler Turniere in Sportarten
MehrKurs 1793 Software Engineering I - Grundkonzepte der OOSE Klausur am 3.8.2002
Seite: 1 Sommersemester 2002 Hinweise zur Bearbeitung der Klausur zum Kurs 1793 Software Engineering I - Grundkonzepte der OOSE Wir begrüßen Sie zur Klausur "Software Engineering I". Bitte lesen Sie sich
MehrInhalt. 1 Einführung 17. Strukturdiagramme. 2 Klassendiagramm 37
Vorwort... 13 1 Einführung 17 1.1 Weshalb muss Software modelliert werden?... 17 1.2 Die Phasen bei der Softwareentwicklung... 18 1.2.1 Analyse... 18 1.2.2 Entwurf... 19 1.2.3 Implementierung und Dokumentation...
MehrSoftwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler
Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 7 Lösungshilfe Aufgabe 1. Analysephase (12 Punkte) Eine Firma hat den Auftrag erhalten eine
MehrUML (Unified Modelling Language) von Christian Bartl
UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...
MehrÜbungen Softwaretechnik I
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 5: Objektorientierte Analyse Einführung Objektorientierung in der
MehrChristoph Kecher, Alexander Salvanos UML 2.5. Das umfassende Handbuch. Rheinwerk. Computing
Christoph Kecher, Alexander Salvanos UML 2.5 Das umfassende Handbuch Rheinwerk Computing Inhalt Vorwort 13 1 Einführung 17 1.1 Weshalb muss Software modelliert werden? 17 1.2 Die Phasen bei der Softwareentwicklung
MehrKlausur "OOAD" im SS Name, Vorname: Matrikel-Nr:
Klausur "OOAD" im SS 2009 Name, Vorname: Matrikel-Nr:.... Bitte tragen Sie zuerst Ihren Namen und Ihre Matrikelnummer ein. Lesen Sie jeweils vor Erarbeitung der Lösung die ganze Aufgabenstellung durch.
MehrAufgabe 1: Sequenzdiagramm Gegeben ist das in Abbildung 1 dargestellte (vereinfachte) Sequenzdiagramm mit sechs Ereignissen (a-f ).
VU Objektorientierte Modellierung Übung 4 188.391, SS2007 Tutorenstunden: Di. 8.5.2007 bis Fr. 11.5.2007 Übungsgruppen: Mo. 14.5.2007 bis Fr. 18.5.2007 Aufgabe 1: Sequenzdiagramm Gegeben ist das in Abbildung
MehrUML -Klassendiagramme
UML -Klassendiagramme UML - offline: ArgoUML http://argouml.stage.tigris.org/ UML online: Links genmymodel.com umlet.com/umletino/umletino.html Arten von UML-Diagrammen Diagramm Strukturdiagramm Verhaltensdiagramm
MehrTEIL I Strukturdiagramme 1 Einführung Klassendiagramm Objektdiagramm Kompositionsstrukturdiagramm...
Auf einen Blick TEIL I Strukturdiagramme 1 Einführung... 13 2 Klassendiagramm... 29 3 Objektdiagramm... 111 4 Kompositionsstrukturdiagramm... 125 5 Komponentendiagramm... 145 6 Verteilungsdiagramm... 161
MehrUML - SequenzDiagramme
UML - Sequenzdiagramme - Seite 1 UML - SequenzDiagramme (1.) Kopieren Sie das erste Beispiel in Dateien und lassen Sie es laufen! Zeichnen Sie das zugehörige Sequenzdiagramm aus dem Quellkode(evtl. rechte
MehrInformatik IIa: Modellierung
Informatik IIa: Modellierung Frühlingssemester 2014 Übung 5: Klassendiagramme, EPK Kapitel 8, 9 Ausgabe: 17.04.2014 Abgabe: 02.05.2014 Name: Matrikelnummer: Aufgabe 1 Wissen zu EPKs (6 Punkte) Frage 1.1
MehrKlassendiagramm im Rahmen der objekt-orientierten Analyse
Klassendiagramm im Rahmen der objekt-orientierten Analyse Jahrgangsstufen 12, 13 Stand: 04.04.2018 Fach/Fächer Übergreifende Bildungsund Erziehungsziele Informatik Technische Bildung, Medienbildung, Berufliche
MehrDas umfassende Handbuch
Christoph Kecher UML 2.0 Das umfassende Handbuch. Jfjf- Ali' ' w v^i* >" '-«(."', Galileo Press Inhalt Vorwort 11 1 Einführung 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3
MehrUML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language
UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language ADV-Seminar Leiter: Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?
MehrSo#waretechnologie für Fortgeschri4ene Teil Eide. Stunde IV: UML. Köln 26. Januar 2017
So#waretechnologie für Fortgeschri4ene Teil Eide Stunde IV: UML Köln 26. Januar 2017 Model of vs. model for TheoreKcal model model for comparison calibra9on verifica9on Empirical model model of deduc9on
MehrKurs 1793 Software Engineering I Nachklausur am 25.09.1999
Seite: 1 Aufgabe 1 (15 Punkte) Raumplanung In dieser Aufgabe soll anhand einer Problembeschreibung ein ER-Diagramm entworfen werden. Problembeschreibung In der Oberstufe einer Schule werden die Schüler
MehrKlausur. Softwareentwurf. 22. März 2011 Bearbeitungszeit: 120 Minuten
Klausur Softwareentwurf 22. März 2011 Bearbeitungszeit: 120 Minuten FG Datenbank- und Informationssysteme Prof. Dr. Gregor Engels unbedingt vollständig und lesbar ausfüllen! Vorname: Matrikelnummer: [
MehrSoftwaretechnik 2015/2016
Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 11: 14.01.2016 Schon
MehrUML 2.0 Das umfassende Handbuch
Christoph Kecher V.-M \MM UML 2.0 Das umfassende Handbuch Galileo Computing Inhalt Vorwort 11 1 Einführung 13 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3 Die Geschichte
MehrAufgabe S1: Einmal quer durch s Skript
Aufgabe S1: Einmal quer durch s Skript / 10 Punkten Entscheiden Sie, ob die folgenden Aussagen zutreffen oder nicht. Machen Sie in der entsprechenden Spalte ein Kreuz. Für jede richtige Antwort erhalten
Mehr4. Modellieren und Diagrammarten
4. Modellieren und Diagrammarten Zur Entwicklung einer Software ist eine strukturierte Planung notwendig. Erst auf der Grundlage eines Modells (z.b. geeignete Klassendiagramme) kann eine Implementierung
MehrKlausur. Softwareentwurf. 14. Februar 2011 Bearbeitungszeit: 120 Minuten
Klausur Softwareentwurf 14. Februar 2011 Bearbeitungszeit: 120 Minuten FG Datenbank- und Informationssysteme Prof. Dr. Gregor Engels unbedingt vollständig und lesbar ausfüllen! Vorname: Matrikelnummer:
MehrObjektorientierte Analyse (OOA) Inhaltsübersicht
Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der
MehrVorlesung Datenbank-Entwurf Klausur
Dr. Stefan Brass 3. Juli 2002 Institut für Informatik Universität Giessen Vorlesung Datenbank-Entwurf Klausur Name: Geburtsdatum: Geburtsort: (Diese Daten werden zur Ausstellung des Leistungsnachweises
MehrModellierungstipps für die Anwendungsfallmodellierung
Modellierungstipps für die Anwendungsfallmodellierung Identifiziere nur relativ grobe Abläufe als Anwendungsfälle! Anwendungsfälle werden nicht in weitere Anwendungsfälle zerlegt, höchstens unter Verwendung
MehrKurs 1793 Software Engineering I Klausur am Sommersemester Hinweise zur Bearbeitung der Klausur zum Kurs 1793 Software Engineering I
Seite: 1 Sommersemester 2006 Hinweise zur Bearbeitung der Klausur zum Wir begrüßen Sie zur Klausur "Software Engineering I". Bitte lesen Sie sich diese Hinweise vollständig und aufmerksam durch, bevor
MehrMPGI 3 SLK A. Wintersemester 2011/ Februar 2012
Technische Universität Berlin Institut für Softwaretechnik und Theoretische Informatik FG Softwaretechnik Ernst-Reuter-Platz 7 10587 Berlin Jähnichen Mehlhase Rein-Jury MPGI 3 SLK A Wintersemester 2011/2012
MehrSoftware- und Systementwicklung
Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm
Mehra) 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
MehrFormale Modellierung Vorlesung vom : Beyond JML
Rev. 1702 1 [12] Formale Modellierung Vorlesung vom 07.05.12: Beyond JML Till Mossakowski & Christoph Lüth Universität Bremen Sommersemester 2012 2 [12] Heute im Programm Grenzen der JML Nach JML: UML
MehrWirtschaftsinformatik 6a: Modellierung. Hochschule für Wirtschaft und Recht SS 16 Dozent: R. Witte
Wirtschaftsinformatik 6a: Modellierung Hochschule für Wirtschaft und Recht SS 16 Dozent: R. Witte Computertechnik Man kann Software auf 2 Arten herstellen: Entweder macht man sie so klar und einfach,
MehrSoftwaretechnologie für Fortgeschrittene Wohce 4 Modellierung UML
Softwaretechnologie für Fortgeschrittene Wohce 4 Modellierung UML The role of UML Theoretical model model for comparison calibration verification Empirical model model of deduction induction Generating
MehrUnified Modeling Language 2
Unified Modeling Language 2 Marvin Frommhold 17.11.2008 Gliederung Einleitung Geschichte Strukturierung der Spezifikation Diagrammtypen Strukturdiagramme Verhaltensdiagramme CASE-Werkzeuge Quellen Was
MehrAbbildungsverweise PlantUML Code. Version 1.0 Vanessa Petrausch
Abbildungsverweise PlantUML Code Version 1.0 Vanessa Petrausch Inhaltsverzeichnis INHALTSVERZEICHNIS 1 AUFBAU DES DOKUMENTS 5 2 KLASSENDIAGRAMM 7 3 ANWENDUNGSFALLDIAGRAMM 9 4 AKTIVITÄTSDIAGRAMM 11 5 ZUSTANDSDIAGRAMM
MehrOO-Design. Klausur FHF * WI1 / WI2 * SS Name:.../ Semester:...
OO-Design Klausur FHF * WI1 / WI2 * SS 2000 Name:.../ Semester:... Lineares Benotungsschema: 90 Punkte = Note 1, 30 Punkte = Note 4 Aufgabe 1: (28 Punkte) - Ergänzen Sie zum Fallbeispiel "Seminaranmeldung"
MehrKapitel 2 - Die Definitionsphase
Kapitel 2 - Die Definitionsphase SWT I Sommersemester 2010 Walter F. Tichy, Andreas Höfer, Korbinian Molitorisz IPD Tichy, Fakultät für Informatik KIT die Kooperation von Forschungszentrum Karlsruhe GmbH
MehrUnified Modeling Language
Unified Modeling Language Thomas Röfer Motivation Entwicklung Spracheinheiten Diagramme (Struktur-/Verhaltensdiagramme) Rückblick Textsuche Naive Suche abrakadabra Boyer-Moore abrakadabra a Knuth-Morris-Pratt
MehrNACHRICHTENTECHNISCHER SYSTEME
Einführung UML COMPUTERSIMULATION NACHRICHTENTECHNISCHER SYSTEME 11. Unified Modeling Language UML 220 Standardsprache d zur Visualisierung, i Spezifikation, Konstruktion und Dokumentation komplexer (Software-)
Mehr4. Übung zu Software Engineering
4. Übung zu Software Engineering WS 2007/2008 Aufgabe 8 Erstellen Sie für den aus Aufgabe 1 bekannten Function-Point-Kalkulator ein Pflichtenheft. Bitte begrenzen Sie dessen Umfang auf maximal 2 DIN A4
MehrKlausur. Softwareentwurf. 04. Februar 2013 Bearbeitungszeit: 120 Minuten
Klausur Softwareentwurf 04. Februar 2013 Bearbeitungszeit: 120 Minuten FG Datenbank- und Informationssysteme Dr. Christian Gerth unbedingt vollständig und lesbar ausfüllen! Vorname: Matrikelnummer: [ ]
MehrUML - Statische Diagramme
UML - Statische Diagramme - Seite 1 UML - Statische Diagramme (1.) Ein Sammler hat eine oder mehrere Sammlungen. Jede Sammlung hat 2 oder mehrere Stücke. Jede Sammlung gehört zu einem Sammler. Eine Sammlung
MehrVorlesung Programmieren
Vorlesung Programmieren Unified Modeling Language (UML) Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer Unified Modeling Language (UML)
MehrINSPIRE - Modellierung
INSPIRE - Modellierung Inhalt Motivation Modellierung UML Diagramme INSPIRE-Schulung LKROS 2 Motivation Was ist ein Modell, und warum wollen wir modellieren? Warum brauchen wir eine Modellierungssprache
MehrDas UML Benutzerhandbuch
Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Aktuell zur Version 2.0 Inhalt Vorwort 15 Ziele 15 Publikum 16 Wie Sie dieses Buch verwenden sollten 16 Aufbau und besondere Merkmale 17
MehrVORDIPLOMSPRÜFUNG FÜR ELEKTROINGENIEURE. Einführung in die Informatik III
Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner VORDIPLOMSPRÜFUNG FÜR ELEKTROINGENIEURE Einführung in die Informatik III Name: Matrikelnummer:
MehrObjektorientiertes Design
Objektorientiertes Design Yi Zhao Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Zhao, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1
MehrKurs 1793 Software Engineering I Klausur am
Kurs 793 Software Engineering I Seite: Hinweise zur Bearbeitung der Klausur zum Kurs 793 Software Engineering I im Sommersemester 2008 Wir begrüßen Sie zur Klausur "Software Engineering I". Bitte lesen
MehrUML. Weiteres Vorgehen im Projekt
UML Download objectif Personal Edition (kostenlos): http://www.microtool.de/objectif/de/download.asp Weiteres Vorgehen im Projekt Komponenten, Klassen, Objekte Prozesse Nichtfunktionale Anforderungen Skizzen,
MehrChristoph Kecher UML2. Das umfassende Handbuch. Galileo Press
Christoph Kecher UML2 Das umfassende Handbuch Galileo Press Vorwort 11 TEIL I Strukturdiagramme i '...,....,...,.;..,,,...,, 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3
MehrTamagotchi-Spezifikation in UML
Tamagotchi-Spezifikation in UML Christian Becker Steffen Glomb Michael Graf Gliederung Grundlagen Notation Werkzeug Modellierung Details der Spezifikation Erfahrungen Beurteilung von Notation und Werkzeug
MehrUniversität Karlsruhe (TH)
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Kapitel 2 Die Definitionsphase Prof. Walter F. Tichy Wo sind wir gerade? Planung Lastenheft (funktionales Modell) Definition (Analyse) Pflichtenheft
MehrFunktions- und Verhaltensmodellierung
www.mathematik-netz.de Copyright, Page 1 of 11 Funktions- und Verhaltensmodellierung 1. Motivierung und Übersicht Das Klassenmodell (auch Domänenklassenmodell genannt) der objektorientierten Programmierung
MehrMethodische objektorientierte Softwareentwicklung
Mario Winter Methodische objektorientierte Softwareentwicklung Eine Integration klassischer und moderner Entwicklungskonzepte dpunkt.verlag I Klassische Aspekte des Software Engineering 1 1 Allgemeine
MehrObjektorientierte Analyse (OOA) Übersicht
Übersicht UML ist die Notation für ein objektorientiertes Vorgehensmodell, sowohl für die Analyse als auch für das Design. Analyse (WAS?) Use Cases Aktivitätsdiagramme (für die Use Cases) Klassendiagramme
MehrUML - Sequenzdiagramm
Name Klasse Datum 1 Allgemeines Neben Aktivitätsdiagramm, Kollaborationsdiagramm, Zustandsdiagramm und Anwendungsfalldiagramm ist das Sequenzdiagramm eines von fünf Diagrammen in UML, welches dynamische
MehrJason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel
Jason T. Roff UML IT Tutorial Übersetzung aus dem Amerikanischen von Reinhard Engel Inhaltsverzeichnis Inhaltsverzeichnis Einführung 11 Grundlagen der UML 15 Warum wir Software modellieren 16 Analyse,
MehrOOA-Dynamische Konzepte
Proseminar UML im SS 2005 OOA-Dynamische Konzepte Teil 2 von Benjamin Daeumlich 1 Übersicht Szenario Definition Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Sequenz- vs. Kommunikationsdiagramm
MehrWebsite Creator: Online Shop. Factsheet
Website Creator: Online Shop Factsheet Stand Februar 2018 Features Dank den umfangreichen Features des Website Creator Online Shops, starten Sie ganz einfach Ihr eigenes Online-Business. Wichtige Key-Features
MehrMartin Fowler, Kendall Scott. UML konzentriert. Eine strukturierte Einführung in die Standard-Objektmodellierungssprache. 2., aktualisierte Auflage
Martin Fowler, Kendall Scott UML konzentriert Eine strukturierte Einführung in die Standard-Objektmodellierungssprache 2., aktualisierte Auflage Deutsche Übersetzung von Arnulf Mester, Michael Sczittnick
MehrSoftwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler
Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 3 Lösungshilfe Aufgabe 1. Klassendiagramme (9 Punkte) Sie haben den Auftrag, eine Online
MehrAnalyse und Design mituml2.1
Analyse und Design mituml2.1 Objektorientierte Softwareentwicklung Von Bernd Oestereich 8., aktualisierte Auflage Oldenbourg Verlag München Wien nhaltsverzeichnis Objektorientierte Softwareentwicklung
MehrState diagrams (Zustandsautomaten)
State diagrams (Zustandsautomaten) Allgemeines Zustandsautomaten geben Antworten auf die Frage Wie verhält sich das System in einem bestimmten Zustand bei gewissen Ereignissen?. Sie spezifizieren somit
MehrAnalyse und Design mituml2
Analyse und Design mituml2 Objektorientierte Softwareentwicklung von Bernd Oestereich 7, aktualisierte Auflage Oldenbourg Verlag München Wien Ш1!Н1Н1КД nhjektorientierte Softwareentwicklung - Analyse und
MehrUnified Modelling Language
Unified Modelling Language SEP 72 Software-Entwicklung Software-Entwicklung ist Prozess von Anforderung über Modellierungen zu fertigen Programmen Anforderungen oft informell gegeben fertige Programme
MehrTU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.
TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Übung zur Vorlesung Einführung in die Informatik 2 für Ingenieure (MSE) Alexander van Renen (renen@in.tum.de)
MehrDatenbanken. Teil 2: Informationen. Kapitel 7: Objektorientierte Sicht. UML-Diagramme. Vorstellung der unterschiedlichen UML-Diagramme
Datenbanken objektorientierte Sicht Seite 1 von 76 Datenbanken Teil 2: Informationen Kapitel 7: Objektorientierte Sicht UML-Diagramme Vorstellung der unterschiedlichen UML-Diagramme 1. Diagrammtypen 2.
MehrAufgabe S1: Einmal quer durch s Skript
Aufgabe S1: Einmal quer durch s Skript / 10 Punkten Entscheiden Sie, ob die folgenden Aussagen zutreffen oder nicht. Machen Sie in der entsprechenden Spalte ein Kreuz. Für jede richtige Antwort erhalten
MehrOOSE11 OOA: Klassen- und Objektdiagramme
OOSE11 OOA: Klassen- und Objektdiagramme Lehrstuhl Softwaretechnologie, Dr. Birgit Demuth Sommersemester 2016 Objektorientierte Analyse (OOA) Heute: Domänenmodell Welche Modellelemente enthält ein UML-
MehrObjektorientierte Analyse (OOA) Verhaltensdiagramme der UML
Verhaltensdiagramme der UML Seite 1 Verhaltensdiagramme der UML Seite 2 Übersicht UML-Diagramme Seite 3 Bedeutung der Aktivitätsdiagramme Anwendung im Projekt Aktivitätsdiagramme beschreiben den funktionellen
MehrPflichtenheft zum erweiterten UML-Tool
Westfälische Wilhelms-Universität Münster Fachbereich Mathematik und Informatik Programmierpraktikum WS 2000/2001 Dozent: Dr. Dietmar Lammers Pflichtenheft zum erweiterten UML-Tool Projektgruppe SynergieSoft
MehrUML Crashkurs v0.1. UML für Fachinformatiker. von Hanjo Müller
UML Crashkurs v0.1 UML für Fachinformatiker von Hanjo Müller 3. Mai 2005 Inhaltsverzeichnis Inhaltsverzeichnis 1 UML - Unified Modeling Language 3 2 UML im Software Entwurf 4 2.1 Ablauf der Softwareentwicklung.............................
MehrMusterlösung WS 06/07. - Ohne Gewähr -
DIPLOMHAUPTPRÜFUNG FÜR ELEKTROINGENIEURE SOFTWARETECHNIK I Musterlösung WS 06/07 - Ohne Gewähr - LfdNr. Thema Punkte Zeitbedarf in min Projektmanagement 5 30 2 Strukturierte Analyse und 20 40 Sequenzdiagramm
MehrD1: Relationale Datenstrukturen (14)
D1: Relationale Datenstrukturen (14) Die Schüler entwickeln ein Verständnis dafür, dass zum Verwalten größerer Datenmengen die bisherigen Werkzeuge nicht ausreichen. Dabei erlernen sie die Grundbegriffe
MehrKurs 1793 Software Engineering I - Grundkonzepte der OOSE Klausur am
Seite: 1 Sommersemester 2004 Hinweise zur Bearbeitung der Klausur zum Kurs 1793 Software Engineering I - Grundkonzepte der OOSE Wir begrüßen Sie zur Klausur "Software Engineering I". Bitte lesen Sie sich
MehrDas UML Benutzerhandbuch
Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Aktuell zur Version 2.0 ADDISON-WESLEY An imprint of Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario
MehrTeil II: OOP und JAVA (Vorlesung 9)
Teil II: OOP und JAVA (Vorlesung 9) Modul: Programmierung B-PRG Grundlagen der Programmierung II Prof. Dot.-Ing. Roberto Zicari Professur für Datenbanken und Informationssysteme (FB 12) 14.06.06 1 Teil
MehrEinführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren
Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 18. Dezember 2014 Rekapitulation Der Gang der Argumentation 1. Der Rohstoff:
MehrBeispielklausur A MPGI 3
Technische Universität Berlin Institut für Softwaretechnik und Theoretische Informatik FG Softwaretechnik Franklinstr. 28/29 10587 Berlin Helke Mertgen Beispielklausur A MPGI 3 Prüfen Sie zunächst, ob
Mehr