16
Name Vorname Matrikel-Nr. Institut für Informatik der Universität Zürich LÖSUNGEN Musterklausur Requirements Engineering I aus dem HS 2007 12. November 2007 Bitte freilassen! Aufgabe 1 Aufgabe 2 Aufgabe 3 Aufgabe 4 Aufgabe 5 Aufgabe 6 Total

Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Name Vorname Matrikel-Nr.

Institut für Informatik

der Universität Zürich

LÖSUNGEN

Musterklausur

Requirements Engineering I

aus dem HS 2007

12. November 2007

Bitte freilassen!

Aufgabe 1 Aufgabe 2 Aufgabe 3 Aufgabe 4 Aufgabe 5 Aufgabe 6 Total

Page 2: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 2 (von 16)

Aufgabe 1: Multiple Choice (20 Punkte)

Kreuzen Sie Zutreffendes an. Zu jeder Frage können mehrere Antworten richtig sein. Bitte beachten Sie, dass Ihnen für jedes falsch gesetzte Kreuz gleich viele Punkte abgezogen werden, wie Sie für eine korrekte Ankreuzung erhalten. Negative Punktzahlen ergeben null Punkte für die betreffende Frage.

Frage 1.1: Systeme und ihr Kontext (3 Punkte)

RICHTIG FALSCH

Änderungen des Entwurfs brauchen die Zustimmung des Auftraggebers bzw. des Kunden.

Die Festlegung der Systemgrenzen ist eine zentrale Aufgabe der Systementwicklung.

Kontextmodelle enthalten nur die Interaktion zwischen dem System und den Kontextelementen.

Probleme und Lösungen können hierarchisch verzahnt sein, daher hängt es von der Situation ab, was eine Anforderung und was eine Entwurfsentscheidung ist.

Anforderungen werden immer vom Kunden formuliert.

Die Systemgrenze liegt immer zwischen System und Kontext.

Frage 1.2: Requirements Engineering Grundlagen (3 Punkte)

RICHTIG FALSCH

Randbedingungen werden bei der Gewinnung von Anforderungen noch nicht berücksichtigt.

Es müssen immer alle Anforderungen des Kunden umgesetzt werden.

Requirements Engineering ist am wirtschaftlichsten, wenn die Gesamtkosten, bestehend aus den Kosten für die Erstellung der Anforderungsspezifikation und den Fehlerkosten, minimal sind.

Der Aufwand für das Requirements Engineering soll umgekehrt proportional zum Risiko sein, das man bereit ist einzugehen.

Requirements Engineering ist der Vorgang der Zusammenstellung aller Anforderungen an ein System.

Nicht-funktionale und funktionale Anforderungen lassen sich immer eindeutig voneinander abgrenzen.

Page 3: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 3 (von 16)

Frage 1.3: Spezifikationsprozess (2 Punkte)

RICHTIG FALSCH

Beim marktorientierten Prozess sind alle Betroffenen bekannt.

Bei deskriptiven Prozessen orientieren sich die Anforderungen an den Fähigkeiten der eingesetzten Standardsoftware.

Explorative Prozesse funktionieren in der Regel nur zusammen mit einem inkrementellen Vorgehen.

Bei reaktiven Prozessen müssen die Anforderungen möglichst detailliert erhoben werden, da die Spezifikation Vertragscharakter hat.

Frage 1.4: Darstellung von Anforderungen (3 Punkte)

RICHTIG FALSCH

Die konstruktive Darstellung von Anforderungen eignet sich besonders für die Modellierung von Anforderungen im Grossen.

Der Formalitätsgrad ist ein Freiheitsgrad der Darstellung.

Teile mit hohem Risiko müssen genau und detailliert spezifiziert werden, Teile mit geringem Risiko eher summarisch.

Ein Vorteil der deskriptiven Darstellung von Anforderungen mit formalen Mitteln ist, dass diese leicht auf Adäquatheit zu prüfen ist.

Die konstruktive Darstellung von Anforderungen bleibt in der Regel lösungsneutral.

Ein Vorteil der konstruktiven Darstellung von Anforderungen ist, dass sämtliche Teilmodelle den gleichen Formalisierungsgrad aufweisen.

Page 4: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 4 (von 16)

Frage 1.5: Anforderungsspezifikation mit natürlicher Sprache (2.5 Punkte)

RICHTIG FALSCH

Natürlichsprachliche Anforderungsspezifikationen sind immer lösungsneutral.

Satzformulierungen im Passiv und Nomen mit spezifischer Bedeutung tragen zum Verständnis und zur Formulierung einer eindeutigen natürlichsprachlichen Anforderungsspezifikation bei.

Werden Einzelanforderungen in kleine Einheiten gefasst, so vereinfacht dies deren Verwaltung.

Ein Glossar ist nur bei einer natürlichsprachlichen Anforderungsspezifikation nötig.

Die Verständlichkeit von natürlichsprachlichen Spezifikationen kann durch eine gute Gliederung erhöht werden.

Frage 1.6: Formale Spezifikation (2 Punkte)

RICHTIG FALSCH

Petrinetze gehören in die Kategorie der rein deskriptiven formalen Spezifikationssprachen.

Die Vollständigkeit formaler Spezifikationen kann sehr leicht nachgewiesen werden.

Formale Spezifikationen sind immer eindeutig.

Formale Methoden sind unwirtschaftlich.

Page 5: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 5 (von 16)

Frage 1.7: Verwaltung von Anforderungen (2 Punkte)

RICHTIG FALSCH

Anforderungen bleiben nach ihrer Erhebung normalerweise stabil und ändern sich nicht mehr.

Für das Verwalten von Anforderungen braucht es ein Konfigurationsmanagement und eine einfache Nachvollziehbarkeit von Anforderungen.

Das Steuerungskomitee (Change Control Board) entscheidet, ob ein Änderungsvorschlag für die Anforderungen nochmals überarbeitet werden muss, abgelehnt oder durchgeführt wird.

Vorschläge für die Änderung von Anforderungen werden ausschliesslich vom Kunden gemacht.

Frage 1.8: Prüfung und Abnahme (2.5 Punkte)

RICHTIG FALSCH

Ein Review ist ein Prüfverfahren, mit dem Spezifikationen aller Formalitätsgrade geprüft werden können.

Das Prüfen, ob eine Anforderungsspezifikation die Wünsche und Vorstellungen der zukünftigen Benutzer widerspiegelt, wird Verifikation genannt.

Ein Prototyp kann zur Beurteilung der praktischen Brauchbarkeit des spezifizierten Systems eingesetzt werden.

Die Testfälle für den Abnahmetest werden grundsätzlich aus dem Architekturentwurf abgeleitet.

Die Formulierung der Anforderungen hat einen wesentlichen Einfluss auf deren Prüfbarkeit.

Page 6: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 6 (von 16)

Aufgabe 2: Anforderungsgewinnung (25 Punkte) Die ColdFood AG stellt Kühlschränke her. Um mit aktuellen Trends mithalten zu können, will man einen intelligenten Kühlschrank entwickeln. Dieser soll dem Benutzer das Leben erleichtern. Der Kühlschrank kann über einen Touchscreen am Kühlschrank selbst und über das Internet gesteuert werde. Dazu muss der Kühlschrank natürlich mit dem Internet verbunden sein. Der Benutzer kann eine Liste von Basislebensmitteln verwalten und angeben, bei welchem Bestand neue Lebensmittel online bestellt werden müssen. Verschiedene Grossverteiler bieten die Möglichkeit, online Lebensmittel zu bestellen bereits an. Falls der Benutzer die Möglichkeit zur automatischen Bestellung nicht nutzen möchte, oder gewisse Lebensmittel auf diese Art nicht bestellt werden können, kann er sich eine Einkaufsliste per Mail schicken lassen. Um zu verhindern, dass Lebensmittel weggeworfen werden müssen, wird der Benutzer kurz vor Ablaufdatum der Lebensmittel gewarnt, entweder per e-Mail oder auf der Anzeige des Kühlschrankes. Um den Bestand der Lebensmittel kontrollieren zu können, muss jedes Lebensmittel beim Einfügen oder Entfernen mit einem Strichcode-Lesegerät registriert werden. Dieses Lesegerät wird nicht von der ColdFood AG selbst hergestellt, es kann von einem darauf spezialisierten Anbieter gekauft werden. Alternativ ist auch eine manuelle Eingabe auf der Anzeige des Kühlschrankes möglich. Um sicherzustellen, dass der Kühlschrank kompatibel mit anderen Geräten und der Hausverwaltungssoftware des so genannten „intelligenten Hauses“ ist, muss dieser der EIB-Norm genügen. Eine eventuelle Integrierung einer Rezeptedatenbank wird in Betracht gezogen. Damit kann sich der Benutzer Rezepte vorschlagen lassen, die den Inhalt seines Kühlschrankes verwenden. Zusätzlich zu den oben genannten Funktionen in Bezug auf Lebensmittel soll die Wartung des Kühlschrankes automatisch geschehen. Der Kühlschrank wird laufend überwacht. Wenn die Überwachung einen Fehler anzeigt (z.B. die maximale Temperatur überschritten wird) erfolgt eine Benachrichtigung per e-Mail oder SMS an den Benutzer. Bei grösseren Problemen wird automatisch die Serviceabteilung des Herstellers informiert. Diese bekommt auch die Messdaten geliefert und kann den Fehler über die Internetverbindung analysieren und gegebenenfalls beheben.

Page 7: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 7 (von 16)

Aufgabe 2.1: Beteiligtenanalyse (5 Punkte) Führen Sie für den Kühlschrank der ColdFood AG eine Beteiligtenanalyse durch. Geben Sie dazu an, welche Stakeholder Anforderungen an das System stellen. Lösung:

- Kunde/Benutzer - Regulatoren (Vorschriften, EIB-Norm) - Serviceabteilung - Grossanbieter Lebensmittel - Geschäftsleitung - Hersteller Strichcode-Lesegerät. - Management Cold-Food -

Korrektur: 1 Punkt pro Stakeholder, wenn „schwammige“ Formulierung 0.5 Anforderungen selbst werden nicht beachtet. Aufgabe 2.2: Kontextabgrenzung (5 Punkte) Zeichnen Sie für das Kühlschranksystem ein Kontextdiagramm (auf Systemebene). Achten Sie auf eine aussagekräftige Beschriftung der Akteure und ihrer Beziehungen zum System. Kühlschranksystem Akteure:

- Kunde - Serviceabteilung - Grossanbieter

Beziehungen:

- Serviceabteilung: > Fehler mitteilen / < Fehler beheben - Kunde : > Lebensmittel verwalten / < Warnung bei Ablaufdatum - Lebensmittellieferant : > Lebensmittel liefern / < Lebensmittel bestellen

Korrekturschema:

- -0.5 pro fehlenden Akteur - - 0.5 pro fehlende / unvollständige (zB keine Richtung) Beziehung - Systeminterna modelliert -0.5 - Keine Akteure die nicht direkt mit System zu tun haben! Sonst -0.5!

Page 8: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 8 (von 16)

Aufgabe 2.3 : Anwendungsfalldiagramm erstellen (10 Punkte) Identifizieren Sie im obigen Text alle Anwendungsfälle, die im Zusammenhang mit dem Benutzer stehen und stellen Sie diese in einem UML Anwendungsfalldiagramm dar. Lösung: Kapitel 8, Seite 20 Akteur: nur Benutzer Anwendungsfälle: - Produkt einfügen (manuell, mit Strichcode) - Produkt entfernen (manuell, mit Strichcode) - Produktdatenbank verwalten - Einkaufsliste abfragen - Problemmeldung erhalten - Rezept vorschlagen - Ablaufdatum warnen Korrektur: Zu viele Akteure -2 Vergessene Anwendungsfälle je -1 (max -6) Falsche Beziehungen -0.5 (max -2) Wenn Syntax generell total falsch, 0.5 Punkt pro erkennbaren Anwendungsfall Keine include/extends notwendig!

Page 9: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 9 (von 16)

Aufgabe 2.4: Darstellbare Aspekte (5 Punkte) Was wird mit einem Anwendungsfalldiagramm dargestellt? Welche Eigenschaften von Anwendungsfällen können mit einem UML Anwendungsfalldiagramm nicht dargestellt werden? Nennen Sie zwei Eigenschaften und geben Sie jeweils eine Darstellungsform an, mit Hilfe derer entsprechende Eigenschaft dargestellt werden kann. Lösung: Anwendungsfalldiagramm gibt Überblick über Szenarien.

Zerlegung von Anwendungsfällen o StateCharts

Beschreibung eines einzelnen Szenarios o Freier Text o Strukturierter Text o Zustandsautomaten bzw. Statecharts o UML-Aktivitätsdiagramme o Interaktionsdiagramme

Reihenfolgeabhängigkeiten zwischen Anwendungsfällen o Pre-, Postconditions o Statecharts o Jackson-Diagramme o Abhängigkeitsdiagramme

Korrekturschema:

1 Punkt für „was wird dargestellt“

Je 1 Punkte für Nennung eines Aspekts (max. 2 Punkte)

Je 1 Punkte für Nennung einer Alternative (max. 2 Punkt) Es geht um Eigenschaften von Anwendungsfällen. Also geben Nennungen wie „die Zusammenhänge zwischen den Akteuren können nicht dargestellt werden“ keine Punkte!

Page 10: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 10 (von 16)

Aufgabe 3: Spezifikationsprozess (10 Punkte) Stellen Sie den Ablauf des präskriptiven Spezifikationsprozesses durch eine einfache Skizze dar.

Skizze: 3P

- Akteure je 0.5 total 1.5P (sollten auch noch +- mit richtigen Aktivitäten verbunden sein)

- Ablauf Anforderungen spezifizieren 0.5P - Gesamtablauf 0.5P (wenn Entwicklung auch drin 0P) - Spezifikaton als Ergebnis 0.5P

Beantworten Sie folgende Fragen:

- Wer spezifiziert die Anforderungen? Kunde (1P)

- Wer validiert die Anforderungen?

Kunde und Vertragspartner (je 1P, max 2P)

- Warum ist dieser Spezifikationsprozess oft mit linearem Vorgehen verbunden?

Page 11: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 11 (von 16)

Genauer Schlusspunkt, keine Wiederholungen, wenn Spezifikation erstellt ist, wird sie nicht mehr verändert. (1P)

- Wie eng ist die Zusammenarbeit zwischen dem Entwickler und dem Kunden?

nicht eng, Kunde erstellt Spezifikation die dann der Kunde erhält. Keine direkte Kommunikation. (1P)

- Geben Sie eine Situation an, in der ein präskriptiver

Spezifikationsprozess ungeeignet ist. Begründen Sie Ihre Aussage. Unklare, noch nicht fertige Anforderungen. Präskriptiver Prozess ungeeignet, da dieser vollständige Spezifikation voraussetzt. (1P für Situation, 1P für Begründung)

Page 12: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 12 (von 16)

Aufgabe 4: Anforderungsspezifikation mit natürlicher Sprache (5 Punkte) Der folgende Text ist ein Ausschnitt aus der natürlichsprachlichen Spezifikation für einen Self-Scanning Service bei einem Detailhändler: “Dieses Gerät ermöglicht es dem Kunden, beim Einkaufen jeden Artikel gleich selbst einzuscannen und Informationen zum Artikel anzuzeigen. Nach der Authentifizierung kann der Kunde durch ein Handlesegerät die RFID-Chips der Artikel einlesen. Danach hat er die Wahl, Informationen zum Artikel anzuzeigen oder den Artikel in die Liste der gekauften Artikel hinzuzufügen. Am Schluss des Einkaufs gibt der Benutzer den Handscanner an einer dafür vorgesehenen Kasse ab, worauf die Kassiererin den Zahlvorgang auslöst. Zur Zeitersparnis hinzu kommt auch ein Plus an Transparenz. Denn auf dem Display des Handscanners sind zu jeder Zeit der Preis des einzelnen Produkts und alle Aktionsvorteile zu sehen. Ferner soll auch der Status der Bonuspunkte abgefragt werden können. Selbstverständlich können Artikel auch jederzeit wieder ins Regal zurückgestellt und ausgescannt werden.” Der Text enthält einige Probleme, die bei der Spezifikation mit natürlicher Sprache auftauchen. Nennen Sie vier der Probleme und belegen Sie diese mit einem Beispiel aus dem obigen Text.

Gliederung: Nur eine Anforderung pro Satz (abhören, archivieren, löschen)

Unspezifische Bedeutung/ undpezifische Wörter : Kunde

Nominalisierung: „Authentifizierung“

Unspezifische Nomen: „Status“

All-Quantifizierung: „jederzeit“

Passiv: „abgefragt werden können“

Mehrdeutigkeiten/Redundanz: Handlesegerät, Handscanner

Anforderungen gehören in Hauptsätze: Am Schluss,..., Zahlungsvorgang auslöst.

Unübersichtlich

Punkte: 1.25 Punkt pro erkanntes Problem (0.25 für Erkennen, 0.5 für richtige Benennung, 0.5 für Beispiel) Fehlerbehandlung generell gibt keinen Punkt, da nicht wirklich Problem von der Sprache sondern generell Problem, das daran nicht gedacht wird! Gliederung als Problem gibt 0.75 (Problem ist Struktur)

Page 13: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 13 (von 16)

Aufgabe 5: Gemischte Aufgaben (20 Punkte) Aufgabe 5.1 : Qualitätsmerkmale (5 Punkte) Geben Sie zwei Qualitätsmerkmale einer guten Spezifikation an. Beschreiben Sie kurz (1-2 Sätze pro Qualitätsmerkmal), welche Probleme auftreten können, wenn dieses Qualitätsmerkmal nicht eingehalten wird. Lösung:

- Adäquat --> Ergebnis ist nicht das, was Kunde will - Vollständig --> Ergebnis ist nicht da, was Kunde will, da Teile fehlen - Widerspruchsfrei --> nicht prüfbar, nicht möglich die Spezifikation zu

realisieren - Verständlich --> Wenn Entwickler nicht versteht, was gemeint ist,

entwickelt er das Falsche - Eindeutig --> sonst Fehlinterpretationen möglich - Prüfbar --> sonst kann nicht bewiesen werden, dass das System die

Anforderungen nicht erfüllt - Risikogerecht --> Aufwand zu klein für Risiko=Gefahr falscher

Entwicklung kritischer Teile/ Aufwand zu gross --> zu hohe Kosten Korrektur: 2 Qualitätsmerkmale: je 1 Punkt 1 Problem pro Merkmal: je 1.5 Punkte Aufgabe 5.2 : IST-Zustand (5 Punkte) Sie möchten den IST-Zustand eines Systems erheben. Wann ist die Beschäftigung mit dem IST-Zustand notwendig? Nenne Sie zwei Techniken, die Sie zur Informationsbeschaffung anwenden können. Warum sind diese besonders geeignet zur Erhebung des IST-Zustandes? - Ermittlung von Stärken und Schwächen des IST-Systems - zum Verstehen eines IST-Systems, das geändernt oder erweitert werden

soll 1P Techniken:

- Interviews --> gibt Auskunft über IST-Zustand - Beobachtung der Benutzer --> zeigt wie der Benutzer mit System interagiert - Beispiele analysieren --> zeigt, wie System im Moment funktioniert - Umfragen/Fragebogen -->gibt Auskunft über IST-Zustand

Behandelt alle das jetzige System, nicht die Zukunft (wie zB ein Prototyp). je 1 Punkt pro Technik (max 2 Punkte) je 1 Punkt für Begründung (max 2 Punkte)

Page 14: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 14 (von 16)

Aufgabe 5.3 : NFA (4 Punkte) Bei der Diskussion über Anforderungen, fällt folgende Aussage: „Nicht funktionale Anforderungen sind weiche Anforderungen.“ Was sind nicht funktionale Anforderungen? Was sind weiche Anforderungen? Stimmen Sie dieser Aussage zu? Erläutern Sie Ihre Entscheidung in 1-2 Sätzen. NFA: Anforderung, deren zu Grunde liegendes Bedürfnis eine nicht gegenständliche Eigenschaft ist (dh sich nciht auf Daten, Operation, Verhalten bezieht). Es geht dabei um die Art. 1P Weiche Anforderung: Anforderung, die graduell erfüllt sein kann. Es geht dabei um die Erfüllung. 1P Die Art und die Erfüllung einer Anforderungen sind nicht voneinander abhängig. So kann eine nicht funktionale Anforderung auch ein hartes Kriterium haben bei der Erfüllung (Bsp). 2P Aufgabe 5.4 : Reviews (6 Punkte) Nennen Sie drei Arten von Reviews. Geben Sie zu jeder Art an, wo Sie den grössten Nachteil sehen, wenn diese Art von Review eingesetzt wird. - Walktrough : Da Autor durch das Review führt, kann er bestimmen, welche

Teile beachtet werden, Gefahr, dass er Teile die zu Kritik führen könnten, auslässt.

- Inspektion: hoher Zeitaufwand - Autor-Kritiker-Zyklus: Gefahr, dass die Besprechung ausartet und zu

Diskussionen führt. Punkte: je 1 Punkt pro Review, ein Punkt pro Nachteil

Page 15: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 15 (von 16)

Aufgabe 6: Formale Spezifikation (10 Punkte) Das untenstehende Klassenmodell einer Bibliothek soll mit OCL-Ausdrücken angereichert werden.

Folgende Invarianten müssen formuliert werden:

- Ein Buch vom Typ „Antik“ ist mehr als 20 Jahre alt. (Ein Buch das mehr als 20 Jahre alt ist, muss aber nicht unbedingt den Typ „Antik“ haben).

- Innerhalb einer Bibliothek haben Bücher einzigartige Signaturen, dh. die Signaturen aller Bücher sind voneinander verschieden.

- Es gibt maximal 1000 Bücher in einer Bibliothek. Halten Sie sich dabei an die folgende Notation: Art und Kontext: context, inv, pre, post Prädikatenlogische Ausdrücke: and, or, not, implies, exists, forAll Operationen auf Resultatmengen: size(), isEmpty(), notEmpty(), Aussagen über alle Instanzen einer Klasse: allInstances() Navigation: Übliche Punktnotation Anwendung auf Mengen: Pfeilnotation context Buch inv: self.Typ=“Antik“ implies self.Alter>20 3 Punkte - context Buch inv: 1p - self.Typ=“Antik“/self.Alter>20 je 0,5 - implies 1P context Bibliothek inv: self.hat->forAll(b1,b2: Buch | b1<>b2 implies b1.Signatur<>b2.Signatur) 4 Punkte - context Bibliothek inv: 1P - self.hat -> 1P - forAll(b1,b2: Buch | ) 1P - b1<>b2 implies b1.Signatur<>b2.Signatur 1P

Page 16: Musterklausur Requirements Engineering I aus dem HS 2007 12. …00000000-3505-93df-ffff... · 2017. 10. 8. · Musterklausur Requirements Engineering I aus dem HS 2007 12. November

Seite 16 (von 16)

context Bibliothek inv: self.hat.size()<=1000 3 Punkte - context Bibliothek inv: 1P - self.hat 1P - size()<=1000 1P