Upload
ngocong
View
218
Download
0
Embed Size (px)
Citation preview
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
1Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
Projektseminar RIKA
Softwaretechnik für die AnalyseWintersemester 1999/2000
Florian Matthes, Holm Wegner
2Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Literatur❏ Florian Matthes, Holm Wegner: Folien zur Vorlesung Software Engineering,
Kapitel 5. Harburg, 1999.(http://www.sts.tu-harburg.de/teaching/ss-99/SoftEng/entry.html)
❏ Martin Fowler and Kendall Scott: UML Distilled: Applying the Standard ObjectModeling Language. Addison-Wesley 1997.
❏ James Rumbaugh, Ivar Jacobson, and Grady Booch: The Unified LanguageReference Manual. Addison-Wesley 1999.
❏ Ivar Jacobson, Grady Booch, and James Rumbaugh: The Unified SoftwareDevelopment Process. Addison-Wesley 1999.
❏ http://www.sts.tu-harburg.de/projects/UML/entry.html
❏ http://www.sts.tu-harburg.de/projects/UML/UMLDictionary.html(Übersetzungstabelle Deutsch/Englisch der UML-Begriffe)
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
2Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
3Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Systemanalyse: Einordnungvage, verschwommene,unzusammenhängende,unvollständige,wider-sprüchlicheAnforderungen
Vorgaben undRahmenbedingungenaus derPlanungsphase
Definitionsprozeß
vollständige, konsistente,eindeutige und durchführbareProduktanforderungen
Legende:Phase
Phasenergebnis
Weitergabe vonTeilprodukten
PlanungsphaseLastenheft
AnalysephasePflichtenheft
EntwurfsphaseProduktentwurf
ImplementierungsphaseProdukt, Komponenten
Abnahme und EinführungInstalliertes Produkt
4Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Lastenheft: Produktanforderungen❏ Aufgabe: Zusammenfassung aller fachlichen Basisanforderungen aus Sicht des
Auftraggebers
❏ Adressat: Auftraggeber sowie Auftragnehmer (Projektleiter, Marketing, ...)
❏ Inhalt: Basisanforderungen („Was?“, nicht „Wie?“)
❏ Form: standardisiertes, numeriertes Gliederungsschema
❏ Sprache: verbale Beschreibung
❏ Umfang: wenige Seiten
Inhalt:❏ Zielbestimmung❏ Produkteinsatz❏ Produktfunktionen❏ Produktdaten❏ Produktleistungen❏ Qualitätsanforderungen
Pflichtenheft: Systemanforderungen
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
3Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
5Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Systemanalyse: Aktivitäten und Ergebnisse
Definitionsphase
Produktdefinition
• Anforderungen ermitteln• Anforderungen festlegen und beschreiben• Anforderungen analysieren• Anforderungen u.U. animieren, simulieren und ausführen• Anforderungen verabschieden
„Requirements Engineering“
Pflichtenheft• Produktmodell• Konzept Benutzungsoberfläche• Benutzerhandbuch
Anforderungen (requirements) : Legen die qualitativen und quantitativenEigenschaften eines Produkts aus der Sicht des Auftraggebers fest.
Systemanalyse (requirements engineering): Systematische Vorgehensweise, um dieAnforderungen in einem iterativen Prozeß zu ermitteln.
6Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Datenmodell(Strukturen)
Funktionsmodell(Operationen)
Prozeßmodell(Abläufe)
Abhängigkeiten Abhängigkeiten
Verfe
iner
ung
Analyse
Entwurf
Realisierung
Klassische Systementwicklung: Phasen & Modelle
Probleme
❏ Brüche beim Übergang zwischen den Phasen (ER-Modell ➨ Relationales Modell)
❏ Komplexe Abhängigkeiten zwischen Daten, Funktionen und Prozessen "außerhalb"der Modelle
Verfe
iner
ung
Verfe
iner
ung
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
4Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
7Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Objektorientierter SW-EntwicklungsprozeßAnalyse Entwurf Implementierung
iterative,inkrementelle
Systementwicklung
Einschränkungen
Klassendiagramm
Anforderungen,Kundenwünsche
Programmiersprache,Persistenz,Verteilung
Laufzeit,Speicherplatz
Anforderungs-katalog
Anwendungs-fälle,
Aktoren
idealesObjektmodell
realesObjektmodell Realisierung
Anforderungs-Analyse idealer Entwurf Implementierungrealer
Entwurf
8Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Die Unified Modeling Language (UML)❏ Booch und Rumbaugh begannen 1994 bei Rational Inc., eine Unified Modeling
Language (UML) zu erarbeiten. (www.rational.com)
❏ UML bietet nur eine Notation für Modelle, aber keine Methodik, wie dieModellierung zu bewerkstelligen ist.
❏ UML wird im Entwicklungsprozeß “Unified Modeling Process”(UMP)(ehemals “Objectory”) benutzt (Jacobson).
❏ UML wurde von Rational Inc. und Hewlett-Packard als Standard für objektorientierteAnalyse und Design bei der OMG vorgeschlagen.
❏ Viele Hersteller passen ihre CASE-Werkzeuge an, um sie UML-fähig zu machen.
❏ Microsoft nutzt UML für sein Informationssystem.
❏ Oracle, SAP, ... benutzen UML.
❏ Fast alle neuen Bücher verwenden UML.
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
5Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
9Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Systemanalyse in UML
LastenheftLastenheft PflichtenheftPflichtenheft
„Use Case Driven Requirements Engineering“
Anwendungsfall-Diagramme
Klassen-Diagramme
Zustands-Diagramme
Einsatz-Diagramme
HandbuchGlossarBenutzungs-schnittstelle
10Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Problembereich (Analyse)
GUI-management
Daten-management
Task-management
Lösungsbereich (Entwurf)
Klasse
Objekt
Aber auch:OO Modellierung
ohne OO Programmier-
sprache
Analyse vs. Entwurf in OO Modellen❏ Unterscheidung zwischen Analyse- und Entwurfsphase wenig ausgeprägt,
da 1:1 Zuordnung Objekte der Realität ➔ Objekte des Softwaresystems
❏ Bestandteile der objektorientierten Analyse werden in den oo. Entwurf übernommenund verfeinert.
❏ Gleiches gilt für die objektorientierte Realisierung eines oo. Entwurfs.
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
6Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
11Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
AnalysemittelBeschreibungssprache: UML
❏ Anwendungsfallmodelle
❏ konzeptuelle Klassendiagramme
❏ konzeptuelle Interaktiondiagramme
12Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Notation von Anwendungsfällen
Aktor A
Aktor B
System X
UCExt
UCIncl
UCVar1
UCBase
UCVar2
«include»
«extend»
SystemgrenzeAktoren
Generalisierung
Erweiternder Fall
Anwendungsfall
Eingeschlossener Fall
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
7Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
13Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Konzeptuelle Modellierung von KlassenZiel:
Konzeptuelle Perspektive
❏ repräsentiert die Konzepte, die zu den Klassen gehören
❏ bietet Sprachunabhängigkeit
Hilfsmittel
❏ Klassendiagramm
• Klasse
• Beziehung
❏ Objektdiagramm
• Objekt (als Instanz einer Klasse)
• Referenz
14Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Klasse im konzeptuellen KlassendiagrammEine Klasse ist die Beschreibung einer Menge von Objekten, die dieselben Attribute,Operationen, Methoden, Beziehungen und Verhalten haben.
Eine Klasse besitzt
❏ Name
❏ Beschreibung (Verantwortung, Aufgabe)
❏ Attribute
• Name
• Beschreibung, evtl. Typ
❏ keine Methoden!
Englischer Begriff: class
Kunde
kundennr :Intname :String
Name
Attribut
Typ
Kundealternative,kompakte
Darstellung ohne Details
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
8Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
15Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
AssoziationEine Assoziation ist eine semantische Beziehung zwischen Klassen,die Verbindungen (z.B. Referenzen) zwischen ihren Instanzen betreffen.
Notation:
❏ Name
❏ Kardinalität
❏ Beschreibung(aus Anwendungsfällen extrahiert)
Englischer Begriff: association
Kunde Bestellung1 *
Kardinalität
Jeder Kunde kann keineoder mehrere Bestellungenaufgeben.
gibt auf
Name
Eine Bestellung wird vongenau einem Kundenaufgeben.
16Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Aggregation / KompositionDie Aggregation bzw. Komposition ist eine semantische Beziehung zwischen einemAggregat A und einer Komponente B. "B ist ein Teil von A“.
Mögliche Eigenschaften der Aggregation
❏ Abhängige Existenz der Komponente (Komponente existiert nicht ohne Aggregatund stirbt mit ihm)
❏ Verbot der geteilten Aggregation (Komponente kann nur Komponente eineseinzigen Aggregats sein)
❏ Transitivität der Komponentenbeziehung
Notation:Bestellung
Position
Aggregat
Komponente Dek
ompo
sitio
n
Aggregation
Englischer Begriff: aggregation
0..1
*
*
Aggregation
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
9Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
17Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
GeneralisierungDie Generalisierung ist eine semantische Beziehung zwischen einem allgemeinerenKonzept A (Superklasse) und einem spezielleren Konzept B (Subklasse).„A generalisiert B“, „jedes B ist ein A“
Für Klassen: Vererbung, Bilden einer Taxonomie.
[Mögliche Eigenschaften von Generalisierungen später]
Notation(en):
Englischer Begriff: generalization
GeneralisierungSp
ezia
lisie
rungMitarbeiter
FreierMitarbeiter
Fester Mitarbeiter
Mitarbeiter
FreierMitarbeiter
Fester Mitarbeiter
Superklasse
Subklasse
18Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
ObjektdiagrammEin Objektdiagramm zeigt Objekte (Instanzen von Klassen), evtl. ihren Zustand undihre Beziehungen zu eine bestimmten Zeitpunkt.
Bestandteile:
❏ Objekte
❏ Referenzen
Notation: a2 :Artikelname=„Teetasse“
hw :Kundekundennr=„14“name=„Holm“
(gerichtete) Referenz
Objektb :Bestellung
datum=28.10.1999a1 :Artikelname=„ Teekanne“
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
10Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
19Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches VorgehenMethode Erstelle konzeptuelles Klassendiagramm
Eingabe: Pflichtenheft.Anwendungsfall-Modell, Pflichtenheft.Glossar
Ausgabe: Pflichtenheft.KonzeptuellesKlassendiagramm
Änderung: Pflichtenheft
Pflichtenheft.KonzeptuellesKlassendiagramm:= Ø
repeat
Finde neue Klassen und Attribute
Finde neue Assoziationen
Dokumentiere Klassen und Beziehungen
Bespreche das Ergebnis mit dem Auftraggeber
until Auftraggeber und Auftragnehmer zufrieden
20Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Klassen (1)
1. Identifiziere Klassen über die Substantivmethode
❏ Relevante Dokumente: Lastenheft, Anwendungsfalldokumentation, Glossar,Formulare, technische Systembeschreibungen, Gesprächsnotizen, ...
❏ Identifiziere Substantive (Konzepte), die für das Problemverständnis relevant sind• Technik: Unterstreichen im Text, lieber zunächst zu viele Substantive als zu
wenige
❏ Identifiziere Synonyme, Akronyme und Fachbegriffe.• Zwei verschiedene Namen sind Synonyme, falls sie das gleiche Konzept
bezeichnen.• Ein Akronym (Initialwort) ist ein Name, der aus den Anfangsbuchstaben eines
Namens gebildet wird.
❏ Identifiziere Homonyme.• Ein Homonym ist ein Name, der zwei (verschiedene) Konzepte benennt.
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
11Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
21Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Klassen (2)
2. Kategorisiere die Substantive
❏ Konkrete Objekte bzw. Dinge, z.B. Pkw
❏ Personen und deren Rollen, z.B. Kunde, Mitarbeiter, Dozent
❏ Informationen über Aktionen, z.B. Banküberweisung
❏ Orte, z.B. Wartezimmer
❏ Organisationen, z.B. Filiale
❏ Schnittstellen des Systems, z.B. Liste, Auswahlliste
❏ Beziehungen zwischen Klassen, z.B. Mietvertrag zwischen Kunde und Mietobjekt
❏ Allgemeine und fachbezogene Informationen, z.B. Artikel, Seminartyp
22Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Klassen (3)
3. Streiche Substantive und Konzepte, die keine eigenständigen konzeptuellenKlassen bezeichnen
❏ Das Ziel ist nicht, möglichst viele Klassen oder Klassen möglichst geringerKomplexität zu identifizieren.
❏ Gestrichene Substantive können evtl. in einer To-Do-Liste gesammelt werden, dasie später bei der Identifikation relevanter Attribute, Operationen und Beziehungenhilfreich sind.
❏ Streiche Namen für Rollen, die eine Klasse in einer Beziehung zu einer anderenKlasse spielt.
❏ Indizien für zu streichende Substantive:
• Es lassen sich weder Attribute noch Operationen identifizieren.
• Das Substantiv modelliert Implementierungsdetails.
• Die Klasse enthält nur Operationen, die sich anderen Klassen zuordnen lassen.
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
12Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
23Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Klassen (4)
4. Wähle aussagefähige und verbindliche Klassennamen
❏ Jeder Klassenname soll• ein Substantiv im Singular sein,• so konkret wie möglich gewählt werden,• kein Homonym sein,• nur in seltenen Fällen ein Akronym sein,• die Gesamtheit der Attribute und Operationen darstellen.
5. Dokumentiere jede Klasse knapp
❏ Ein definierender Satz, z.B.
Eine Seminarbuchung ist ein Dokument, das die Anmeldung eines Kunden zu einerSeminarveranstaltung dokumentiert.
❏ Liste der Synonyme, eventuell Abgrenzung zu anderen Klassen
Synonyme: Anmeldung, Reservierung
24Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Attribute1. Identifiziere Attribute im Anschluß an die Substantivmethode
❏ Identifiziere für das Pflichtenheft relevante Attribute jeder Klasse.
❏ Erfasse Schlüsselattribute nur dann, wenn sie fachlich notwendig sind.
2. Überprüfe den Attributnamen
❏ Jeder Attributname soll• ein Substantiv im Singular oder Plural sein,• so konkret wie möglich gewählt werden,• kein Homonym sein.
3. Definiere den Typ der Attribute
❏ Im konzeptuellen Klassendiagramm kann der Typ unspezifiziert oder nur vagespezifiziert bleiben.
❏ Komplex strukturierte Typen sollten durch eigenständige Klassen ersetzt werden.
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
13Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
25Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Customer
Buy items
Log in
Refund purchaseditems
Beispiel: Point of Sale Terminal (1)
Ein Point of Sale Terminal (POST) ist ein computergestütztes System, um Verkäufe,Bezahlungen und Auszahlungen in einem Handelsgeschäft zu unterstützen.
Es enthält Hardwarekomponenten (Computer, Anzeige, Balkencode-Lesegerät, ...)und Softwarekomponenten.
Cashier
26Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Use Case: Buy item 1. This use case begins when a customer arrives at a POST checkout with items to purchase.2. The cashier records the universal product code (UPC) from each item.3. The System determines the item price and adds the item to the running sales transaction.4. If there is more than one of the same item, the cashier can enter the quantity as well.5. The description and the price of the current item are displayed.6. ...
Beispiel: Point of Sale Terminal (2)
Anwendungsfallbeschreibung
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
14Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
27Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Beispiel: Point of Sale Terminal (3)
ProductSpecification
POST
Item Cashier
Customer
Payment
SalesLineItem
ProductCatalog
Store
Sale Manager
Anfänglich identifizierte Klassen Iterativ identifizierte Klassen
28Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Assoziationen (1)
1. Identifiziere mögliche Assoziationen zwischen Objekten
❏ Suche in den relevanten Dokumenten nach Verben und nach Substantiven, dieAktionen oder Prozesse in der Problembeschreibung identifizieren.
❏ Identifiziere für jede Assoziation die beteiligten Klassen.
❏ Bevorzuge binäre Assoziationen (d.h. mit zwei beteiligten Klassen).
2. Kategorisiere diese Assoziationen
❏ räumliche Nähe (in der Nähe von)
❏ Aktionen (fährt, bucht)
❏ Kommunikation (redet mit)
❏ Besitz (hat)
❏ allgemeine Beziehungen (ist abhängig von, ist verheiratet mit)
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
15Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
29Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Assoziationen (2)
3. Streiche Assoziationen, die keine Assoziationen im konzeptuellenKlassendiagramm sind
❏ Streiche nicht-permanente Beziehungen
❏ Streiche für das Pflichtenheft irrelevante Assoziationen
❏ Streiche implementierungsbezogene Assoziationen
4. Falls erforderlich, definiere Assoziations- und Rollennamen
❏ Assoziationen sind in der Mehrzahl der Fälle durch die partizipierenden Klasseneindeutig bestimmt. In diesem Fall sind Assoziations- und Rollennamen nichterforderlich.
❏ Ansonsten (z.B. bei rekursiven Assoziationen) definiere
• einen Namen (ein Verb oder eine Verbalphrase) für die Assoziation• einen Rollennamen für jede an der Assoziation beteiligte Klasse• einen Satz, der die Semantik der Assoziation beschreibt.
30Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
5. Bestimme die Kardinalität jeder Rolle jeder Assoziation
❏ Liegt eine Muß-Beziehung vor?• Sobald das Objekt erzeugt ist, muß auch die Beziehung zu dem anderen Objekt
aufgebaut werden.
❏ Liegt eine Kann-Beziehung vor?• Die Beziehung kann zu einem beliebigen Zeitpunkt nach dem Erzeugen des
Objekts erzeugt werden.
❏ Ist die Obergrenze fest oder variabel?• Ist eine Obergrenze vom Problem her zwingend vorgegeben?• Im Zweifelsfall immer mit variablen Obergrenzen arbeiten!
❏ Gelten besondere Bedingungen?
• Gerade Anzahl, Untergrenze, ...
Kardinalität ..k
Methodisches Vorgehen: Finde Assoziationen (3)
Kardinalität 0..
Kardinalität 1..
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
16Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
31Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Assoziationen (4)
5. Unterscheide Assoziation und Aggregation anhand der folgenden Kann-Kriterien:
❏ Läßt sich die Beziehung durch „besteht aus“ oder „ist Teil von“ beschreiben?(Kollektion, Behälter, Ganzes & Teile, Gruppe & Mitglied)
❏ Ist die Kardinalität auf einer Seite der Assoziation 1 oder 0..1 ?
❏ Ist die Assoziation transitiv und asymmetrisch?
❏ Gehören die Komponenten in ein Subsystem?
❏ Erfolgt der Zugriff auf die Teilobjekte ausschließlich über das Aggregat-Objekt?
❏ Ist die Lebensdauer der Komponente durch die Lebensdauer des Aggregatsbeschränkt?
32Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen: Finde Assoziationen (5)
6. Entscheide, ob ein Schnappschuß oder eine Historie zu modellieren ist
❏ Schnappschuß: Wer ist augenblicklich Chef der Abteilung?
❏ Historie: Wer war zum Zeitpunkt t Chef der Abteilung?
7. Dokumentiere Restriktionen auf der Assoziation
❏ Ordnung auf den Beziehungen {ordered}
❏ Abgeleitete Beziehungen {derived as ...}
❏ Konsistenzbeziehungen im Bezug auf andere Beziehungen
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
17Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
33Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
a:Arotate(30.0, origin)
b:Point
Senderobjekt Empfängerobjekt
ParameterName der Nachricht
Objektreferenz
class A {Point b = ...; Point origin = new Point(0,0);public test() {b.rotate(30.0, origin)}
}...a = new A();a.test();
Nachricht
Konzeptuelle Modellierung von Interaktionen (1)
Notation im Objektdiagramm:
34Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Konzeptuelle Modellierung von Interaktionen (2)
Name Pfeiltyp Sender Empfänger
Signal ist aktiv ist aktivAufruf sequentiell ist aktiv, blockiert wird aktiviertAufruf asynchron ist aktiv wird aktiviert
Ergebnis Aktivierung fortgesetzt wird inaktiv
Übersicht der Nachrichtenarten:
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
18Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
35Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Sequenzdiagramm: Asynchrone Interaktion
:Anrufer :Vermittlung :Angerufener
Ziffer(4)
Klingelton
Abheben
...
Klingelsignal
Wählton
Abheben
Ende Klingelton Klingelende
aktives Objekt(Rahmen fett)
Nachricht
Nachricht mitLaufzeit
Aktivierung
Ziffer(2)
a
b
c
{b-a < 1 sec}
Restriktion
d
e
f
Zeitachse
benannterZeitpunkt
36Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Sequentielle prozedurale Interaktion
o:Ordercreate()
:TicketDB
reserve(date,count)debit(cost, o)
:AccountAktor
Objekt
Lebenslinie
Erzeugung
Aktivierung
Nachricht
Zerstörung
Ergebnis
bonus()
rekursiveAktivierung
Objekt(anonym)
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
19Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
37Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Nebenläufige prozedurale Interaktion
o3:C3
o4:C4o2:C2o1:C1
create(x)
call(x)
doit(y)doit(z)
o5:C5
signal(w)
recurse()
asynchroner Aufruf
Erzeugen vonNebenläufigkeit
nebenläufige Aktivierung
rekursiver Aufruf
38Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Kollaborationsdiagramm: Beispiel
:OrderTakerrequest(order)
:CreditBureau
:TicketDBtickets
2:cost=reserve(order)
1:checkCredit(customer) 3:debit(customer, cost)
NachrichtSequenznummer
Objekt Referenz
Rollenname
LokaleVariable
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
20Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
39Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen (1)
Die Erstellung von Interaktionsdiagrammen im Rahmen der objektorientiertenAnalyse hat das Ziel, alle (externen, d.h. für den Auftraggeber relevanten) Interaktionenzwischen dem System und seiner Umgebung zu identifizieren und ihre dynamischeSemantik zu beschreiben.
Sie verwendet Klassendiagramme und Interaktionsdiagramme als Hilfsmittel derKommunikation und zur Dokumentation der Ergebnisse.
Das Vorgehensmodell besteht aus zwei Phasen:
1) Identifikation externer Ereignisse (Sammlung im Ereigniskatalog)
2) Zuordnung von Verantwortlichkeiten für diese Ereignisse an extern sichtbareKlassen (Methoden)
Ausblick: Im objektorientierten Entwurf erfolgt eine Verfeinerung der Ereignisse und derVerantwortlichkeiten.
40Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen (2)
Unterscheide:
❏ Konzeptuelles Modell in objektorientierter Analyse
• Aktoren, Entitätsklassen, Kontrollklassen, Grenzklassen
• externe Ereignisse und Interaktionen
• Systemverantwortlichkeiten
❏ Architekturmodell im objektorientierten Entwurf
• Klassen, Pakete
• interne Interaktionen
• Klassenverantwortlichkeiten
• Prä- und Postkonditionen für Methoden
❏ Ausführbares Modell bei der Programmierung
• ...
System
System
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
21Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
41Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen (3)
Eingabe: Pflichtenheft.Anwendungsfallmodell,Pflichtenheft.Klassendiagramme
Ausgabe: Pflichtenheft.Sequenzdiagramme,Pflichtenheft.KollaborationsdiagrammeMethoden in Pflichtenheft.Klassendiagramme
Änderung: Pflichtenheft
X:= die Menge der Anwendungsfälle in Pflichtenheft.AnwendungsfallmodellEreigniskatalog:= {}for each x in X do
Identifikation externer Ereignisse (Benutzeraktionen),die in x erwähnt werden
Ereigniskatalog:= Ereigniskatalog + neu identifizierte Ereignisse
end
42Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Methodisches Vorgehen (4)
Diskussion der folgenden Ereignisse mit dem Auftraggeber, die sonst häufig erst in derEntwurfs- und Implementierungsphase erkannt werden, die aber erfahrungsgemäß auchkonzeptuell wesentlich sind:
• Aufrufe oder Signale von externen Systemen oder Prozessen
• Zeitablauf
• Systeminitialisierung (startup)
• Systembeendigung (shutdown), normal oder abnormal
• Aufruf oder Beendigung des "Schlafmodus" auf PC
• Einmalige Aktionen bei der Installation (Upgrade) der Software
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
22Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
43Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Ereigniskatalog
enterItem()endSale()makePayment()
Beispiel: POST (1)
Use Case:
Buy items
1. This use case begins..
enterItem(upc,quantity)
endSale()
makePayment()
Operation: enterItem
Precondition:1. Cashier must be logged in.
Postconditions:1. If a new sale ...
Operation:endSale()
Precondition:1. ...Postconditions:1. ....
Anwendungsfall Sequenzdiagramm Ereigniskatalog Verträge
:System:Cashier
44Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Beispiel: POST (2)
USE CASE: BUY ITEMSTypical course of events:
1. This use case begins when a a Customer arrives at the POSTcheckout with items to purchase.
2. The cashier records the universal product code (UPC) from each item. If there is more than one of the same item, thecashier can enter the quantity as well.
3. System determines the item price and adds the item information to the running salestransaction. The description andthe price of the current item aredisplayed
:System
enterItem(UPC,quantity)
endSale()
makePayment(amount)
:Cashier
Projektseminar Realisierung eines I+K AnwendungssystemsWS 1999/2000
23Softwaretechnik für die Analyse
© Florian Matthes, Holm Wegner
45Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Beispiel: POST (3)
Name: enterItem(upc : number , quantity : integer )
Responsibilities: Enter (record) sale of an item and add it to the sale. Display the item description and price.
Type: SystemCross References: System Functions:
Use Cases:Notes:Exceptions: If the UPC is not valid, indicate
that it was an error.Output:Pre-conditions: UPC is known to the system.Post-conditions: Product and quantity are added to the sale
transaction or an error is displayed.
46Realisierung eines I+K Anwendungssystems: Softwaretechnik für die Analyse
Aufgabe: AnalyseErgebnisse bis 11.11.1999:
❏ 1 Seite Lastenheft
❏ Anwendungsfälle & Aktoren mit genauer Beschreibung
❏ Glossar
❏ Konzeptuelles Klassendiagramm
❏ Systeminteraktionen für zentrale Funktionen
1 2 3 4
5 6 7
8 9 10 11 12 13
Heute