SoftwareEngineering Prof.Dr.StefanEnderle NTAIsny
Nachtrag
4ArbeitsschrittAnalyse
Begriffe Analyse: VorgangzurBeschreibungdergewünschten AnforderungenaneinSystem. DieAnforderungenwerdenineinemDokumentstrukturiert Anforderung: BedingungoderFähigkeitfunktionalerodernicht funktionalernatur,dieeinsystemerfüllenmuss. Analysedokument: BeschreibungeinesSystemsmitBegriffenausdem Anwendungsbereich. Was abernicht wie
Einleitung ArbeitsschrittAnalyse: GesprächemitKunden/Kundenvertreter ErmittlungvonAnforderungen ErstellungAnalysedokument ZweiTeilabschnitte: Anforderungsanalyse: BeschreibungallerAnforderungenandasSystem Analysemodell: ÜberprüfungderAnforderungsanalyseaufMachbarkeit
4.1Anforderungsanalyse Ziel: FindenallerAnforderungenandasSystem BeschreibungausSichtdesBenutzers MeistmehrereIterationen: Anforderungeneinholen Dokumentieren Fragentretenauf Fragenklären Dokumentationanpassen DokumentationderAnforderungenistTeildesVertrags
Anforderungsanalyse Haupt Schwierigkeit: UnterschiedlicheDenkmustervonKundeund Analytiker FindeneinergemeinsamenSprache Dadurchschwierig,Ideenauszutauschen KonsequenteKlärungvonpotentiellen Missverständnissen Unterscheidungzwischendem,wasderKundewill unddem,wasertatsächlichbenötigt
Tätigkeiten
Tätigkeiten Systembeschreibung: AllgemeineEinführungindasSystem Begriffsverzeichnis: GemeinsameSprachezwischenKundeund Analytiker. BegriffeausAnwenderdomäne. Aktorenliste: BeschreibungderRechtederAktoren Domänenmodell: BeschreibungallerObjektederDomäne zumverständnisderzurverfügungstehendendaten
Tätigkeiten Anwendungsfalldiagramm: ÜbersichtlicheDarstellungderFunktionalitätdes Systems Anwendungsfallbeschreibung: DetaillierteBeschreibungderAnforderungenandas System Prototyp: DetaillierteDarstellungderAnwenderschnittstelle
4.1.1Systembeschreibung BeschreibungdesSystems oberflächlich ausführlich alshintergrundfürdieanforderungsdokumentation Inhalt: Ausgangssituation(Kunde,Auftraggeber) ZielsetzungdesSystems Wissensquellen Organisation(Geschäftsbereich,Ort) StandderTechnik(existierendeSysteme) GesetzlicherRahmen AbgrenzungdesneuenSystems
4.1.2Begriffsverzeichnis KlärungderFachsprachedesKundenbzw.Anwenders GenaueDefinitionvonBegriffenundProzessen
4.1.3Aktorenliste AuflistungallermitdemSystemkommunizierender Aktoren GenaueBeschreibungderRechtejedesAktors DiesvermeidetUnklarheitenin Anwendungsfalldiagrammund beschreibung (durcherweiterungen,optionalepfadeundvariationen später!)
4.1.4Anwendungsfalldiagramm DiagrammmitallenAktoren,Anwendungsfällenundderen Kommunikationuntereinander Anwendungsfall: Abgeschlossene,zusammenhängende,wiederkehrende AnwendungdesSystems Aktor: BenutzerdesSystemsmitRechtenundAufgaben HatgenaudanneineBeziehungzueinem Anwendungsfall,wennerberechtigtist,diesen auszulösen.
UMLAnwendungsfalldiagramm engl.:use CaseDiagram
Anwendungsfalldiagramm WeitereElemente: extends : <<extend>> > EinAnwendungsfallkanneinenanderen erweitern. include : > EinAnwendungsfallbenutzteinenanderen.
Anwendungsfalldiagramm
Anwendungsfalldiagramm FindenvonAktorenundAnwendungsfällen (z.b.ausprotokolldeskundengesprächs): SubjektimSatzistoftAktor VerbenlassenoftaufTätigkeitenschließen: AnwendungsfalloderTeildavon ObjektesindoftDaten(fürDomänenmodell)
4.1.5Anwendungsfallbeschreibung AlleAnwendungsfällewerdendetailliertbeschrieben InhaltproAnwendungsfall: EindeutigeNummeralsReferenz TitelmitFunktionalität KurzbeschreibungmitZusammenfassung VorbedingungenfürdieAusführung AblaufderEreignisse: E :EreignissedurchBenutzer A :AntwortdesSystems AE :AlternativesEreignis AuswirkungenaufSystemzustandundDatenbestand AnmerkungenzumVerständnis
Anwendungsfallbeschreibung
4.1.6Analyseprototyp EnthältalleAnwenderschnittstellendesSystems Oberflächesolltesoweitmöglichfunktionieren Menüs Fensteröffnenundschließen Dialoge Buttons KeineFunktionüberAnwenderschnittstellehinaus KeineGrundlagefürImplementierung! (keinsaubererentwurf)
Analyseprototyp Beispiel:
Analyseprototyp Vorteile: AnalytikererhältfrühesFeedbacküberRichtigkeitder Anforderungen KundebekommtfrühzeitigGefühlfürAussehenund FunktionsweisedesSystems ProgrammiererbekommtfrühMöglichkeit,sichmit Anforderungenvertrautzumachen
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,...)
Domänenmodell DarstellungdesDomänenmodells: UMLKlassendiagramm Abstraktionsschritt: NichtObjekte,sondernKlassenwerdenmodelliert InderAnalysemeistvordenAnwendungsfällen,inder Dokumentationabermeistzuletzt.
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
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.
UMLKlassenmodell Methoden: FähigkeiteneinerKlasse Unterscheidungsmöglichkeit: KonstruktorenundDestruktoren SpeichernundLadenvonObjektzuständen AttributeoderGesamtzustandändern AttributeoderGesamtzustandauslesen Berechnungausführen,basierendaufaktuellemZustand
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
UMLKlassenmodell Vererbung: InKlassenkannesinhaltlicheÜbereinstimmunggeben: Attributekönnengleichsein (TypundWert) Methodenkönnengleichsein (Parameter,Rückgabewert,Code) GibtesgenügendÜbereinstimmungen,sokönnendieseüber dievererbungsbeziehungverbundenwerden: Generalisierung/Spezialisierung(GenSpec)
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
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
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
UMLKlassenmodell Vererbungsbeziehung: WennesaufAttributeundMethodennichtankommt: Ticket {abstract} Platz Ticket Zähl Ticket
UMLKlassenmodell Assoziationen: könnenfolgendezusammenhängedarstellen: Datenabhängigkeit: EinObjektstelltInformationenfüreinanderesObjektzur Verfügung EinObjektistAttributeinesanderenObjekts FunktionalerZusammenhang: EineKlassebenötigtFunktioneneineranderenKlasse. Allg: EineKlassebenötigtetwasvoneineranderen
UMLKlassenmodell Assoziationen: Darstellung: LiniezwischenKlassen NamederAssoziation(aktivesVerb!) (wird_verkauft,hat_einkommen,...) Evtl.gefülltesDreieckfürLeserichtung Kardinalität(jeweilsamEndederLinie) Sitzplatz 1 gilt_für 1 Ticket
UMLKlassenmodell AssoziationenundKardinalität: DieKardinalitätgibtan,wievieleObjekteeinerKlassezueinem ObjektderKlasseamanderenEndeinBeziehungstehen können: Beliebigviele(auch0): * GenaueineMöglichkeit: 1 BereichvonWerten: 1..3oder1..* MehrereWertebereiche: 1..3,5,10
UMLKlassenmodell Assoziationen: Beispiel:
UMLKlassenmodell Assoziationen: Beispiel:
UMLKlassenmodell Assoziationen: Beispiel:
UMLKlassenmodell Assoziationen: Beispiel:
UMLKlassenmodell AssoziierteKlasse:
UMLKlassenmodell Assoziationen: Schleife:
UMLKlassenmodell AggregationundKomposition: ModellierendenFall,dasseineKlasseausTeilen zusammengesetztwerdenkann. Aggregation: TeilekönnenbeiZerstörungdesGanzenweiterexistieren. Komposition: ExistenzderTeilehörtnachEndedesGanzenebenfallsauf.
UMLKlassenmodell AggregationundKomposition: DarstellungundBeispiele: Aggregation: NachKonkursdesKinosgibtesdieRäumenoch. Komposition: LöschendesSitzplanslöschtauchdieorganisatorische EinheitderReihen.
4.2Analysemodell Anforderungsanalyse= WünscheundAnforderungendesKundenermitteln Systembeschreibung Begriffsverzeichnis Aktorenliste Anwendungsfalldiagramm Anwendungsfallbeschreibung Analyseprototyp Domänenmodell Anforderungsanalyse= MachbarkeitundVollständigkeitprüfen
Analysemodell UnterschiedeAnforderungsanalyse Analysemodell
Analysemodell TätigkeitenbeimErstellendesAnalysemodells Produkte: Analysemodelldiagramm BeschreibungallerElemente(Schnittstellen,Controller, Entitäten)
4.2.1Analysemodelldiagramm KlassendiagrammenthältstatischeZusammenhänge zwischenklassen AnalysemodelldiagrammenthältauchFunktionalität 3UMLStereotypen: Schnittstelle Controller Entität
Analysemodelldiagramm entsprichtmvc
Analysemodelldiagramm Beispiel:Lift Steuerung KeineeinzelnenObjekte,sondernKlassen!
Analysemodelldiagramm DasAnalysemodelldientwiedernurdemÜberblick (vgl.anwendungsfalldiagramm/ beschreibung) AlsdetaillierteBeschreibungfolgt: Systemschnittstellen Anwenderschnittstellen Geschäftslogik Datenbasis Datenmodellzyklus
4.2.2Systemschnittstellen Systemschnittstellen= Schnittstellen,dieZugriffaufanderetechnischeSysteme ermöglichen. (D.h.aufSubsystemeoderexterneSysteme) ProSchnittstelleeinDokument(1Seite). EinSystembenötigtvoneinemanderenSystem Funktionen,diedortinderBeschreibungaufgelistet werden. EinSystembietetFunktionenan,dieindereigenen Beschreibungaufgelistetwerden.
Systemschnittstellen Beispiel1zur Ticket Line
Systemschnittstellen Beispiel2zur Ticket Line
Systemschnittstellen Allgemein: Titel BezeichnungdesSystemsim Analysemodelldiagramm Kurzbeschreibung WesentlicheAufgabeundVerantwortung, grundlegendefunktionalität ListederMethoden MethodenmitParameterundRückgabewert(keine Datentypen),evtl.ausgelösteFehler,Verhalten ListedermöglichenFehler AlleFehlersämtlicherMethodenaufgelistet
4.2.3Anwenderschnittstellen Anwenderschnittstellen= SchnittstellenzudenBenutzerndesSystems. ProSchnittstelleeinDokument(1Seite) mitscreenshotsodergrafiken. SolltemitAnalyseprototypübereinstimmen.
Anwenderschnittstellen Beispiel:
Anwenderschnittstellen WichtigePunkte: BedeutungallerdargestellterElementemuss dokumentiertsein AlleAktionen,dieausgehendvonder Anwenderschnittstelledurchgeführtwerdenkönnen, müssenaufgelistetsein InhaltevonListenundFeldernmüssendefiniertsein
4.2.4Geschäftslogik Inder Geschäftslogik werdendiecontroller Klassen genauerbeschrieben. DieControllersetzendiefunktionalenAnforderungen um,dieindenanwendungsfällenbeschriebenwurden. AusgangspunktsinddieControllerdes Analysemodelldiagramms.
Controller Beschreibung Beispiel: AusgangspunktAnalysemodelldiagramm BeschreibungEINESControllers
Controller Beschreibung Beispiel: Überwachung
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
Controller Beschreibung
Controller Beschreibung
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!
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
Entitäten Beschreibung
4.3DynamischeModelle OftreichenstatischeMittel(Klassendiagrammetc.)nicht aus,umeinsystemzubeschreiben. DynamischeModellesindinUML: Kollaborationsdiagramm Sequenzdiagramm Zustandsdiagramm
4.3.1Sequenzdiagramm Sequenzdiagramm= DarstellungeinerzeitlichenKomponenteaufBasisder AbfolgevonNachrichten
Sequenzdiagramm ElementeeinesSequenzdiagramms:
Sequenzdiagramm ElementeeinesSequenzdiagramms:
Sequenzdiagramm PfeilefürNachrichtenundMethodenaufrufe:
Sequenzdiagramm
4.3.2Zustandsdiagramm Sequenzdiagramm= EntsprichtendlichemAutomaten Bestandteile: Zustände Ereignisse Aktionen Zustandsübergänge
Zustandsdiagramm Zustand BesitztNamen repräsentiertdenzustandeinesobjektes AbgerundetesRechteck:
Zustandsdiagramm EreignissekönnenwährenddesZustandseintretenund Aktionenauslösen(ohneZustandsänderung) BezeichnungenfürbesondereEreignisse: Entry:beiWechselindenZustand Exit:beiVerlassendesZustandes Do:währenddesZustandes
Zustandsdiagramm Zustandsübergänge PfeilemitoffenenSpitzen BeschriftungmitEreignis,daszudemÜbergangführt Anfangs undendzustand
Zustandsdiagramm Sammelzustände KleinesSymboluntenrechts
Zustandsdiagramm ParalleleZustände Exit,wennalleZustandsfolgenimEndzustandsind