Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Transkript

1 SoftwareEngineering Prof.Dr.StefanEnderle NTAIsny

2 Nachtrag

3 4ArbeitsschrittAnalyse

4 Begriffe Analyse: VorgangzurBeschreibungdergewünschten AnforderungenaneinSystem. DieAnforderungenwerdenineinemDokumentstrukturiert Anforderung: BedingungoderFähigkeitfunktionalerodernicht funktionalernatur,dieeinsystemerfüllenmuss. Analysedokument: BeschreibungeinesSystemsmitBegriffenausdem Anwendungsbereich. Was abernicht wie

5 Einleitung ArbeitsschrittAnalyse: GesprächemitKunden/Kundenvertreter ErmittlungvonAnforderungen ErstellungAnalysedokument ZweiTeilabschnitte: Anforderungsanalyse: BeschreibungallerAnforderungenandasSystem Analysemodell: ÜberprüfungderAnforderungsanalyseaufMachbarkeit

6 4.1Anforderungsanalyse Ziel: FindenallerAnforderungenandasSystem BeschreibungausSichtdesBenutzers MeistmehrereIterationen: Anforderungeneinholen Dokumentieren Fragentretenauf Fragenklären Dokumentationanpassen DokumentationderAnforderungenistTeildesVertrags

7 Anforderungsanalyse Haupt Schwierigkeit: UnterschiedlicheDenkmustervonKundeund Analytiker FindeneinergemeinsamenSprache Dadurchschwierig,Ideenauszutauschen KonsequenteKlärungvonpotentiellen Missverständnissen Unterscheidungzwischendem,wasderKundewill unddem,wasertatsächlichbenötigt

8 Tätigkeiten

9 Tätigkeiten Systembeschreibung: AllgemeineEinführungindasSystem Begriffsverzeichnis: GemeinsameSprachezwischenKundeund Analytiker. BegriffeausAnwenderdomäne. Aktorenliste: BeschreibungderRechtederAktoren Domänenmodell: BeschreibungallerObjektederDomäne zumverständnisderzurverfügungstehendendaten

10 Tätigkeiten Anwendungsfalldiagramm: ÜbersichtlicheDarstellungderFunktionalitätdes Systems Anwendungsfallbeschreibung: DetaillierteBeschreibungderAnforderungenandas System Prototyp: DetaillierteDarstellungderAnwenderschnittstelle

11 4.1.1Systembeschreibung BeschreibungdesSystems oberflächlich ausführlich alshintergrundfürdieanforderungsdokumentation Inhalt: Ausgangssituation(Kunde,Auftraggeber) ZielsetzungdesSystems Wissensquellen Organisation(Geschäftsbereich,Ort) StandderTechnik(existierendeSysteme) GesetzlicherRahmen AbgrenzungdesneuenSystems

12 4.1.2Begriffsverzeichnis KlärungderFachsprachedesKundenbzw.Anwenders GenaueDefinitionvonBegriffenundProzessen

13 4.1.3Aktorenliste AuflistungallermitdemSystemkommunizierender Aktoren GenaueBeschreibungderRechtejedesAktors DiesvermeidetUnklarheitenin Anwendungsfalldiagrammund beschreibung (durcherweiterungen,optionalepfadeundvariationen später!)

14 4.1.4Anwendungsfalldiagramm DiagrammmitallenAktoren,Anwendungsfällenundderen Kommunikationuntereinander Anwendungsfall: Abgeschlossene,zusammenhängende,wiederkehrende AnwendungdesSystems Aktor: BenutzerdesSystemsmitRechtenundAufgaben HatgenaudanneineBeziehungzueinem Anwendungsfall,wennerberechtigtist,diesen auszulösen.

15 UMLAnwendungsfalldiagramm engl.:use CaseDiagram

16 Anwendungsfalldiagramm WeitereElemente: extends : <<extend>> > EinAnwendungsfallkanneinenanderen erweitern. include : > EinAnwendungsfallbenutzteinenanderen.

17 Anwendungsfalldiagramm

18 Anwendungsfalldiagramm FindenvonAktorenundAnwendungsfällen (z.b.ausprotokolldeskundengesprächs): SubjektimSatzistoftAktor VerbenlassenoftaufTätigkeitenschließen: AnwendungsfalloderTeildavon ObjektesindoftDaten(fürDomänenmodell)

19 4.1.5Anwendungsfallbeschreibung AlleAnwendungsfällewerdendetailliertbeschrieben InhaltproAnwendungsfall: EindeutigeNummeralsReferenz TitelmitFunktionalität KurzbeschreibungmitZusammenfassung VorbedingungenfürdieAusführung AblaufderEreignisse: E :EreignissedurchBenutzer A :AntwortdesSystems AE :AlternativesEreignis AuswirkungenaufSystemzustandundDatenbestand AnmerkungenzumVerständnis

20 Anwendungsfallbeschreibung

21 4.1.6Analyseprototyp EnthältalleAnwenderschnittstellendesSystems Oberflächesolltesoweitmöglichfunktionieren Menüs Fensteröffnenundschließen Dialoge Buttons KeineFunktionüberAnwenderschnittstellehinaus KeineGrundlagefürImplementierung! (keinsaubererentwurf)

22 Analyseprototyp Beispiel:

23 Analyseprototyp Vorteile: AnalytikererhältfrühesFeedbacküberRichtigkeitder Anforderungen KundebekommtfrühzeitigGefühlfürAussehenund FunktionsweisedesSystems ProgrammiererbekommtfrühMöglichkeit,sichmit Anforderungenvertrautzumachen

24 4.1.7Domänenmodell ObjektederAnwendungsdomäne ObjekteundderenAttribute MeistfolgendeObjekte: BeteiligteoderbetroffenePersonen (Kunde,Verkäufer,Ansprechpartner,Administrator,...) ZuständeeinesProzesses (Transaktion,Buchung,Reparatur,Abflug,Ankunft,...) SachgegenständeeinesProzesses (Vertrag,Rechnung,Memo,...) AlltagsobjektederAnwendungsdomäne (Auto,Haus,...) Infrastruktur (Zimmer,Zimmerplan,Firmenhierarchie,...)

25 Domänenmodell DarstellungdesDomänenmodells: UMLKlassendiagramm Abstraktionsschritt: NichtObjekte,sondernKlassenwerdenmodelliert InderAnalysemeistvordenAnwendungsfällen,inder Dokumentationabermeistzuletzt.

26 UMLKlassenmodell Detailgrade: NurKlassenname KlassennameundAttribute Klassenname,AttributeundMethoden Aufführungssaal Aufführungssaal Ort Bezeichnung Art Anzahl_Plätze Kosten_pro_Tag Aufführungssaal Ort Bezeichnung Art Anzahl_Plätze Kosten_pro_Tag definieren suchen

27 UMLKlassenmodell Attribute: Gedächtnis einesobjektes Eigenschaften AlleAttribute Wertezusammen:Zustand Person Name Geschlecht Haarfarbe Augenfarbe Alter Aufführungssaal Ort Bezeichnung Art Anzahl_Plätze Kosten_pro_Tag Attribute,diez.B.ineinerDatenbankgespeichertwerden,um dasobjektspäterzurekonstruieren,heißenpersistent.

28 UMLKlassenmodell Methoden: FähigkeiteneinerKlasse Unterscheidungsmöglichkeit: KonstruktorenundDestruktoren SpeichernundLadenvonObjektzuständen AttributeoderGesamtzustandändern AttributeoderGesamtzustandauslesen Berechnungausführen,basierendaufaktuellemZustand

29 UMLKlassenmodell Methoden Aufführungssaal Ort Bezeichnung Art Anzahl_Plätze Kosten_pro_Tag definieren suchen Person Name Geschlecht Haarfarbe Augenfarbe Alter definieren suchen Alter_festlegen Haarfarbe_ändern löschen laden speichern

30 UMLKlassenmodell Vererbung: InKlassenkannesinhaltlicheÜbereinstimmunggeben: Attributekönnengleichsein (TypundWert) Methodenkönnengleichsein (Parameter,Rückgabewert,Code) GibtesgenügendÜbereinstimmungen,sokönnendieseüber dievererbungsbeziehungverbundenwerden: Generalisierung/Spezialisierung(GenSpec)

31 UMLKlassenmodell Vererbung: Generalisierung/Spezialisierung(GenSpec): Platz Ticket Zähl Ticket Veranstaltung Aufführungssaal Datum Platz Veranstaltung Aufführungssaal Datum Anzahl_Plätze verkaufen Platz_zuweisen Platz_ändern stornieren suchen verkaufen Anzahl_zuweisen Anzahl_ändern stornieren suchen

32 UMLKlassenmodell Vererbung: Generalisierung/Spezialisierung(GenSpec): Ticket Veranstaltung Aufführungssaal Datum Platz Ticket Platz verkaufen stornieren suchen Platz_zuweisen Platz_ändern Zähl Ticket Anzahl_Plätze Anzahl_zuweisen Anzahl_ändern

33 UMLKlassenmodell AbstrakteOberklasse: VonderOberklasseTicketkannkeinObjekterzeugtwerden {abstract} Ticket {abstract} Veranstaltung Aufführungssaal Datum Platz Ticket Platz verkaufen stornieren suchen Platz_zuweisen Platz_ändern Zähl Ticket Anzahl_Plätze Anzahl_zuweisen Anzahl_ändern

34 UMLKlassenmodell Vererbungsbeziehung: WennesaufAttributeundMethodennichtankommt: Ticket {abstract} Platz Ticket Zähl Ticket

35 UMLKlassenmodell Assoziationen: könnenfolgendezusammenhängedarstellen: Datenabhängigkeit: EinObjektstelltInformationenfüreinanderesObjektzur Verfügung EinObjektistAttributeinesanderenObjekts FunktionalerZusammenhang: EineKlassebenötigtFunktioneneineranderenKlasse. Allg: EineKlassebenötigtetwasvoneineranderen

36 UMLKlassenmodell Assoziationen: Darstellung: LiniezwischenKlassen NamederAssoziation(aktivesVerb!) (wird_verkauft,hat_einkommen,...) Evtl.gefülltesDreieckfürLeserichtung Kardinalität(jeweilsamEndederLinie) Sitzplatz 1 gilt_für 1 Ticket

37 UMLKlassenmodell AssoziationenundKardinalität: DieKardinalitätgibtan,wievieleObjekteeinerKlassezueinem ObjektderKlasseamanderenEndeinBeziehungstehen können: Beliebigviele(auch0): * GenaueineMöglichkeit: 1 BereichvonWerten: 1..3oder1..* MehrereWertebereiche: 1..3,5,10

38 UMLKlassenmodell Assoziationen: Beispiel:

39 UMLKlassenmodell Assoziationen: Beispiel:

40 UMLKlassenmodell Assoziationen: Beispiel:

41 UMLKlassenmodell Assoziationen: Beispiel:

42 UMLKlassenmodell AssoziierteKlasse:

43 UMLKlassenmodell Assoziationen: Schleife:

44 UMLKlassenmodell AggregationundKomposition: ModellierendenFall,dasseineKlasseausTeilen zusammengesetztwerdenkann. Aggregation: TeilekönnenbeiZerstörungdesGanzenweiterexistieren. Komposition: ExistenzderTeilehörtnachEndedesGanzenebenfallsauf.

45 UMLKlassenmodell AggregationundKomposition: DarstellungundBeispiele: Aggregation: NachKonkursdesKinosgibtesdieRäumenoch. Komposition: LöschendesSitzplanslöschtauchdieorganisatorische EinheitderReihen.

46 4.2Analysemodell Anforderungsanalyse= WünscheundAnforderungendesKundenermitteln Systembeschreibung Begriffsverzeichnis Aktorenliste Anwendungsfalldiagramm Anwendungsfallbeschreibung Analyseprototyp Domänenmodell Anforderungsanalyse= MachbarkeitundVollständigkeitprüfen

47 Analysemodell UnterschiedeAnforderungsanalyse Analysemodell

48 Analysemodell TätigkeitenbeimErstellendesAnalysemodells Produkte: Analysemodelldiagramm BeschreibungallerElemente(Schnittstellen,Controller, Entitäten)

49 4.2.1Analysemodelldiagramm KlassendiagrammenthältstatischeZusammenhänge zwischenklassen AnalysemodelldiagrammenthältauchFunktionalität 3UMLStereotypen: Schnittstelle Controller Entität

50 Analysemodelldiagramm entsprichtmvc

51 Analysemodelldiagramm Beispiel:Lift Steuerung KeineeinzelnenObjekte,sondernKlassen!

52 Analysemodelldiagramm DasAnalysemodelldientwiedernurdemÜberblick (vgl.anwendungsfalldiagramm/ beschreibung) AlsdetaillierteBeschreibungfolgt: Systemschnittstellen Anwenderschnittstellen Geschäftslogik Datenbasis Datenmodellzyklus

53 4.2.2Systemschnittstellen Systemschnittstellen= Schnittstellen,dieZugriffaufanderetechnischeSysteme ermöglichen. (D.h.aufSubsystemeoderexterneSysteme) ProSchnittstelleeinDokument(1Seite). EinSystembenötigtvoneinemanderenSystem Funktionen,diedortinderBeschreibungaufgelistet werden. EinSystembietetFunktionenan,dieindereigenen Beschreibungaufgelistetwerden.

54 Systemschnittstellen Beispiel1zur Ticket Line

55 Systemschnittstellen Beispiel2zur Ticket Line

56 Systemschnittstellen Allgemein: Titel BezeichnungdesSystemsim Analysemodelldiagramm Kurzbeschreibung WesentlicheAufgabeundVerantwortung, grundlegendefunktionalität ListederMethoden MethodenmitParameterundRückgabewert(keine Datentypen),evtl.ausgelösteFehler,Verhalten ListedermöglichenFehler AlleFehlersämtlicherMethodenaufgelistet

57 4.2.3Anwenderschnittstellen Anwenderschnittstellen= SchnittstellenzudenBenutzerndesSystems. ProSchnittstelleeinDokument(1Seite) mitscreenshotsodergrafiken. SolltemitAnalyseprototypübereinstimmen.

58 Anwenderschnittstellen Beispiel:

59 Anwenderschnittstellen WichtigePunkte: BedeutungallerdargestellterElementemuss dokumentiertsein AlleAktionen,dieausgehendvonder Anwenderschnittstelledurchgeführtwerdenkönnen, müssenaufgelistetsein InhaltevonListenundFeldernmüssendefiniertsein

60 4.2.4Geschäftslogik Inder Geschäftslogik werdendiecontroller Klassen genauerbeschrieben. DieControllersetzendiefunktionalenAnforderungen um,dieindenanwendungsfällenbeschriebenwurden. AusgangspunktsinddieControllerdes Analysemodelldiagramms.

61 Controller Beschreibung Beispiel: AusgangspunktAnalysemodelldiagramm BeschreibungEINESControllers

62 Controller Beschreibung Beispiel: Überwachung

63 Controller Beschreibung ElementederController Beschreibung: Titel:entsprichtControllerimAnalysemodelldiagramm Kurzbeschreibung:WesentlicheAufgabe BeziehungenzuControllern:ListemitControllernamenund Zweck BeziehungenzuEntitäten:ListemitEntitäten,benutzte DatenundZweck ListederMethoden:Name,Parameter,Rückgabewert (keinetypen!),fehler,verhalten MöglicheFehler:ListeallerFehler Objektmodell:AusschnittdesAnalysemodelldiagramms Anmerkungen

64 Controller Beschreibung

65 Controller Beschreibung

66 4.2.5Datenbasis Datenbasis= MengevonKlassen,umalleimSystemnotwendigen Datenzuverwalten DieseKlassen(Entitäten)verwaltennurDaten: geeignetedatenstrukturen Speicherungz.B.ineinerDatenbank Aufbereitung(z.B.SuchenoderSelektion) DieKlassenbesitzenansonstenkeineFunktionalität. EntitätenmüssenmitKlassendesDomänenmodells übereinstimmen!

67 Entitäten Beschreibung ElementederEntitäten Beschreibung: Titel:entsprichtEntitätimAnalysemodelldiagramm Attribute:Name,Typ,Wertebereich,Beschreibung Methoden:Name,Beschreibung,Fehler MöglicheFehler:ListeallerFehler Beziehungen:AssoziationenmitanderenEntitäten, Kardinalität Generalisierung/Spezialisierung:Ober und Unterklassen Bestand:z.B.Anfang,Wachstum,Endbestand,Zugriffe

68 Entitäten Beschreibung

69 4.3DynamischeModelle OftreichenstatischeMittel(Klassendiagrammetc.)nicht aus,umeinsystemzubeschreiben. DynamischeModellesindinUML: Kollaborationsdiagramm Sequenzdiagramm Zustandsdiagramm

70 4.3.1Sequenzdiagramm Sequenzdiagramm= DarstellungeinerzeitlichenKomponenteaufBasisder AbfolgevonNachrichten

71 Sequenzdiagramm ElementeeinesSequenzdiagramms:

72 Sequenzdiagramm ElementeeinesSequenzdiagramms:

73 Sequenzdiagramm PfeilefürNachrichtenundMethodenaufrufe:

74 Sequenzdiagramm

75 4.3.2Zustandsdiagramm Sequenzdiagramm= EntsprichtendlichemAutomaten Bestandteile: Zustände Ereignisse Aktionen Zustandsübergänge

76 Zustandsdiagramm Zustand BesitztNamen repräsentiertdenzustandeinesobjektes AbgerundetesRechteck:

77 Zustandsdiagramm EreignissekönnenwährenddesZustandseintretenund Aktionenauslösen(ohneZustandsänderung) BezeichnungenfürbesondereEreignisse: Entry:beiWechselindenZustand Exit:beiVerlassendesZustandes Do:währenddesZustandes

78 Zustandsdiagramm Zustandsübergänge PfeilemitoffenenSpitzen BeschriftungmitEreignis,daszudemÜbergangführt Anfangs undendzustand

79 Zustandsdiagramm Sammelzustände KleinesSymboluntenrechts

80 Zustandsdiagramm ParalleleZustände Exit,wennalleZustandsfolgenimEndzustandsind