Teil III der V or les ung Objek tor ientier te Analy se ( OOA) 30) Ü ber blic k über die OOA

(1)

Softwaretechnologie, © Prof. Uwe Aßmann Technische Universität Dresden, Fakultät Informatik1

Teil III der V or les ung Objek tor ientier te Analy se ( OOA) 30) Ü ber blic k über die OOA

Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden Version 11-0.1, 20.05.11 Prof. U. Aßmann, Softwaretechnologie2

O bl igat or ische Li ter at ur

►

Zu se r, K ap . 7- 9

►

S tö rr le , K ap . 5

►

M an fr e d B ro y un d A nd re a s R au sch . D a s n eu e V -M od e ll® X T. E in an pa ssb ar es M od el l f ür S of tw ar e un d S yst em E ng in ee rin g. In fo rm at ik- S pe kt ru m .S p rin ge r B e rli n / H ei de lb er g. V ol um e 2 8, N um be r 3 / Ju ne , 2 00 5, P ag es 22 0- 2 29 ht tp :/ /w w w .sp rin ge rli nk. co m /co nt en t/ l1 73 63 83 86 33 43 05 /

(2)

Softwaretechnologie, © Prof. Uwe Aßmann Technische Universität Dresden, Fakultät Informatik3

30.1 Ü ber blick über die Objek tor ientier te Analy se

Prof. U. Aßmann, Softwaretechnologie

D ie zent ral en Fr age der S of tw ar et echnol ogi e

Wie kommen wir vom Problem des Kunden zum Programm (oder Produkt)?

W ie ko m m en w ir vo m P ro bl em d es K un de n zu m P ro gr am m ( od er P ro du kt )?

Von der Beschreibung der Welt des Kunden (Domänenmodel, Weltmodel)Zum Programm

(3)

Prof. U. Aßmann, Softwaretechnologie5

S of tw ar eent w ickl ung im V -M odel l

Analyse Grobentwurf Feinentwurf Implementierung

Abnahmetest Systemtest Integrationstest Modultest

Testfälle Testfälle Testfälle Boehm 1979 („V-Modell“)

OOP

OOD

OOA Prof. U. Aßmann, Softwaretechnologie6

O bj ekt or ient ier te A nal yse und E nt w ur f

►

D ie A rb ei tsp ha se A na ly se e rm itt el t, w a s d er B en u tze r vo m S yst em be nö tig t

■Schnittstellen (Funktionen, Daten, Klassen, Code) ■Begriffe der Anwendungsdomäne ■Oft nennt man sie Systemanalyse oder Anforderungsanalyse ►

D ie A rb ei tsp ha se E nt w urf e rm itt el t, w as de r E n tw ickl er zu sä tz lich zu de n E rg eb ni sse n de r A na ly se in s S ys te m a uf ne h m e n m uss, w as ab er de r B en ut ze r ni ch t se he n m uss.

(4)

E nt w urf

V on der A nal yse zum E nt w ur f A na ly se

Anforderungs- Ermittlung

Anforderungs- Spezifikation

Fa ch lich e M od el lie ru ng

Architektur- Spezifikation (Entwurfsmodell)

A rch ite kt ur - E nt w ur f

Klassen- Spezifikationen (Implementierungsmode

Fe in - E nt w ur f

Produktdefinition (Anforderungen und Domänen-Modell)

Vertrag mit dem Kunden Prof. U. Aßmann, Softwaretechnologie8

analysis model

V on den A nf or der ungen zum Fei nent w ur f

Kontextmodell (context model, system interface)

Domänen- modell Anwendungsfälle (use cases)

Textuelle Anforderungen Architektur/ Entwurfs- modell Feinentwurf Implementierungs modell

Fachliches Modell Top-level- Architektur

Nutzer- modell

Produktdefinition Anforderungs- spezifikation

(5)

analysis model

V on den A nf or der ungen zum Fei nent w ur f

Kontextmodell (context model, system interface)

Domänen- modell Anwendungsfälle (use cases)

Textuelle Anforderungen

Fachliches Modell Top-level- Architektur

Nutzer- modell

Produktdefinition Anforderungs- spezifikation

Lö su ng sr au m (S yste m ra um so lu tio n sp ace )

P ro ble m ra um (p ro ble m sp ace

Architektur/ Entwurfs- modell Feinentwurf Implementierungs modell Prof. U. Aßmann, Softwaretechnologie10

Vorbereitende Anforderungsanalyse (preparatory requirements analysis)

S che m at isc he r A bl au f de r A nal ys e (A nf or der ungen und fachl iches M odel l)

Anforderungsanalyse (“real” requirements analysis)

Domänenmodel Funktionale Anforderungen

Anforderungen

Pflichtenheft

Vertrag Produktdefinition Kontext-Modell

Grundlegende Architekturanalyse (basic architecture analysis) Top-level-Architektur

GUI Prototyp

(6)

S che m at isc he r A bl au f de r A nal ys e (A nf or der ungen und fachl iches M odel l)

Domain Analysis (Domain concepts) Function Analysis - Use case analysis

Stakeholder Analysis (Nutzergruppen) Anforderungsanalyse Context Model Analysis

Domain Model Funktionale Anforderungen Anforderungen Pflichtenheft Vertrag

Produktdefinition

Vorbereitende Anforderungsanalyse Grundlegende Architekturanalyse Top-level Architecture Analysis^C^on

text Model Top-level architecture

GUI Prototyp

GUI Analysis Prof. U. Aßmann, Softwaretechnologie

V ol ler A bl auf der A nal yse (s. S WT -2)

Domain Analysis (Domain concepts)

Problem Analysis Goal Analysis Function Analysis - Use case analysis Project Task Planning

Stakeholder Analysis (Nutzergruppen) Quality Analysis (Non-functional Reqs)GUI Analysis Acceptance Criteria Analysis Acceptance Test

Anforderungsanalyse Context Model Analysis

Domain Model Funktionale Anforderungen Acceptance Tests

Anforderungen Pflichtenheft Vertrag

Produktdefinition

Grundlegende Architekturanalyse Top-level Architecture Analysis^C^on

text Model Top-level architecture

GUI Prototyp

Vorbereitende Anforderungsanalyse

(7)

Inhal te ei nes V er tr ags m it ei nem K unden

►

P fli ch te nh ef t

■Produktdefinition ♦Anforderungsspezifikation (das WAS) Nutzermodell (stakeholders) Domänenmodell Funktionale Anforderungen In SWT 2: Problemmodell, Zielmodell, Nicht-funktionale Anforderungen ♦Fachliches Modell (der Teil vom WIE, den der Kunde wissen muss) Kontextmodell GUI-Prototyp Top-level-Architektur ■Akzeptanztestfälle: ♦Messbare Akzeptanzkriterien, die bei der Abnahme vom Kunden abgehakt werden können. Ohne bestandenen Akzeptanztest keine Bezahlung! ►

P re isl ich e R eg el un g

►

A ch tu ng : In d er L ite ra tu r w ird d er B eg rif f “A na lyse m od e ll” so w oh l f ü r di e P ro du kt de fin iti on a ls au ch n ur f ür d as fa ch lich e M od el l ve rw en de t!

Inhal te der A nf or der ungspezi fikat ion (W A S ?)

►

N ut ze rm od el l ( st ake ho ld er m od el ): Li st e o de r U M L- K la sse nd ia g ra m m al le r am S yst em In te re ssi er te n

■In SWT-2 verfeinern wir das, in dem wir über die Ziele der stakeholder nachdenken ■Enthält die Benutzer des Systems (die Aktoren) ►

D om än en m od el l ( do m ai n m od el ):

■Termini, Struktur und Grundkonzepte des Aufgabengebiets ■Schaffung einheitlicher Terminologie für die Anforderungsspezifikation ■Aus der Sicht des Kunden ■Zusammenhang mit Anforderungsspezifikation sichern ■Implementierungsaspekte ausklammern: Annahme perfekter Technologie ►

P ro bl em m od el l, Zi el m od el l (s. S W T- 2)

(8)

Inhal te der A nf or der ungspezi fikat ion

►

Fu nkt io na le A nf or de ru ng en : Fu nkt io na le E sse nz d es S yst em s. W as m uss da s S yst em kö nn en ?

■Nicht das Wie, sondern nur das Was ■möglichst quantitativ (z.B. Tabellenform) ■eindeutig identifizierbar (Nummern) ■Notation: Anwendungsfalldiagramme (Nutzfalldiagramme), Funktionsbäume oder textuell. Manchmal auch mathematisch ►

N ich t- fu nkt io na le A nf or de ru ng en : Q ua lit ät sa nf or de ru ng en ( s. S W T- 2)

■Resourcenausnutzung: Antwortzeit, Speicherbedarf, Last, Durchsatz ■Sicherheitskriterien ■HW/SW-Plattform ■Entwicklungs- und Produkt-Standards Prof. U. Aßmann, Softwaretechnologie16

Inh al te des Fachl ichen M odel ls (Fachko nzept ) (D as WI E , das der K unde w issen m uss)

►

K on te xt m od el l : äu sse re S ch ni tt st el le n de s S yst em s

■Ein- und Ausgabekanäle, Masken, Abfragen ■Daten, die ein und aus fliessen, im Domänenmodell typisiert ►

G U I P ro to typ : P ro to typ is ch e M aske n, Fo rm ul ar e, B ild sch irm e, d ie d en G U I au sm ach en : W ie si eh t da s P ro gr am m a us?

►

To p- le ve l A rch ite kt ur ( In iti al e A rch ite kt ur , Fa ch ar ch ite kt ur ): B e st im m t di e H a up tko m po ne nt en d e s S yst em s un d ih re In te ra kt io n en , o hn e a uf D et ai ls ei nzu ge he n

■Verfeinert das Kontextmodell um eine Stufe, d.h. die top-level Architektur ■Stellt das dar, was der Kunde von der Systemarchitektur wissen muss

(9)

O bj ekt or ient ier te A nal yse (O O A )

►

G ru nd id ee : M o de lli er un g de r fa ch lich e n A uf ga b e (P ro du kt de fin iti on m it fa ch lich em M od el l u nd A n fo rd e ru ng ssp e zi fika tio n) d ur ch koope ri ere nde O bj ek te .

System als "Gesellschaft" kooperierender Objekte

Klassen: Eigenschaften und Aufgaben von Objekten Beziehungen zwischen Klassen (bzw. Objekten)

Typische Anwendungsfälle (Anforderungen) Zustände und Verhalten von Objekten beschreibt

Statisches ModellDynamisches ModellAnforderungsspez. Top-level Architektur

Domänenmodell Kontext- Diagramm

Stakeholders GUI-Prototyp

Funktionale Anforderungen

Produktdefinition (OOA Modell) Fachl.Modell Prof. U. Aßmann, Softwaretechnologie18

V on Analysemodellen zu BCE- Entwurfsmodellen (3-Schichtenarchitektur) O O A - M ode ll Top- le ve l A rc hi te kt ur

D omä ne nmode ll K ont ex t- D ia gra mm

S ta ke hol de rs G U I- P rot ot yp

A nf orde runge n (z. B . us e ca se s) O O D - M ode ll G U I (bounda ry ) A nw endungs logi k (c ont rol ) D at enha lt ung (e nt it y) E nt w urf D at enmode ll (E nt it it es , M at eri al ie n)

P roze ss e, W ork fl ow s A rc hi te kt ur Fe ine nt w urf

G U I- A rc hi te kt ur - Te xt U I - W eb G U I - Ja va G U I O O P G U I- S chi cht (B ounda ry , B )

A nw endungs logi k- Impl eme nt ie rung (C ont rol , C )

D at enmode ll- Impl eme nt ie rung (D at a ba se , D )

(10)

Zum P rakt ikum

►

m eh r al s 95 % al le r Th em en im P ra kt iku m si nd B C E -A rch ite kt ur en

■Oft mit Web-GUI ■Unterscheidung zwischen GUI, Anwendungslogik und Datenhaltung ist essentiell ►

M an so llt e ve rst eh en , da ss au s de m D om än en m od el l

■die Datenhaltung folgt ■die Typen der Daten folgen, die im Kontextmodell und in der Top-Level- Architektur fliessen ■der GUI-Prototyp stark bestimmt wird (Kommunikation mit dem Benutzer) ►

D ie E nt w ickl er o ft n ur f ür B , C , od er E zu st än di g si nd

Ü ber bl ick Tei l I II: O bj ekt or ient ier te A nal yse (O O A )

1.Überblick Objektorientierte Analyse 1.(schon gehabt:) Strukturelle Modellierung mit CRC-Karten 2.Strukturelle metamodellgetriebene Modellierung mit UML für das Domänenmodell 1.Strukturelle metamodellgetriebene Modellierung 2.Modellierung von komplexen Objekten 1.Modellierung von Hierarchien 2.(Modellierung von komplexen Objekten und ihren Unterobjekten) 3.Modellierung von Komponenten (Groß-Objekte) 3.Strukturelle Modellierung für Kontextmodell und Top-Level-Architektur 3.Analyse von funktionalen Anforderungen 1.Funktionale Verfeinerung: Dynamische Modellierung und Szenarienanalyse mit Aktionsdiagrammen 2.Funktionale querschneidende Verfeinerung: Szenarienanalyse mit Anwendungsfällen, Kollaborationen und Interaktionsdiagrammen 3.(Funktionale querschneidende Verfeinerung für komplexe Objekte) 4.Beispiel Fallstudie EU-Rent

(11)

M odel ing the R eal S ol ut ion Fi nd the ri ght abst ract ions!

P ro to typ e of a w ash in g m ach in e

The B asi c Law s of M isunder st andi ng Spoken is not heard Heard is not listened Listened is not understood Understood is not accepted Accepted is not done

(12)

The E nd

►

E in ig e Fo lie n si nd e in e üb er ar be ite te V er si on a us de r V or le su ng S o ftw a re te ch no lo gi e vo n © P ro f. H . H uss m an n, 2 00 2, u se d b y pe rm issi on .