Projektseminar RIKA Softwaretechnik für die Analyse · Lastenheft Analysephase Pflichtenheft...

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)





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


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





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.


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





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


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.





Systemanalyse in UML

LastenheftLastenheft PflichtenheftPflichtenheft

„Use Case Driven Requirements Engineering“

Anwendungsfall-Diagramme

Klassen-Diagramme

Zustands-Diagramme

Einsatz-Diagramme

HandbuchGlossarBenutzungs-schnittstelle


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.





AnalysemittelBeschreibungssprache: UML

❏ Anwendungsfallmodelle

❏ konzeptuelle Klassendiagramme

❏ konzeptuelle Interaktiondiagramme


Notation von Anwendungsfällen

Aktor A

Aktor B

System X

UCExt

UCIncl

UCVar1

UCBase

UCVar2

«include»

«extend»

SystemgrenzeAktoren

Generalisierung

Erweiternder Fall

Anwendungsfall

Eingeschlossener Fall





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


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





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.


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





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


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“





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


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.






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



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.






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


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.





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


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. ...


Anwendungsfallbeschreibung






ProductSpecification

POST

Item Cashier

Customer

Payment

SalesLineItem

ProductCatalog

Store

Sale Manager

Anfänglich identifizierte Klassen Iterativ identifizierte Klassen


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)






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.


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


Kardinalität 0..

Kardinalität 1..






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?



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





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:


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:





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


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)





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


Kollaborationsdiagramm: Beispiel

:OrderTakerrequest(order)

:CreditBureau

:TicketDBtickets

2:cost=reserve(order)

1:checkCredit(customer) 3:debit(customer, cost)

NachrichtSequenznummer

Objekt Referenz

Rollenname

LokaleVariable





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.



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






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



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





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


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





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.


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

Projektseminar RIKA Softwaretechnik für die Analyse · Lastenheft Analysephase Pflichtenheft...

Documents

Transcript of Projektseminar RIKA Softwaretechnik für die Analyse · Lastenheft Analysephase Pflichtenheft...