Home

komplette Skript - Fachgebiet Echtzeitsysteme

1. Datenbank DB Menge von Relationen Tabellen DB Schema Menge von Relationenschemata Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 268 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme Prim r und Fremdschl ssel von Relationen schemata LJ Prim rschl ssel einer Relation Relationenschemas eine Menge von Attributen die jede Zeile Tupel der Relation eindeutig identifiziert es d rfen also keine zwei Zeilen einer Relationen die selben Attributwerte f r alle Prim rschl sselattribute besitzen Prim rschl ssel k nnen damit als Identifikatoren f r alle Eintr ge in Datenbanktabellen genutzt werden Fremdschl ssel einer Relation Attribute einer Relation die Prim rschl ssel in einer anderen Relation sind Die Fremdschl sselwerte aller Zeilen einer Relation m ssen als Prim rschl sselattribute von Zeilen der entsprechenden anderen Rela tion auftreten Damit k nnen Prim r und Fremdschl ssel Definitionen zur Beschreibung von Konsistenzbedingungen f r Datenbanken eingesetzt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 269 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Integritatsbedingungen Konsistenzregeln zum Ausleih Beispiel lokale Integritatsbedingungen Q zu jedem Attribut in jedem Relationenschema gibt es eine Typdefinition die zul ssige We
2. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 589 Fachgebiet Management der Software Entwicklung Echtzeit fp systeme Bewertung des Rational Unified Prozesses es gibt Standardisierungsvorschlag f r OMG und kommerzielles Produkt WWW basiert http www 306 ibm com software awdtools rup Manager hat die grobe Inception Elaboration Construction Transition Sicht Entwickler hat zus tzlich die feinere arbeitsbereichsorientierte Sicht Wartung ist eine Abfolge zu entwickelnder Produktgenerationen es wird endg ltig die Illusion aufgegeben dass Analyse Design zeitlich begrenzte strikt aufeinander folgende Phasen sind komplexes noch in Ver nderung befindliches Vorgehensmodell f r UML noch nicht mit Beh rdenstandards V Modell richtig integriert Qualit tssicherung ist kein eigener Aktivit tsbereich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 590 Management der Software Entwicklung Eon A systeme 10 4 Leichtgewichtige Prozessmodelle Herk mmlichen Standards f r Vorgehensmodelle zur Softwareentwicklung V Modell RUP wird vorgeworfen dass sie sehr starr sind Unmengen an Papier produzieren und nutzlos Arbeitskr fte binden Deshalb werden seit einiger Zeit sogenannte leichtgewichtige Prozessmodelle light weight processes propagiert die sinnlosen b rokratischen Overhead vermeiden w
3. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 532 Fachgebiet Qualit tssicherung und Testverfahren Echtzeit po systeme Prinzipien der Qualitit tssicherung U Qualit tszielbestimmung Auftraggeber und Auftragnehmer legen vor Beginn der Softwareentwicklung gemeinsames Qualit tsziel f r Softwaresystem mit nach pr fbarem Kriterienkatalog fest als Vertragsbestandteil des Lastenheftes gt Abnahmetests quantitative Qualit tssicherung Einsatz automatisch ermittelbarer Metriken zur Qualit tsbestimmung objektivierbare ingenieurm ige Vorgehensweise konstruktive Qualit tssicherung Verwendung geeigneter Methoden Sprachen und Werkzeuge Sprachen mit vern nftiger Syntax statischem Typkonzept integrierte fr hzeitige analytische Qualit tssicherung nicht nur fertiges Soft wareprodukt testen sondern alle erzeugten Dokumente wie Analyse und Design modelle sowie einzelne Softwarekomponenten unabh ngige Qualit tssicherung Entwicklungsprodukte werden durch eigen st ndige Qualit tssicherungsabteilung berpr ft und abgenommen verhindert u a Verzicht auf Testen zugunsten Einhaltung des Entwicklungszeitplans Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 533 Qualit tssicherung und Testverfahren Echtecit systeme 9 2 Ma nahmen zur Erstellung fehlerarmer Software Begriffe Failure Fault Error im Englischen
4. U weitere Operationen Vereinigung Durchschnitt Differenz von gleich strukturierten Tabellen Umbenennung von Spalten Attributen Achtung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 272 Von der OO Analyse zum Datenbank Entwurf Enten gg systeme 6 2 Operationen lassen sich beliebig kombinieren schachteln Relationenalge Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 273 Von der OO Analyse zum Datenbank Entwurf Ennet ER systeme braRelationaler Datenbankentwurf Anforderungsanalyse Informationsanalyse Funktionsanalyse konzeptioneller Schemaentwurf Sichtenentwurf Sichtenanalyse Sichtenintegration logischer Entwurf go Ro Verteilungsentwurf vertauschen V i Datendefinition phyischer Entwurf N Implementierung amp Wartung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 274 Von der OO Analyse zum Datenbank Entwurf Echtzeit Mich systeme Anforderungsanalyse siehe bisherige Kapitel der Vorlesung Ergebnis LJ informale Beschreibung des Fachproblems Texte tabellarische Aufstellungen Formbl tter Maskenentw rfe LJ Trennen der Informationen ber Daten Datenanalyse von den Informationen ber Funktionen Funktionsanalyse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentech
5. Objektorientierte Anforderungsanalyse Echtzeit systeme Definition von Instanz Mitglied und Extension von Klassen jedes Objekt ist Instanz genau einer seiner Klasse abstrakte Klassen kursive Namen besitzen keine Instanzen jedes Objekt ist Mitglied seiner eigenen Klasse und aller ihrer Oberklassen LJ die Extension einer Klasse ist die Menge ihrer Mitglieder Grafik f r Extensionen Extension der Menge der LegalEntity Objekte Extension der Menge der Extension der Menge der Company Objekte Person Objekte Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 214 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit systeme Beispiel eines einfachen Klassendiagramms ohne Attribute mas x i Entit i disjoint 4S A disjoint Person has Reservation ZS Contracts hasClients gt lt 4 reservedVehicle hasVehicles gt Vehicle 7 rentedVehicle overlapping 4S LR SY MVRS Motor Vehicle Reservation System Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 215 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit fic systeme 5 4 Exkurs zu Petri Netzen Petri Netze wurden zur Modellierung und Analyse des Verhaltens von Systemen mit statischer Struktur und nebenl ufig parallel arbeitenden Teilkomponenten entwickelt Ihre Urform wurde von Adam Petri in seiner Disserta
6. Objektorientierter Softwareentwurf Eonze X systeme Schnittstellen und Beziehungen zwischen Klassen und Paketen LJ Import Beziehung Dependency Paket A importiert Paket B und sieht damit alle public Elemente von B in B enthaltene Klassen Pakete Export von B Paket A importiert nur eine Klasse und sieht damit genau diese Klasse Public und Private Import Beziehung zwischen Paketen bei normalem Import werden alle aus B importierten Elemente zu ffent lich sichtbaren public Elementen von A und werden von dort weiter exportiert bei access Import werden alle ffentlich sichtbaren Elemente von B zu nur lokal sichtbaren Elementen von A werden nicht weiter exportiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 437 Objektorientierter Softwareentwurf Eon A systeme 8 3 Verteilungsdiagramme von UML Die bisher eingef hrten UML Diagramme beschreiben das Softwareprodukt aus logischer Sicht Bislang nicht betrachtet wurde Zusammenfassung des Codes von Klassen und Verhaltensdiagrammen zu Bin rdateien die ausgeliefert werden Zuordnung von Hilfsdateien zu einzelnen Bin rdateien wie Datenbanken Online Hilfetexte Fehlermeldungsdateien Konfigurationstabellen Verteilung von Softwareprodukt auf mehrere Hardwarekomponenten oder Betriebssystemprozesse Vorgehensweise Beschreibung von physikalischen verteilbaren Sof
7. wie beim evolution ren Vorgehensmodell bei Erfolg weiter zu Transition Einf hrung Auslieferung des Systems an den Anwender inklusive Marketing Support Dokumentation Schulung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 585 Management der Software Entwicklung Eon A systeme Eigenschaften des Rational Unified Prozesses RUP L modellbasiert f r die einzelnen Schritte des Prozesses ist festgelegt welche Modelle Dokumente des Produkts zu erzeugen sind LJ prozessorientiert die Arbeit ist in eine genau definierte Abfolge von Aktivit ten unterteilt die von anderen Teams in anderen Projekten wiederholt werden k nnen iterativ und inkrementell die Arbeit ist in eine Vielzahl von Iterationen unter teilt das Produkt wird inkrementell entwickelt risikobewusst Aktivit ten mit hohem Risiko werden identifiziert und in fr hen Iterationen in Angriff genommen zyklisch die Produktentwicklung erfolgt in Zyklen Generationen Jeder Zyklus liefert eine neue als kommerzielles Produkt ausgelieferte Systemgeneration ergebnisorientiert jede Phase Iteration ist mit der Ablieferung eines definierten Ergebnisses meist zu einem konkreten Zeitpunkt Meilenstein verbunden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 586 Management der Software Entwicklung Eon A systeme Faustregeln f r die Ausgestaltung eines Ent
8. Einf hrung in Software Engineering Echte ed systeme Organisation der Lehrveranstaltung LJ Termine f r Sp taufsteher Mittwoch 16 15 Uhr bis 17 45 in SIIO1IAO3 Vorlesung ab 15 10 14 Donnerstag 16 15 bis 17 00 Uhr in S11011A03 Vorlesung ab 16 10 14 Donnerstag 17 05 bis 17 50 Uhr in S11011A03 Ubung ab 23 10 14 Q Klausur Klausur am Ende der Vorlesungszeit 25 02 2015 ab 8 00 Uhr gt alte Klausuraufgaben werden online gestellt mit Musterl sung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 5 N a r bi Einf hrung in Software Engineering Een ES systeme Quellenverweis und Danksagung F r die Erstellung der ersten Version dieser Vorlesung stand mir dankenswerter Weise das Folienmaterial der Software Engineering Vorlesung von Prof Dr Gregor Engels Universit t Paderborn zur Verf gung Bei den berarbeitungen dieser Vorlesung wurden die bernommenen Teile aber inzwischen stark berarbeitet so dass davon auszugehen ist dass alle Fehler bez glich Inhalt Layout und Umgang mit der deutschen Sprache allein dem Dozenten der Lehrveranstaltung zuzuschreiben sind Des weiteren habe ich Anregungen und Bilder aus dem Vorlesungsmaterial von Dr Michael Eichberg TU Darmstadt bernommen Vorlesungsunterlagen von EiSE WS 2007 2008 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 6 N a r a N hgebi Einf hrung i
9. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 443 Objektorientierter Softwareentwurf Echteslt systeme 8 4 Softwareevolution und Refactoring Refactoring ist Evolution bzw Sanierung von Software in kleinen Schritten ohne das Verhalten der betroffenen Software zu ndern Regressionstests nach jeder Ande rung neu durchgef hrte Tests werden eingesetzt um nach jedem kleinen Umbau schritt sicherzustellen dass sich Softwareverhalten nicht ge ndert hat Ziele des Refactorings Verst ndlichkeit von Software erh hen gt nderungen und Erweiterungen von Software erleichtern effizienzsteigernde Ma nahmen erleichtern hnliche identische Codestellen zusammenfassen durch Metriken Analysen als fragw rdig erkannten Code ausmerzen Debugging von Software vereinfachen dem Alterungsprozess von Software entgegenwirken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 444 Objektorientierter Softwareentwurf Eche AS systeme Gr nde aus denen Refactoring nicht eingesetzt wird L wegen Termindruck ist angeblich keine Zeit nutzlose Aufr umarbeiten durchzuf hren aber anschlie ende Erweiterungen Fehlersuche gehen schneller Refactoring f hrt zu ggf tats chlich erst einmal ineffizienteren Programmen aber effizienzsteigernde Programmtransformationen sind anschlie end einfacher durchzuf hren never
10. lt comparison predicate gt lt value expression gt lt comp op gt lt value expression gt lt subquery gt lt comp op gt lt gt lt gt lt gt lt subquery gt SELECT ALL DISTINCT lt result specification gt lt table expression gt lt result specification gt lt value expression gt lt between predicate gt lt value expression gt BETWEEN lt value expression gt AND lt value expression gt lt in predicate gt lt value expression gt NOT IN lt subquery gt lt in value list gt lt in value list gt lt value specification gt lt value specification gt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 314 Von der OO Analyse zum Datenbank Entwurf Een EX systeme Erl uterungen zu der Syntax von Suchbedingungen LJ es lassen sich ber den Spalten Attributen einer Tabelle beliebige aussagenlogische Formeln aufbauen man beachte dass ein solches Pr dikat immer bezogen auf ein Tupel der betrach teten Tabelle ausgewertet wird bestimmte Pr dikate erlauben das Schachteln von Anfragen das between Pr dikat ist eine Abk rzung f r zwei Vergleiche mit lt und gt das in Pr dikat berpr ft ob ein bestimmter Wert in einer Menge von Werten ent halten ist die geschachtelte Anfrage mu Tabelle mit einer Spalte berechnen mit dem like Pr dikat kann man regul re Ausdr cke in Zeichen
11. w hrend Aktionsausf hrung zu einem Ereignis in Teilautomat A k nnen bereits neue Ereignisse in anderem Teilautomat B behandelt werden gt jeder Teilautomat hat eigene Kopie der Warteschlange mit eingetroffenen Ereignissen die noch abzuarbeiten sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 405 Von der OO Analyse zum Software Entwurf Echizeit A systeme Komplexe echt parallele Zustands berg nge R fork Kontrolle aufspalten join Kontrolle vereinigen Achtung Die and Zust nde mit fork join Konstrukt lassen sich nicht mehr in Produktautomaten bersetzen Man hat in einem Objekt mehrere threads of control Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 406 Von der OO Analyse zum Software Entwurf Echtzeit ip systeme Beispiel Lebenszyklus von ReservationContract Objekten setClient incomplete N setVehicle Data Q Zustandsdiagramme besitzen hnlichkeit mit Aktivit tsdiagrammen Knoten sind aber hier Zust nde genau eines Objekts und keine Aktionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 407 Von der OO Analyse zum Software Entwurf Eon ES systeme Weitere Elemente von UML Statecharts History Mechanismus in komplexen Zust nden bei Wiedereintritt in Zustand wird nicht Anfangszustand a
12. 6 Abnahme Zeitraum f r Paketbearbeitung NT Nettozeit Pufferzeit float Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 623 Management der Software Entwicklung Echtzeit systeme Balkendiagramm mit Personalplanung 14 4 03 28 4 03 5 5 03 19 5 03 2 6 03 16 6 03 30 6 03 11 7 03 lich f r alle Phasen Edeltraud Valerie Design DB Schema Listen epee Updates Integration verantwort Analyse O Uab Benutzeroberfl che Men nm Integration Nettozeit Achtung Puff it Bu Durch Ressourcenzuteilung entstehen zus tzliche Zeit flo a ze restriktionen z B Listen nach DB Schema Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 624 Management der Software Entwicklung Echtzeit systeme 10 7 Aufwands und Kostensch tzung Die Kosten eines Softwareproduktes und die Entwicklungsdauer werden im wesent lichen durch den personellen Aufwand bestimmt Bislang haben wir vorausgesetzt dass der personelle Aufwand bekannt ist hier werden wir uns mit seiner Berechnung bzw Sch tzung befassen Der personelle Aufwand f r die Erstellung eines Softwareproduktes ergibt sich aus gt dem Umfang des zu erstellenden Softwareprodukts gt der geforderten Qualit t f r das Produkt bliches Ma f r Personalaufwand Mitarbeitermonate MM oder Mitarbeiterjahre MJ 1 MJ 10 MM
13. AddVehicle Neues Fahrzeug wird in Fuhrpark aufgenommen ausgeblendet F FetchVehicle_ gt Fahrzeug wird abgeholt _ReturnVehicle_ gt Fahrzeug wird zur ckgebracht _RemoveVehicle_ gt Fahrzeug wird ausgemustert N MVRS_Vehicles Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 164 Objektorientierte Anforderungsanalyse Echtzeit systeme Kommentare zu der Zerlegung in Teilsysteme LJ man muss sich gut berlegen ob die Zerlegung eines Systems in Teilsysteme in der Analysephase bereits sinnvoll ist eigentlich geht es ja um das was bietet das System an und nicht um das wie wird das System realisiert aber f r die Projektplanung ist eine fr he grobe Einteilung eines Systems in Teil systeme und Zuordnung von Funktionen zu Teilsystemen sinnvoll zudem ist es eine naheliegende M glichkeit eine gro e Menge von Anwendungsfallen sinnvoll zu unterteilen eine andere Variante der Unterteilung Hierarchisierung werden wir am Ende des Abschnitts kennenlernen mit Paketen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 165 Objektorientierte Anforderungsanalyse Echtzeit systeme Externe Beziehungen zwischen und Generalisierung von Akteuren MVRS_Clients _ Adaclient 2 Erstes Release hat noch keine separate N Verwaltung von Kundenstammdaten 0 2 1 MVRS_Reservations r ion Fa zeug wi d f ei e besti
14. ggf das Zusammenspiel der Operationen verschiedener Klassen durch die in Abschnitt 7 3 eingef hrten Interaktionsdiagramme beschrieben werden zu einigen Klassen eine Beschreibung ihres isolierten Verhaltens durch die in Abschnitt 7 4 eingef hrten Statecharts Automaten hinzugef gt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 250 Objektorientierte Anforderungsanalyse one AS systeme Aufbau eines Pflichtenheftes 5 7 Produktleistungen Verfeinerung des entsprechenden Lastenheftkapitels Weitere Angaben zu den einzelnen Produktfunktionen oder Produktdaten der vorangegangenen Kapitel Hier werden oft Leistungsanforderungen bzgl Zeit und Genauigkeit angegeben Verzichtet man auf diesen Abschnitt nicht ganz dann wird man ggf hier bereits die Interaktionsdiagramme und Statecharts der UML verwenden siehe Kapitel 7 Qualit tsanforderungen Verfeinerung des entsprechenden Lastenheftkapitels Wieder wird f r die in Abschnitt 1 4 eingef hrten Softwarequalit tsmerkmale in Matrix Form angegeben wie wichtig sie sind siehe auch DIN ISO Norm 9126 zu Qualit tsanforderungen an Software Benutzungsoberfl che neuer Abschnitt Grundlegende Anforderungen an die Benutzeroberfl che wie Gestaltungsricht linien werden hier festgehalten zu einem ausf hrbaren Pflichtenheft geh rt auch ein Rapid Prototype der tats chlichen sp teren Benutzeroberfl che Prof Dr A
15. Software System Gro es Problem Anforderungsdefinitionen sind h ufig informal und damit eigentlich nie ganz widerspruchsfrei vollst ndig pr zise formuliert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 35 Software Technik Was ist das Echtesit systeme Verfugbarkeit von Software Availability Verf gbarkeit ist ein Ma daf r wie h ufig ein Software System nicht die gew nschte Funktionalit t in vollem Umfang zur Verf gung stellen kann Metriken f r Bewertung der Verf gbarkeit von Software 1 rate of failure occurrence ROFOC H ufigkeit von nicht erwartetem Verhalten z B 2 Fehler pro 100 operationellen Zeiteinheiten mean time to failure MTTF mittlerer Zeitabstand zwischen zwei Fehlern also von unerwartetem bzw unerw nschtem Verhalten Problem Schwere der Fehler und Zeit Aufwand f r Fehlerbehebung werden bei obigen Definitionen erst mal nicht ber cksichtigt avallability AVAIL mittlere Verf gbarkeit der Software z B 998 von 1000 Zeiteinheiten war das System benutzbar Problem Ber cksichtigt Zeit Aufwand f r Fehlerbehebungen oder andere Wartungsaktivit ten aber nicht Schwere der Fehler Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 36 Fachgebiet Software Technik Was ist das Echtzeit u systeme Wz Zuverlassigkeit von Software Reliability Zuverl ssige
16. Z Schritt Aktualisierung der Wertepaare FPs lt gt Aufwand aus Wertepaare Neu abgeschlossenen Entwicklungen berechnung der Aufwandskurve Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 640 Seite 641 Fachgebiet Echizeit systeme 3 13534104 UO nIUNY 33119Mag 20 001 23 Bunyamaqgynyury 101424 assnyuly Z Jap swwins S 0 uaBunsaieAu0y Spuejsaquazeg 9 S 0 4 607 P 01 0 ua unjabalswyeusny gt S 0 uye n q 01 0 uauones dou y2 y e Y ojsbunyagueiaa p S 0 3re suonyesueu S 0 Buny squesay ajesjuezep usyeg Jjeluaz3g Z O F WN JUaM Iulod S 0 uawaJsAssbunpusamuy uon gt ung uap Wepur uasapue yw BUNJU uso yEsynyuly D Cc x C LI _ Oo 3 O ep O D Oo Cc Oo Berechnungsformel fur die FP Methode uage sny uabeygv 9poyJalN dF Ip uny jawuojsHunuyoaseg Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Management der Software Entwicklung Echtzeit systeme Zus tzliche Einflussfaktoren Die vorige Tabelle unterscheidet sieben Einflussfaktoren andere Quellen nennen 14 bzw 19 verschiedene Faktoren die Werte von 0 bis 5 erhalten siehe Hu99 Komplexit t der Datenkommunikation Grad der verteilten Datenverarbeitung geforderte Leistungsf higkeit Komplexit t der Konfiguration Zielplattform Anforderung an Transaktionsrate
17. gt No LJ Durability Was passiert wenn nach der Durchf hrung einer Reihe von Uberwei sungen von einer Bank auf eine andere das DBMS der einen Bank abstiirzt No Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 322 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme Sperrkonzept f r serialisierbare Schedules Durch Sperren mu vermieden werden da von T1 gelesene Attributwerte und noch in Bearbeitung befindliche Attributwerte von T2 parallel ver ndert werden Sperrgranularit t ganze Tabelle f r umfangreichere Operationen Auswertungen gt einzelne Zeile bei selektivem Lesen oder ndern gt einzelnes Attribut bei sehr selektivem Lesen oder ndern bliche Sperrarten Lesesperre erlaubt weitere Lesesperre aber keine Schreibsperre Schreibsperre erlaubt keine weitere Sperre bliche Sperrprotokolle Zwei Phasen Protokoll alle Sperranforderungen vor allen Sperrfreigaben striktes Zwei Phasen Protokoll Sperrfreigaben mit Transaktionsende Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 323 Von der OO Analyse zum Datenbank Entwurf Een AX systeme 6 7 Ausblick Die relationalen Datenbankmanagementsysteme RDBMS dominieren weiterhin den Markt So genannte Nicht Standard DBMS bzw NoSQL Ansatze sind auf ganz spezielle Anwendungsbereiche beschr nkt und besitzen meist nur eine kleine
18. lt referential constraint definition gt FOREIGN KEY lt reference column list gt lt references specification gt lt references specification gt REFERENCES lt referenced table and columns gt lt referenced table and columns gt lt table name gt lt reference column list gt lt reference column list gt lt column name gt lt column name gt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 304 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit dp systeme Erl uterungen zur SQL Syntax Teil 2 LJ es gibt drei Arten von Integrit tsbedingungen gt unique constraints legen Prim rschl ssel und Sekund rschl ssel fest es handelt sich um intrarelationale Integrit tsbedingungen auf einer Tabelle gt referential constraints legen Fremdschl sselbedingungen fest es handelt sich um interrelationale Integrit tsbedingungen zwischen zwei Tabellen gt check constraints erlauben die Definition komplexer er Konsistenzbe dingungen mit Hilfe von Anfragen es handelt sich um intrarelationale Integrit tsbedingungen U jede Integrit tsbedingung die eine Spalte betrifft kann bei der Definition dieser Spalte angegeben werden L jede Integrit tsbedingung ber mehr als einer Spalte z B zusammengesetzte Schl ssel mu als separate Definition formuliert werden Prof Dr Andy Sch rr TU Darmstadt FB 1
19. systeme Einfaches Objektdiagramm Objekt mit Bezeichner Dead Fish Inc noch ohne Klassenangabe worksFor Menge von Objekten Slot Attribute instance der Klasse Contract Link Instanz with Value von works _for ohne Bez Assoziation 789 Contrac worksFor Objekt mit Arne genau ein Bez Arne Contract und Instanz der Objekt Klasse Client U Modellierung von konkreten Szenarien Snapshots mit Klasseninstanzen Instance Specifications Objekten und Assoziationsinstanzen Links Gegenst ck der Datenmodellierung zu den funktionalen Anwendungsf llen manchmal hilfreich f r den bergang von der realen Welt zu den abstrakten Klassendiagrammen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 187 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit systeme Kandidaten f r Objekte und Klassen UL alle phyischen ber hbaren Gegenst nde wie Vehicle Personenrollen wie Clerk Client Institutionen wie Company abstrakte Begriffe wie Address durchzuf hrende Transaktionen wie Renting Payment eintretende Ereignisse wie Accident Man beachte Auch Operationen Transaktionen Ereignisse Prozesse k nnen sinnvolle Objekt kandidaten sein Nicht nur passive Datenbest nde werden als Objekte modelliert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 188 Objektorientierte Anforderungsa
20. Codegenerierung aus Statecharts Mit Codefragmenten und Definition des Aufz hlungstyps ResState f r Reserva tionContract Zust nde erg nztes leicht ge ndertes Beispiel von Seite 389 ReservationContract lt lt enumeration gt gt state ResState ResState create ReservationContract initial ResState new ResState confirm void incomplete ResState new ResSte cancel void confirmed ResState new ResStat dead ResState new ResState client String category String period String I setCategory c category q create setClient cl Client cl u setPeriod p period p confirm period equals amp amp category equals confirmed cancel Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 412 Von der OO Analyse zum Software Entwurf Echtesit systeme Generierbarer Code aus Statechart public class ReservationContract public String getClient return client public void setClient String client if state ResState initial this client client state ResState incomplete else tue nichts man k nnte h chstens eine Ausnahme ausl sen public void confirm if state ResState incomplete amp amp category equals amp amp period equals state ResState confirmed else tue nichts man k nnte h chstens eine Ausnahme ausl sen private String client private ResState state ResStat
21. Embrace the Change Addison Wesley 1999 Eins der Standardwerke zum Thema XP geschrieben vom Erfinder Mehr Bettlekt re mit Hintergrundin formationen und Motivation f r XP Techniken als konkrete Handlungsanweisung K M Dymond CMM Handbuch Springer Verlag 2002 Einfach zu verstehende schrittweise Einf hrung in CMM Levels und Upgrades von einem Level zum n chsten in deutscher Sprache Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 654 Management der Software Entwicklung Echtzeit systeme Hu99 R H rten Function Point Analysis Theorie und Praxis Die Grundlage f r ein modernes Software Management expert verlag 1999 177 Seiten Kompaktes Buch zur Kostensch tzung mit Function Point Methode das Wert auf nachvollziehbare Bei spiele legt Zus tzlich gibt es eine Floppy Disc mit entsprechenden Excel Sheets Hu96 W S Humphrey Introduction to the Personal Software Process SEI Series in Software Engineering Addison Wesley 1996 Das CMM Modell f r den kleinen Mann Das Buch beschreibt wie man als einzelner Softwareentwick ler von bescheidenen Anf ngen ausgehend die Prinzipien der Prozess berwachung und verbesserung ein setzen kann Zielsetzungen sind zuverl ssigere Zeit und Kostensch tzungen Fehlerreduktion JBR99 I Jacobson G Booch J Rumbaugh The Unified Software Development Process Addison Wesley 1999 Pr sentation des auf die UML zugeschni
22. Implementierungsberichte Abweichungen vom Entwurf Zeitplan technische Dokumentation einzelner Module gt Testprotokolle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 59 Vorgehensmodelle der Software Entwicklung Echte dec systeme Integration und Systemtest Systemintegration Die einzelnen Module werden schrittweise zum Gesamtsystem zusammengebaut Diese Phase kann mit der vorigen Phase verschmolzen werden falls der Test isolierter Module nicht praktikabel ist LJ Aufgaben siehe Kapitel 9 Systemintegration Zusammenbau der Module Gesamtsystemtest in Entwicklungsorganisation durch Kunden a Test Fertigstellung der Dokumentation U Ergebnisse fertiges System Benutzerhandbuch amp technische Dokumentation gt Testprotokolle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 60 Vorgehensmodelle der Software Entwicklung Ente gg systeme Auslieferung und Installation Migration und Einf hrung Die Auslieferung Installation und Inbetriebnahme der Software beim Kunden findet h ufig in zwei Phasen statt LJ Aufgaben siehe LV Software Engineering Wartung und Qualit tssicherung Auslieferung an ausgew hlte Pilot Benutzer Test Auslieferung an alle Benutzer Migration auf neues System Schulung bzw Einf hrung der Benutzer LJ Ergebnisse fertiges System Akzeptanz
23. MotorVehicle A benutzt B Client MotorVehicle A verweist auf B InsuranceContract RentalContract E E E E A kommuniziert mit B Client Clerk Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 199 Objektorientierte Anforderungsanalyse Eigenschaften von Assoziationen Beispiel Reservation Contract Fragestellung 2 Personen zu einem Kontrakt _ TN Client Objekte has Links Fachgebiet f Echtzeit systeme Z Reservation Contract Objekte Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 200 Fachgebiet f Objektorientierte Anforderungsanalyse Echtzeit systeme Eigenschaften von Assoziationen 2 Q Multiplizit t Kardinalit t Client has Reservation 1 Contract ein ReservationContract ein Client hat beliebig viele hat genau einen Client ReservationContracts Format von Multiplizit tsangaben lt untere Grenze gt lt obere Grenze gt 0 1 4 0 U Leserichtung Client hat Contract und nicht umgekehrt has Contract J gt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 201 Objektorientierte Anforderungsanalyse EACHOphiRt Echizeit systeme Navigierrichtung hat im Prinzip nichts mit Leserichtung zu tun Achtung Reservation g Leserichtung Navigationsrichtung Contract meist sinn
24. Statement Das Observer Entwurfsmuster erlaubt uns die Auftrennung der alten Klasse Customer in CustomerSubject und CustomerHtmlObserver etc Anmerkung Die Control Klasse des MVC Konzepts fehlt hier noch die View Obeserver Objekte bei Model Subject Objekten registriert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 514 jektorientierter Softwareentwur Echtzeit A Objekt tierter Soft twurf systeme Klassendiagramm des Entwurfsmusters Observer ee oe _ observers I I subject Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 515 Objektorientierter Softwareentwurf Eenzet A systeme Von Design Pattern zu Anti Pattern Anti Pattern beschreiben h ufig verwendete L sungen Entwurfsmuster f r Probleme die sich in der Praxis nicht bew hren negative Konsequenzen haben Sie sind damit das Gegenst ck zu den Design Patterns die bew hrte L sungen f r oft wiederkehrende Probleme festhalten Design Pattern Anti Pattern K Einfl Problem C Kontext 8 isse gt Kontext amp Einfl sse Anti Pattern L sung ans C Symptome amp Konsequenzen gt Vorteile Konsequenzen Refactoring Verwandte L sungen Design Pattern L sung Vorteile Konsequenzen Verwandte L sungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 516 Objektorientierter Softwareentwurf Eon
25. U Teilsystem Sicht Zerlegung des Quellcodes in unabh ngig bearbeitbare Teile mit pr zise definierten Schnittstellen in UML mit Paketdiagrammen Package Diagrams siehe Abschnitt 8 2 Konfigurations Sicht Zusammenstellung ausf hrbarer Systemversionen als ausf hrbare Dateien mit zus tzlichen Tabellen Online Manualen gt in UML mit Verteilungsdiagrammen Deployment Diagrams siehe Abschnitt 8 3 LJ Physikalische Sicht Abbildung von Software auf Hardware oder Betriebs systemdienste insbesondere bei verteilten und oder eingebetteten Systemen in UML mit Verteilungsdiagrammen Deployment Diagrams siehe Abschnitt 8 3 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 422 Objektorientierter Softwareentwurf Echt ipo systeme Weitere UML Diagrammarten Analyse Kundenanforderungen Anwendungsf lle z B als Lastenheft Use Cases F I Workflow Modell I I I Activity Diagrams 4 konzept Datenmodell na Class Diagrams LE 5 u u u u u mu mu m m Interaction Diagrams Class Diagrams reaktives Verhalten BEE HEHE HEHE BPE BB BE BE EEE N S E Statecharts Teilsystemmodellierung Package Diagrams siehe Abschnitt 8 2 Softwarekonfigurationen Deployment Diagrams siehe Abschnitt 8 3 Abbildung auf Hardware Deployment Diagrams siehe Abschnitt 8 3 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r D
26. charakterisierbar durch AVAIL Metrik Zuverl ssigkeit F higkeit des Systems Dienste wie spezifiziert zu liefern charakterisierbar durch POFOD Metrik Betriebssicherheit F higkeit des Systems ohne katastrophale Ausf lle zu operieren bei uns Vertrauensw rdigkeit genannt Systemsicherheit F higkeit des Systems sich auch gegen zuf llige oder beabsichtigte Angriffe zu sch tzen l sst sich als Teilaspekt der Robustheit eines Softwaresystems auffassen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 531 Qualit tssicherung und Testverfahren Eon A systeme Qualititatsmanagement im berblick U bislang vorgestellte Vorgehensweise zur Entwicklung von vornherein qualitativ hochwertiger Softwareprodukte gt Fehlervermeidung durch konstruktive Qualititatssicherung im Folgenden geht es um die nachtr gliche berpr fung der Qualit t entwickelter Produkte oder Dokumente Fehlerelimination durch analytische Qualit tssicherung Q berpr fung und Verbesserung der Qualit t des Softwareentwicklungsprozesses selbst wird im nachfolgenden Kapitel 9 behandelt ISO 9000 Zertifizierung best tigt geregelte Vorgehensweise trifft nahezu keine Aussage ber Qualitit t der eingesetzten Vorgehensweisen Capability Maturity Model CMM unterscheidet verschiedene Reife grade bei Softwareentwicklungsprozessen und schl gt Verbesserungsma nahmen vor
27. gibPreis Euro public Schnittstellenoperatic bewege public class Auto private Euro preis private String ort public Euro gibPreis return preis Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 127 Grundlagen der objektorientierten Modellierung Echte die systeme Klassenhierarchien und Vererbung LJ Vererbung inheritance ist ein Mechanismus um neue Klassen mit Hilfe bereits bestehender Klassen zu definieren L damit lassen sich Klassen wiederverwenden reuse eine Unterklasse subclass erbt von der Oberklasse superclass die Schnittstelle n mit allen von aussen aufrufbaren Operationen die Implementierungen der Operationen ggf mit Hilfsmethoden alle Attributdeklarationen Instanzvariablen eine Unterklasse kann ererbte Operationen und manchmal auch Attribute redefinieren neue Attribute und Operationen definieren durch Vererbung entstehen Klassenhierarchien Vererbung ist eine transitive Beziehung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 128 Grundlagen der objektorientierten Modellierung Enten gg systeme Vererbungsbeispiel Attribute der Klasse Alter erh heAlter Operationen der Klasse ZN Mitarbeiter Gehalt neue Attribute der Klasse erh heGehalt t neue Operationen der Klasse Achtung die ererbten Attribute und Operation
28. halten gro en Einfluss haben Werden bei einem Objekt durch Zustands nderun gen die Verhaltensweisen mehrere komplexer Methoden ge ndert so empfiehlt sich die Erzeugung einer Zustandsklasse je Objektzustand und die Auslagerung der Berechnungen als redefinierbare Methoden in die Zustandsklassen Beispiel Movie mit Berechnung von Charge und F requent R enter P oints aus dem vorigen Abschnitt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 498 Objektorientierter Softwareentwurf Echteslt systeme Beispiel fur State Entwurfsmuster Die Klasse MovieState besitzt zwei abstrakte Methoden getCharge und get Movie FRP die in den drei Unterklassen mit eel den speziellen Berechnungsvorschriften on nn redefiniert werden Die Assoziation zwischen Movie und MovieState zeigt bereits dass es MovieState geplant ist ein MovieState Objekt in mehreren Movie Objekten zu verwen rede den anstatt viele gleiche MovieState getFRP int Objekte zu erzeigen siehe Flyweight Pattern RegularMovilf ChildMovie RegularMoviel ChildMovie NewMovie Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 499 Objektorientierter Softwareentwurf Echtzeit fic systeme Genauere Definition des State Entwurfmusters und Anwendung een k face _ state I Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentech
29. leider nicht mehr auf der H he der Zeit trotzdem aber lesenswert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 8 Einf hrung in Software Engineering Een ES systeme HK05 M Hitz G Kappel E Kapsammer W Retschitzegger UML Work 3 te Auflage dpunkt verlag 2005 422 Seiten Sehr sch n geschriebenes UML Buch mit durchg ngigem Beispiel das auch auf die d steren Seiten der UML eingeht und umstrittene Sprachkonstrukte ausf hrlich diskutiert JB99 I Jacobson G Booch J Rumbaugh The Unified Software Development Process Addison Wesley 1999 Pr sentation eines auf UML zugeschnittenen Vorgehensmodells der Software Entwicklung Ka98 B Kahlbrandt Software Engineering Objektorientierte Software Entwicklung mit der Unified Modeling Language Springer Verlag 1998 504 Seiten Mit das Buch das vom Inhalt her dieser Vorlesung am n chsten steht Der Schwerpunkt liegt auf dem Ein satz von UML allgemeinere Themen wie Kostensch tzung und Testen werden daf r ausgeklammert Pf98 S L Pfleeger Software Engineering Theory and Practice Prentice Hall 1998 576 Seiten Von Idee und Aufbau her sehr sch nes Buch An dem durchg ngigen Beispiel des Ariane 5 Absturzes wird potentielle Nutzen der Software Technik demonstriert Das Buch liefert breite bersicht ber die Software Technik Allerdings wird zu wenig auf objektorientierte Software Entwicklung eingegangen W004
30. systeme 6 6 Transaktionen und 2 Phasen Protokoll Transaktion Eine Transaktion ist ein Block von Lese und nderungsoperation die eine semantisch abgeschlossene Operation auf einer Datenbank durchf hren Sie besitzt folgende Eigenschaften gt Atomicity alle Anderungsoperationen werden ausgef hrt oder gar keine Consistency nach Ende der Transaktion ist Datenbank in konsistentem Zustand berpr fung von Integrit tsbedingungen Isolation parallel laufende Transaktionen st ren sich nicht gegenseitig sondern werden aus Anwendersicht hintereinander ausgef hrt Durability Wirkung einer einmal erfolgreich beendeten Transaktion ist dauerhaft und wird nicht einmal durch technische St rungen r ckgesetzt Man spricht von den ACID Eigenschaften einer Transaktion Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 321 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Beispiele fur Notwendigkeit von Transaktionen Q Atomicity Was wenn DBMS bei einer berweisung nach Erniedrigung des Kon tostands von K1 und vor Erh hung des Kontostands von K2 abstiirzt No Consistency Was passiert wenn nach einer Uberweisung von Konto K1 auf Konto K2 Dispositionskredit f r Konto K1 weit berzogen ist No Isolation Was passiert wenn gleichzeitig zwei Bankfilialen den Stand eines Kontos lesen und jeweils um einen bestimmten Betrag erniedrigen wollen
31. Chef ihrEinkommen einePerson Firma Einkommen end Bewertung der dynamischen Bindung ungeheuer praktisch da man sich viele case Statements spart und damit schnell neue Unterklassen einfiihren kann gef hrlich da Aufrufer im Allgemeinen nicht weiss was fiir Code ausgef hrt wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 133 Grundlagen der objektorientierten Modellierung Een ES systeme Objekttypen der Typ eines Objektes legt genau fest welche Operationen auf dieses Objekt anwendbar sind Typen sind damit Schnittstellendefinitionen Interfaces f r Objekte die Operationen Methoden einer Klasse bilden implizit einen Typ eine statisch typisierte Programmiersprache wie Java garantiert zur bersetzungszeit dass zur Laufzeit nie Methoden auf ein Objekt angewendet werden dessen Klasse diese Methode nicht anbietet eine Klasse implementiert besitzt im allgemeinen mehrere Schnittstellen ein Objekt besitzt damit im allgemeinen mehrere Typen Typen bilden damit Sichten auf Objekte Klassen f r verschiedene Anwendungszwecke Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 134 Grundlagen der objektorientierten Modellierung Von Klassen zu Typen Interfaces Verk uflich typ implementiert gibPreis Euro je preis Euro ort String gibPreis Euro A Abstraktion ewege Typ Schnittstelle einer Kl
32. Insbesondere bei eingebetteten Systemen unterscheidet sich die Entwicklungsplattform sehr deutlich von der Zielplattform Das Kapitel ist wie das vorangegangene Kapitel aufgebaut Gliederung in Teilprodukte neuer Abschnitt F r die iterative Erstellung des Produktes Gesamtfunktionalit t wird ber mehrere Releases hinweg st ckweise zur Verf gung gestellt werden die Produktfunktio nen einzelnen Teilprodukten zugeordnet Die Teilprodukte werden gem ihrer Wichtigkeit f r den Kunden angeordnet Eingabe f r Detailplanung eines Softwareentwicklungsprozesses siehe Kapitel 10 gt hier hat man einen flie enden bergang von der Analyse zum Design Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 253 Objektorientierte Anforderungsanalyse Echtzeit ec systeme Aufbau eines Pflichtenheftes 8 14 Erganzungen neuer Abschnitt Hier wird alles aufgef hrt was sonst nicht ins Schema passt 15 Testfalle neuer Abschnitt Hier werden alle Tests aus Anwendersicht aufgef hrt die bei der Abnahme des Software Produkts durchlaufen miissen Alle wichtigen Produktfunktionen und Leistungen sollten durch entsprechende Testfalle abgedeckt werden 16 Glossar das Glossar aus dem Lastenheft wird fortgeschrieben Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 254 Objektorientierte Anforderungsanalyse Eon ES systeme 5 7 Weitere Litera
33. Institut f r Datentechnik Seite 344 Von der OO Analyse zum Software Entwurf Echtzeit A systeme Einschub Verschiedene Darstellungen von Interfaces und Nutzung klassenartige Notation alte Lollipop Notation neue UML 2 0 Notation Be Import L Standard Edition TU a I I I lt lt use gt gt I I required W Interface lt lt uses gt gt Suppplierin Supplierlnterface Lollipop lt lt realize gt gt provided realize Interface implements i Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 345 Von der OO Analyse zum Software Entwurf Echtesit systeme Erlauterungen zu Schnittstellen Interfaces von Klassen Schnittstellen Interfaces spielen in UML die selbe Rolle wie in Java man kann getrent von der Implementierung von Methoden in Klassen erst mal Operationen auff hren die implementiert werden m ssen eine Klasse kann mehrere Schnittstellen anbieten implementieren eine Schnitt stelle kann durch mehrere Klassen implementiert werden damit bietet die Klasse diese Schnittstellen an provided interfaces zus tzlich kann eine Klasse andere Schnittstellen benutzen deren Existenz for dern anstatt direkt die Methoden einer anderen Klasse zu benutzen importieren man spricht in diesem Fall von ben tigten Schnittstellen required interface zueinander passende ben tigte und angebotene Schnittstellen k nnen verbunden werden die ben ti
34. Institut fiir Datentechnik Seite 337 Von der OO Analyse zum Software Entwurf Echtesit systeme Rekursive Aufrufe am Beispiel destroy v1 Motorvehicle r1 ReservationContract new v2 Motorvehicle r2 ReservationContract destroy v1 setReservationContract r2 1 r1 setMotorvehicle null nach v1 InkrevReservationContract null 2 vi setReservationContract null nach r1 InkMotorvehicle null Aufrufkette terminiert da bereits v1 InkrevReservationContract null 3 r2 setMotorVehicle v1 nach v1 InkrevReservationContract r2 4 5 6 v2 setReservationContract null nach r2 InkMotorvehicle null r2 setMotorVehicle null nach v2 InkrevReservationContract null Aufrufkette terminiert da bereits r2 InkMotorvehicle null v1 setReservationContract r2 nach r2 InkMotorvehicle v1 Aufrufkette terminiert da bereits v1 InkrevReservationContract r2 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 338 Von der OO Analyse zum Software Entwurf Ense N systeme Codeerzeugung f r Assoziationen mit h herer Kardinalit t RentalContract 1 4 has Pr oO N class Client private RentalContract has_RentalContract Verwendung eines Arrays nur bei feststehender maximaler Kardinalit t geeignet class Client besser Verwendung einer geordneten private OrderedSet has_RentalContract Menge
35. Institut fiir Datentechnik Seite 608 Fachgebiet f Management der Software Entwicklung Echtzeit systeme Eigenschaften von CMMI Es gibt F higkeitsgrade f r einzelne Prozessgebiete hnlich zu SPiCE 0 Incomplete Ausgangszustand keine Anforderungen 1 Performed die spezifischen Ziele des Prozessgebiets werden erreicht 2 Managed der Prozess wird gemanagt 3 Defined der Prozess wird auf Basis eines angepassten Standard Prozesses gemanagt und verbessert 4 Quantitatively Managed der Prozess steht unter statistischer Prozesskontrolle 5 Optimizing der Prozess wird mit Daten aus der statistischen Prozesskontrolle verbessert Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 609 Fachgebiet Management der Software Entwicklung Echtzeit systeme Eigenschaften von CMMI Fortsetzung Es gibt Reifegrade die F higkeitsgrade auf bestimmten Prozessgebieten erfordern hnlich zu CMM 1 Initial keine Anforderungen diesen Reifegrad hat jede Organisation automatisch 2 Managed die Projekte werden gemanagt durchgef hrt und ein hnliches Projekt kann erfolgreich wiederholt werden 3 Defined die Projekte werden nach einem angepassten Standard Prozess durchgef hrt und es gibt eine kontinuierliche Prozessverbesserung 4 Quantitatively Managed es wird eine statistische Prozesskontrolle durchgef hrt 5 Optimizing die Prozesse werden mit Dat
36. Methoden und Werkzeuge vern nftig miteinander arbeiten Zuweisung von Rollen an Personen kl rt Verantwortlichkeiten und Kompetenzen Rollen und Arbeitsbereiche legen noch nicht fest in welcher Reihenfolge Aufga ben erledigt werden Begriffsfestlegungen LJ eine Rolle beschreibt eine Menge von eng zusammengeh rigen Aufgaben und Verantwortlichkeiten oft auch notwendige Qualifikationen LJ ein Arbeitsbereich umfasst eine Menge eng zusammengeh riger Aufgaben und Verantwortlichkeiten zu einem Arbeitsbereich geh rt eine Menge voneinander abh ngiger Artefakte die als Eingabe ben tigt oder als Ausgabe produziert werden oft besteht eine 1 zu 1 Beziehung zwischen Rollen und Arbeitsbereichen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 65 Vorgehensmodelle der Software Entwicklung Echtzeit systeme Unvollst ndiges Beispiel f r Rollenverteilung Qualit tsmanager berpr ft berpr ft liefert Programm liefert Spez berichtet Designer Budget Controller Firmenleitung macht Vorgaben berpr ft Kostenbericht Projektleiter berichtet Produkt an fordert Vertriebler k ndigt Nachbesserung Marketier versendet Werbematerial Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 66 Vorgehensmodelle der Software Entwicklung Een ES systeme 2 4 Weitere Literatur Be99 K Beck Extreme Programming Explained Addison Wesle
37. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 583 Fachgebiet Management der Software Entwicklung Echtzeit systeme 10 3 Rational Unified Process fur UML Product Life Cycle Stand 1999 sieht inception phase transition sicht inception inception phase elaboration phase elaboration phase construction construction phase _construcon prase SHS Entwickler sicht iteration 1 iteration 1 iteration iteration 2 iteration iteration 3 iteration iteration iteration 5 iteration 5 m zu un nann um sun nm mm Firma IBM ehemals Rational dominiert e Entwicklung der Standard OO Modellierungssprache UML und des zugeh rigen Vorgehensmodells Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 584 Management der Software Entwicklung Eon ES systeme Phasen der Lebenszyklusgenerationen LJ Inception Vorbereitung Definition des Problembereichs und Projektziels f r Produktgeneration mit Anwendungsbereichsanalyse Domain Analysis und Machbarkeitsstudie f r erste Generation aufw ndiger bei Erfolg weiter zu Elaboration Entwurf erste Anforderungsdefinition f r Produktgeneration mit grober Softwarearchitektur und Projektplan ggf mit Rapid Prototyping bei Erfolg weiter zu Construction Konstruktion Entwicklung der neuen Produktgeneration als eine Abfolge von Iterationen mit Detailanalyse design
38. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 637 ware Entwicklu Eon po Management der Software Entwicklung systeme Beispiel f r die Bewertung einer externen Abfrage LI alle Reservierungsvertr ge zu einem Kunden mit Kundennummer anzeigen mit Kundename und nummer sowie Fahrzeugkategorie und nummer LI die Kosten f r alle Reservierungsvertr ge eines Kunden anzeigen der ber seine Kundennummer festgelegt wird Es wird wie folgt gez hlt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 638 Management der Software Entwicklung Eehtzet dec systeme berblick ber die FP Methode 1 Ba98 Produktanforderungen ee seele 1 Schritt Kategorisierung f r Eingabedaten Abfragen Ausgabedaten Datenbest nde jede Anforderung 2 2 2 2 Schritt Klassifizierung jeder Anforderung Br einfach einfach komplex komplex 3 Schritt Eintrag der jeweiligen 3 Anzahl in das Berechnungs f formular und Eingaben Ermittlung der Abfragen unbewerteten FPs Ausgaben Datenbest nde Referenzdaten 4 Schritt Bewertung der Einflu faktoren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 639 Fachgebiet f Management der Software Entwicklung Echtzeit 3 systeme 2 berblick ber die FP Methode 2 5 Schritt Berechnung der bewerteten FPS 6 Schritt Ablesen des Aufwandes
39. TU Darmstadt FB 18 Institut f r Datentechnik Seite 361 Fachgebiet Von der OO Analyse zum Software Entwurf Echtzeit systeme Weitere OCL Features pradikatenlogische Boole sche Ausdrucke LI die aussagenlogischen Operatoren not or and implies f r logische Negation Disjunktion Konjunktion und Implikation Schlussfolgerung sowie if then else mit Boole scher Bedingung Allquantifizierung der Pr dikatenlogik mit forAll context RentalOffice Kundennamen sind eindeutig inv self myClients gt forAll c1 c2 c1 lt gt c2 implies c1 name lt gt c2 name Existenzquantifizierung der Pr dikatenlogik mit exists context RentalOffice Kundennamen sind eindeutig inv not self myClients gt exists c1 c2 c1 lt gt c2 and c1 name c2 name Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 362 Von der OO Analyse zum Software Entwurf Echtesit systeme Erlauterungen zu Ausdrucken mit Existenz und Allquantoren LI mit exp operation Notation wird in der Regel eine Operation auf das element wertige Ergebnis eines Ausdrucks angewendet z B alle Kunden genau einer Firma bestimmen mit exp gt operation Notation wird immer eine Operation auf ein mengen wertiges Ergebnis eines Ausdrucks angewendet z B auf der Menge aller Kunden eine bestimmte Eigenschaft berpr fen mit den Variablen c1 und C2 werden jeweils alle Elemente der betrachteten Meng
40. Teilmenge der Funktionalit t der RDMBS Ein wichtiger neuer Bereich sind die so genannten Key Value Datenspeicher f r Speicherung von vielen Terabytes an strukturierten Daten hochgradig verteilte redundante ausfallsichere Datenhaltung schwache Konsistenzgarantieren eventual consistency Konsistenz von Replikaten wird nicht sofort sondern nur irgendwann garantiert LI einfache Schnittstellen zu Anwendungen Beispiel Google s verteiltes Datenhaltungssystem BigTable Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 324 Von der OO Analyse zum Datenbank Entwurf Ente Y systeme 6 8 Weitere Literatur EN94 R Elmasri S B Navathe Grundlagen von Datenbanksystemen Fundamentals of Database Systems Pearson Studium 3 Auflage 2009 535 Seiten Original in Englisch bei Benjamin Cummings Publ Company publiziert SSH10 G Saake K U Sattler A Heuer Datenbanken Konzepte und Sprachen MITP Verlag 4 Auflage 2010 780 Seiten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 325 Von der OO Analyse zum Software Entwurf Echtzeit dich systeme 7 Von der OO Analyse zum Software Entwurf Themen dieses Kapitels LJ Feinheiten der Datenmodellierung mit UML Klassendiagrammen U Modellierung von Abl ufen mit Interaktionsdiagrammen Beschreibung reaktiven Systemverhaltens mit Automaten LI Br cke von reinen Analyse zu
41. auch bei feststehender maximaler Kardinalit t da nderbarer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 339 Von der OO Analyse zum Software Entwurf Eenzet ee systeme Probleme bei Assoziationen mit Eigenschaften hasClient Rental hasClient client clientld Klassendiagramm Objektdiagramm gt daclientid ein Attribut der Klasse Client ist hat jeder Kunde genau eine ihn identifiziernde Nummer bzw Id ist ein Client ein Kunde von mehreren RentalOffices dann muss er trotz dem bei allen die selbe Id besitzen gt die clientld eines Kunden muss also Bestandteil bzw Eigenschaft der Beziehung zu einem bestimmten RentalOffice werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 340 Von der OO Analyse zum Software Entwurf Echtzeit fic systeme Einsatz von Assoziationsklassen Achtung Contract ist eine bin re Assoziation mit einem Attribut subcontract Contract if Person has Contract C with Company A and Contract C with Company A and C is subcontract of C then Company A has subcontract with Company A subcontract LJ Assoziation mit Klasseneigenschaften Link mit Objekteigenschaft d rfen Attribute besitzen und Assoziationen eingehen LJ zu jedem Objektpaar h chstens ein Linkobjekt einer Assoziation falls unique Prof Dr Andy Sch rr TU Darmst
42. dass sie damit Bestandteil der Attribute und Operationen der Klasse im Klassen diagramm werden context Client def rentedVehicles rentalContract motorVehicle checkAgeLimit limit Integer age gt limit Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 355 Von der OO Analyse zum Software Entwurf Echtesit systeme Verschiedene Arten von OCL Ausdrucken Fortsetzung 3 Definition abgeleiteter und initialer Attributwerte so werden die initialen Werte von normalen Attributen und Berechnungsvorschriften fiir abgeleitete Attri bute definiert die in einem Klassendiagramm definiert sind verwendet man statt Attributnamen die Namen der Rollen von Assoziationen so k nnen auch Initial werte f r Assoziationen und abgeleitete Assoziationen definiert werden context Client age Integer init O das Alter einer neu erzeugten Person wird auf 0 gesetzt context Client noVehicles Integer derive rentalContract gt size die Anzahl der ausgeliehenen Fahrzeuge einer Person entspricht der Anzahl der Ausleihvertrage dieser Person context RentalOffice company Company derive client company definiert eine abgeleitete Assoziation mit Rollenname company als Abk rzung f r den Pfad client company Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 356 Von der OO Analyse zum Software Entwurf Echtesit systeme Verschiedene
43. fung durch Moderator bei vielen offensichtlichen Fehlern wird das Dokument sofort zur ckgewiesen Einf hrungssitzung bei der Pr fling den Gutachtern vorgestellt wird Individualuntersuchung des Pr flings Ausschnitt durch Gutachter anhand aus geteilter Referenzdokumente mit Spezifikation Standards auf Inspektionssitzung werden Pr fergebnisse mitgeteilt und protokolliert sowie Pr fling gemeinsam untersucht Q Freigabe des Pr flings durch Moderator oder R ckgabe zur berarbeitung Bemerkung Bei Individualpr fung werden ca 80 der Fehler gefunden bei gemeinsamer Sitzung werden ca 20 der Fehler gefunden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 545 Qualit tssicherung und Testverfahren Echtecit systeme Review abgeschwachte Form der Inspektion LJ Prozessverbesserung und Erstellung von Statistiken steht nicht im Vordergrund U Moderator gibt Pr fling nicht frei sondern nur Empfehlung an Manager LJ kein formaler Inspektionsplan mit wohldefinierten Inspektionsregeln Walkthrough L Autor des Pr flings liest ihn vor ablauforientiert im Falle von Software Gutachter versuchen beim Vorlesen ohne weitere Vorbereitung Fehler zu finden E LJ Autor entscheidet selbst ber weitere Vorgehensweise E Zielsetzungen Fehler Probleme im Pr fling identifizieren Ausbildung Einarbeitung von Mitarbeitern Prof Dr Andy Sch rr TU Darmstadt FB 1
44. mer wird automatisch angelegt Reservierungsvertrag mit Vertragsnummer ver ndern alle Werte ausser Kunde Reservierungsvertrag mit Vertragsnummer l schen Daten zu einem Reservierungsvertrag mit Vertragsnummer anzeigen Es wird wie folgt gez hlt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 634 Management der Software Entwicklung Eenzet A systeme Externe Ausgaben External Output EO Ausgabedaten eines Elementarprozesses Produktfunktion Use Case der Anwender Daten oder Steuerinformationen liefert Achtung der Elementarprozess darf keine Ein gabedaten ben tigen ansonsten handelt es sich um eine Externe Abfrage oder Gez hlt werden f r jeden Elementarprozess die Anzahl seiner als Ausgabe verwende ten Entit tstypen Klassen S tze und deren Datenelementtypen Attribute Felder Anhand dieser Z hlung wird Komplexit t des Elementarprozesses wie folgt bestimmt einfach 4 FPs mittel 5 FPs oder komplex 7 FPs Externe Ausgaben Anzahl Attribute lt 5 5 lt Anzahl Attribute lt 19 Anzahl Attribute gt 19 Anzahl Klassen lt 1 einfache Komplexit t einfache Komplexit t mittlere Komplexit t 2 lt Anzahl Klassen lt 3 einfache Komplexit t mittlere Komplexit t hohe Komplexit t Anzahl Klassen gt 3 mittlere Komplexit t hohe Komplexit t hohe Komplexit t Prof Dr Andy Sch rr TU Darmstadt FB 18 Instit
45. ndert so wird sie mit return an die Aufrufstelle zuriickgegeben sonst 8 bersetze ge ndertes Programm und behebe Fehler 9 ersetze kopierten Code durch Aufruf der neuen Methode 10 l sche berfl ssige Variablen deren Anwendungsstellen alle ausgelagert wurden 11 bersetze und teste ge ndertes Programm Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 476 Objektorientierter Softwareentwurf Eon ES systeme Gro e Refactorings bzw Softwaresanierung Bislang wurden nur Refactorings vorgestellt die kleine und im wesentliche lokale nderungen an einem Programm vornehmen Oft muss aber die gesamte Programm struktur im gro en Umfang saniert werden Dann spricht von gro en Refactorings siehe RLO4 Diese Sanierungsma nahmen m ssen U sorgf ltig geplant werden siehe Projektmanagement in Software Engineering I und in einen iterativen Softwareentwicklungsprozess integriert werden als eigene Refactoring Iterationen oder als Teil von normalen Iterationen es muss daf r Kostensch tzung durchgef hrt werden normale Kostensch tzung f r Neuentwicklungen ist leider nicht anwendbar ggf als eigener Branch im Versionsverwaltungssystem gef hrt werden damit funktionale Weiterentwicklung des Systems und Refactoring sich nicht st ren Problem wann werden nderungen integriert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik
46. wegen Urlaub Krankheit bliches Ma f r Produktumfang Lines of Code LOC Anzahl Zeilen der Implementierung ohne Kommentare Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 625 Management der Software Entwicklung Eon ES systeme Sch tzverfahren im berblick LJ Analogiemethode Experte vergleicht neues Projekt mit bereits abgeschlossenen hnlichen Projekten und sch tzt Kosten gef hlsm ig ab Expertenwissen l sst sich schwer vermitteln und nachvollziehen Prozentsatzmethode aus abgeschlossenen Projekten wird Aufwandsverteilung auf Phasen ermittelt anhand beendeter Phasen wird Projektrestlaufzeit gesch tzt funktioniert allenfalls nach Abschluss der Analysephase Parkinsons Gesetz die Arbeit ist beendet wenn alle Vorr te aufgebraucht sind praxisnah realistisch und wenig hilfreich Price to Win die Software Kosten werden auf das Budget des Kundens gesch tzt andere Formulierung von Parkinsons Gesetz f hrt in den Ruin Gewichtungsmethode Bestimmung vieler Faktoren Erfahrung der Mitarbeiter verwendete Sprachen und Verkn pfung durch mathematische Formel m LOC basierter Vertreter COnstructive COst MOdel COCOMO FP basierte Vertreter Function Point Methoden in vielen Varianten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 626 Management der Software Entwicklung Eon A s
47. wenn Laufzeitmessungen auf Probleme hinweisen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 460 Objektorientierter Softwareentwurf Echte dec systeme Vorbereitung f r Elimination von conditional code Verschieben der Methoden getCharge und getFrequentRenterPoints von Klasse Rental in Klasse Movie da sie vom PriceCode von Movie abh ngen public class Rental private Movie _movie private int _daysRented public Rental Movie movie int daysRented _movie movie daysRented daysRented public int getDaysRented return _daysRented public Movie getMovie return _movie public double getCharge return _movie getCharge _daysRented public int getFrequentRenterPoints return _movie getFrequentRenterPoints _daysRented Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 461 Objektorientierter Softwareentwurf Echuet ed systeme Die ver nderte Klasse Movie mit getCharge und getFrequentRenterPoints public class Movie public double getCharge int daysRented double result 0 switch getPriceCode case Movie REGULAR result 2 if daysRented gt 2 result daysRented 2 1 5 break case Movie NEW_RELEASE result daysRented 3 break case Movie CHILDREN result 1 5 if daysRented gt 3 result daysRented 3 1 5 break return result public int getFre
48. wie man den Petri Netz Formalismus erweitern kann Gef rbte Petri Netze die Marken sind Werte bestimmter Typen mit denen gerechnet werden kann Zahlen Strings Zeitbehaftete Petri Netze dem Verharren von Marken auf Pl tzen und oder dem Schalten von Transitionen werden Zeiten zugeordnet Hierarchische Petri Netze erlauben eine strukturierte bersichtlichere Darstellung von gro en Netzen durch Verfeinerung von Pl tzen und oder Transitionen Pr dikat Transitionsnetze Transitionen k nnen mit Pr dikaten anno tiert werden die das Schalten von Transitionen erlauben verhindern Eine bersicht ber Petri Netz Werkzeuge findet man z B unter http www informatik uni hamburg de TGil PetriNets tools ein einfaches Applet ist http www informatik uni hamburg de T Gl PetriNets tools java Guth Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 225 Objektorientierte Anforderungsanalyse Echte ed systeme 5 5 Ablaufmodellierung UML Activity Charts Aufgabe Die Beschreibung von Systemfunktionen beschr nkte sich bislang auf die exemplarische Modellierung einzelner Gesch ftsvorf lle bzw Szenarien als Anwendunssf lle Vorgehensweise Mit Aktivit tsdiagrammen Activity Charts wird der zeitliche Zusammenhang einzelner Gesch ftsvorf lle in Form von Gesch ftsprozessen modelliert werden alle Alternativen einer Systemfunktion gleichzeitig erfasst wird erstes Auge
49. Altlasten deren Refactoring im Augenblick nicht m glich ist oder sich nicht mehr lohnt in einer Klasse Entwickler die sich nicht davon berzeugen lasssen dass die Zerlegung einer gro en Klassen in viele kleine Klassen zu einem bersichtlicheren und fast genauso effizienten Entwurf f hrt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 519 Objektorientierter Softwareentwurf Echteslt systeme Das Anti Entwurfsmuster Poltergeist Name Poltergeist Synonyme Big Do It Controller Class Hintergr nde Poltergeister sind unerw nschte Zeitgenossen die kurze Zeit zu sehen h ren und dann wieder verschwunden sind Das gleiche gilt f r die Objekte von Poltergeist Klassen die erzeugt und kurz darauf wieder gel scht werden Struktur Form eine Klasse mit begrenzten Aufgaben Typischerweise kontrol liert sie das Zusammenspiel anderer Klassen f r einen kurzen Zeitraum Abarbei tung einer Berechnung und besitzt kaum eigene Attribute Typische Namen f r solche Klassen sind Manager oder Controller Konsequenzen das permanente Erzeugen und L schen der Objekte solcher Kla sen f hrt zu ineffizienten Programmen Zudem erschweren sie nderungen an den von ihnen kontrollierten Klassen Gr nde von der Verwendung prozeduraler Programmiersprachen gepr gte Entwickler neigen dazu insbesondere bei der Realisierung eingebetteter Systeme die Kontroll L
50. Anforderungen requirements elicitation vorgeschlagen LJ Bestimmung aller Interessentengruppen stakeholders am Software Produkt und Durchf hrung von Interviews mit diesen Interessenten LJ Ermittlung von Anforderungen aus verschiedenen Sichten Viewpoints Interessentengruppe legen u a Sichten auf ein Software Produkt fest Durchf hrung von Workshops mit Brainstorming Prozess und oder Storyboard Techniken bei denen alle Interessentengruppen vertreten sind Ermittlung von Anforderungsf llen typischen Funktionabl ufen und ggf Durchspielen dieser F lle mit verteilten Rollen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 77 Requirements Engineering und Machbarkeitsstudie Echuet ipo systeme Stakeholders Interessengruppen eines Software Produkts Von dem zu erstellenden Software Produkt sind im Allgemeinen verschiedene Personengruppen mit oft sehr unterschiedlichen ggf auch sich widersprechenden Interessen betroffen In unserem Fall etwa LJ der Besitzer der Autoverleihfirma Auftraggeber und Anwender die Aushilfs bzw B rokr fte Anwender die Kunden der Firma indirekte Anwender an Entwicklung beteiligte Personengruppen siehe Rollen in Abschnitt 2 3 Betr ger Diebe Anwender die das Produkt missbrauchen wollen Es ist die erste Aufgabe bei der Erhebung von Anforderungen alle beteiligten Stakeholders zu identifizieren Bei Konflikten zwischen verschiede
51. Anforderungen Ausfallsicherheit Schnittstellen des Softwareprodukts Entwicklungsplan Zielfestlegung Projektmittel Entwicklungsphasen Management eingesetzte Methoden und Werkzeuge Qualitatssicherungsplan Qualit tsziele messbare Gr en Kriterien f r Ergebnisse v Entwicklungsphasen Planung von Tests Verifikation Inspektionen Testplan Teststrategie f r Integrationstest Testf lle Testwerkzeuge Kriterien f r Testvollst ndigkeit Testende Wartungsplan Umfang Art der Unterst tzung Konfigurationsmanagement Plan f r Verwaltung von Softwareversionen und Softwarevarianten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 598 Management der Software Entwicklung Echtzeit systeme Von ISO 9000 3 vorgeschriebene T tigkeiten UL Konfigurationsmanagement f r Identifikation und R ckverfolgung von nderungen Verwaltung parallel existierender Varianten LJ Dokumentmanagement f r geordnete Ablage und Verwaltung aller bei der Softwareentwicklung erzeugten Dokumente Qualit tsaufzeichungen Fehleranzahl oder Metriken f r Verbesserungen am Produkt und Prozess Festlegung von Regeln Praktiken und bereinkommen f r ein Qualit ts sicherungssystem LJ Schulung aller Mitarbeiter sowie Verfahren zur Ermittlung des Schulungsbedarfes Zertifizierung Die Einhaltung der Richtlinien der Norm wird von unabh ngigen Zertifizierungs stellen im j hrlichen Rhyt
52. Ben und eine kleiner Anzahl von Autos verleiht i Br ahrzeug in konkretes Fahrzeug das der Autovermietung geh rt GH Favoriten QEntr ate 5 Abk rzung f r Motor Vehicle Reservation System der Name des zu entwickelnden Softwaresystems B Glossar Version 0 9 vom 10 04 2005 21x Autor Andy Sch rr Datum 7 10 04 2005 v Vesionfog Status in Arbeit akzeptiert freigegeben Eine selbstandige Firma die genau eine Niederlass Ein konkretes Fahrzeug das der Autovermietung g Abk rzung f r Motor Vehicle Reservation System d bereimen Abbrechen Drucken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Requirements Engineering und Machbarkeitsstudie Echtzeit g systeme 3 4 Aufwands und Kostensch tzung Die Kosten eines Software Produktes und die Entwicklungsdauer werden im wesentlichen durch den personellen Aufwand bestimmt Letzterer ergibt sich aus dem Umfang des zu erstellenden Software Produkts der geforderten Qualit t f r das Produkt bliches Ma f r Personalaufwand Mitarbeitermonate MM oder Mitarbeiterjahre MJ 1 MJ 10 MM wegen Urlaub Krankheit bliche Ma e f r Produktumfang m Lines of Code LOC Anzahl Code Zeilen ohne Kommentare m Function Points FP Anzahl von Einzelfunktionen Bestimmung der Produktqualit t siehe Abschnitt
53. Bereitstellung von Unterlagen Systemgrenzen festlegen was geh rt zum Softwaresystem dazu Umfang des zu erstellenden Softwaresystems in FPs messen Umrechnung von Umfang FPs in Aufwand MM mit Aufwandskurve Zuschl ge einplanen f r unvorhergesehene Dinge Schatzungenauigkeit Aufwand auf Phasen bzw Iterationen verteilen Umsetzung in Projektplan mit Festlegung von Teamgr e Aufwandsch tzung pr fen und dokumentieren Aufwandsch tzung f r Projekt w hrend Laufzeit regelm ig aktualisieren 10 Datenbasis f r eingesetztes Sch tzverfahren aktualisieren Verfahren verbessern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 646 Management der Software Entwicklung Eee dis systeme Einplanung von Zuschl gen Faustformel nach Augustin Korrekturfaktor K 1 8 1 0 8 F f r Zuschl ge mit F als gesch tzter Fertigstellungsgrad der Software Problem mit der Berechnung des Fertigstellungsgrades der Software Der Wert F ist vor Projektende unbekannt muss also selbst gesch tzt werden als F bisheriger Aufwand bisheriger Aufwand gesch tzter Restaufwand Modifizierte Formel f r korrigierte Aufwandssch tzung MM MMe MM MM MM 1 8 1 0 8 MM MM MM MM korrigierter gesch tzter Gesamtaufwand in Mitarbeitermonaten MM bisher erbrachter Aufwand in Mitarbeitermonaten MM korrigierter gesch tzter Restaufwand in Mitarbeitermonaten MM
54. Bus wie LAN kann nur als Knoten modelliert werden da Verbindungen immer bidirektional sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 441 Objektorientierter Softwareentwurf Echtzeit ick systeme Verteilungsdiagramme f r verschiedene Software Verteilungsszenarien ApplicatibnServer I lt lt artifact gt gt MVRS ApplicationLogic Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 442 Objektorientierter Softwareentwurf Eon ES systeme Verschiedene Verteilungsmoglichkeiten LJ Ultra Thin Client die gesamte Software l uft auf dem Server Anzeige auf dem Client PC Terminal erfolgt beispielsweise ber X Protokoll bertr gt Fensterin halte vom Server zum Client und Benutzereingaben vom Client zum Server Thin Client die Benutzeroberfl chensoftware ist vollst ndig auf dem Client die Kommunikation mit der Anwendungsschicht und der darunterliegenden Daten bank erfolgt ber Corba oder Java remote method invocation oder Fat Client Benutzeroberfl che und Anwendungsschicht befinden sich auf dem Client Datenbank API application interface regelt Kommunikation mit Daten bank auf dem Server Ultra Fat Client die gesamte Anwendung einschlie lich der Datenbank oder Teilen der Datenbank befinden sich auf dem Client ein sogenanntes verteiltes Datenbanksystem regelt Zugriff auf Datenbanken auf verschiedenen Rechnern
55. D Statecharts A visual formalism for complex systems Science of Computer Programming vol 8 Elsevier Science Publ 1987 231 274 Originalliteratur in der hierarchische Automaten als sogenannte Statecharts erfunden wurden La98 Larman C Applying UML and Patterns Prentice Hall 1998 Eines der ersten UML B cher das anhand eines durchg ngigen Beispiels ein Vorgehensmodell zum Ein satz von UML vorstellt Eine vereinfachte und abge nderte Version dieses Vorgehensmodells wird in die ser Vorlesung benutzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 416 Objektorientierter Softwareentwurf Echtssit systeme 8 Objektorientierter Softwareentwurf Themen dieses Kapitels O endg ltiger bergang von der Analyse zum Entwurf U Modellierung von Softwarearchitekturen mit weiteren UML Diagrammarten Erkennung und Restrukturierung Refactoring schlechter Software LJ Einsatz von Entwurfsmustern Design Pattern als Standardl sungen Achtung Ergebnis der Entwurfsphase ist ein detailierter Bauplan des Softwareprodukts mit Festlegung von Verantwortlichkeiten f r Realisierung Test von Teilsystemen LJ Ausgangspunkt ist das in der Analyse ermittelte Fachkonzept die Produktdaten und funktionen des zu realisierenden Systems Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 417 Objektorientierter Softwareentwurf Echo 8 1 Von der A
56. Darmstadt FB 18 Institut f r Datentechnik Seite 24 Software Technik Was ist das Echtesit systeme Einordung der Software Technik LJ Das Gebiet Software Technik wird der praktischen Informatik zugeordnet hat aber auch Wurzeln in der theoretischen Informatik LJ Abgrenzung zu anderen Teilgebieten der Informatik ist schwierig wie Datenbanken bersetzerbau Informatik bergreifende Aspekte spielen eine wichtige Rolle wie Projektplanung Organisation Neben der Informatik gibt es eigene Software Technik Studieng nge und sogar spezielle Studieng nge wie Automotive Software Engineering Es wird auch behauptet dass sich die Software Technik zur Informatik wie die Elektrotechnik zur Physik verh lt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 25 Software Technik Was ist das cone ae systeme Definition des Begriffs Software nach Humphry Hu89 The term software refers to aprogram and all the associated information and materials needed to support its installation operation repair and enhancement Weniger umfassende Definition des New Oxford American Dictionary software the programs and other operating information used by a computer Fazit f r diese Lehrveranstaltung Der Begriff Software umfasst neben dem auf einem Mikroprozessor ausf hrbarem Programm alle weiteren Dokumente die f r die Weiter Entwicklung und Nutzung von
57. Darmstadt FB 18 Institut fiir Datentechnik Seite 352 Fachgebiet Von der OO Analyse zum Software Entwurf Echtzeit systeme Die Object Constraint Language OCL Mit OCL lassen sich Integrit tsbedingungen Invarianten formulieren die gt aus der Sicht einer Klasse eines Objekts beschrieben werden k nnen keine symmetrischen Bedingungen ber mehreren Objekten gt nur auf andere Klasseninstanzen Bezug nehmen die ber Assoziationen mit dem Hauptobjekt verbunden sind sich durch Pr dikatenlogik ausdr cken lassen keine Zeitbedingungen Beispiel von oben Kunde kann nur Autos mieten die zum Wagenpark seiner Autovermietung geh ren Formulierung in OCL aus Sicht der Klasse Client Inv self rentalOffice motorVehicle gt includesAll self rentalContract motorVehicle Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 353 Von der OO Analyse zum Software Entwurf Echtesit systeme Erlauterungen zum vorigen OCL Ausdruck U inv Invariant steht fiir Invariante immer geltende Boolesche Bedingung f r alle Objekte der Klasse Client in diesem konkreten Fall die Bedingung wird fiir jedes Objekt der Klasse alle Mitglieder der Klasse und ihrer Unterklassen gepr ft self entspricht in Java dem this und greift auf das gerade betrachtete Objekt der Klasse Client zu rentalOffice muss man sich als Methode der Klasse Client vorstellen die alle ber einen Link m
58. Datentechnik Seite 50 Software Technik Was ist das one AS systeme 1 6 Weitere Literatur BD00 B Bruegge A H Dutoit Object Oriented Software Engineering Conquering Complex and Changing Systems Prentice Hall 2000 Mit seiner kurzen Einf hrung in UML und einer breiten Darstellung von Kommunikationsformen Managementstrategien Analyse und Designheuristiken eine brauchbare Erg nzung zu reinen UML Dar stellungen Im Gegensatz zu Standard Software Technik B chern werden Themen wie Testen etc aus OO Perspektive behandelt BEM92 A W Brown A N Earl J A McDermid Software Engineering Environments Automated Support for Software Engineering McGraw Hill 1992 Etwas trockenes und nicht mehr ganz aktuelles Buch zum Thema Software Werkzeuge Beschreibt sehr sch n Anforderungen an solche Umgebungen liefert aber keine Informationen zu aktuellen CASE Tools Di72 E W Dijkstra The Humble Programmer Communications of the ACM Vol 15 No 10 1972 Aufsatz von historischem Interesse GJM91 C Ghezzi M Jazayeri D Mandrioli Fundamentals of Software Engineering Prentice Hall 1991 Klassisches Software Technikbuch mit st rker lehrbuchartigem Charakter im Vergleich zu Ba96 Naturgem leider nicht mehr auf der H he der Zeit trotzdem aber lesenswert Hu89 W S Humphry The Software Engineering Process Definition and Scope ACM SIGSOFT Software Engi neering Notes Vol 14 No 4 1989 Humphry ist einer
59. Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 312 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit systeme SQL Anfrage mit Verbundbildung SELECT Autoren ISBN Autor Name FROM Autoren Ausleihe WHERE Autoren ISBN Ausleihe ISBN gt berechnet den Verbund der beiden Tabellen ber ISBN natural join _ anstelle von geht auch Vergleich auf lt gt oder lt oder Autoren ISBN Autor Name 0 8053 1753 8 Elmasri Schmitz 0 8053 1753 8 Navathe Schmitz 0 8053 1753 8 Elmasri Derichsweiler 0 8053 1753 8 Navathe Derichsweiler 3 8244 2021 X Sch rr Radermacher 3 8244 2075 9 Z ndorf Radermacher Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 313 Von der OO Analyse zum Datenbank Entwurf Een systeme Syntax der SQL Suchbedingungen Auszug lt search condition gt lt boolean term gt lt search condition gt OR lt search condition gt lt boolean term gt lt boolean factor gt lt boolean term gt AND lt boolean term gt lt boolean factor gt NOT lt boolean primary gt lt boolean primary gt lt predicate gt lt search condition gt lt predicate gt lt comparison predicate gt lt between predicate gt lt in predicate gt lt like predicate gt lt null predicate gt lt quantified predicate gt lt exists predicate gt
60. ES systeme Definition von Anti Pattern In Anlehnung an BM 98 benutzen wir folgendes Schema f r die Definition von Anti Design Pattern bzw Anti Entwurfsmuster das allerdings etwas verk rzt und an unser Schema f r Entwurfsmuster angepasst wurde LJ Name Synonyme Namen unter denen das Anti Muster bekannt ist Hintergr nde Beschreibung der Hintergr nde der Verwendung des Anti Musters LI LJ Struktur Form Beschreibung des Aufbaus des Anti Musters zur Identifikation LI Konsequenzen Beschreibung der negativen Auswirkungen die sich aus der Exi stenz des Anti Musters ergeben Gr nde Beschreibung der typischen Gr nde f r die Existenz des Anti Musters Beispiel ein Beispiel das den Aufbau des Anti Musters verdeutlicht Neue L sung Hinweise zum Refactoring i e zur Ersetzung des Anti Musters durch ein empfehlenswertes Entwurfsmuster Erlaubte Ausnahmen Umst nde unter denen das Anti Muster akzeptabel ist und kein Refactoring durchgef hrt werden soll muss Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 517 Objektorientierter Softwareentwurf Echteslt systeme Das Anti Entwurfsmuster Blob Name Blob Schleimmonster Synonyme The God Class Hintergr nde Erinnern Sie sich an den Film The Blob Ein au erirdisches Schleimmonster trifft auf der Erde ein frisst alles auf und w chst und w chst Der Film ist ein gutes Beispiel f r eine
61. Echtecit systeme 3 1 Die Durchfuhrbarkeitsprufung fur ein Software Projekt Wie bei jeder anderen Produktentwicklung auch muss vor Beginn eines Software Entwicklungsprojektes in einer Machbarkeitsstudie Durchf hrbarkeitsstudie gepr ft werden ob die konomische Durchf hrbarkeit die fachliche Durchf hrbarkeit die personelle Durchf hrbarkeit f r verschiedene Realisierungsalternativen gegeben ist Risikoabsch tzung Dabei ist zu unterscheiden zwischen Software Produktion f r konkreten Auftraggeber generell besteht Bedarf f r Software Produkt zu kl ren ist nur was der Auftraggeber genau haben will anonymen Markt es sind Trendstudien Marktanalysen etc durchzu f hren um Bedarf und Rentabilit t zu kl ren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 70 Requirements Engineering und Machbarkeitsstudie Echtecit systeme konomische Durchf hrbarkeit Das Zauberwort ROI Return On Investment Die Software Entwicklung muss sich lohnen sprich die Einsparungen Gewinne durch den Einsatz der neuen Software m ssen h her als die gesch tzten Kosten der Soft ware Entwicklung sein Trifft nicht zu auf O nderungen auf Grund neuer gesetzlicher Bestimmungen z B ge nderter Mehrwertsteuersatz Datenschutzbestimmungen LJ Abl sung veralteter Technologien z B Hardware Plattformen Programmiersprachen E Prof Dr Andy
62. Echtzeit dich systeme 6 Von der OO Analyse zum Datenbank Entwurf Themen dieses Kapitels LJ kleiner Exkurs zu Datenbanken Aufbau Standards Entwurfsprinzipien etc LJ Klassendiagramme Entity Relationship Diagramme als Ausgangspunkt LJ Datenbankschemabeschreibung Datenmodellierung mit SQL LI einfache Datenbankanfragen und Updates mit SQL Achtung Die Entwicklung von Datenbanken ist ein komplexer Themenbereich der blicherweise in einer eigenen Vorlesung behandelt wird Notgedrungen ist der berblick hier ber die Thematik sehr knapp und unvollst ndig Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 252 Von der OO Analyse zum Datenbank Entwurf Echtzeit A systeme Zur Erinnerung Ablauf f r Erstellung eines OO Programms Panung Kundenanforderungen Anwendungsf lle l z B als Lastenheft UML Use Cases l siehe Abschnitt 3 3 iehe Abschnitt 5 2 sie e Abschnitt 5 2 Workflow Modell UML Activity Diagrams Analyse i i konzept Datenmodell siehe Abschnitt 5 5 UML Class Diagrams siehe Abschnitt 5 3 feines Verhaltensmodell UML Interaction Diag siehe Abschnitt 7 3 feines Klassenmodell Class Diagram mit Ops iehe Abschnitt 7 1 siehe Abschnitt 7 1 reaktives Verhalten UML State Machines siehe Abschnitt 7 4 Analyse gt Design Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 2
63. Instanz das Singleton Pattern F r die Realisierung einer Hierarchie auf Rental Objekten werden wir das Composite Pattern verwenden F r die Realisierung des PriceCodes das bereits im vorigen Abschnitt vorgestellte State Pattern das neue Flyweight und das Factory Pattern F r die Traversierung der Rental Hierarchie das bereits bekannte Iterator Pattern siehe etwa Java benfalls bereits verwendet wurde das Chain of Responsibility Pattern F r die Trennung von Model und View das Observer Pattern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 483 Objektorientierter Softwareentwurf Echteslt systeme berblick ber klassische Design Pattern Das klassische Buch zum Thema Software Design Pattern wurde von der Gang of Four Gamma Helm Johnson Vlissides geschrieben Sie f hren in GH 94 etwa 22 Design Pattern in drei Gruppen ein Einen Ausschnitt aus der damit eingef hrten Pattern Sprache bzw Familie zeigt folgende Grafik Iterator f r Durchlaufen der Kinder Structural Patterns sharing von Teilhierarchien en r Flyweight Composite oa ee _ sharing von Zustanden erzeugt Flyweights Behavioral Pattern Creational Patterns Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 484 Ge n
64. Institut f r Datentechnik Seite 457 Objektorientierter Softwareentwurf Echte dec systeme Verbleibende Kritik am Beispielprogramm E E E E die Schleife der Methode statement vermischt immer noch Erstellung eines Ausdrucks und Berechnung von Geb hren und Bonuspunkten Ausleihgeb hren eines Kunden und Bonuspunkte lassen sich nicht direkt abfragen nur aus Ergebnis von statement extrahieren die Methode getCharge enth lt immer noch ein switch Statement Notwendige Umbauten Berechnung von totalAmount und frequentRenterPoints in eigene Methoden extrahieren resultierende Ineffizienzen durch weitere Umbauten beheben sp ter dann die Fallunterscheidungen in den Methoden getCharge und frequent RenterPoints durch Polymorphie ersetzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 458 Objektorientierter Softwareentwurf Echte d systeme Die Methode statement mit extrahierten Berechnungen public String statement Enumeration rentals _rentals elements String result Rental Record for getName n while rentals hasMoreElements Rental aRental Rental rentals nextElement result t aRental getMovie getTitle t String valueOf aRental getCharge n result Amount owed is String valueOf getTotalCharge n result You earned String valueOf getTotalFrequentRenterPoints frequent renter points retur
65. LJ notwendige Aktionen Planung mit Kosten und Zeitsch tzung einf hren gt Anderungs und Qualit tssicherungsmanagement Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 601 Management der Software Entwicklung Echte die systeme Stufe 2 wiederholbarer intuitiver Prozess Stand nach dieser Vorlesung LJ Prozess Charakteristika Kosten und Qualit t schwanken gute Terminkontrolle Know How einzelner Personen entscheidend LJ notwendige Aktionen Prozessstandards entwickeln gt Methoden f r Analyse Entwurf Testen einf hren Stufe 3 definierter qualitativer Prozess Stand der US Industrie 1989 LJ Prozess Charakteristika zuverl ssige Kosten und Terminkontrolle schwankende Qualit t institutionalisierter Prozess unabh ngig von Individuen LJ notwendige Aktionen Prozesse vermessen und analysieren gt quantitative Qualit tssicherung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 602 Management der Software Entwicklung Echtzeit systeme Stufe 4 gesteuerter geleiteter quantitativer Prozess LJ Prozess Charakteristika gute statistische Kontrolle ber Produktqualit t Prozesse durch Metriken gesteuert LJ notwendige Aktionen gt instrumentierte Prozessumgebung mit berwachung gt konomisch gerechtfertigte Investitionen in neue Technologien Stufe 5 optimierender ruckgekoppelte
66. Name kursiv ware dann abstrakte Klasse contractld category Attribute deposit ggf noch ohne period Attributtypen Operationen werden in Kapitel 7 eingef hrt Abstrakte Klassen sind Klassen die keine eigenen Objekte besitzen sondern nur ihre Eigenschaften an Unterklassen vererben k nnen Nur abstrakte Klassen k nnen abstrakte Operationen ohne Implementationen besitzen siehe Abschnitt 7 1 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 191 Objektorientierte Anforderungsanalyse Eon ES systeme Identifikation von Attributen Attribute speichern Eigenschaften von Objekten als Werte und normalerweise nicht als eigenst ndige Objekte U ihre Attributwerte sind Elemente von Attributdatentypen U sinnvolle Attributdatentypen sind gt primitiver Datentypen wie Integer und String oder gt Aufz hlungstypen wie Color Black White oder gt einfache zusammengesetzte Typen wie Address und Date Achtung Datum und Adresse sind aus Modellierungssicht keine Objekte da Adressen oder Datumsangaben mit unterschiedlichen Werten auch verschiedenen sind sie haben keine eigene Objektidentit t LI Attribute sollten bei der Modellierung nie Zeiger auf andere wichtige Objekte sein also keine Klassen als Typ besitzen daf r gibt es Assoziationen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 192 Objektorientierte Anfo
67. OCL Ausdriicken wie folgt verwendet werden Colour white so wird das Literal notiert Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 364 Von der OO Analyse zum Software Entwurf Echtesit systeme Typ berpr fungen Einschr nkungen und undefinierte Ausdr cke O Mit obj ocllsTypeOf Class kann man berpr fen ob ein Objekt direkte Instanz einer bestimmten Klasse ist liefert true oer false als Ergebnis Q Mit obj ocllsKindOf Class kann man berpr fen ob ein Objekt direkte Instanz einer bestimmten Klasse oder einer ihrer Unterklassen oder Interface ist Mit obj oclAsType Class kann man einen Ausdruck der die Klasse CA als Typ hat auf die Klasse Class einschr nken falls Class eine direkte oder indirekte Unterklasse von CA ist Wird der Operator zur Laufzeit auf eine Instanz einer Klasse Cl angewendet die keine direkte oder indirekte Unterklasse von Class ist dann ist das Ergebnis undefiniert im Prinzip kann jeder Ausdruck den Wert undefiniert annehmen das l sst sich mit dem Pr dikat ocllsUndefined berpr fen so gilt etwa not obj oclAs Type Class ocllsUndefined obj ocllsKindOf Class der Wert undefiniert propagiert fast immer durch Ausdr cke hindurch Ausnahmen true undefined or true sowie false undefined and false sowie e if true then e else undefined Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik
68. OO Analyse zum Datenbank Entwurf Echtzeit Mich systeme Physischer Entwurf Tuning der internen Abbildung der Relationen auf Sekund r Speicher mit Definition von Indexen Indizes die direkten assoziativen Zugriff auf alle Tupel einer Relation mit bestimmten Attributwerten erlauben LJ Clusterverfahren zur Gruppierung von Daten im Sekund rspeicher so dass zusam men ben tigte Daten auf denselben Seiten liegen vor allem bei OO DBMS E Implementierung und Wartung Der ganze Rest Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 280 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme 6 3 Vom Klassendiagramm zum Relationenmodell Bei der Abbildung eines Klassendiagramms in das relationale Modell gehen wir grundsatzlich wie folgt vor LJ Klassen und Assoziationen i a jeweils ein eigenes Relationenschema Klassen Attribute Attribute eines Relationschemas Objekt Identifikator Attribute gt Prim r Schl ssel v Relationenschema LJ Prim rschl sselwahl bei Relationship Typen durch Multiplizit ten festgelegt LI erzeugte Relationenschemata k nnen teilweise verschmolzen werden LJ Einf hrung sogenannter Fremdschl sselbedingungen LJ besondere Behandlung von Vererbung notwendig hier ausgeklammert Problem bei der Abbildung Korrekte Behandlung von Assoziationen Kapazit tserhaltung Prof Dr Andy Sch rr TU Darmstadt FB 18
69. Objektfluss ohne fork Knoten wie etwa im Beispiel auf Seite 231 gezeigt sowie Vereinigung von Kon trollfl ssen mit join Knoten Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 239 Objektorientierte Anforderungsanalyse Eenzet A systeme Schreibabk rzungen f r Objektflussverzweigung und zusammenf hrung Mehrere auslaufende oder einlaufende Objektfl sse haben also eine und Semantik Es wird bei mehreren auslaufenden Datenfl ssen das von Action produzierte Token Wert kopiert wie bei fork und an Action2 und Action3 weitergeleitet Bei mehreren einlaufenden Datenfl ssen werden die ankommenden Werte irgendwie verschmol zen und zusammen weitergeleitet wie bei join Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 240 Objektorientierte Anforderungsanalyse Echtzeit go systeme Aktivit tsdiagramm zur Beschreibung des Gesamtprozesses r r Reservation Handling Vehicle Handling MakeReservation recent f Apni MakeReservation fetchEvent A z d FetchVehicle returnEvent Ereig n IS das als Aktion aus p gt cancelEvent Ausnahme l sendes ReturnVehicle den Bereich Ereignis i verl sst CancelReservation Swimlanes u Bereiche lt lt exception gt gt ausgelostes Ereignis CallPolice SendAlertMessage RemoveCar Ausnahmen selbst und Bereiche die durch Ausnahmen verlassen werden k nnen werden normalerwei
70. Param eindeutig ist Parameterliste mit Parametern der folgenden Form lt Richtung gt lt Name gt lt Typ gt lt Defaultwert gt Richtung e in out inout wie in Ada mit in als Default Wert und in Eingabeparameter f r Operation out Ausgabeparameter f r Operation von Java nicht unterst tzt inout Ein und Ausgabeparameter f r Operation R ckgabetyp Typ des Ergebniswerts der Operation Funktion nicht jede Operation ist eine Funktion und muss R ckgabewert besitzen Klassenoperationen in Java Static genannt werden unterstrichen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 329 Von der OO Analyse zum Software Entwurf Eon A systeme Faustregeln f r die Festlegung von Operationen LJ Operationen f r lesenden schreibenden Zugriff auf Attribute d rfen fehlen lassen sich sp ter automatisch generieren LJ Konstruktoren d rfen ebenfalls fehlen falls es sich nur um parameterlose Standard Konstruktoren handelt lassen sich auch automatisch generieren Operationen f r die Manipulation von Assoziationen k nnen ebenfalls fehlen lassen sich auch automatisch generieren Aktivit ten aus Anwendungsfallbeschreibungen Aktivit tsdiagrammen die auf Instanzen genau einer Klasse operieren werden dieser Klasse zugeordnet andere Aktivit ten werden in Teilaktivit ten zerschlagen oder bei umfassenden Objekten deklariert siehe Objektkompositi
71. Prozentsatz interaktiver Dateneingaben geforderte Benutzerfreundlichkeit interaktive bzw Online Pflege des internen Datenbestandes Komplexit t der Verarbeitungslogik Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 642 Management der Software Entwicklung Echtzeit systeme Zus tzliche Einflussfaktoren Fortsetzung 10 11 12 13 14 19 16 17 18 19 geforderter Grad der Wiederverwendbarkeit ben tigte Installationshilfen leichte Bedienbarkeit Grad der Automatisierung der Bedienung Mehrfachinstallationen auf verschiedenen Zielplattformen Grad der gefoderten nderungsfreundlichkeit Randbedingungen anderer Anwendungen Sicherheit Datenschutz Pr fbarkeit Anwenderschulung Datenaustausch mit anderen Anwendungen Dokumentation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 643 Management der Software Entwicklung Een Y systeme Ermittlung der FP Aufwandskurve LJ beim ersten Projekt muss man auf bekannte Kurven f r hnliche Projekte zur ckgreifen IBM Kurve mit FP 26 MM VW AG Kurve LJ alternativ kann man eigene abgeschlossene Projekte nachkalkulieren allerdings Nachkalkulationen sind aufw ndig Dokumentation von Altprojekten oft unvollst ndig oft gibt es nur noch den Quellcode keine Lasten oder Pflichtenhefte Kosten Personenmonate alter Projekte oft unklar wurden berstunden ber
72. Quellcode und Wartungsverpflich tung bleibt beim Auftragnehmer Produktion von Individualsoftware ohne Wartung alle Entwicklungs dokumente Analysedokumente Quellcode etc werden zusammen mit dem Bin rcode und der Benutzerdokumentation bergeben Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 570 Management der Software Entwicklung Echtzeit systeme Die Abnahmephase Auslieferung Fortsetzung LJ Abnahmetest Auftraggeber berpr ft die vertraglich vereinbarten Abnahmekriterien Wartung verbleibt bei Auftragnehmer Benutzbarkeit Effizienz Zuverl ssigkeit Korrektheit werden getestet Wartung geht auf Auftraggeber ber zus tzlich spielen Wartbarkeit Portierbarkeit Testbarkeit Erweiterbarkeit eine wichtige Rolle Abnahmeprotokoll In ihm werden die durchgef hrten Abnahmetests und ihre Ergebnisse festgehalten Abnahme Schriftliche Erkl rung der Annahme des Softwareprodukts im juristischen Sinne Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 571 Management der Software Entwicklung Eon ES systeme Einf hrungsphase Installation In der Einf hrungsphase werden nach der Abnahme des Softwareprodukts folgende Aktivit ten durchgef hrt LJ Installation Einrichtung des Produkts beim Kunden auf Zielumgebung zum Zwecke der Inbetriebnahme Software f r anonymen Markt Pilotinstallationen Bet
73. Record for getName n while rentals hasMoreElements double thisAmount 0 Rental each Rental rentals nextElement thisAmount each getCharge frequentRenterPoints each getFrequentRenterPoints II Extract und MoveMethod auch f r frequentRenterPoints Berechnung durchgef hrt show figures for this rental result t each getMovie getTitle t String valueOf thisAmount n totalAmount thisAmount add footer lines result Amount owed is String valueOf totalAmount n result You earned String valueOf frequentRenterPoints frequent renter points return result Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 456 Objektorientierter Softwareentwurf Echuet Mie systeme Beispielprogramm die ver nderte Klasse Rental komplett public class Rental private Movie _movie private int _daysRented public Rental Movie movie int daysRented _movie movie daysRented daysRented public int getDaysRented return _daysRented i public Movie getMovie return _movie F public double getCharge double result 0 switch getMovie getPriceCode return result public int getFrequentRenterPoints if getMovie getPriceCode Movie NEW_RELEASE amp amp getDaysRented gt 1 return 2 else return 1 Prof Dr Andy Sch rr TU Darmstadt FB 18
74. Satz von Testf llen wird festgelegt der Betriebsprofil widerspiegelt Das System wird mit den Testf llen getestet und die Anzahl der Fehlfunktionen die L nge der Ausfallzeiten wird gemessen Nachdem eine statistisch signifikante Anzahl von Fehlern beobachtet wurde kann die Zuverl ssigkeit der Software berechnet werden Probleme bei dieser Vorgehensweise Erstellung eines Betriebsprofils im allgemeinen sehr schwierig Erstellung einer hinreichenden Menge von Testf llen oft sehr aufw ndig Statistische Signifikanz schwer definierbar Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 562 Qualit tssicherung und Testverfahren Eon ES systeme 9 7 Weitere Literatur Ba98 H Balzert Lehrbuch der Softwaretechnik Band 2 Software Management Software Qualit tssicherung Unternehmensmodellierung Spektrum Akademischer Verlag 1998 Hier findet man fast alles Wissenswerte zum Thema Qualit tssicherung und Testen von Software R V Binder Testing Object Oriented Systems Models Pattern and Tools Addison Wesley 1999 Bislang umfassendste Monographie zu diesem Themengebiet Insbesondere zu Testen von Klassen Ber cksichtigung von Automaten sowie zur Testautomatisierung findet ausf hrliche Informationen Naturgem noch eher knapp gehalten sind die Informationen zum Testen auf Basis von UML Modellen FS98 M Fowler K Scott UML konzentriert Die neue Standard Obje
75. Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 167 Fachgebi Objektorientierte Anforderungsanalyse Echtzeit ipo systeme Kommentare zur Generalisierungsbeziehung U ein Owner ist ein spezieller Clerk der alle Eigenschaften eines Clerk besitzt erbt und zus tzliche Eigenschaften haben kann LJ ein speziellerer Akteur darf alle die Systemfunktionen benutzen Anwendungsf lle die der allgemeinere Akteur benutzen darf ein spezieller Akteur kann mit allen Akteuren interagieren mit denen der allgemeinere Akteur interagiert die Generalisierung zwischen Akteuren ist ein Spezialfall der Generalisierung zwischen klassenartigen Modellierungselementen in UML als Classifier bezeichnet die Vererbung auf Java Klassen extend ist ein Spezialfall der Generalisierung von UML Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 168 Objektorientierte Anforderungsanalyse Ense N systeme Generalisierungsbeziehungen zwischen Anwendungsfallen MVRS_Clients abstrakter NA Anwendungsfall Generalisierung u MVRS_Reservations __ManipulateReserva tion _ 2 Client MVRS_Vehicles _ Manipulate Vehicle VRAA ae _AddVehicle gt _ Fet chVe hice gt MakeReservation 2 CancelReservation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 169 a hgebi Objektorientierte Anforderungsanalyse Een AX sy
76. Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 57 Vorgehensmodelle der Software Entwicklung Echtzeit systeme Systementwurf system design programming in the large Im Systementwurf wird exakt festgelegt wie die Funktionen der Software zu realisieren sind Es wird der Bauplan der Software die Software Architektur entwickelt LJ Aufgaben siehe auch Kapitel 6 Kapitel 7 und Kapitel 8 Programmieren im Gro en Entwicklung eines Bauplans Grobentwurf der System in Teilsysteme Module Pakete zerlegt Auswahl bereits existierender Software Bibliotheken Rahmenwerke Feinentwurf der Modulschnittstellen und Algorithmen vorgibt konzeptuelles Design von Datenbankstrukturen LJ Ergebnisse Entwurfsdokument mit Software Bauplan gt detailierte re Testpl ne Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 58 Vorgehensmodelle der Software Entwicklung Echtzeit systeme Codieren und Modultest Implementierung programming in the small Die eigentliche Implementierungs und Testphase in der einzelne Module in einer bestimmten Reihenfolge realisiert und validiert werden LJ Aufgaben siehe auch Kapitel 8 und Kapitel 9 Programmieren im Kleinen Implementierung einzelner Module Einhaltung von Programmierrichtlinien Code Inspektionen kritischer Modulteile Walkthroughs Test der erstellten Module LJ Ergebnisse amp Menge realisierter Module
77. Seite 365 Von der OO Analyse zum Software Entwurf Echtzeit Mich systeme Verschiedene Arten von Kollektionen Set unordered unique elements die normale Menge ohne Ordnung auf den Elementen und ohne Duplikate LJ OrderedSet ordered unique elements eine Liste von Elementen die gem Index der Elemente sortiert ist es gibt keine Duplikate LJ Bag unordered not unique eine ungeordnete Ansammlung von Elementen die unsortiert sind oft Multimenge genannt LJ Sequence ordered not unique eine Liste von Elementen die gem Index der Elemente sortiert ist und Duplikate enthalten darf Operationen auf Kollektionen LI die blichen Mengenoperationen Vereinigung U Operationen zur Iterationen ber Mengen Selektion von Teilmengen LJ Operationen f r Zugriff auf einzelne Listenelemente ber Index Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 366 Von der OO Analyse zum Software Entwurf Echtesit systeme Beispiele fur Standard Operationen auf Kollektionen U weitere Operationen auf Kollektionen Mengen Multimengen Listen gt z B s gt includes e f r Element e ist in einer Kollektion S enthalten context Client inv self rentalContract motorVehicle gt forAll v self rentalOffice motorVehicle gt includes v gt z B s1 gt includesAll s2 f r alle Elemente von 2 sind enthalten in 1 context Client inv self rentalOffice m
78. Statechart Zustands diagramm Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 397 Von der OO Analyse zum Software Entwurf Echtzeit ip systeme bersetzung von Statecharts 2 Statechart Zustands diagramm a aes gt Gece Problem das ist falsch a_ gt S2 a das ist korrekt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 398 Von der OO Analyse zum Software Entwurf Ense ged systeme And Zust nde Concurrent States ReservationHandling paralleler Unterzustand Incomplete sobald abort Signal NoPeriod DefPeriod kommt wird In J nterPeriod ok complete in jedem Fall verlassen O ok DefClient Complete diese Transition ehterClient feuert sobald alle Anfangs Unterzustande zust nde NoDeposit DefDeposit ihren Endzustand enterDeposit erreicht haben _ N it VA Signal ok f hrt zum Verlassen von Incomplete falls alle Def Zust nde aktiv sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 399 Von der OO Analyse zum Software Entwurf Echuet AS systeme Erl uterung von and Zust nden ein and Zustand enth lt beliebig viele Unterautomaten beim Betreten des and Zustands geht jeder Unterautomat in seinen Anfangszustand ber jeder Unterautomat ist f r sich aktiv wie ein normaler Automat und kann seinerseits wieder
79. Systems FetchVehicle Subject Il _ ReturnVehicle _ RemoveVehicle RepairVehice_ 2 RepairVehicle ist eine Funktion die vom MVRS System in keiner Weise unterst tzt wird im geplanten Release und deshalb au erhalb des MVRS Kastens Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 160 Fachgebiet f Echizeit A systeme Objektorientierte Anforderungsanalyse Anwendungsfalldiagramm mit Akteuren MVRS Actor benutzt Association _RemoveClient __AddVehicle FetchVehicle _ Retu rnVehicle RemoveVehicle _2 Seite 161 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Objektorientierte Anforderungsanalyse Echuet ipo systeme Kommentare zu Benutzt Beziehungen Assoziationen Akteure sind die sp tere Benutzer des Systems in verschiedenen Rollen die Linie von Akteur Actor zu Anwendungsfall Use Case erlaubt Aufruf eines Anwendungsfalles durch einen Akteur Benutzung der Systemfunktion interagieren mehrere Akteure mit einem Anwendungsfall so ist nicht festgelegt was das bedeutet wie bei MakeReservation gt meist hier jeder Akteur f r sich darf die Systemfunktion benutzen gt ggf aber auch nur alle Akteure d rfen die Systemfunktion nutzen unklar ist zun chst auch wieviele Funktionen Anwendungsf lle ein Anwender gleichzeitig benutzen darf meist keine E
80. Xor und and Zust nde enthalten kommt ein Signal an so wird dieses Signal von jedem Unterautomaten abgearbeitet theoretisch gleichzeitig in Praxis in beliebiger Reihenfolge kann ein Unterautomat mit einem Signal nichts anfangen bleibt er einfach im aktuellen Zustand ein Unterautomat wird entweder durch Transition nach aussen mit explizitem Ereignis verlassen oder wenn alle Unterautomaten ihre Endzust nde erreicht haben aber alte UML B chern und Werkzeuge behaupten ggf anderes Es gibt wenige UML CASE Tools die Ausf hrung von Statecharts mit and Zust nden unterst tzen ohne Unterst tzung von and Zust nde gibt es viele Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 400 Von der OO Analyse zum Software Entwurf Echtesit systeme Abstraktes Beispiel mit and Oberzustand Transition falls Ereignis und A inC und DinG Achtung LJ die Unterautomaten A und D schalten nebenl ufig bei passendem Ereignis U Querbeziige auf Zustand des Nachbarautomaten m glich mit in XJ als Transitionsbedingung aber kein guter Modellierungsstil Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 401 Von der OO Analyse zum Software Entwurf Echtzeit Mich systeme bersetzung von and Oberzustand in Produktautomaten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 402 Von der OO Analys
81. aan ren next Index getCnarge double current Rentallterato getFRP iint lt getCharge double getFRP int Videoshop getinstance Videosho Fachgebiet Echizeit systeme VisitedElemen Customer Customer getRental RentalCompone getName String printStatement String htmlStatement String C getCharge double getFRP int Rentallterator _current Index Rentallterator first void next void current RentalComponer isDone boolean _instance Videoshop Index _current ist entweder Zahl Index f r VeA Videoshop oder Zeiger auf n chste RentalComponent Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 513 Objektorientierter Softwareentwurf Echteslt systeme Das letzte Entwurfsmuster Observer Name Observer Beobachter Absicht etabliert eine 1 zu n Beziehung zwischen einem Subjekt und einer Menge von Beobachtern die ber nderungen des Subjekts informiert werden Motivation erlaubt die saubere Trennung von Logik Model und Darstellung View in einem Programm Das Objekt Subject Model informiert alle seine Observer Views ber jede Zustands nderung damit sich diese die Darstellung aktualisieren k nnen Beispiel Die Klasse Customer unseres Videoverleihprogramms bietet immer noch eine bunte Mischung von Methoden an die einerseits logische Berechnungen durchf hren getName und andererseits Darstellungen berechnen print
82. abge holt werden es ist unklar welche Teile des beschriebenen Gesch ftsprozesses durch Software unterst tzt werden sollen Festlegung der Systemgrenze fehlt sie enth lt ausschlie lich Aussagen ber den funktionalen Ablauf des betrachte ten Gesch ftsprozesses keine Angaben zu Datenmengen Antwortzeiten Art der Benutzer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 88 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit systeme Klassisches Beispiel fur Mehrdeutigkeit von Aussagen Untersuchung des Satzes Mary had a little lamb durch Hervorhebung einzelner W rter und Nachschlagen der W rter in einem W rterbuch Glossar have 1 to hold in possession as property 2 to trick or fool someone been had by a partner 3 to beget or bear have a baby 4 to partake have as dinner Ile lamb 1 a young sheep less than one year without permanent teeth 2 the young of various other animals antelope etc 3 a person as gentle or weak as a lamb 4 aperson easily cheated or deceived 5 the flesh of lamb used as food 6 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 89 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit systeme M gliche Bedeutungen von Mary had a little lamb have lamb Bedeutung 1 Mary owned a little sheep under one year 4 Mary
83. bei Real Integer Konvertierung und verursachten Fehlfunktion des SRI Systems dadurch wurden wichtige Flugdaten durch ein Testmuster berschrieben das SRI System und sein Backup schalteten sich aufgrund des Fehlers ab Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 13 Software Technik Was ist das ee systeme Schlussfolgerungen aus dem Ariane 5 Beispiel die Anforderungen an ein Software System sind pr zise aufzuschreiben es ist sicherzustellen dass die tats chliche Realisierung die gestellten Anforderungen und nur diese erf llt bei Wiederverwendung von Software ist zu pr fen ob die urspr nglichen Voraussetzungen noch gegeben sind die dokumentiert sein sollten Redundanz identischer Teilsysteme hilft gegen Hardwarefehler nicht aber gegen Software Design fehler aktives Risikomanagement notwendig das die Auswirkungen m glicher Softwarefehlfunktionen analysiert und Pr ventivma nahmen einleitet Software sollte nicht nur Fehlersituationen durch Konsistenzchecks erkennen sondern robust gegen Fehlfunktionen einzelner Teilsysteme sein Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 14 Software Technik Was ist das Eet de X systeme z 1 2 Die Software Krise von 1968 bis Stand der Dinge 1968 Programmsysteme der 60er Jahre wurden zunehmend komplexer aber es gab keine geeigneten Programmier Sprachen keine
84. cksichtigt welche Aktivit ten wurden mitgez hlt das Verh ltnis von MM zu FP bei abgeschlossenen eigenen Projekten wird zur nachtr glichen Kalibrierung der Kurve benutzt gt neues Wertepaar wird hinzugef gt oder neues Wertepaar ersetzt ltestes Wertepaar Frage was f r eine Funktion benutzt man f r Interpolation von Zwischen werten meist nicht linear sondern eher quadratisch oder gar exponentiell Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 644 Management der Software Entwicklung Eontzeit systeme Nachkalkulation von Projekten mit Backfiring Methode Bei alten Projekten gibt es oft nur noch den Quellcode und keine Lasten oder Pflich tenhefte aus denen FPs errechnet werden k nnen In solchen F llen versucht man FPs aus Quellcode wie folgt nach Jo92 r ckzurechnen Sprache Lines of Code Function Points Komplexit t niedrig mittel Assembler 200 320 C 60 128 Fortran 75 107 COBOL 65 107 C 30 53 Smalltalk 15 21 Achtung LOC in Programmiersprache X pro MM Codierung angeblich nahezu konstant damit ist z B Produktivit t beim Codieren in Smalltalk 4 mal h her als in C Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 645 Management der Software Entwicklung Echtzeit systeme Vorgehensweise bei Kostensch tzung mit FP Methode Festlegung des verwendeten Ansatzes
85. das Ver ndern einzelner Attribute eines einzelnen Tupels oder einer Menge von Tupeln die zu ver ndernden Tupel werden gt durch eine Query bestimmt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 317 Von der OO Analyse zum Datenbank Entwurf Eon A systeme Syntax der SQL nderungsanweisungen lt insert statement gt lt insert column list gt lt insert value list gt lt insert value gt lt update statement gt lt set clause list gt lt set clause gt lt delete statement gt INSERT INTO lt table name gt lt insert column list gt VALUES lt insert value list gt lt query specification gt lt column name gt lt column name gt lt insert value gt lt insert value gt lt value specification gt NULL UPDATE lt table name gt SET lt set clause list gt WHERE lt search condition gt lt set clause gt lt set clause gt lt column name gt lt value expression gt NULL DELETE FROM lt table name gt WHERE lt search condition gt Achtung Neben den hier vorgestellten update und delete Anweisungen gibt es noch andere die an einer bestimmten Stelle in einer Tabelle ndern oder l schen Diese Anweisungen werden bei der Einbettung von SQL Anweisungen in Programme benutzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik S
86. geeigneten Methoden Vorgehensweisen keine geeigneten Werkzeuge Die Folgen in der Vergangenheit Software Kosten stiegen kontinuierlich Hardwarekosten fallen extrem viele Software Entwicklungsprojekte scheiterten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 15 Fachgebiet Software Technik Was ist das Echtzeit fp systeme Die Schlussfolgerung aus der Software Krise LJ Software Entwicklung entsprach dem Bau von Pal sten ohne Architekten Pl ne Maschinen LJ Erstellung von Software sollte nicht l nger kreative Kunst sondern ingenieur m ige Wissenschaft sein mit wohldefinierten Vorgehensweisen Deshalb Einf hrung der Software Technik f r die ingenieurm ige Erstellung von Software Systemen Zitat nach Dijkstra Di72 Als es noch keine Rechner gab war auch das Programmieren noch kein Problem als es dann ein paar leistungsschwache Rechner gab war das Programmieren ein kleines Problem und nun wo wir gigantische Rechner haben ist auch das Programmieren zu einem gigantischen Problem geworden In diesem Sinne hat die elektronische Industrie kein einziges Problem gel st sondern nur neue geschaffen Sie hat das Problem geschaffen ihre Produkte zu nutzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 16 Software Technik Was ist das Echtesit systeme Und wo stehen wir heute Standish Gro
87. gesch tzter Restaufwand in Mitarbeitermonaten Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 647 Management der Software Entwicklung Een AX systeme Erl uterungen zu Korrekturfaktor f r Kostensch tzung LJ zu Projektbeginn ist F 0 da noch kein Aufwand erbracht wurde damit wird der gesch tzte Aufwand um 80 nach oben korrigiert LJ am Projektende ist F 1 da sp testens dann die aktuelle Sch tzung mit tats chli chem Wert bereinstimmen sollte es gibt also keinen Aufschlag mehr Unsicherheiten in der Sch tzung nehmen nicht nicht linear ab da Wissenszu wachs ber zu realisierende Softwarefunktionalit t und technische Schwierigkei ten im Projektverlauf keinesfalls linear ist im Laufe des Projektes wird Fertigstellungsgrad F nicht immer zunehmen sondern ggf auch abnehmen wenn Sch tzungen sich als zu optimistisch erwiesen haben Auftraggeber wird mit Zuschlag von 80 auf gesch tzte Kosten nicht zufrieden sein deshalb werden inzwischen manchmal Vertr ge geschlossen bei denen nur Preis je realisiertem FP vereinbart wird Risiko f r zu niedrige Sch tzung von FPs liegt bei Auftraggeber Risiko f r zu niedrige Umrechnung v FPs in MM liegt bei Auftragnehmer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 648 Management der Software Entwicklung Eon A systeme Aufwandsverteilung auf Phasen bzw Entwicklungsaktivit ten Hat
88. ist sehr lang oder enth lt Schleifen mit umfangreichem Rumpf oder wie bei statement Extract Class Extract Method um Code zu zerschlagen long parameter list eine Methode besitzt sehr viele Parameter kann z B f r Ergebnis von ExtractMethod gelten Replace Parameter with Method ersetzt Par durch Methodenaufruf Introduce Parameter Object fasst mehrere Parameter zusammen divergent change low cohesion logisch verschiedene Programm nderungen werden immer wieder in der selben Klasse durchgef hrt wie bei statement Extract Class zerlegt Klasse in verschiedene Klassen f r jeweils einen logischen Zweck Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 470 Objektorientierter Softwareentwurf Eon ES systeme Gr nde f r Refactoring 2 LJ shotgun surgery high coupling das Gegenteil von divergent change eine logische Programm nderung erfordert Umbauten an vielen Klassen Methoden Move Method f r Konzentration von nderungsstellen Move Attribute f r Konzentration von Anderungsstellen feature envy eine Klasse ist mehr an den Attributen Feldern einer anderen Klassen interessiert als diese selbst z B statement an Attributen von Rental Move Method bringt neidische Methoden zu benutzten Attributen switch statements wenn komplexe wiederkehrende bedingte Anweisungen anstelle von Unter
89. kontinuierlicher Anstregungen um die Schw chen von Entwick lungsprozessen zu identifizieren und zu eliminieren Hier vorgestellte Ans tze ISO 9000 Normenwerk Int Standard f r die Softwareindustrie Capability Maturity Model CMM des Software Engineering Institutes SEI an der Carnegie Mellon University Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 596 Management der Software Entwicklung Echtzeit systeme Qualit tssicherung mit der ISO 9000 Das ISO 9000 Normenwerk http www iso 9000 co uk legt f r das Auftraggeber Lieferantenverh ltnis einen allgemeinen organisatorischen Rahmen zur Qualit tssicherung fest Das ISO 9000 Zertifikat best tigt dass die Verfahren eines Unternehmens der ISO 9000 Norm entsprechen Wichtige Teile ISO 9000 1 allgemeine Einf hrung und berblick ISO 9000 3 Anwendung von ISO 9001 auf Softwareproduktion ISO 9001 Modelle der Qualit tssicherung in Design Entwicklung Produktion Montage und Kundendienst ISO 9004 Aufbau und Verbesserung eines Qualit tsmanagementsystems Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 597 Management der Software Entwicklung Eon ES systeme Von ISO 9000 3 vorgeschriebene Dokumente Q Vertrag Auftraggeber Lieferant T tigkeiten des Auftraggebers Behandlung von Anforderungs nderungen Annahmekriterien Abnahmetest Spezifikation funktionale
90. man den Gesamtaufwand f r ein Softwareentwicklungsprojekt gesch tzt muss man selbst bei einer ersten Grobplanung schon die ungef hre L nge einzelner Phasen oder Iterationen festlegen f r die Aufteilung des Aufwandes auf Phasen bzw Aktivit tsbereiche gibt es die Prozentsatzmethode hier in der Hewlett Packard Variante aus Ba98 gt Analyseaktivit ten 18 des Gesamtaufwandes Entwurfsaktivit ten 19 des Gesamtaufwandes Codierungsaktivit ten 34 des Gesamtaufwandes gt Testaktivit ten 29 des Gesamtaufwandes f r die Aufwandsberechnung einzelner Iterationen einer Phase wird die Zuord nung von FPs zu diesen Iterationen herangezogen oder es wird bei festgelegter Projektl nge und fester L nge von Iterationen z B 4 Wochen die Anzahl der FPs die in einer Iteration zu behandeln sind festgelegt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 649 Management der Software Entwicklung Echtzeit systeme Bestimmung optimaler Entwicklungsdauer Faustformel nach Jones f r geringen Kommunikationsoverhead und hohen Parallelisierungsgrad Dauer 2 5 Aufwand in MM s 0 38 f r Stapel Systeme s 0 35 f r Online System s 0 32 f r Echtzeit Systeme durchschnittliche Teamgr e Aufwand Dauer berlegungen zu obiger Formel Anzahl der maximal sinnvoll parallel arbeitenden Mitarbeiter h ngt ab von Projektart gro e Projekte d rfen nicht endlos lange laufen
91. mit UML Aktivit tsdiagrammen Exkurs zu Petri Netzen semantische Basis von Aktivit tsdiagrammen Vorschlag f r den Aufbau eines Pflichtenheftes Achtung Ergebnis der Analysephase ist ein Pflichtenheft erweitertes Lastenheft mit UML Diagrammen zur Beschreibung von Produktdaten und funktionen LJ Ausgangspunkt k nnen ein in der Machbarkeitsstudie erzeugtes Lastenheft oder eine unstrukturierte Produktbeschreibung des Auftraggebers sein Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 152 Objektorientierte Anforderungsanalyse Fachgebiet Echtzeit iyo systeme 2 5 1 Vom einfachen Lastenheft zum erweiterten UML Pflichtenheft Pianung Kundenanforderungen z B als Lastenheft l siehe Abschnitt 3 3 Analyse konzept Datenmodell UML Class Diagrams siehe Abschnitt 5 3 feines Klassenmodell Class Diagram mit Ops siehe Abschnitt 7 1 Analyse gt Design Anwendungsf lle UML Use Cases iehe Abschnitt 5 2 siehe Abschnitt 5 2 Workflow Modell UML Activity Diagrams siehe Abschnitt 5 5 feines Verhaltensmodell UML Interaction Diag siehe Abschnitt 7 3 reaktives Verhalten UML State Machines siehe Abschnitt 7 4 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 153 Objektorientierte Anforderungsanalyse Echtzeit systeme Einsatz von UML in der Analysephase LJ Ausgangs
92. nur die Bedingung einer Kante wahr sein die aus einem betrachteten Bedingungsknoten ausl uft die Ausf hrung eines aufgerufenen Aktivit tsdiagramms ist beendet wenn eine Marke den Endknoten erreicht mehrere gleichzeitige Ausf hrungen Aktivierungen eines Aktivit tsdiagramms sind im Normalfall nicht zul ssig UML Konstrukt hierf r wird nicht vorgestellt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 230 Objektorientierte Anforderungsanalyse Echtzeit Fachgebiet f g systeme Aktivit tsdiagramm MakeReservation mit Objektfluss Eingabe __ Findclient nDB Parameter BE Datenfluss Parameter gibt zwei Kopien des Eingabeobjekts weiter Schreib abk rzung MakeReservation Objekt Pin f r auslaufenden Datenfluss determines set of all vehicles vs of category c Objekt Pin f r Selects free vehicle v for N ei nlaufenden given period p that is Datenfl uss not reserved during p Ausgabe Parameter Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 231 Objektorientierte Anforderungsanalyse Echt fips systeme Erlauterungen zu Aktivitatsdiagrammen mit Objektfluss LJ es handelt sich dabei um moderne Variante der Datenflussdiagramme LJ eine Kontrollflusskante wird durch eine oder mehrere Objektflusskanten ersetzt die Ausgaben einer Aktion zur n chsten Aktion weitergeben statt
93. oder Leistung Aufwand F r Software Entwicklung oft verwendete Definition Produktivit t Gr e der Software geleistete Mitarbeitertage Probleme mit dieser Definition Ma f r Gr e der Software Ber cksichtigung der Produktqualit t Aufwand Mitarbeitertage lt gt Nutzen Return Of Investment Gr e der Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 566 Management der Software Entwicklung Echtzeit systeme Einflussfaktoren f r Produktivit t ACF97 Angabe der Form 1 X steht f r Produktivit tssteigerung um maximal Faktor X Angabe der Form 1 Y steht f r Produktivit tsminderung um maximal Faktor Y gt Werkzeug Einsatz gt Geeignete Methoden gt gt gt gt gt gt gt Produktkomplexitat Hohe Zuverl ssigkeitsanforderung Firmenkultur corporate identity Arbeitsumgebung eigenes B ro abschaltbares Telefon Begabung der Mitarbeiter Erfahrung im Anwendungsgebiet Bezahlung Berufserfahrung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 567 Management der Software Entwicklung Eehtzeit dec systeme Produktivit ts und Qualit tsverlauf bei Einsatz neuer Werkzeuge J092 Zu Abnahme in Prozent Qualit t a m Wartungsproduktivitat Entwicklungsproduktivit t Zeit Einf hrungs o l phase Qualit t Anz
94. reinen Design T tigkeiten Achtung Die hier vorgestellten Diagrammelemente und Techniken k nnen also sowohl zur Erstellung sehr pr ziser ausf hrbarer Anforderungsdokumente Pflichtenhefte als auch f r das Design von Software eingesetzt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 325 Von der OO Analyse zum Software Entwurf Ense N systeme Zur Erinnerung Panung Kundenanforderungen Anwendungsf lle z B als Lastenheft gt UML Use Cases siehe Abschnitt 3 3 siehe Abschnitt 5 2 Workflow Modell UML Activity Diagrams Analyse i i konzept Datenmodell siehe Abschnitt 5 5 UML Class Diagrams siehe Abschnitt 5 3 feines Verhaltensmodell UML Interaction Diag siehe Abschnitt 7 3 feines Klassenmodell Class Diagram mit Ops iehe Abschnitt 7 1 siehe Abschnitt 7 1 reaktives Verhalten UML State Machines siehe Abschnitt 7 4 Analyse gt Design Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 326 Von der OO Analyse zum Software Entwurf Echtesit systeme 7 1 Verfeinerte Klassendiagramme Aufgabe Verfeinertes Klassendiagramm erzeugen das Operationen f r Zugriff auf Objekteigenschaften anbietet Zusammenh nge deklarierter Klassen pr zisiert Vererbungshierarchien exakter beschreibt zus tzliche Konsistenzbedingungen pr zise festlegt Vorgehensweise Einz
95. richtigen Zustand aus hat die exakt dieselbe Bedeutung Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 393 Von der OO Analyse zum Software Entwurf Echtesit systeme Elimination von Transition mit xor Zustand als Quelle create fu te o Nae GE Tr WithPeriod came eo a WithCategor Die Transition mit Ereignis clear alle Datenfelder wieder l schen wurde durch eine entsprechende Transition von jedem Unterzustand aus ersetzt Jetzt kann man den Oberzustand Incomplete entfernen Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 394 Von der OO Analyse zum Software Entwurf Echtzeit ip systeme Zu hierarchischem Statechart quivalenter flacher Automat create N confirm WithPeriod WithClient setClient WithCategon Achtung jedes normale hierarchische Statechart l sst sich in einen normalen flachen Automaten bersetzen Ausnahmen kommen sp ter Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 395 Von der OO Analyse zum Software Entwurf Echtzeit g systeme Abstraktes Beispiel mit xor Oberzustand bersetzung in normales Zustandsdiagramm Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 396 Von der OO Analyse zum Software Entwurf Echtzeit ip systeme bersetzung von Statecharts in einfache Zustandsdiagramme
96. t kann nicht in Lines Of Code pro Zeiteinheit sinnvoll gemessen werden sonst w re Programmieren in Assembler die beste L sung also Vorsicht mit Einsatz von Ma zahlen keine sozialistische Planwirtschaft Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Management der Software Entwicklung Eon ES systeme Softwareumfang Function Points Bei der Function Point Methode zur Kostensch tzung wird der Softwareumfang anhand der Produktanforderungen aus dem Lastenheft gesch tzt Es gibt inzwischen einige Spielarten hier wird weitgehend der Ansatz der International Function Point Users Group IFPUG vorgestellt siehe auch http www ifpug org Jede Anforderung wird gem IFPUG einer von 5 Kategorien zugeordnet ACF97 Eingabedaten ber Tastatur CD externe Schnittstellen Ausgabedaten auf Bildschirm Papier externe Schnittstelle Abfragen z B SQL Queries auf einem internen Datenbestand Datenbest nde sich ndernde interne Datenbankinhalte Referenzdateien im wesentlichen unver nderliche Daten Dann werden Function Points FPs berechnet bewertet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 629 Management der Software Entwicklung Fachgebiet Echizeit Ap systeme gt Datenbest nde Internal Logical File ILF Interne Entit ten Unter einer internen Gesch fts Entit t definiert die IFPUG eine au
97. tsbereich Aktion3 Beginn Fallunterscheidung A Ende Verzweigung Nicht Bedingung Bedingung Aktion4 lt lt datastore gt gt persistente Datenspeicherung Ereignis wird empfangen Ereignis wird weggeschickt Ende der N lt lt centralBuffer gt gt Nebenl iufigkeit tempor re Datenspeicherung nur dieser Teilablauf wird beendet andere amp Q nebenl ufige Aktionen werden fortgef hrt Immer noch unvollst ndige bersicht ber alle Elemente von Aktivit tsdiagrammen Zeit Ereignis Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 243 Objektorientierte Anforderungsanalyse Eon ES systeme Abschlie ende Anmerkungen zu Aktivit tsdiagrammen LJ es handelt sich um die Diagrammart die in UML 2 0 am radikalsten berarbeitet wurde eine ganze Reihe von Modellierungselementen f r mengenwertige Pins loops wurden hier nicht vorgestellt LJ viel Energie ist in die pr zise Definition der Semantik dieser Diagramme geflossen trotzdem ist eine Reihe von Punkten nicht gekl rt LJ Theoretisch kann mit Aktivit tsdiagrammen programmiert werden Codegeneratoren daf r sind aber kaum verf gbar Einsatzm glichkeiten UL blich pr zise re Definition einzelner Anwendungsf lle oder des Zusammen spiels von Anwendungsf llen Gesch ftsprozessmodellierung un blich Programmierung reaktiver Systeme unter Einsatz von Ereignissen hierf r werd
98. zur Soft ware Entwicklung ist ein Vorgehensmodell das den Gesamtprozess der Software Erstellung und pflege in einzelne Schritte aufteilt und die Verantwortlichkeiten der beteiligten Personen Rollen klar regelt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 53 Vorgehensmodelle der Software Entwicklung Echtzeit systeme 2 1 Der Code and Fix Zyklus Typische Vorgehensweise f r kleine 1 Personen Projekte und bungsaufgaben im Grund Studium Code schreiben und bersetzen Code testen debuggen Code verbessern Fehlerbeseitigung Erweiterung Effizienzsteigerung GOTO 2 Probleme mit dieser Vorgehensweise Wartbarkeit und Zuverl ssigkeit nehmen kontinuierlich ab wenn der Programmierer k ndigt ist alles vorbei wenn Entwickler und Anwender nicht identisch sind gibt es oft Meinungsver schiedenheiten ber erwarteten realisierten Funktionsumfang Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 54 Vorgehensmodelle der Software Entwicklung Eenzet EX systeme 2 2 Das klassische Wasserfallmodell siehe Kapitel 3 ha lund Kapitel 10 Einteilung in Phasen Phasen erzeugen Dokumente Anforderungs siehe Kapitel 5 analyse System siehe Kapitel 6 bis entwurf Kapitel 8 Codieren und Modultest Entwicklungszeit Integration amp Systemtest siehe Kapitel 10 siehe Kapitel 9 Auslieferung amp Installation
99. 1 4 und Kapitel 10 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 97 Requirements Engineering und Machbarkeitsstudie Een ES systeme Sch tzverfahren im berblick LJ Analogiemethode Experte vergleicht neues Projekt mit bereits abgeschlossenen hnlichen Projekten und sch tzt Kosten gef hlsm ig ab Expertenwissen l sst sich schwer vermitteln und nachvollziehen Prozentsatzmethode aus abgeschlossenen hnlichen Projekten wird Vertei lung des Aufwands auf Phasen ermittelt Anhand abgeschlossener Phasen wird Restlaufzeit des Projekts gesch tzt funktioniert allenfalls nach Abschluss der Analysephase Parkinsons Gesetz die Arbeit ist beendet wenn alle Vorr te aufgebraucht sind praxisnah realistisch und wenig hilfreich Gewichtungsmethode Bestimmung vieler Faktoren Erfahrung der Mitarbeiter verwendete Sprachen und Verkn pfung durch mathematische Formel LOC basierter Vertreter COnstructive COst MOdel COCOMO lt gt FP bas erte Vertreter Function Point Methoden in vielen Varianten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 98 Fachgebi Requirements Engineering und Machbarkeitsstudie Eenzet ipo systeme 3 5 Projektplane und Projektorganisation Am Ende der Machbarkeitsstudie steht die Erstellung eines Projektplans mit Identifikation der einzelnen Arbeitspakete gt Terminplanung zeitl
100. 2 we Adaclent J SL MVRS_ Reservations lt lt Misuse Case gt gt ee 4 _ManipulateReservation gt Away lt lt triggers gt gt a ReportTheft _ Make Reservation gt CancelReservation_ 2 die Funktion CheckClient soll den Autodiebstahl im Vorfeld verhindern die Funktion ReportTheft wird ben tigt falls doch die Stereotypen Misuse Case prevents und triggers sind Eigenerfindungen Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 173 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit om Detaillierte textuelle Anwendungsfallbeschreibung Use Case MakeReservation Actors Clerk plus ggf beteiligte Teilsysteme Purpose Fahrzeug der Kategorie C wird f r Zeitraum T reserviert Entry Cond Reservierungsfunktion wird aktiviert geht immer Overview Aufgrund des Telefonanrufes der schriftlichen Bestellung oder des pers nlichen Erscheinens eines Kunden K Client gibt Clerk eine Reservierung mit Fahrzeugkategorie C und Zeitraum T ein Diese Reservierung wird soweit m glich ber cksichtigt und es wird eine Best tigung dem Kunden zugeschickt Exit Cond gew hlte Reservierung in DB oder unver nderte DB Includes SendMail f r Verschicken einer Reservierungsbest tigung Special Req Die Suche nach verf gbaren Fahrzeugen dauert nicht l nger als 30 Sekunden Category sehr hohe Priorit t Cross Ref auf LF 30 aus Lastenhef
101. 53 Fachgebiet f Von der OO Analyse zum Datenbank Entwurf Echtzeit J Ablauf f r Datenbankentwicklung Pianung Kundenanforderungen z B als Lastenheft l siehe Abschnitt 3 3 Analyse konzept Datenmodell UML Class Diagrams siehe Abschnitt 5 3 Datenbankschema Definition mit SQL siehe Abschnitt 6 3 Analyse gt Design systeme Anwendungsf lle UML Use Cases iehe Abschnitt 5 2 siehe Abschnitt 5 2 Workflow Modell UML Activity Diagrams siehe Abschnitt 5 5 DB Anfragen Updates mit SQL siehe Abschnitt 6 5 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 254 Von der OO Analyse zum Datenbank Entwurf Echtzeit Mich systeme Danksagung Dieses Kapitel ist ein Exzerpt einer Vorlesung und st tzt sich im wesentlichen auf das sogenannte Biberbuch SSH10 der Kollegen Saake Sattler und Heuer ab Die Definition der Syntax von SQL 89 als EBNF wurde allerdings dem Skript zur Vor lesung Datenbanksysteme entnommen des Kollegens Janas von der Uni BW M nchen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 255 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme 6 1 Einf hrung in Datenbanken Eine Datenbank auch Datenbanksystem ist ein System zur Beschreibung Speicherung und Wiedergewinnung umfangreicher Datenmengen die von mehreren Anwendungsprogrammen oder Anwender
102. 8 Institut f r Datentechnik Seite 156 jektorienti u Echt fp Objektorientierte Anforderungsanalyse systeme Bestimmung geeigneter Anwendungsfalle 2 LJ auf relevante Verben einschr nken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 157 Fachgebiet f Objektorientierte Anforderungsanalyse Echtzeit 3 systeme Systemgrenze und Anwendungsfalle des MVRS Beispiels Reservation System Select an option 1 Reserve Vehicle 2 Fetch Vehicle 3 Return Vehicle 4 Cancel Reservation Input F Clerk Benutzer Akteur oberflache System grenze Make Reservation Return Vehicle Fetch Vehicle Systemfunktionalitat Anwendungsf lle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 158 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit systeme Oberflachenbau mit GUI Werkzeug i Together 6 File Edit Search View Project Run Deploy Selection Tools Help BRSBS 5e XhO 4 VEN EB BI eg ss i B Workspace mrs Explorer mo a A 5a 20 B amp U Components o F this amp lt NullLayout gt A laben Client Number fi 00000000000 FB textField1 Reservation Date Daymontnyear label2 Ale Button A ae Car Category J jor lal amp choicet ae ok t cancel EH button TextField E button2 Menu Components En Non Visual Components A TextA
103. 8 Institut f r Datentechnik Seite 305 Von der OO Analyse zum Datenbank Entwurf Echtzeit u systeme Beispiel f r Tabellendefinition mit Fremdschl sselbedingung CREATE TABLE B cher ISBN CHAR 10 NOT NULL PRIMARY KEY Titel CHAR 200 Verlagsname CHAR 30 NOT NULL REFERENCES Verlage Verlagsname Beispiel f r Tabellendefinition mit zusammengesetztem Prim rschl ssel CREATE TABLE Buchexemplare Nummer INT ISBN CHAR 10 Ausleiher CHAR 30 PRIMARY KEY Nummer ISBN FOREIGN KEY ISBN REFERENCES B cher FOREIGN KEY Ausleiher REFERENCES Benutzer Name Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 306 Von der OO Analyse zum Datenbank Entwurf Echtzeit Mich systeme Erweiterungen in SQL2 SQL 92 LJ Strings variabler L nge aber feste Maximall nge verschiedene Datentypen f r Datums und Zeitangaben neben Strings auch Bitfolgen fester variabler L nge selbstdefinierte Datentypen Aufz hlungstypen etc mehr Schema nderungen mit ADD DROP und ALTER TABLE Erweiterungen in SQL3 U objektorientierte Konzepte U Tabellen in Tabellen E Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 307 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme SQL als Datenanfragesprache Der SQL Anfrageteil beruht auf der Relationenalgebra und besteht im wesentlichen aus einem Konstrukt dem sogenannten SFW Block f r sele
104. 8 Institut f r Datentechnik Seite 430 Objektorientierter Softwareentwurf Eenzet EX systeme Umsetzung der Standard Architektur in UML MVC Model View Control Unterpaket von MVRS Ablaufsteuerund N O Control importiert View Benutzerschnittstelll Contracts LegalEntities Vehicles Platform CommunicationSoftwa Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 431 Fachgebiet Objektorientierter Softwareentwurf Echtzeit systeme Standard Stereotypen f r Klassen am Beispiel MVC Konzept LJ Benutzer Schnittstellenklassen erhalten den Stereotyp lt lt boundary gt gt im Folgenden in allen Diagrammen meist rot dargestellt u a alle im MVC Konzept dem View zugeordneten Klassen Klassen die haupts chlich der Datenhaltung dienen erhalten den Stereotyp lt lt entity gt gt im Folgenden meist blau dargestellt u a alle im MVC Konzept dem Model zugeordnete Klassen Kontrollklassen die die Interaktionen anderer Klassen steuern erhalten den und selbst kaum Daten speichern erhalten den Stereotyp lt lt control gt gt im Folgenden meist gelb dargestellt u a alle im MVC Konzept der Control zugeordneten Klassen Selbst eingef hrte Stereotypen F r bestimmte Anwendungsbereiche kann die Einf hrung weiterer Stereotypen sinnvoll sein wie etwa lt lt sensor gt gt bei eingebetteten Systemen oder lt lt transac tion gt gt und lt
105. 8 Institut f r Datentechnik Seite 546 Fachgebiet Qualit tssicherung und Testverfahren Echtzeit systeme 9 4 Werkzeugunterst tzte statische Testverfahren Formale Verifikation von Software Es wird durch mathematisches Beweisverfahren gezeigt dass Implementierung die Eigenschaften ihrer Spezifikation erf llt oder dass Spezifikation bestimmte Eigen schaften besitzt Probleme sehr zeitaufw ndig und deshalb nur in kritischen F llen durchf hrbar automatische Verifikation mit Werkzeugen auf kleine Softwarekomponenten oder Funktionen beschr nkt Spezifikation bzw geforderte Eigenschaften m ssen in formaler Form vorliegen in Kombination mit UML als Modellierungssprache schwierig da es zu UML noch keine umfassende Semantikdefinition gibt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 547 Qualit tssicherung und Testverfahren Echtecit systeme Werkzeuggestutzte Fehlersuche mit statischer Datenflussanalyse Die Datenflussanalyse erkennt in Grenzen deklarierte nicht verwendete Variablen Parameter gt lesende Zugriffe auf nicht initialisierte Variable Zuweisungen von Werten an Variablen die nie gelesen werden Probleme mit Programmverzweigungen IF b1 THEN a ELSE b END IFb2 THEN x a ELSEx bEND ist nur dann korrekt wenn Bedingungen b1 und b2 quivalent sind Das l sst sich meist durch statische Programmanalyse nicht sicherstel
106. Arten von OCL Ausdrucken Fortsetzung 4 Vor und Nachbedingungen fiir Operationen fiir eine Operation einer Klasse oder Schnittstelle kann man angeben unter welchen Bedingungen sie nur aufge rufen werden darf Vorbedingungen und welche Bedingungen nach ihrer erfolg reichen Ausf hrung immer gelten context Client incrementFrequentRenterBonus bonus Integer Integer pre bonus gt 0 and currentBonus bonus lt 50 es ist nur eine Bonuserh hung auf maximal auf 50 post currentBonus bonus currentBonus pre and result currentBonus mit pre wird auf den Wert des Attributs currentBonus vor der Ausf hrung der Operation zugegriffen Achtung ist beim Aufruf einer Operation die Vorbedingung verletzt oder nach Ausf hrung einer Operation ihre Nachbedingung so ist das Ausf hrungsverhalten undefiniert Eine Implementierung kann dann beispielsweise eine Ausnahme werfen oder den Aufruf der Methode ignorieren oder Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 357 Von der OO Analyse zum Software Entwurf Echtzett g systeme Interaktion von Vererbung Generalisierung und OCL Ausdr cken LJ Invarianten Vor und Nachbedingungen gelten f r alle Mitglieder einer Klasse also auch f r die Instanzen ihrer Unterklassen LJ Instanzen einer Unterklasse m ssen alle Invarianten ihrer Oberklassen erf llen plus ggf zus tzliche eigene scharfere Invarianten eine Unterklass
107. Bedeutung sind Dazu geh ren unter anderem Beschreibung der Anforderungen an die Software Modelle Architekturen der Software alle Arten von Testf llen alle Arten von Benutzer Dokumentation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 26 Software Technik Was ist das Enten gg systeme Definition des Begriffs Software Technik Software Engineering Software Technik ist nach Ka93 O die Entwicklung O die Pflege und Q der Einsatz qualitativ hochwertiger Software unter Einsatz von QO wissenschaftlichen Methoden wirtschaftlichen Prinzipien geplanten Vorgehensmodellen Werkzeugen quantifizierbaren Zielen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 27 Software Technik Was ist das Echtesit systeme Erganzende Definitionen LY Nach IEE83 the systematic approach to the development operation maintenance and retirement of software L Nach BEM92 Software Engineering is the science and art of specifying designing imple menting and evolving with economy timelineness and elegance programs doc umentations and operating procedures whereby computers can be made useful to humanity LJ Nach Ba96 Software Technik Zielorientierte Bereitstellung und systematische Verwen dung von Prinzipien Methoden Konzepten Notationen und Werkzeugen fiir die arbeitsteilige ingenieurm ige Entwi
108. Client passives PSN findClient cn Signal returnClient cn mit findClient theClient x Parameter aktive R ckgabe geao Operations Zeit wert f r aufruf mit spanne voriges Parametern Signal getCategory y returnPeriod p returnCategory c findVehicles p c selectVehicle vs findVehicles vs return von SS Operations returnSelectedVehicle v addReservation cn p c v aufruf addReservation r sendMail r Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 376 Von der OO Analyse zum Software Entwurf one AS systeme Erl uterungen zu Sequenzdiagramm Fortsetzung Passive Objekte besitzen eine gestrichelte Lebenslinie solange sie inaktiv sind sie werden nur durch Empfang einer Nachricht meist ein synchroner Operations aufruf aktiv bis zum Ende der Ausf hrung der gerufenen Operation Ein asynchrones Signal oder ein synchroner Operationsaufruf kann beliebig viele Parameter besitzen Diese Pfeile sind wie folgt beschriftet lt Var gt lt Operationsname gt lt Parameterliste gt Ein synchroner Operationsaufruf wird mit einem gestrichelten return Pfeil mit offener Spitze beendet dieser Pfeil ist wie folgt beschriftet lt Operationsname gt lt Parameterliste gt lt Wert gt Achtung Theoretisch k nnten Signale als Daten auch synchron verschickt und Operationen auch asynchron aufgerufen werden aber meist verwen
109. DREN Achtung die neuen Klassen sind noch ziemlich sinnlos aber man hat einen vern nftigen Zwischenzustand f r Programmtests erreicht Denn niemals zu gro e Refactoring Schritte auf einmal durchf hren sondern viele kleine durch Werkzeug durchgef hrte Schritte mit eingestreuten Tests Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 466 Objektorientierter Softwareentwurf ehe ed systeme Refactoring Schritt MoveMethod von Movie nach MovieState public class Movie public double getCharge int daysRented return _movieState getCharge daysRented abstract class MovieState double getCharge int daysRented double result 0 switch getPriceCode case Movie REGULAR result 2 if daysRented gt 2 result daysRented 2 1 5 break case Movie NEW_RELEASE result daysRented 3 break case Movie CHILDREN result 1 5 if daysRented gt 3 result daysRented 3 1 5 break return result Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 467 Objektorientierter Softwareentwurf Bone fp systeme Refactoring Schritt ReplaceConditional with Polymorphism abstract class MovieState abstract double getCharge int daysRented class RegularMovie extends MovieState double getCharge int daysRented double result 2 if daysRented gt 2 resul
110. Die 3NF beinhaltet immer die 2NF da X c K sein darf und dann K gt X gilt damit verbietet die 3NF auch X Y f r X c K Forderung der 2NF Beispiel Mit PANr als Prim r Schl ssel f r Beispiel auf Seite 291 gilt gt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 297 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Herstellung der dritten Normalform Sei 3NF verletzt im Relationenschema R durch K gt X A mit Schl ssel X Attribut menge X und Nicht Primattribut A Dann eliminiert man die Verletzung durch NA N A Beispiel Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 298 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Zusammenfassung der Schemaeigenschaften 1NF nur atomare Attribute 2NF keine partielle Abh ngigkeit eines Nicht Primattributs von einem Schl ssel 3NF S1 keine transitive Abh ngigkeit eines Nicht Primattributs von Schl ssel E E E E Minimalit t S2 minimale Anzahl von Relationen in NF Bedeutung f r die Praxis LJ Beim Datenbankentwurf beachtet man meist nur die Bedingungen S1 und S2 man entwirft also eine minimale Anzahl von Relationenschemata in 3NF Noch st rkere Normalformen als die 3NF sind f r die Praxis oft zu einschr n kend und werden deshalb eher selten verwendet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r D
111. Echtzeit A systeme Vision der objektorientierten Softwareentwicklung Problem Datenaspekt Fur Verhaltensaspekt Analyse OOA Entwurf OOD depen a OOA OO Analyse nn GOD 00 Design OOP OO Programmierung OODB OO Datenbanken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 114 Grundlagen der objektorientierten Modellierung Echtzeit A systeme Realit t der objektorientierten Modellierung Datenaspekte Verhaltensaspekte Klassendiagramme u a und Zustands bergangsdiagramme Datenflussdiagramme Objektdiagramme Ablaufdiagramme relationales DB Schema Objektorientiertes SQL Implementierung Programm Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 115 Fachgebiet f Grundlagen der objektorientierten Modellierung Echtzeit 3 systeme 2 4 2 Grundbegriffe der Objektorientierung Objektorientierte Programmierung nach Bo94 a method of implementation in which programs are organized as cooperative collections of objects each of which represents an instance of some class whose classes are all members of a hierarchy of classes united via inheritance relationships Essentials der Objektorientierung sind also 1 alles ist ein Objekt Objekte sind Instanzen von Klassen die ihr Verhalten festlegen Objekte kommunizieren ber Nachrichtenaustausch Klassen bilden ein
112. Failure Fehlerwirkung es handelt sich um ein Fehlverhalten eines Pro gramms das w hrend seiner Ausf hrung tats chlich auftritt Fault Defect Bug Fehlerzustand es handelt sich um eine fehlerhafte Stelle Zeile eines Programms die ein Fehlverhalten ausl sen kann Error es handelt sich um eine fehlerhafte Aktion Irrtum die zu einer fehlerhaften Programmstelle f hrt oder Ausf hrung fehlerhafter Zeile Oder anders formuliert Fehler bei der Programmierung errors K nnen zu Fehlern in einem Programm faults f hren die Fehler bei der Programmausf hrung failure bewirken Achtung Anstelle von Failure wird oft von Error Fehlverhalten ausl sende Aktion gesprochen deshalb spricht man oft von error codes oder error handler Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 534 Qualit tssicherung und Testverfahren Echtzeit systeme Entstehung und Fortpflanzung von Fehlern Faults korrekt fehlerhaft bzgl Machbarkeitsstudie fehlerhafte eigentlich Ben tigte grobe Anforderungen Anforderungen Anforderungen Programmverhalten Anforderungsanalyse korrekte Spezifikations induzierte Fehler Systemspezifikation Spezifikation fehler aus Anforderungen Entwurf Design Kt NE induzierte Fehler aus Codierung En LE induzierte Fehler aus T dl i korrektes korrigierte gefundene nicht unbekannte est und Integration Programm Fehler korrigier
113. Institut f r Datentechnik Seite 281 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit Beispiel f r Klassendiagramm in Relationenschema ein Student h rt attends at eine Menge von Vorlesungen jede Vorlesung h rt er bei genau einem Professor Professor zu einem konkreten Paar von Vorlesung und Student ist eindeutig festgelegt jede Vorlesung geh rt zu genau einem Modul mit 1 a mehreren Vorlesungen jede Vorlesung wird von ein bis mehreren Professoren gehalten semesterweise abwechselnd Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 282 Von der OO Analyse zum Datenbank Entwurf Echtzeit Mich systeme Realisierung als Relationschemata garantiert dass es keine zwei Studenten mit der selben Nummer gibt garantiert dass es keine zwei Professoren mit der selben Nummer gibt garantiert dass es keine zwei Module mit der selben Nummer gibt garantiert dass es keine zwei Vorlesungen mit der selben Nummer gibt realisiert zudem die Assoziation for und garantiert damit dass es zu einer Vorlesung immer genau ein Modul gibt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 283 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Realisierung als Relationschemata Fortsetzung gt Relationenschema gives LNo PNO der aus LNo und PNo bestehende Prim rschl ssel erlaubt beliebige Kombinationen von Vorlesungen u
114. Klasse die immer mehr Verantwortlichkei ten und Code in einem System an sich zieht Struktur Form eine Klasse mit einer sehr gro en Anzahl an Methoden und Attri buten die haupts chlich nur Daten verwaltende andere Klassen benutzt Eine oder mehrere Methoden sind typischerweise selbst wiederum sehr gro und komplex Konsequenzen nderungen unterschiedlicher logischer Sachverhalte m ssen immer wieder in der selben Klasse durchgef hrt werden diese Blob Klasse ist zudem kaum wiederverwendbar und sehr schwer zu testen Gr nde von der Verwendung prozeduraler Programmiersprachen gepr gte Entwickler neigen dazu insbesondere bei der Realisierung eingebetteter Systeme die Kontroll Logik des Systems in einer Klasse und einer Methode zu verankern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 518 Objektorientierter Softwareentwurf Eon ES systeme Das Anti Entwurfsmuster Blob Fortsetzung Beispiel die urspr ngliche Klasse Customer unserer Videoverleihsoftware mit ihren gro en Methoden print statement und htmlStatement LJ Neue L sung Auslagerung von logisch zusammengeh rigen Attributen und Methoden in eigene Klassen oder bereits existierende Klassen Zerlegung von Berechnungen durch Delegation Chains of Responsibilities in Teilberechnungen Einf hrung von Oberklassen die erweiterbares Grundverhalten einf hren Erlaubte Ausnahmen Verkapselung von
115. Kontrollmarken control tokens entlang Kontrollflusskanten zu verschieben werden Objekte data tokens entlang von Objektflusskanten verschoben Ausf hrung eines Aktivit tsdiagramms beginnt wenn auf allen Eingabe parameterpl tzen mindestens ein Objekt liegt im einfachsten Fall die Objekte k nnen dort in einer Warteschlange abgelegt werden einmalige Ausf hrung konsumiert von jedem Eingabeparameterplatz genau ein Objekt Ausf hrung endet damit dass auf alle Ausgabeparameterpl tze neue Objekte gelegt werden im einfachsten Fall und oder Endeknoten erreicht wurde die Objekte k nnen dort in einer Warteschlange abgelegt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 232 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit po systeme Erl uterungen zu Aktivit tsdiagrammen Fortsetzung LI stellt eine Aktion einen Aufruf eines Aktivit tsdiagramms dar so entsprechen die Eingabeparameter der Aktivit t den Eingabe Pins der Aktion gt die Ausgabeparameter der Aktivit t den Ausgabe Pins der Aktion UML kennt eine eigene Teilsprache f r die Programmierung einfacher Aktionen die Action Language folgendes unterst tzt Erzeugen L schen von Objekten Erzeugen L schen von Links gt Abfragen auf Objekten und Links gt das Weitergeben von mehreren Kopien von Objekten an verschiedene Aktionen wie bei period wird eigentlich umst ndlicher modelliert durch V
116. Objektklassen U gleichartige Objekte werden in einer Klasse zusammengefasst jedes Objekt ist Instanz genau einer Klasse alle Instanzen einer Klasse sind Bestandteil ihrer Extension ein Objekt ndert seine Klasse w hrend seiner Lebenszeit nicht E E E E die Klasse legt f r ihre Instanzen fest alle Attribute mit zul ssigen Wertebereichen alle Operationen mit ihren Implementierungen als Methoden die Trennung von Schnittstelle ffentliche Operationen der Klasse und Rumpf Implementierung dieser Operationen Klassen bilden Kapseln abstrakte Datentypen ADTs f r ihre Objekte abstrakte Klasse Klasse ohne Instanzen mit unvollst ndiger Implementierung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 125 Fachgebiet Grundlagen der objektorientierten Modellierung Echtzeit systeme Von konkreten Objekten zu Klassen Auto Auto Klasse preis Euro private interner Zustand ort String gibPreis Euro public Schnittstellenoperatic bewege AA rain M V 6120 Auto DA T 4378 Auto preis 30 000 preis 20 000 ort M nchen ort Darmstadt Abstraktion ole ue Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 126 Grundlagen der objektorientierten Modellierung Eehtzeit systeme Klassen in Java realisiert Auto Auto Klasse preis Euro private interner Zustand ort String
117. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 106 Grundlagen der objektorientierten Modellierung Echtecit systeme Eingesetzte klassische Modellierungssprachen F r die Modellierung funktionaler Aspekte Verhalten O Datenflussdiagramme durch Kan le verbundene Prozessoren O Funktionsb ume hierarchische Dekomposition von Algorithmen LJ F r die Modellierung von Datenstrukturen O Data Dictionary Ansammlung von Typdefinitionen O Entity Relationship Diagramme Klassendiagramme ohne Operationen F r die Modellierung von Kontrollstrukturen O Struktogramme Nassi Shneiderman Diagramme QO Pseudocode F r die Modellierung zustandsbehafteter nebenl ufiger Systeme O Zustands bergangsdiagramme endliche Automaten QO Petrinetze Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 107 u jektorienti ieru Eche P Grundlagen der objektorientierten Modellierung systeme Beispiel eines einfachen Entity Relationship Diagramms ER Diagramm MotorVehicle Number Period Legende O Attribut lt gt Relationship Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 108 f f Fachgebi Grundlagen der objektorientierten Modellierung Echtzeit systeme Erl uterungen zu ER Diagrammen LJ ER Diagramme werden vor allem f r den Datenbank Entwurf eingesetzt LJ Entities entsprechen Klassen
118. SOFT Software Engineering Notes vol 23 no 4 1998 S 22 365 Jobs wurden gestrichen und es gab keine Pl ne f r Neueinstellungen Polizeioffiziere mussten die Papierarbeit bernehmen Die f r das Design des Systems verantwortliche Beratungsfirma f hrt als einen Grund des Desasters an police people were in charge of the development team Software design was not one of their core competences Der Innenminister Hartmuth Wrocklage f hrte die Probleme darauf zur ck dass die Komplexit t des Projekts untersch tzt worden war Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 12 Software Technik Was ist das one AS systeme Ein wirklich teurer Software Fehler Ariane 5 On June 4 1996 on its maiden flight the Ariane 5 was launched and per formed perfectly for approximately 40 seconds Then it began to veer off course At the direction of the Ariane ground controller the rocket was destroyed by remote control total cost of the disaster was 500 million Pfleeger Software Engineering Theory and Practice S 37 Ursache 6 Flugbahn der Rakete wird durch Inertial Reference System SRI gemessen dessen Software teilweise von Ariane 4 bernommen wurde 6 ein Teilsystem von SRI rechnete nach dem Start weiter obwohl seine Ergebnisse in Ariane 5 nicht mehr ben tigt wurden andere Flugbahndaten von Ariane 5 als bei Ariane 4 erzeugten berlauf
119. Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 577 Management der Software Entwicklung Echtzeit systeme Das V Modell SE 1 System Anforderungs a SE9 berleitung in die analyse N Nutzung l SE 2 System Entwurf SE 8 System Integration l SE 3 SW HW Anforderungs gt analyse lt SE 7 SW Integration SE 4 SW Grobentwurf SE 5 SW Feinentwurf 2 SE 6 SW Implementierung berblick zum V Modell 97 findet man in OHJ99 neu ist das V Modell XT Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 578 Management der Software Entwicklung Eon ES systeme Beschreibung der einzelnen Phasen des V Modells LJ Systemanforderungsanalyse Gesamtsystem einschlie lich aller Nicht DV Kom ponenten wird beschrieben fachliche Anforderungen und Risikoanalyse LJ Systementwurf System wird in technische Komponenten Subsysteme zerlegt also die Grobarchitektur des Systems definiert Softwareanforderungsanalyse technischen Anforderungen an die bereits identi fizierten Komponenten werden definiert Softwaregrobentwurf Softwarearchitektur wird bis auf Modulebene festgelegt Softwarefeinentwurf Details einzelner Module werden festgelegt Softwareimplementierung wie beim Wasserfallmodell inklusive Modultest Software Systemintegration schrittweise Integration und Test der verschiede nen Systemanteile berleitung in die Nutzung entsp
120. Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 71 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit po systeme Bestandteile einer Machbarkeitsstudie LJ Lastenheft f hrt alle fachlichen Anforderungen grob auf die Software aus Sicht des Auftraggebers erf llen soll es wird bei klassischer Vorgehensweise nicht festgelegt wie sich die Anforderungen realisieren lassen LJ Projektkalkulation der Umfang des gew nschten Software Produktes wird gesch tzt und es werden daraus die Entwicklungskosten abgeleitet Q Projektplan Zeitplan f r die Durchf hrung des Projektes mit Unterteilung in Phasen und Festlegung von Phasenergebnissen und Phasenverantwortlichen Gro e Probleme LJ wie ist Umfang Gr e eines Software Produktes definiert U wie l t sich Produktumfang ohne Betrachtung der Realisierung sch tzen LJ in welchem Verh ltnis stehen Produktumfang Entwicklungszeit und kosten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 72 Requirements Engineering und Machbarkeitsstudie Eenzet EA systeme Ermittlung von Anforderungen aus WW00 Q Needs Bestandsaufnahme existierender Gesch ftsprozesse Problembeschreibungen warum soll Software entwickelt werden Features Lastenheft mit grober Beschrei bung von Hauptfunktionen neuer Software was f r Funktionen sollen die gefundenen Probleme l sen siehe Abschnitt 3 3 Software Require
121. Seite 477 Objektorientierter Softwareentwurf Echteslt systeme Bewahrung von Teilsystemschnittstellen beim Refactoring Oft hat der Entwickler eines Teilsystems einer Bibliothek eines Rahmenwerkes nicht Zugriff auf den Code der Anwendungen die sein Teilsystem verwenden Damit kann er im Zuge des Refactorings seines Teilsystems eigentlich keine nderungen an der Schnittstelle seines Teilsystems durchf hren ohne alle Anwender zu Umbauten zu zwingen Details hierzu in RLO4 LJ deshalb versucht man neue Versionen eines Teilsystems beim Refactoring aber nicht nur dabei soweit m glich abw rtskompatibel zu gestalten LJ baut man Umleitungen ein die alte nicht mehr erw nschte Schnittstellenanteile auf neuere Realisierung abbilden und damit Anwender nicht zum sofortigen Umbau ihrer Anwendungen zwingen alte Klassen und Methoden werden als nicht mehr zu benutzend markiert in Java deprecated diese Markierung f hren zu Compilerwarnungen Vorteil Anwender hat Zeit um notwendige Umbauten durchzuf hren Nachteil neue Softwarearchitektur ist teilweise schlechter als alte weil Altlasten nun zus tzlich zur sanierten neuen L sung weiter existieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 478 Objektorientierter Softwareentwurf Echte dec systeme Beispiele f r nicht abw rtskompatible Schnittstellen nderungen O nderungen an Klassen U
122. So gibt es in St05 beispielsweise folgende Zusatzfelder LJ statt entry condition wird feiner zwischen Ausl ser eines Anwendungsfalles und Vorbedingung f r die Ausf hrbarkeit des Anwendungsfalles unterschieden LJ statt exit condition wird feiner zwischen Nachbedingung eines Anwendungsfalles was gilt danach immer und Ergebnis des Anwendungsfalles unterschieden was hat der Anwendungsfall bewirkt anstatt einer einzigen Ablaufbeschreibung je Anwendungsfall werden oft mehrere Ablaufbeschreibungen Standardablauf und Ausnahmen Varianten in einem Anwendungsfall zusammengefasst und damit auf extend Beziehung verzichtet sinnvoll k nnen des weiteren Felder f r H ufigkeit des Auftretens eines Anwendunssfalles sowie allgemeine Anmerkungsfelder sein auch f r textuelle Darstellung von Abl ufen gibt es die verschiedensten Varianten z B tabellarische Form mit beteiligten Akteuren je Teilschritt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 178 Objektorientierte Anforderungsanalyse Echtzeit systeme Kategorisierung ranking von Anwendungsf llen Die Vergabe von Priorit ten an Anwendungsf lle wird f r die Projektplanung benutzt Anwendungsf lle mit h herer Priorit t werden fr her realisiert als Anwen dungsf lle mit niedrigerer Priorit t Anwendunegsfalle haben hohe Priorit t wenn sie gro en Einfluss auf Architektur des Softwareproduktes besitzen zeitkritische sicherhe
123. Software Engineering Einf hrung SE bzw Analyse amp Design Prof Dr Andy Sch rr Fachgebiet Echtzeitsysteme FB 18 amp FB 20 Technische Universit t Darmstadt Merckstr 25 D 64283 Darmstadt Andy Schuerr es tu darmstadt de Tel 06151 16 6940 Raum S 306 313 WWW Seite der Vorlesung http www es tu darmstadt de lehre se i v Bildquelle Jules Verne The Great Explorers of the XIXth Century New York Charles Scribner s Sons 1912 Software Engineers Death March Project Fachgebiet f Einf hrung in Software Engineering a om Inhaltsverzeichnis der Vorlesung Software Technik Was ist das Vorgehensmodelle der Software Entwicklung Requirements Engineering und Machbarkeitsstudie Grundlagen der objektorientierten Modellierung Objektorientierte Anforderungsanalyse Von der OO Analyse zum Datenbank Entwurf Von der OO Analyse zum Software Entwurf Objektorientierter Software Entwurf Qualitatssicherung und Testverfahren Wird in Software Engineering Wartung und Qualitatssicherung behandelt Management der Software Entwicklung wird in Software Engineering Projektmanagement behandelt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 2 A f Fachgebi Einf hrung in Software Engineering Eenzet ipo systeme Zielsetzungen der Vorlesung LJ den Zuh rer von der Notwendigkeit der Software Technik berzeugen LI Basis f r fortf hrende Software Engi
124. Software funktioniert meistens Zuverl ssigkeit ist also ein Ma f r die Wahrscheinlichkeit dass ein Software System sich in genau so verh lt wie es von ihm erwartet wird Korrekte Software 100 zuverl ssige Software Eingabe a die einen Fehler Programm Ausgabe FI Ausgaben mit Fehlern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 37 Fachgebiet Software Technik Was ist das Echtzeit systeme Vertrauensw rdige Software Safety Vertrauensw rdige Software verursacht auch im Fehlerfall keine Katastrophen inkorrekte Software kann vertrauensw rdig sein z B wenn die Software per se keinen wirklichen Schaden anrichten kann korrekte Software muss nicht vertrauensw rdig sein Fehler in Anforderungsdefinition Beispiele nicht vertrauensw rdiger Software LI Joystick Steuerung in Spielconsole von Natur aus vertrauensw rdig Joystick Steuerung im Los Alamos National Laboratory Am 26 Februar 1998 f hrte die Fehlfunktion einer Joystick Steuerung dazu dass sich zwei Uranst cke nicht langsam sondern mit maximaler Geschwin digkeit aufeinander zubewegten Der Operator dr ckte rechtzeitig einen Notausknopf angeblich war die Summe der Massen unterkritisch ACM SIGSOFT Sofware Engineering Notes vol 23 no 4 1998 S 21 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 38 Software Technik Was ist d
125. T Weilkiens B Oestereich UML2 Zertifizierung Testvorbereitung zum OMG Certified UML Professio nal Fundamental dpunkt Verlag 2004 149 Seiten Trainingsbuch f r UML Zertifizierung nur als Erg nzung zu anderen UML B chern genie bar Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 9 Software Technik Was ist das ee systeme 1 Software Technik Was ist das Themen dieses Kapitels LJ worin unterscheidet sich Software von anderen technischen Produkten einige spektakul re Softwarefehler LJ Definition en und Geschichte des Begriffs Software Technik LY Software Qualit tsmerkmale Merke F r die Entwicklung gro er Software Produkte mit Milliarden Zeilen Code in Autos Flugzeugen Medizintechnikger ten braucht man andere Vorgehensweisen als f r das L sen kleiner bungsaufgaben Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 11 Software Technik Was ist das ee systeme 1 1 Bekannte Software Katastrophen Ein sch nes Beispiel f r Inkompetenz Since 1989 some 120 Million Deutschmarks have been wasted trying to design and install a new computer system for the police in Hamburg Germany The sys tem designed to ease the load of paperwork on the police never worked What strikes me are the three conclusions of the whole affair that appeared in Ham burger Abendblatt 16 April 1998 ACM SIG
126. Testen Sie testen Implementierung gegen ihre Spezifikation und lassen die interne Programm struktur unber cksichtigt komplement r zu bislang vorgestellten White Box Verfahren f r Abnahmetest ohne Kenntnis des Quellcodes geeignet setzt eigentlich vollst ndige und widerspruchsfreie Spezifikation voraus per se ein Problem bei Verwendung von UML als Modellierungssprache repr sentative Eingabewerte Szenarien m ssen ausgew hlt werden man kann ja im Allgemeinen nicht alle Eingabekombinationen testen Sequenzdiagramme aus Anwendungsf llen beschreiben wichtige Testf lle man braucht Orakel f r berpr fung der Korrektheit der Ausgaben braucht man allerdings bei den White Box Verfahren auch ausf hrbare Statecharts als Orakel verwenden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 554 Qualit tssicherung und Testverfahren Eon A systeme Kriterien f r die Auswahl von Eingabewerten An der Spezifikation hier in UML orientierte quivalenzklassenbildung so dass f r alle Werte einer quivalenzklasse sich das Softwareprodukt gleich verh lt Unterteilung in g ltige und ung ltige Eingabewerte gesonderte Betrachtung von Grenzwerten z B Anfang und Ende von Intervallen Auswahl von Repr sentanten so dass jede Variante jedes Sequenz und Kollabora tionsdiagramms Aktivit tsdiagramms einmal durchlaufen wird Auswahl von Repr sentanten so
127. Unterklasse ist Teilmenge der Extension ihrer Oberklasse Klassen als Typ sie werden zur Festlegung der Schnittstelle Operationen und internen Struktur Attribute ihrer Objekte Instanzen eingesetzt eine Unterklasse erweitert die Schnittstelle und Strukturdefinition ihrer Oberklasse vor allem in der Entwurfsphase verwendeter Klassenbegriff Klassen als Implementierung eine Klasse stellt den Quellcode f r ihre Objekte zur Verf gung eine Unterklasse erbt den Quellcode ihrer Oberklasse und erweitert und berschreibt ihn soweit n tig wurde hier in den Vordergrund gestellt vor allem in der Implementierungsphase verwendeter Klassenbegriff Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 140 Fachgebi Grundlagen der objektorientierten Modellierung Echtzeit 42 systeme Kommunikation von Objekten U Objekte kommunizieren miteinander durch das Versenden von Nachrichten message passing das sendende Objekt sender verschickt eine Nachricht das empfangende Objekt receiver erh lt eine Nachricht der Empf nger besitzt eine Methode f r die Nachrichtenbearbeitung Zwei Arten von Nachrichten 1 Operationsaufruf Kommunikation zwischen einem sendenden und einem festgelegten empfangenden Objekt Empf nger f hrt Methode aus die gerufene Operation implementiert Signal Kommunikation zwischen einem ausl senden Objekt und allen Objekten die dieses Sign
128. abk rzende Schreibweise f r self rentalOffice gt collect motorVehicle bzw f r self rentalOffice gt collect anOffice anOffice motorVehicle collect wird auf einer Kollektion von Elementen aufgerufen mit einem Ausdruck als Argument cs gt collect e ist die Vereinigung der Auswertung des Ausdrucks e f r jedes einzelne Objekt in der Kollektion CS ein OCL Ausdruck der Art obj role1 role2 bildet also automatisch die Vereinigung der Ergebnisse der Anwendung von role2 auf alle Ergebnisse des Aufrufs von role1 auf obj Ergebnisse sind immer Listen Sequenzen die mit dem Aufruf list gt asSet in eine Menge ohne Duplikate umgewandelt werden k nnen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 369 Von der OO Analyse zum Software Entwurf OCL Constraints im Klassendiagramm Fachgebiet f Echtzeit amp systeme z inv self client gt forAll cl c2 inv cl lt gt c2 implies cl name lt gt c2 name Client PAttributes name String age Integer RentalOffice Hkttrioutes name Integer noOfCars Integer 0 client 1 rentalOffice derive motorVehicle gt size N rentalOffice 1 client rentalContract 0 motorVehicle RentalContract iA ttributes deposit Integer rentalContract MotorVehicle Int o N Hkttrivutes 1 dnt oA age Integer N price ihteger motorVehicle 0 self rentalOff
129. adt FB 18 Institut f r Datentechnik Seite 341 Von der OO Analyse zum Software Entwurf Echtzeit 2 systeme Konsistenzbedingungen f r Assoziationsklasse am Beispiel Contract _41 i Dead Fish Inc Contract Contract SU faci Contract super Arne subcontract Contract age ee Hire amp Fire subcontract sub Contract Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 342 Von der OO Analyse zum Software Entwurf Echtesit systeme Zugehorigkeit von Objekten zu Klassen jedes Objekt ist Instanz genau einer seiner Klasse normale UML Interpretation abstrakte Klassen kursive Namen besitzen keine Instanzen jedes Objekt ist Mitglied seiner eigenen Klasse gt und aller ihrer Oberklassen LJ die Extension einer Klasse ist die Menge ihrer Mitglieder Grafik fur Extensionen Extension der Menge der LegalEntity Objekte Extension der Menge der Extension der Menge der Company Objekte Person Objekte Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 343 o zu ware Entwu Echtzeit A Von der OO Analyse zum Software Entwurf systeme Mehrfachvererbung multiple inheritance Motor Vehicle abstrakte Klasse Achtung Mit Mehrfachvererbung sehr vorsichtig umgehen Oft handelt es sich dabei um einen Modellierungsfehler Prof Dr Andy Sch rr TU Darmstadt FB 18
130. agen dass Aufwand f r Wartung und Pflege doppelt bis viermal so hoch wie Aufwand f r Entwicklung ist Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 573 Management der Software Entwicklung Echtzeit systeme Typische Probleme in der Wartungsphase LJ Einsatz wenig erfahrenen Personals nicht Entwicklungspersonal Fehlerbehebung f hrt neue Fehler ein stetige Verschlechterung der Programmstruktur Zusammenhang zwischen Programm und Dokumentation geht verloren zur Entwicklung eingesetzte Werkzeuge CASE Tools Compiler sterben aus ben tigte Hardware steht nicht mehr zur Verf gung Resourcenkonflikte zwischen Fehlerbehebung und Anpassung Erweiterung v llig neue Anspr che an Funktionalit t und Benutzeroberfl che Konsequenz Rechtzeitige Sanierung oder Neuentwicklung von Softwareprodukt und bessere Integration der Wartungsphase in Vorgehensmodell Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 574 Management der Software Entwicklung Eonze EX systeme Prozessmodell f r die Wartung nderungsw nsche Versionsplanung mpiementerung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 575 Management der Software Entwicklung Eon ES systeme Probleme mit dem Wasserfallmodell insgesamt amp Wartung mit ca 60 des Gesamtaufwandes ist eine Phase gt andere Prozessmodelle mit Wa
131. ahl entdeckter Fehler Quellcodezeilen Produktivit t Produktwert Kosten oder Quellcodezeilen Mitarbeitermonate Nach anderen Untersuchungen liegt die maximale Produktivit tssteigerung bei optimalem Einsatz von Werkzeugen CASE Tools bei 50 bis 60 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 568 Management der Software Entwicklung Echtzeit systeme 10 1 Zur ck zum Wasserfallmodell Machbar siehe Kapitel 3 und Kapitel 10 keitsstudie Anforderungs siehe Kapitel 5 analyse und Kapitel 7 System siehe Kapitel 7 entwurf und Kapitel 8 Codieren und Modultest Integrations siehe Kapitel 9 bislang nicht amp Systemtest siehe Kapitel 10 ee eee Auslieferung amp Installation Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 569 Management der Software Entwicklung Eon ES systeme Die Abnahmephase Auslieferung Diese Phase beendet die Entwicklung einer Generation eines Softwareproduktes durch die vertragsgem e bergabe an den Auftraggeber Es werden folgende Aktivit ten durchgef hrt O bergabe des Produkts Produktion f r den anonymen Markt Lizenz wird mit Bin rcode und Dokumentation bergeben ggf Wartungsvertrag f r Bezug k nftiger Soft wareversionen und Benutzung von Hotline Produktion von Individualsoftware mit Wartung Bin rcode der Software wird mit Dokumentation bergeben
132. al zum aktuellen Zeitpunkt empfangen k nnen oft ber Kanal Signal l st Aktion mit Zustands nderung bei Empf nger aus Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 141 Fachgebiet Grundlagen der objektorientierten Modellierung Echtzeit systeme Zwei Arten der Kommunikation 1 synchrone Kommunikation der Sender wartet bis der Empf nger die Nachricht verarbeitet hat und einen R ckgabewert produziert hat asynchrone Kommunikation der Sender wartet nicht bis der Empf nger die Nachricht verarbeitet hat ben tigter R ckgabewert wird in separater Nachricht r ckverschickt Kopplung Nachrichtenart gt Kommunikationsart LJ Operationsaufrufe sind sehr oft synchron manchmal aber auch asynchron U Signal Verschickung ist fast immer asynchron Synchronit t wird h chstens dadurch erreicht dass Sender auf zur ckkommendes separates Signal wartet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 142 Grundlagen der objektorientierten Modellierung Eehtzeit dip systeme Zwei Ausf hrungsarten 1 sequentiell nur ein Objekt des Systems ist zu jedem beliebigen Zeitpunkt aktiv single thread of control parallel mehrere Objekte sind zu einem bestimmten Zeitpunkt gleichzeitig aktiv multiple threads of control Beispiele f r synchron asynchron und sequentiell parallel L Methodenaufruf in Java synchron und
133. allterator current RentalComponent iterate Rentallterator isDone boolean first Index next Index current Rentallterator Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 492 Fachgebiet Objektorientierter Softwareentwurf Echtzeit systeme Fortsetzung des lterator Entwurfsmusters U Konsequenzen Vorteile gt die Verwendung der Iterator Schnittstelle sollte einfacher als die Verwendung der Schnittstelle von Aggregate sein einheitlich gestalte Schnittstelle f r Iterationen ber beliebigen Aggregaten in der Implementierung k nnen verschiedenen Durchlaufstrategien versteckt werden Filtern r ckw rts durchlaufen mehrere Iterationen k nnen gleichzeitig aktiv sein Varianten des Musters unterst tzen sogar die Verschr nkung von Hinzuf gen L schen von Elementen auf einem Aggregat auf dem eine Iteration gerade l uft Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 493 Objektorientierter Softwareentwurf Eon ES systeme Fortsetzung des lterator Entwurfsmusters LJ Implementierungshinweise w hrend der Iteration sollte das Aggregat nicht ver ndert werden insbe sondere das current Objekt nicht aus dem Aggregat gel scht werden will man Iterationen auf sich ndernden Aggregaten unterst tzen so muss das Aggregat die M glichkeit besitzen den Iterator von L schungen zu informieren oder L sch
134. also mehr Mitarbeiter mit der Anzahl der Mitarbeiter w chst aber der Kommunikations und der Verwaltungsaufwand berproportional also weniger Mitarbeiter Anzahl sinnvoll parallel zu besch ftigender Mitarbeiter w hrend Projekt laufzeit Putnam Kurve Mitarbeiter VI Zeit gt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 650 Management der Software Entwicklung Eenzet A systeme Rechenbeispiele f r Faustformel Aufwand in MM Projektart Projektdauer Mitarbeiterzahl 20 MM Stapel Batch 7 8 Monate 2 6 Mitarbeiter Echtzeit Realtime 6 5 Monate 3 1 Mitarbeiter Stapel 18 7 Monate 10 7 Mitarbeiter Echtzeit 13 6 Monate 14 7 Mitarbeiter 2000 MM Stapel 45 0 Monate 44 4 Mitarbeiter Echtzeit 28 5 Monate 70 2 Mitarbeiter Achtung gesch tzter Aufwand in Mitarbeitermonaten enth lt bereits organisatorischen Overhead f r Koordination von immer mehr Mitarbeitern in 45 0 Monaten mit 44 4 Mitarbeitern 2 000 MM werden also nicht 100 mal mehr FPs oder LOCs als in 7 8 Monaten mit 2 6 Mitarbeitern 20 MM erledigt eher nur 30 bis 40 mal mehr FPs Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 651 Management der Software Entwicklung Eon A systeme Bewertung der FP Methode LJ lange Zeit wurde LOC basierte Vorgehensweise propagiert LJ inzwischen FP Methode ist wohl einziges halbweg
135. ammarten f r die Berechnung von Werten und die Definition von Bedingungen eingesetzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 371 Von der OO Analyse zum Software Entwurf Echtesit systeme 7 3 Verfeinerte Verhaltensbeschreibung UML Interaction Diagrams Aufgabe Mit Interaktionsdiagrammen werden die Anwendungsf lle aus Abschnitt 5 2 genauer beschrieben sobald die dabei ben tigten Klassen und ihre Operationen klar sind Die mit Abstand popul rste Form von Interaktjonseiagrammen Interaction Diagrams sind die Sequenzdiagramme andere Formen werden hier nicht worgektellt gt Vorgehensweise zuerst Anwendungsf lle mit textueller Beschreibung oder ggf Aktivit ts diagramme in einfache Sequenzdiagramme bersetzen die Aussenverhal ten eines Systems beschreiben gt dann Systemoperationen in Klassenoperationen zerlegen bei der Fallbeispieldefinition mit Aktivit tsdiagrammen keine Voraussetzung nun mit Sequenzdiagrammen Nachrichtenaustausch innerhalb des Systems mit Betonung des zeitlichen Ablaufs modellieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 372 Von der OO Analyse zum Software Entwurf Echtesit systeme Unser Anwendungsfall makeReservation makeReservation lt lt include gt gt Extension points ER after 4 client not foun after 9 no free vehicle lt lt extend gt gt jf WL lt lt ext
136. ariable name gt lt having clause gt HAVING lt search condition gt wird nicht behandelt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 309 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme Auswertung einer select Anweisung 1 from Klausel im Prinzip wird hier das Kreuzprodukt aller angegebenen Tabellen gebildet ohne bereinanderlegen von Spalten bzw Attributen where Klausel dann werden alle die Tupel der resultierenden virtuellen Tabelle selektiert die die hinter WHERE angegebene Bedingung erf llen sroup by Klausel es werden Tupelgruppen gebildet deren angegebene Spalten werte gleich sind having Klausel schlie lich werden aus den gebildeten Gruppen nur solche aus gew hlt die die hinter HAVING angegebene Bedingung erf llen select Klausel bildet aus der berechneten Tabelle mit Gruppen eine neue Tabelle die je Gruppe ein Tupel enth lt Verdichtung mit Aggregationsfunktionen selektiert alle oder einzelne Spalten und berechnet ggf vollst ndig neue Spaltenwerte aus den Spaltenwerten jeweils eines betrachteten Tupels Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 310 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Beispiel mit Buchern wieder aufgegriffen Autoren Ausleihe ISBN Autor ISBN Name 0 8053 1753 8 Elmasri 0 8053 1753 8 Schmitz 0 8053 1753 8 Navathe 0 8053 1753 8 Derichsweil
137. artbarkeit solange bis die Software nicht mehr nderbar ist Gesetz der zunehmenden Entropie Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 46 Software Technik Was ist das ee gt systeme Portierbare Software Portability Ein System ist portierbar falls es in verschiedenen Umgebungen ohne gro en nderungsaufwand l uft Umgebung Hardware und oder Basissoftware Betriebssystem Fenstersystem Portierbarkeit erreicht man durch LJ Trennung kleiner umgebungsabh ngiger Teile vom Rest des Systems LJ Verwendung standardisierter Programmier Sprachen LJ Verwendung standardisierter weitverbreiteter Betriebssysteme L Verwendung standardisierter Fenstersysteme Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 47 Software Technik Was ist das ee systeme 1 5 Wissensgebiete der Software Technik Der IEEE Computer Society Guide to the Software Engineering Body of Knowledge SWEBOX http www swebox org z hlt folgende Wissensgebiete auf 1 Software Requirements es wird festgelegt was ein Software System leisten soll und warum Software Design das Wie steht nun im Vordergrund der Bauplan Architektur Software Construction gem Bauplan wird das Software System realisiert Software Testing Fehler werden systematisch gesucht und eliminiert Prof Dr Andy Sch rr TU Darmstadt FB 18 In
138. as Eon u Sichere Software Security Software sollte gegen b swillige Fehlbenutzungen und Angriffe abgesichert sein Dabei besteht ein flie ender bergang zwischen der Absicherung eines Software Systems gegen unabsichtliche Ausf lle von Komponenten oder Fehlbedienungen siehe Robustheit und absichtliche Angriffe Dependability als Oberbegriff nach Sommerville So07 Dependability Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 39 Software Technik Was ist das Echtesit systeme Robuste Software Robustness Ein Software System ist robust wenn es auch unter unvorhergesehenen Umstan den funktioniert verniinftig reagiert z B auf zufallige oder beabsichtige Angriffe nicht erwartete Daten so wenige wie m glich erwartete Eingabedaten Programm Auch der Software Entwicklungsprozess sollte robust sein z B gegen Anmerkung Ausfall von Mitarbeitern unvermeidlicher Hardware Betriebssystemwechsel Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 40 Software Technik Was ist das cone ae systeme Interne Qualitatsfaktoren von Software LI Effizienz Efficiency Performance Erweiterbarkeit Extendibility Kompatibilit t mit anderen Komponenten Compatibility Portierbarkeit auf andere Plattformen Portability Wartbarkeit maintenability Wiederverwendbarkeit Reusability Prof Dr Andy Sch
139. as einfacher als Hinzuf gen deshalb weniger FPs LJ man ben tigt modifizierte Regeln f r die Berechnung von FPs f r ge nderte Funktionen ndern L schen Hinzuf gen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 653 Management der Software Entwicklung Eon ES systeme 10 8 Weitere Literatur ACF97 V Ambriola R Conradi A Fugetta Assessing Process Centered Software Engineering Environments ACM TOSEM Vol 6 No 3 ACM Press 1997 S 283 328 Nicht zu alter Aufsatz mit berblickscharakter zum Thema dieses Kapitels Beschr nkt sich allerdings im wesentlichen darauf die drei Systeme OIKOS Ambriola EPOS Conradi und SPADE Fugetta der drei Autoren miteinander zu vergleichen Es handelt sich dabei um Systeme der zweiten Generation die in die sem Kapitel nicht vorgestellt wurden Ba98 H Balzert Lehrbuch der Softwaretechnik Band 2 Software Management Software Qualit tssicherung Unternehmensmodellierung Spektrum Akademischer Verlag 1998 Hier findet man fast alles Wissenswerte zum Thema Management der Software Entwicklung BP84 V R Basili B T Perricone Software Errors and Complexity An Empirical Investigation Communicati ons of the ACM Vol 27 No 1 42 52 ACM Press 1984 Eine der ersten Publikationen zu empirischen Untersuchungen tiber den Zusammenhang von Software komplexit t und Fehlerh ufigkeit Be99 K Beck Extreme Programming Explained
140. asse M V 6120 Auto DA T 4378 Auto preis 30 000 Modell ort M nchen Abbild reale Welt preis 20 000 ort Darmstadt Abstraktion Fachgebiet f Echtzeit A systeme Typ Schnittstelle einer Klasse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 135 Fachgebiet f Grundlagen der objektorientierten Modellierung Echtzeit 3 systeme Klassen und Typen in Java realisiert fat tgs Auto Klasse i i preis Euro implementiert aibres Euro ka VETON Jori Sting j a gibPreis Euro Abstraktion bewege Abstraktion public class Auto implements Verkauflich Beweg lich private Euro preis private String ort public interface Verkauf public interface Beweg lich lich public Euro gibPrei public void be Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 136 Grundlagen der objektorientierten Modellierung Eon A systeme Mehrfachvererbung LJ eine Klasse kann in Java mehrere Interfaces implementieren sie erbt damit quasi die zu implementierenden Operationen Q eine Klasse kann aber in Java nur eine Oberklasse erweitern sie erbt Operationen mit Implementierungen Attribute mit Typdefinition LJ in anderen OO Programmiersprachen kann eine Klasse von mehreren Oberklassen erben man spricht von Mehrfachvererbung U dabei k nnen Vererbungskonflikte auftreten verschiedene M
141. atentechnik Seite 299 Von der OO Analyse zum Datenbank Entwurf Echteeit systeme 6 5 Datenbankprogrammierung mit SQL SQL wurde am IBM San Jose Research Laboratory entwickelt und im Laufe der Jahre auch SEQUEL oder RDL genannt Die Entwicklung von Standard SQL erfolgte in den folgenden Etappen bis Anfang der 80er Jahre Wildwuchs verschiedener Dialekte erste Sprachstandardfestlegung um 1986 endg ltiger Sprachstandard im Jahre 1989 SQL 89 gt in Deutschland als DIN ISO 9075 im Jahre 1990 publiziert Weitere wichtige Etappen im Jahre 1992 wird SQL 92 SQL2 verabschiedet seit Jahre 1999 gibt es SQL 99 SQL3 im wesentlichen heutiges SQL In diesem Abschnitt wird Teilmenge von SQL 89 vorgestellt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 300 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit fp systeme Syntax von SQL DDL Teil 1 als EBNF lt schema gt CREATE SCHEMA lt schema authorization clause gt lt schema element gt lt schema authorization clause gt AUTHORIZATION lt authorization identifier gt lt schema element gt lt table definition gt lt privilege definition gt wird nicht behandelt lt view definition gt wird nicht behandelt lt table definition gt CREATE TABLE lt table name gt lt table element gt lt table element gt y lt table element gt lt column def
142. atentechnik Seite 423 Objektorientierter Softwareentwurf Echteslt systeme Neue Diagrammarten in UML fur die Entwurfsphase L Paketdiagramme zur Modularisierung wie in Java als hierarchisches Dateisystem fiir Programmteile zur Bildung von Bibliotheken Teilsysteme Verteilungsdiagramme Installationsdiagramme Komponenten gt Hardware fasssen Klassen und Konfigurationsbeschreibungen zu verteilbaren und installierbaren Dateien Archiven zusammen beschreiben Struktur der Hardware Bestandteile Verbindungen oder Struktur von Betriebssystemprozessen bestehen aus verteilbaren Software Artefakten sowie aus Hardware Knoten und Verbindungen zwischen Knoten ordnen Artefakte bestimmten Knoten zu Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 424 Objektorientierter Softwareentwurf Echteslt systeme 8 2 Modularer Softwareentwurf mit der UML Package Diagrams Klassen und Paketdiagramme bilden in UML die Basis f r die Zerlegung eines Softwaresystems in Teilsysteme Module und Teilsystemen von Teilsystemen etc LJ Klassen atomare Teilsysteme Bestandteile sind Attribute und Operationen Bestandteile haben Sichtbarkeiten public protected private Pakete in der Analyse komplexe Teilsysteme gt Bestandteile sind Unterpakete oder zusammengeh rige Diagramme realisieren einfach nur hierarchisches Dateisystem Sichtbarkeiten sp
143. atest Schulung nach der Installation werden Benutzer und Betriebspersonal in die Bedienung des Produkts eingewiesen Software f r anonymen Markt separater Vertrieb entsprechender Kurse Inbetriebnahme bergang zwischen Installation und vollem Betrieb dabei ggf Abl sung eines Altsystems direkte Umstellung riskant Altsystem wird stillgelegt alle Daten ber tragen und dann Vollbetrieb des neuen Systems Parallelllauf aufw ndig Altsystem und neues System laufen parallel ihre Daten m ssen dauernd konsistent gehalten werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 572 Fachgebiet Management der Software Entwicklung Echtzeit dp systeme Wartungs und Pflegephase Mit der Einf hrung einer Software in den produktiven Betrieb beginnt die Wartung und Pflege von Software gt unter Wartung versteht man das Beseitigen von Fehlern unter Pflege versteht man die Anpassung und Erweiterung von Software Es gibt aber auch die Unterteilung der Wartung in ca 20 korrigierende Aktivit ten corrective maintenance Behebung von Fehlern und Inkonsistenzen zwischen Implementierung u Lastenheft ca 25 anpassende Aktivit ten adaptive maintenance Anpassung an neue Rahmenbedingungen Portierung auf neue Hardware ca 55 perfektionierende Ma nahmen perfective maintenance Ver besserung der Effizienz und Wartbarkeit der Software Untersuchungen bes
144. bendige Transitionen im Petri Netz Verf gbare PKWs Tankgutscheine Verf gbare Vans R ckgabe Ausgeliehene PKWs Ausgeliehene Vans Anzahl R ckgaben F r die obige Markierung und jede beliebige andere Markierung ist keine Transition lebendig da f r jede der vier Transitionen eine Schaltfolge existiert sodass danach die Transition nie mehr aktiviert werden kann Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 223 Objektorientierte Anforderungsanalyse Echtzeit systeme Petri Netz Beispiel mit Anfangsmarkierung Verf gbare PKWs Tankgutscheine Verf gbare Vans 100 100 1 1 4 10 R ckgabe R ckgabe Ausgeliehene PKWs Ausgeliehene Vans 1 Anzahl R ckgaben Das obige Petri Netz mit der vorgegebenen Anfangsmarkierung ist weder lebendig noch verklemmungsfrei noch tot Es gilt sogar dass das Petri Netz mit keiner m gli chen Anfangsmarkierung lebendig oder verklemmungsfrei ist da jede m gliche Aus f hrung nach einer endlichen Anzahl von Schritten terminiert da keine Transition mehr aktiviert ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 224 Objektorientierte Anforderungsanalyse Eon ES systeme Petri Netz Varianten und Werkzeuge LI die hier vorgestellten Petri Netze sind sehr ausdrucksschwach und eignen sich kaum f r die Modellierung realer Anwendungen Deshalb gibt es viele Vorschl ge
145. beschrieben Verweise auf Glossar Spezialf lle oder oft ben tigte Hilfsfunktionen werden als sekund re Anwendungsf lle wie in Abschnitt 5 2 vorgeschlagen ausgelagert der Zusammenhang von prim ren und sekund ren Anwendungsfallen kann durch weitere Anwendungsfalldiagramme festgehalten werden f r eine pr zisere Beschreibung von Anwendungsf llen k nnen in Einzel f llen Aktivit tsdiagramme eingesetzt werden ggf werden auch die erst in Abschnitt 7 3 eingef hrten Sequenzdiagramme daf r verwendet insbesondere wenn zeitliche Aspekte wichtig sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 249 Objektorientierte Anforderungsanalyse Echtzeit systeme Aufbau eines Pflichtenheftes 4 6 Produktdaten Verfeinerung des entsprechenden Lastenheftkapitels Die l ngerfristig zu speichernden Daten des Systems werden ggf wie im Lastenheft durchnummeriert aus Anwendersicht beschrieben konzeptuelles Datenmodell Dabei werden die Daten mit Mengenangaben entweder gt rein textuell beschrieben wie im Lastenheft wieder Verweise auf Glossar oder in Form von UML Klassendiagrammen mit zus tzlichen Kommenta ren erfasst einfache Variante im Sinne von Abschnitt 5 3 Achtung soll ein sogenanntes ausf hrbares Pflichtenheft mit einem Rapid Prototyp des Softwaresystems erstellt werden so muss ein feineres Klassenmodell im Sinne von Abschnitt 7 1 erstellt werden
146. che Attribute f r Anforderungen LJ Status spiegelt den Zustand einer aufgestellten Anforderung wider z B mit Werten vorgeschlagen abgesegnet umgesetzt LJ Nutzen erwarteter Nutzen einer Anforderung der oft mit der Priorit t gleichge setzt wird z B mit Werten kritisch wichtig n tzlich Aufwand gesch tzter Aufwand f r die Realisierung einer Anforderung z B mit Werten hoch mittel niedrig Risiko Sch tzung der Wahrscheinlichkeit dass es bei Realisierung der Anforde rung zu un erwarteten unerw nschten Problemen kommt die Projekt gef hrden Stabilit t Sch tzung der Wahrscheinlichkeit dass sich diese Anforderung im Pro jektverlauf noch ndern wird z B mit Werten hoch mittel niedrig Release Angabe des Releases Produktgeneration die die Anforderungen reali sieren soll Grund Verweis auf eine Quelle die begriindet warum die Anforderung aufge stellt wurde bzw welcher konkreter Nutzen mit ihrer Realisierung verbunden ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 86 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit u systeme Beispiel Kundenbeschreibung eines Software Produkts Motor Vehicle Reservation System MVRS A rental office lends motor vehicles of different types The assort ment comprises cars vans and trucks Vans are small trucks which may be used with the same driving licens
147. chuerr Zahlen Datei i 1 while not eof a do n read a Feld i i i 1 nd 1 1 open b usr schuerr Zahlen Datei fori 2toldo begin for j downto i do fFeld j 1 gt Feld j then begin k Feld j 1 Feld j 1 Feld j Feld j k end write b Feld i 1 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 33 r s Fachgebi Software Technik Was ist das ES systeme Bewertung des Sortierprogramms nicht leicht verst ndlich da Kommentare fehlen Variablenbezeichner nichtssagend nicht korrekt robust da Programm f r Dateien mit mehr als 10 Elementen abst rzt nicht effizient da gt realisierter Sortieralgorithmus quadratischen Aufwand hat nicht portierbar da Dateinamenskonventionen von Unix im Quelltext auftauchen dieselbe Datei mehrfach ge ffnet wird geht nicht immer nicht wiederverwendbar da Dateinamen fest verdrahtet sind ebenso maximale Dateil nge und zu sortierende Elemente Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 34 Software Technik Was ist das Ee systeme Korrektheit von Software Correctness Ein Software System ist funktional korrekt wenn es sich genauso verh lt wie es in der Anforderungsdefinition festgelegt wurde Korrektheit ist also relativ pr zise Anforderungs Problem definition korrekt
148. cklung Echte die systeme Planung von Arbeitspaketabh ngigkeiten kritische Pfade u Aufgaben A 16 E 33 Listen aufbau A 34 E 43 Anfrage operationen 6 Tage A 44 E 53 A 54 E 63 Integration W Systemtest p gt Abnahme A 34 E 43 4 10 Tage Update g operationen A 34 E 53 A 16 E 32 n 10 Tage Benutzer g Online Hilfe oberflache iS Tage 18 Tage A 34 E 53 40 Tage A 1 E 10 A 11 E 15 A 16 E 33 Datenbank I Analyse _ schema 10 Tage N J 10 Tage Manual 20 Tage Berechnung kritischer Pfade mit kritischen Aufgaben f r kritische Aufgabe gilt fr heste Anfangszeit Dauer sp teste Endzeit 1 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 619 Management der Software Entwicklung Eon ES systeme Zusammenfassung der Berechnung LI Vorw rtsberechnung fr hester Anfangszeiten f r Aufgaben fr heste Anfangszeit erster Aufgabe 1 fr heste Anfangszeit von Folgeaufgabe Maximum fr heste Anfangszeit Dauer einer Vorg ngeraufgabe R ckw rtsberechnung sp tester Endzeiten f r Aufgaben gt sp teste Endzeit letzter Aufgabe fr heste Anfangszeit Dauer 1 sp teste Endzeit von Vorg ngeraufgabe Minimum sp teste Endzeit Dauer einer Nachfolgeraufgabe kritische Au
149. cklung und Anwendung von umfang reichen Software Systemen Zielorientiert bedeutet die Beriicksichtigung z B von Kosten Zeit Qualit t Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 28 Software Technik Was ist das Echtesit systeme Definition des Begriffs Software Techniker Software Ingenieur Software Techniker Entwickler ist nach GJM91 A software engineer must of course be a good programmer be well versed in data structures and algorithms and be fluent in one or more programming lan guages The software engineer must be familiar with several design approaches be able to translate vague requirements and desires into precise specifications and be able to converse with the user of a system in terms of gt D application rather than computeres Daraus folgende notwendige F higkeiten Q Kommunikation auf verschiedenen Abstraktionsebenen LJ Kommunikation mit Personen mit unterschiedlichen Vorstellungen Ausbildungen Q Arbeitsplanung und koordination U Erstellung und Verwendung von Modellen Spezifikationen unser Schwerpunkt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 29 Fachgebiet Software Technik Was ist das Echtzeit systeme Ethische Regeln und professionelles Verhalten des Software Entwicklers Pr ambel verk rzt Software Entwickler sollen sich verpflichten Analyse Spezifi
150. ct from where select bestimmt Projektionen auf Spalten mehrer Relationen Tabellen from legt zu verwendende Basis Relationen fest where definiert Selektions und Verbundbedingungen group by Auswertungen auf Untergruppen Summenbildung having Selektionsbedingungen f r Bildung von Untergruppen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 308 Von der OO Analyse zum Datenbank Entwurf Een systeme Syntax der select Anweisung SFW Block lt SFW block gt SELECT ALL DISTINCT lt select list gt lt table expression gt Zuweisung mit INTO in Variablen einer Programmiersprache wird nicht behandelt lt select list gt lt value expression gt lt value expression gt lt value expression gt lt column specification gt komplizierte Ausdr cke zugelassen lt table expression gt lt from clause gt lt where clause gt lt group by clause gt lt having clause gt lt from clause gt FROM lt table reference gt lt table reference gt lt table reference gt lt table name gt lt variable name gt lt where clause gt WHERE lt search condition gt wird nicht behandeltn lt group by clause gt GROUP BY lt column specification gt lt column specification gt lt column specification gt lt qualifier gt lt column name gt lt qualifier gt lt table name gt lt v
151. dass jede Transition jedes Statecharts des Produktautomaten bei and Zust nden mindestens einmal schaltet Achtung Auswahl von Eingabewerten schwierig f r Objekte als Operationsparameter z B quivalenzklassenbildung mit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 555 Qualit tssicherung und Testverfahren Echtzeit ed systeme Auswahl von Testeingaben fur countVowels PROCEDURE countVowels s Sentence VAR count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot E Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 556 Qualitatssicherung und Testverfahren Echizeit 3 systeme 9 6 Der Testprozess als Bestandteil des Wasserfallmodells Machbarkeits zur Erinnerung studie Anforderungs analyse System entwurf Entwicklungszeit Auslieferung amp Akzeptanztest f Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 557 Qualit tssicherung und Testverfahren Echtzeit systeme Der Testprozess isoliert betrachtet durch Entwickler Testabteilung Komponententest Prozedur Subsystemtest durch Entwickler Testabteilung Klasse Integrationstest durch Entwickler Testabteilung system i Hier nur Testen von Code und nicht Testen von UML Modellen betrachtet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Daten
152. der Gro en im Bereich der Verbesserung von Softwareentwicklungsprozessen Seine B cher und Aufs tze sind durchweg empfehlenswert f r die Fortbildung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 51 Software Technik Was ist das ee systeme IEE83 IEEE Standard Glossar of Software Engineering Terminology IEEE Standard 729 EEE Computer Society Press 1983 Der Titel sagt bereits alles Ka98 B Kahlbrandt Software Engineering Objektorientierte Software Entwicklung mit der Unified Modeling Language Springer Verlag 1998 Mit das Buch das vom Inhalt her dieser Vorlesung am n chsten steht Der Schwerpunkt liegt auf dem Ein satz von UML allgemeinere Themen wie Kostensch tzung und Testen werden daf r ausgeklammert H M Sneed Software Management M ller GmbH 1987 Quelle zum Teufelsquadrat Abh ngigkeit von Kosten Qualit t Quantit t und Entwicklungszeit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 52 Vorgehensmodelle der Software Entwicklung Echte die systeme 2 Vorgehensmodelle der Software Entwicklung Themen dieses Kapitels Lebensabschnitte der Software Entwicklung und Alterung das traditionelle Vorgehensmodell zur Software Entwicklung LI wichtige Begriffe wie Lastenheft Anforderungsdefinition Merke Voraussetzung f r den sinnvollen Einsatz von Notationen und Werkzeugen
153. der hier vorgestellten lokalen Optimierungsma nahmen Tate B A Bitter Java Manning Publications 2002 350 Seiten Buch zum Thema Bad Smells bei der Java Programmierung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 526 Qualit tssicherung und Testverfahren Echtecit systeme 9 Qualitatssicherung und Testverfahren Themen dieses Kapitels O bersicht ber Softwarequalit tssicherungsma nahmen LJ Fehlersuche als ein Mittel unter vielen zur Qualit tsverbesserung LJ systematische Verfahren zur Fehlersuche U Einfluss von UML Modellen auf die Fehlersuche Achtung Dieses Kapitel lehnt sich an Teil III von Ba98 und an Teil 5 von So01 an gibt aber nur eine kurze Zusammenfassung der dort angesprochenen Themen Weiteres zum Thema Testen als ein Mittel der Qualitit tssicherung in der Vorlesung Software Engineering II F r umfassende Informationen zum Thema Testen objektorientier ter Systeme wird auch B199 empfohlen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 527 Qualit tssicherung und Testverfahren Echtzeit Mich systeme 9 1 Softwarequalit tssicherung im berblick Zur Erinnerung Das Ziel der Software Technik ist die Bereitstellung von Methoden Sprachen und Werkzeugen zur effizienten Entwicklung messbar qualitativ hochwertiger Software die korrekt bzw zuverl ssig arbeitet vertrauensw rdig i
154. dertes Videoverleih Programm Ausschnitt Movie getTitle String getCharge double getFRP iint MovieState getCharge double getFRP int Objektorientierter Softwareentwurf RentalComponent _dateRange String RentalComponent getDateRange String getCharge double getFRP int Q lt lt Leaf gt gt RentalLeaf _movie Movie _daysRented int _charge double _frequentRenterPoints int RentalLeaf getMovie Movie getCharge double getFRP iint RentalComposite RentalComposite getCharge double getFRP int addChild void iterate Rentallterator first Index next Index current Rentallterator Videoshop _instance Videoshop Videoshop getInstance Videoshop Fachgebiet Echizeit systeme VisitedElement Customer Customer getRental RentalComponent getName String printStatement String htmlStatement String getCharge double getFRP int Rentallterator _current Index Rentallterator first void next void current RentalComponent isDone boolean Index _current ist entweder Zahl Index f r Vector oder Zeiger auf nachste RentalComponent Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 485 Objektorientierter Softwareentwurf Eon A systeme Aufbau eines Entwurfsmusters in Anlehnung an GH 94 E E E E E E E E E O O E Name Synonyme Namen unter denen das Muster bekannt ist Klassifikation Einordnung in vorgest
155. det man nur asynchrone Signale und synchrone Operationsaufrufe Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 377 Von der OO Analyse zum Software Entwurf Echtzeit ip systeme Genauere aber eher un bliche Sequenzdiagrammdarstellung or UML Standard Edition TU Er Diese Darstellung werden wir im Folgenden nicht weiter verwenden sondern die Lebenslinien aktiver Objekte immer durchgehend dick darstellen findClient cn findClient theClient findVehicles p c findVehicles vs Aktive Objekte leihen ihre dicke Lebenslinie beim Aufruf von Operationen an passive Objekte aus W hrend der DB Operationsaufrufe oben kann ja das MVRS Objekt nichts anderes machen und ist deshalb zeitweise nicht aktiv Das wird hier korrekt durch gestrichelte Lebenslinie dargestellt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 378 Von der OO Analyse zum Software Entwurf a u Echizeit a systeme z Grafisch einfachere Darstellung von Operationsaufrufen Visual T for UML Standard Edition TU Darmst aClerk Clerk makeReservation getClient theClient Client theClient findClient cn returnClient cn return Pfeile getPeriod von Operations aufrufen werden en nicht dargestellt getCategory returnCategory c vs findVehicles p v selectVehicle vs returnSelectedVehicle v r addReservation cn p c v sendMail
156. die Elemente von Aggregate die bei einem Durchlauf zur ck gegeben werden Iterator Objekte dieser Klassen merken sich den Stand der Iteration sodass mit den zur Verf gung stehenden Methoden von Aggregate eine unterbrochene Iteration jederzeit wieder fortgesetzt werden kan Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 489 Objektorientierter Softwareentwurf Echteslt systeme Fortsetzung des lterator Entwurfsmusters LJ Kollaboration hier textuell definiert und nicht als Sequenzdiagramm 1 Mit der Methode iterate wird neuer Iterator zu einem Aggregate Objekt erzeugt Sie liefert ein Iterator Objekt als Ergebnis das auf Aggregate zeigt Der Durchlauf durch alle Elemente des Aggregats wird mit dem Aufruf von first auf dem Iterator Objekt gestartet es wird dabei _current first auf Aggregate aufgerufen und dabei Attribut _current f r erstes Element gesetzt Mit current auf Iterator Objekt fordert man das aktuelle Element an hierf r wird current _current auf Aggregate aufgerufen was das aktuelle Element Objekt zur ckliefert gibt es kein weiteres Objekt mehr so wird das null Objekt zur ckgegeben Mit next Aufruf auf Iterator Objekt wird _current next _current Aufruf auf Aggregate ausgel st und somit der Index auf n chstes Element des gesetzt Anmerkung wird Aggregat als Array Vector realisiert so ist Index eine Zahl die durch next jeweils um eins hochgez hlt
157. dt FB 18 Institut f r Datentechnik Seite 131 Grundlagen der objektorientierten Modellierung one ipo systeme Dynamisches Binden LJ in polymorphen funktionalen Sprachen wird derselbe Programmcode f r Eingabe parameter unterschiedlicher Typen abgearbeitet kein dynamisches Binden U bei objektorientierten Sprachen kann ein bestimmter Operationsaufruf in jeder erbenden Unterklasse durch eine v llig andere Methode implementiert sein die klassenabh ngige Auswahl einer bestimmten Implementierungsmethode zu einem Operationsaufruf zu einer empfangenen Nachricht zur Programmlaufzeit nennt man dynamisches Binden im Gegensatz dazu wird die Auswahl einer bestimmten Prozedur aus einer Menge gleichbenannter Prozeduren zur bersetzungszeit Overloading genannt anhand der Aktualparametertypen Beispiel der Operator kann auf integer cardinal float realisiert sein Der bersetzer entscheidet anhand der Aktualparameter welchen Maschinencode er f r das erzeugen muss Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 132 Grundlagen der objektorientierten Modellierung Echtecit systeme Beispiel fur dynamisches Binden Pseudocode einePerson Mitarbeiter oder Chef inrEinkommen einePerson gibEinkommen Realisierung in imperativer Sprache einePerson Mitarbeiter oder Chef case einePerson Typfeld of Mitarbeiter inrEinkommen einePerson Gehalt
158. e Analysen von Petri Netzen weitere Begriffe Eine Transition t in einem Petri Netz ist f r eine Markierung m tot wenn von m aus keine Markierung m erreicht werden kann f r die t aktiviert ist Eine Transition t in einem Petri Netz ist f r eine Markierung m lebendig wenn sie f r keine von m aus erreichbare Markierung m tot ist damit ist lebendig eine st rkere Forderung als nicht tot tist f r m nicht tot es ist irgendeine Markierung von m aus erreichbar f r die t aktiviert ist tist lebendig f r m f r alle von m aus erreichbaren Markierungen m gibt es eine von m erreichbare Markierung m sodass t aktiviert ist Eine Markierung m eines Petri Netzes ist lebendig tot wenn alle seine Transitionen lebendig tot sind Eine Markierung m ist verklemmungsfrei wenn keine von m aus erreichbare Markierung m tot ist Ein Petri Netz ist lebendig tot verklemmungsfrei wenn seine Anfangsmarkierung lebendig tot verklemmungsfrei ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 220 Objektorientierte Anforderungsanalyse Eon A systeme Anmerkungen zu Petri Netz Eigenschaften LJ Sind mehrere Transitionen in einem Petri Netz aktiviert so feuert irgendeine davon nichtdeterministische Entscheidungen Die daraus resultierende nderung der Belegung von Pl tzen mit Marken kann dazu f hren dass bislang aktivierte konkurrierende Transition
159. e Erlauterungen zu Sequenzdiagrammen LJ Sie beschreiben den zeitlichen Ablauf der Kommunikation von mehreren Objek ten die Lebenszeit der Objekte wird durch vertikale Lebenslinien definiert Aktive Objekte alle im vorigen Beispiel haben einen durchgehenden dicken Bal ken als Lebenslinie und in als Kasten doppelte vertikale Linien externe Akteure eines Systems sind immer aktive Objekte Die Reihenfolge der Nachrichten horizontale Pfeile zwischen zwei Lebenslinien in vertikaler Richtung bestimmt die Reihenfolge ihrer Abarbeitung Pfeile mit offener Pfeilspitze stellen Nachrichten dar die als asynchrone Signale von einem Sender zu einem Empf nger geschickt werden Sender ist nicht blok kiert bis ein Ergebnis beim Empf nger berechnet und zur ckgeschickt worden ist Pfeile mit geschlossenen Pfeilspitzen stellen Nachrichten dar die als synchrone Aufrufe des Senders von Operationen des Empf ngers realisiert sind In diesem Fall ist der Sender blockiert bis die Operation ausgef hrt wurde Achtung die Nachrichten bertragung ist hier in der Vorlesung immer zeitlos schr g verlaufende Nachrichtenpfeile defnieren zeitbehaftete Kommunikation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 375 Von der OO Analyse zum Software Entwurf ee systeme z Sequenzdiagramm mit passivem internen Objekt Visual pq for UML Standard Edition TU Darmst aClerk Clerk makeReservation theClient
160. e in allen Kombinationen durchlaufen C1 und C2 k nnen also auch auf das selbe Objekt verweisen f r alle Kombinationen wird der Ausdruck hinter berpr ft der Ausdruck forAll c1 c2 c1 lt gt c2 implies c1 name lt gt c2 name berpr ft ob f r alle Paare verschiedener Kunden C1 ungleich C2 deren Namen ungleich sind der Ausdruck exists c1 c2 c1 lt gt c2 and c1 name c2 name berpr ft ob es ein Paar verschiedener Kunden gibt bei denen die Namen gleich sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 363 Von der OO Analyse zum Software Entwurf Echtzeit ec systeme Weitere OCL Features Standarddatentypen Integer Float und String L Standarddatentyp Integer die Konstanten 0 1 1 sind mit den blichen Operatoren darauf definiert abs lt L Standarddatentyp Float die Konstanten 0 0 1 1 1 1 sind mit den blichen Operatoren darauf definiert absQ lt Standarddatentyp String Konstanten der Art ich bin ein String sowie die folgenden Operatoren sind definiert s1 concat s2 konkateniert zwei Strings s1 size gibt die L nge eines Strings zur ck S1 substring i1 i2 gibt den entsprechenden Teilstring zur ck dabei muss 1 lt 11 lt I2 lt 1 size gelten sonst wird Ergebnis undefiniert selbst definierte Aufzahlungstypen wie Colour mit den Literalen white k n nen in
161. e Machines Statecharts von Harel LJ erweiterte Zustandsdiagramme mit zusammengesetzten Zust nden nebenl ufigen Teildiagrammen ein Diagramm wird immer genau einer Klasse zugeordnet jede Klasse besitzt h chstens ein Diagramm sie werden oft zur Implementierung von Objektverhalten benutzt werden interpretativ ausgef hrt oder in Quellcode bersetzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 391 Von der OO Analyse zum Software Entwurf Echtesit systeme Statechart mit zusammengesetztem Zustand create fulfill Initial a a Transition aus ition i allen Unterzu setClient a Anfangs standen Endzustand zustand Incomplete xor state WithPeriod WithClient WithCategor confirm Lebenszyklus eines ReservationContract Objektes mit Oberzustand Incomplete der Unterzust nde besitzt Immer genau einer der Unterzust nde von Incomplete ist aktiv deshalb wird der Zustand xor Zustand genannt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 392 Von der OO Analyse zum Software Entwurf Echtesit systeme Elimination von Anfangs und Endzustanden von xor Zustand create fulfill Initial u Incomplete setClient confirm WithPeriod WithClient WithCategor Die Transition in den Anfangszustand wurde auf den ersten richtigen Zustand umgelenkt die Transition aus dem Endzustand geht nun vom letzten
162. e Vererbungshierarchie Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 116 Grundlagen der objektorientierten Modellierung Echte d systeme Weitere Essentials der Objektorientierung Objekte besitzen eine unver nderliche Identit t Objekte besitzen einen ver nderlichen Zustand Objekte besitzen ein dynamisches Verhalten Objekte sind Abstraktionen der realen Welt Objekte verkapseln ihren internen Zustand Objekte besitzen einen polymorphen Typ dynamisches Binden Objekte k nnen nebenl ufig aktiv sein Objekte k nnen persistent sein dauerhaft gespeichert Oder nach Roger King My cat is object oriented After all a cat exhibits characteristic behavior responds to messages is a heir of a long tradition of inherited responses and manages its own quite independent internal state Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 117 u jektorienti ieru Echuet P Grundlagen der objektorientierten Modellierung systeme Konkrete und abstrakte Objekten Problemgebiet konkrete Objekte der realen Welt Abstraktion von N u la Details deskriptive Modelle der realen Welt pr skriptive Modelle der Implementierung Abstraktion von Implementierung details konkrete Laufzeitobjekte im Programm i Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 118 Grundlagen der objekto
163. e as cars Some client may reserve motor vehicles of a certain category for a certain period He or she has to sign a reservation contract The rental office guaran tees that a motor vehicle of the desired category will be available for the requested period The client may cancel the reservation at any time When the client fetches the motor vehicle he or she has to sign a rental contract and optionally an associated insurance contract Within the reserved period at latest at its end the client returns the motor vehicle and pays the bill Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 87 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit po systeme Probleme mit der Kundenbeschreibung LI sie enth lt keine Aussagen dar ber warum der Kunde genau den skizzierten Gesch ftsprozess durch Software unterst tzen will z B weil Reservierungen bereits fters vergessen wurden Wartungsintervalle berschritten wurden sie enth lt undefinierte Begriffe unter denen Auftragnehmer und Auftraggeber sich m glicherweise unterschiedliches vorstellen z B assortment category sie enth lt m glicherweise irrelevante Aussagen z B Vans are small trucks which may be used with the same driving licence as cars sie ist noch sehr unvollst ndig z B ist unklar was passiert wenn Fahrzeuge nicht rechtzeitig zur ckgegeben werden Fahrzeuge trotz Reservierung nicht
164. e beiden Assozationsenden Rollen einer Assoziation k nnen die gleichen Eigen schaften wie Attribute besitzen Reservation client contract Contract readonly unique ordered isBossOf readonly Links dieser Assozation d rfen beim Objekt auf der anderen Seite der readonly Rolle nur bei der Initialisierung des Objektes angelegt und nur mit Objekt zusammen gel scht werden LJ unique ist diese Eigenschaft an einem der beiden Assoziationsenden angegeben so darf es keine parallelen Links geben also keine zwei Links zwischen dem selben Objektpaar ordered aus Sicht des Objektes an der anderen Seite des betroffenen Assozations endes ist die Menge der ausgehenden Links geordnet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 206 Objektorientierte Anforderungsanalyse Echtzeit systeme Kombinationen von unique und ordered unique true und ordered true es handelt sich um eine Liste von Elementen die jeweils nur einmal in der Liste auftreten d rfen sequence unique true und ordered false es handelt sich um eine Menge set unique false und ordered true es handelt sich um eine Liste im blichen Sinne unique false und ordered false es handelt sich um eine Kollektion deren Elemente ungeordnet sind und mehrfach auftreten d rfen bag Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 207 Fachgebiet Ob
165. e darf die Vorbedingungen f r geerbte Methoden aufweichen aber nicht einschr nken Methoden m ssen unter den geerbten Vorbedingungen weiterhin aufrufbar sein eine Unterklasse darf die Nachbedingungen f r geerbte Methoden versch rfen aber nicht aufweichen Methoden m ssen die Nachbedingungen geerbter Methoden weiterhin erf llen es werden dabei zus tzliche Eigenschaften der Ausgabewerte oder Attributwerte nach Ausf hrung der Methode festgelegt Initialisierungen von Eigenschaften eines Objekts sind wie Nachbedingungen von Konstruktoren zu behandeln Ausdr cke f r abgeleitete Eigenschaften Attribute und Assoziationen sind wie Invarianten von Klassen zu behandeln Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 358 Fachgebiet Von der OO Analyse zum Software Entwurf Echtzeit i systeme Zul ssige Verfeinerung von OCL Bedingungen bei Vererbung context Client1 incrementFrequentRenterBonus bonus Integer Integer Clienti sei eine direkte Unterklasse von Client pre bonus gt 0 and currentBonus bonus lt 100 mit bonus 0 soll nun Bonus auf 0 zur ckgesetzt werden zus tzlich d rfen Client1 Objekte Bonus bis 100 besitzen if bonus 0 then current Bonus 0 f r neu erlaubten Parameter Wert neue Nachbedingung else currentBonus bonus currentBonus pre post result currentBonus context Client1 inv age gt 21 weitergehende Einschr nk
166. e initial Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 413 Von der OO Analyse zum Software Entwurf Ehe N systeme 7 5 Zusammenfassung Planung Kundenanforderungen Anwendungsf lle z B als Lastenheft gt UML Use Cases siehe Abschnitt 3 3 iehe Abschnitt 5 2 siehe Abschnitt 5 2 Workflow Modell UML Activity Diagrams Analyse i i konzept Datenmodell siehe Abschnitt 5 5 UML Class Diagrams siehe Abschnitt 5 3 feines Verhaltensmodell UML Interaction Diag siehe Abschnitt 7 3 feines Klassenmodell Class Diagram mit Ops siehe Abschnitt 7 1 reaktives Verhalten UML State Machines siehe Abschnitt 7 4 Analyse gt Design Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 414 Von der OO Analyse zum Software Entwurf Echtzeit ich systeme Konsistenzbedingungen zwischen Diagrammen LJ Klassendiagramm lt gt Objektdiagramm jedes Objektdiagramm ist zul ssige Instanz des zugeh rigen Klassendiagramme LJ Klassendiagramm lt gt Sequenzdiagramm jede Operation muss bei der richtigen Klasse richtig deklariert sein Sequenzdiagramm lt gt Zustandsdiagramm Statechart Operationsfolgen des Sequenzdiagramms sind zul ssig im Zustandsdiagramm Ausf hrungen von Zustandsdiagrammen sollten alle beschriebenen Abl ufe von Sequenzdiagrammen erzeugen k nnen Klassendiagramm lt gt Zustandsdiagramm S
167. e oder Partition l st aus und nutzt lt lt primary gt gt ae Anwendungsfall lt lt include gt gt lt lt secondary gt gt _ Hilfsanwendungsfall lt lt primary gt gt Anwendungsfall ausl sender Akteur Generalisierung auf N lt lt extend gt gt Aktivierungsbedingung Generalisierung auf N Anwendungsfallen Akteuren ebenfalls beteiligt Spezialisierung lt lt secondary gt gt a Ausnahmeanwendungsfall lt lt secondary gt gt fur Anwendungsfall zusatzlicher Akteur Es handelt sich um eine ziemlich vollst ndige Aufz hlung aller UML Sprachelemente die in Anwendungsfalldiagrammen benutzt werden k nnen Die Unterscheidung von prim ren und sekund ren Akteuren und Anwendungsf llen wird dabei eher selten verwendet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 183 Objektorientierte Anforderungsanalyse Eon eo systeme 5 3 Produktdatenmodellierung UML Object Class Diagrams Aufgabe Ausgehend von den Produktdaten im Lastenheft oder einer Flie textbeschreibung des Softwareprodukts und den Anwendungsf llen wird ein konzeptuelles Daten modell Dom nenmodell des Anwendungsbereiches erstellt Es handelt sich dabei nicht um das interne Datenmodell des sp ter realisierten Softwareproduktes Vorgehensweise Bestimmung von Objekt bzw Klassenkandidaten mit verschiedenen Methoden Unterstreichungen im Text Akteure Glossar Bestimmung wichtiger Asso
168. e zum Software Entwurf Echtesit systeme Kochrezept f r die bersetzung von And Oberzustand in Produktautomat 1 Es wird das Kreuzprodukt der Zust nde aller Regionen des And Oberzustandes gebildet also alle m glichen Kombinationen der Unterzust nde F r jeden neuen Zustand z4 Z und alle m glichen Signale s wird berpr ft ob es genau eine Transition mit Aufschrift s b a von z nach z gibt Wurde in Schritt 2 eine solche Transition gefunden dann wird neue Transition mit Aufschrift s b a von Z Z Zp nach Z Z Zp eingef hrt Wenn in Schritt 2 mehrere solche Transitionen gefunden wurden dann werden mehrere Urzust nde im Tupel Z4 Zi Z ausgetauscht werden f r alle m gliche Kombinationen der Bedingungen b neue Transitionen angelegt lt gt werden die Aktionen ai der urspr nglichen Transitionen mit wahren Bedin gungen b in irgendeiner Reihenfolge als Gesamtaktion ausgef hrt Zum Abschluss werden nicht erreichbare Kreuzprodukt Zust nde eliminiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 403 Von der OO Analyse zum Software Entwurf one AS systeme Regeln f r die Gestaltung von Statecharts U Objekteigenschaften mit gr erem Wertebereich nicht in Zust nden halten Alter eines Autos Gehaltsstufe einer Person L Teildiagramme mit mehr als 5 bis 7 Zust nden vermeiden durc
169. echnik Seite 197 Objektorientierte Anforderungsanalyse Echtzeit systeme Aufz hlungen und andere primitive Typen als Klassen dargestellt lt lt enumeration gt gt lt lt primitive gt gt Colour Name prename String surname String lt lt primitive gt gt String LJ Aufz hlungen enumerations werden wie normale Klassen mit einem besonderen Stereotyp lt lt enumeration gt gt dargestellt F r die Definition der Literale der Auf z hlung wird der Attributbereich missbraucht Q Einfache Datentypen wie Integer oder Stringn werden als existent vorausgesetzt oder k nnen als Klassen mit Stereotyp lt lt primitive gt gt eingef hrt werden LJ Datentypen mit interner Struktur S tze records k nnen als primitive Typen eingef hrt werden Attribute werden zur Definition der Komponenten verwendet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 198 Objektorientierte Anforderungsanalyse Echtzeit systeme Identifikation von Assoziationen Assoziationen sind in aller Regel zweistellige Relationen zwischen Klassen Ihre Instanzen sind Links die Instanzen der vorgebenen Klassen verbinden In erster Linie sind solche Assoziationen aufzuf hren die nicht nur tempor r w hrend der Abarbeitung einer Operation Systemfunktion existieren Kandidaten f r Assoziationen U A ist ein logischer physikalischer Teil von B Client Company A berwacht besitzt B RentalOffice
170. ef hrt werden Q Minimalkriterium da nicht mal alle Kanten des Kontrollflussgraphen OQ Nstart traversiert werden 6 Ninit count 0 i 0 Q viele Fehler bleiben unentdeckt Awhile WHILE s i DO Beispiel Nit IF slil a OR U bei countVowels gen gt als Test fall ein konsonantenfreier Satz wie etwa a Ncount 1 Count count 1 nicht betrachtet U Verschiebung von i i 1 in if Anweisung hinein w rde nicht als Fehler entdeckt i 1 Nfinal Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 552 Qualit tssicherung und Testverfahren ati systeme Kontrollflusstest Zweig berdeckung C Test Jede Kante des Kontrollflussgraphen muss mindestens einmal ausgef hrt werden realistisches Minimalkriterium umfasst Anweisungs berdeckung count 0 i 0 Fehler bei Wiederholung oder anderer Kombination von Zweigen WHILE s i DO bleiben unentdeckt IF s i a Beispiel LJ Testfall ab f r countVowels Neount 1 Count 1 w rde Kriterium bereits erf llen LJ Zuweisung count 1 w rde nicht als fehlerhaft erkannt ist A T Nfinal LJ ebenso nicht die verk rzte Bedingung s i a Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 553 Qualit tssicherung und Testverfahren Eon ES systeme Funktionstestverfahren Black Box
171. egistrierung von Fahrzeugen Orientierung an Phasen oder Notationen der Software Entwicklung Beispiel f r Phasenorientierte Sichten Philips Research Customer View Gesch ftsmodelle Marktsituation des Kunden Application View Anforderungen aus Sicht einzelner Interessentengruppen Functional View pr zise Beschreibung der gew nschten Funktionen Conceptual View Einschr nkungen f r das Design der Software Realization View Einschr nkungen f r die Realisierung der Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 80 Requirements Engineering und Machbarkeitsstudie Eon A systeme Brainstorming Workshop zur Ermittlung von Anforderungen Alle von dem Software Produkt betroffenen Personengruppen beim Auftraggeber und beim Auftragnehmer werden zu einem Workshop f r ein bis zwei Tage zusammenge rufen Der Workshop hat folgende Phasen U vorab wird Material zur Vorbereitung Einstimmung verschickt LJ zun chst werden Ideen f r Anforderungen Funktionen gesammelt Ideen auf Zettel an Wand geheftet Kritik an ge usserten Ideen verboten gt wilde Ideen ausdr cklich erw nscht Erg nzungen Kombinationen von Ideen erw nscht dann werden Ideen gruppiert und irrelevante Ideen aussortiert und so die gew nschten Funktionen des Software Produkts bestimmt schlie lich werden die ermittelten Funktionen nach Priorit ten sortiert durch Abstimmungspr
172. eine Rolle wie bewertet man geerbten Code einer Klasse gt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 550 Qualit tssicherung und Testverfahren Eon ES systeme 9 5 Dynamische Testverfahren Die zu betrachtende Komponente Operation Klasse Paket Gesamtsystem wird mit konkreten Eingabewerten ausgef hrt und ihr Verhalten wird dabei beobachtet Im Wesentlichen lassen sich dabei folgende Alternativen unterscheiden LJ Strukturtest white box test die interne Struktur der Komponente oder ihrer UML Spezifikation wird zur Testplanung und berwachung herangezogen kontrollflussbasiert Ablaufverhalten von Operationen wird untersucht datenflussbasiert Variablenzugriffe setzen lesen stehen im Vordergrund werden im Folgenden nicht genauer betrachtet zustandsbasiert Zust nde u Transitionen einer Klasse werden betrachtet LJ Funktionstest black box test die interne Struktur der Komponente wird nicht betrachtet getestet wird Ein Ausgabeverhalten gegen Spezifikation z B Sequenzdiagramm aus Anwendungsfallbeschreibung oder gt OCL Ausdruck der als Nachbedingung Operationsverhalten beschreibt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 551 Qualit tssicherung und Testverfahren Echtzeit systeme Kontrollflusstest Anweisungs berdeckung Cy Test Jeder Knoten des Kontrollflussgraphen muss mindestens einmal ausg
173. einer OO Sprache ohne Methoden LJ Einfache Relationships entsprechen Zeigerpaaren LJ Attribute entsprechen Attributen Name MotorVehicl Number public class Client public class Motorvehicle private int number private Client InkRevRents private String name private Motorvehicle InkRents Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 109 Grundlagen der objektorientierten Modellierung Eonze EX systeme Beispiel eines einfachen Datenflussdiagramms reserveVehicle Reservation ErrorMessage Client period Reservierung Name hat nicht geklappt getClientNo selectVehicle Vehicle Category Contract DB Period VNo CINo Vehicle DB mkReservation Legende Datenbank en Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 110 Grundlagen der objektorientierten Modellierung Een ES systeme Erl uterungen von Datenflussdiagrammen LJ sie eignen sich gut f r die Beschreibung des Aufbaus eines Systems das aus Kom ponenten besteht die ber Verbindungen miteinander kommunizieren LI f r die Beschreibung von Berechnungsabl ufen ist ihre Bedeutung Semantik aber nicht klar genug definiert gt M ssen alle in einen Prozess einlaufenden Datenfl sse mit Daten belegt sein bevor der Prozess rechnen kann Liegen auf den Datenfl ssen immer Daten an oder werden Signale ver schickt die bei Berechnungen konsumier
174. eite 318 systeme Von der OO Analyse zum Datenbank Entwurf Echtzeit Beispiele fur SQL Einfugeoperationen INSERT INTO Bucher VALUES 3 486 25053 1 Datenbanksysteme Oldenbourg die Anweisung f gt in die Tabelle Bucher eine neue Zeile mit vollst ndiger Ang abe aller Spaltenwerte ein INSERT INTO B cher ISBN Titel VALUES 3 486 25053 1 Datenbanksysteme die Anweisung gt f gt in die Tabelle B cher eine neue Zeile ein setzt bei den Spalten ISBN und Titel die angegebenen Werte ein gt und setzt f r die verbleibende Spalte den Defaultwert oder NULL ein INSERT INTO Buchexemplare ISBN Nummer SELECT ISBN 1 FROM B cher die Anweisung erzeugt f r jedes bekannte Buch ein Exemplar mit Nummer 1 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 319 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit u systeme Beispiele f r Delete und Update Anweisungen DELETE FROM Ausleihe WHERE Name Bond die Anweisung l scht alle Ausleihe Eintr ge der Person mit Namen Bond UPDATE Ausleihe SET Name Rovenich WHERE Name Weigmann die Anweisung ndert den Namen einer Person in der gesamten Tabelle UPDATE Bucher SET Preis Preis Preis 100 2 WHERE ISBN LIKE 3 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 320 Von der OO Analyse zum Datenbank Entwurf Eon ES
175. el aufgrund organisa torischer politischer technischer nderungen nicht eingeplant Abnehmer der Software k nnen erst das fertige Produkt bewerten strikte Phaseneinteilung ist unrealistisch R ckgriffe sind notwendig Wartung mit ca 60 des Gesamtaufwandes ist eine Phase grunds tzlichere Renovierungsma nahmen und endg ltige Stilllegung Abl sung der Software werden meist nicht mitgeplant Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 63 Vorgehensmodelle der Software Entwicklung Eehtzeit d systeme 2 3 Andere Vorgehensmodelle Die naheliegendste Idee zur Verbesserung des Wasserfallmodells ergibt sich durch die Einf hrung von Zyklen bzw R ckgriffen Sie erlauben Wiederaufnehmen fr herer Phasen wenn in sp teren Phasen Probleme auftreten Machbarkeits studie KI Anforderungs R ckgriff b analyse System entwurf Andere Beispiele LJ das evolution re Modell iteriertes Wasserfallmodell LJ Rapid Prototyping f r Vorstudien Q das V Modell XT der Bundesbeh rden Bundeswehr LJ siehe Kapitel 10 der Vorlesung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 64 Vorgehensmodelle der Software Entwicklung Echte die systeme Rollenbasierte Software Entwicklung und Arbeitsbereiche Projekte funktionieren wenn die richtigen Personen unter Verwendung geeigneter Sprachen
176. elaktivit ten der textuellen Anwendungsfallbeschreibungen oder in Aktivit tsdiagrammen in Klassenoperationen umwandeln Assoziationen und Vererbungsbeziehungen zwischen Klassen genauer beschreiben und erg nzen Konsistenzbedingungen in Umgangssprache oder Pr dikatenlogik Object Constraint Language definieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 327 Von der OO Analyse zum Software Entwurf Echtesit systeme Identifikation von Operationen ReservationContract contractld Number readonly category CatType deposit Currency 500 period DateRange noOfContracts int 0 startContractCreation id Number Operationen setCategory category CatType oder eine Operation CreateContract mit allen notwendigen Daten getCategory CatType setVehicleData getVehicleData cancelContractCreation finishContractCreation cancelContract removeFulfilledContract Operationen werden fiir Objekterzeugung und l schung sowie f r Zugriff auf Attribute assoziierte Objekte Zustands nderungen eingef hrt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 328 Von der OO Analyse zum Software Entwurf Eon ES systeme Aufbau von Operationen lt Sichtbarkeit gt lt Name gt lt Parameterliste gt lt R ckgabetyp gt Sichtbarkeit wie bei Attributen Name ein Name der innerhalb der Klasse zusammen mit
177. elltes Schema Pattern Sprache Absicht Beschreibung des Hauptzwecks in einem Satz Motivation wof r ist Muster geeignet bzw was f r Probleme soll es l sen Anwendbarkeit in welchen Situationen ist das Muster besonders gut einsetzbar Struktur generisches Klassendiagramm f r Entwurfsmuster Kollaboration Zusammenspiel der Klassen als Interaktionsdiagramm oder Text Konsequenzen wie erreicht das Muster die in Motivation aufgef hrten Ziele Implementierung Implementierungshinweise mit weiteren Codebeispielen Hinweise auf Fallstricke programmiersprachenspezifische Aspekte etc Einfaches Beispiel ein Beispiel das die Anwendung des Musters verdeutlicht Bekannte Anwendungen Software in der Muster erfolgreich eingesetzt wurde Verwandte Muster Verweise auf Muster die hnliche Probleme addressieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 486 Objektorientierter Softwareentwurf Eon ES systeme Das Entwurfsmuster Iterator L Name Iterator Q Synonym Cursor im Datenbankbereich oder auch Enumeration Absicht erlaubt geschachtelte und oder beliebig viele Iterationen ber Menge Liste von Objekten ggf auch ber Objekthierarchien Motivation oft wird das Traversieren der Elemente einer Datenstruktur aus soft waretechnischer Sicht falsch realisiert gt Anwendung erh lt Zeiger auf Element in Datenstruktur damit wird Datenstruktur offengelegt und nderungen an Daten
178. em anderen zu wechseln Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 145 Grundlagen der objektorientierten Modellierung Echte die systeme 4 3 Objektorientierte Programmier und Modellierungssprachen Der OO Turm von Babel Anfang der 90er Jahre gab es unz hlige etwa 50 miteinander konkurrierende OO Modellierungsans tze samt der zugeh rigen Diagrammarten und CASE Umgebungen die sich mal mehr mal weniger voneinander unterschieden Beispiele LJ Object Oriented Analysis OOA Coad Yourdon Object Oriented Design OOD Booch Object Modeling Technique OMT Rumbaugh OO Software Engineering OOSE Jacobson E E E E Fusion Coleman Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 146 Grundlagen der objektorientierten Modellierung Echtecit systeme Die Idee von Booch Rational Software Corporation Vielzahl von OO Modellierungsdialekten wird durch eine Standard Sprache ersetzt die Unified Modeling Language UML um so unn tige Grabenkriege in der OO Gemeinde zu beerdigen die Vorteile verschiedener Modellierungsans tze zu vereinen potentiellen Anwendern die Qual der Wahl abzunehmen die Voraussetzung f r Datenaustausch zwischen OO Werkzeugen schaffen enge Integration von OO Werkzeugen damit erm glichen Abh ngigkeit der Anwender von einem Hersteller zu reduzieren Werkzeugherstellern von der Unterst tzung vieler Ans tze
179. en und damit austauschbar zu machen die Hinzunahme oder das L schen neuer Unterklassen zu erleichtern technische Probleme bei der Verteilung von Programmen ber mehrere Prozesse hinweg zu vermeiden Beispiel in Abh ngigkeit vom bergebenen Parameter priceCode wird beim Auf ruf der Methode createlnstance von MovieStateFactory entweder ein Objekt der Klasse NewMovie oder RegularMovie oder ChildMovie erzeugt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 502 Objektorientierter Softwareentwurf Echteslt systeme Beispiel fur Factory Muster _title String Movie getTitle String getCharge double getFRP iint CHILDREN int REGULAR int NEW int getCharge double getFRP int createlnstance hat IN PriceCode Param mit Wert aus CHILDREN NEW REGULAR Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 503 Objektorientierter Softwareentwurf Echteslt systeme Erlauterungen zu MovieStateFactory LJ Die Methode createlnstance hat den im Diagramm nicht sichtbaren Parameter int priceCode der die Werte CHILDREN NEW und REGULAR annehmen darf LJ Von der MovieStateFactory wird kein Objekt angelegt da alle Attribute und Methoden statisch sind createlnstance f r eine bestimmte MovieState Art berpr ft zun chst ob das ent sprechende statische Attribut instance bereits auf ein Objekt verweist Falls ja wird dieses Ob
180. en werden in aller Regel nicht wieder aufgef hrt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 129 bi Grundlagen der objektorientierten Modellierung Echt systeme Polymorphie in objektorientierten Programmiersprachen Das Wort Polymorphie kommt aus dem Griechischen und heisst vielgestaltig Als polymorph werden alle Programmiersprachen bezeichnet die die Definition von Prozeduren Operationen erlauben die auf einer bestimmten Eingabeparameterposition Aktualparameter unterschiedlicher Typen Klassen erlauben Vorteil Statt vieler hnlicher Prozeduren f r jeden Typ hat man nur eine Prozedur in der man Fehler suchen muss die man ab ndern muss Beispiele polymorpher Programmiersprachen LI funktionale Sprachen wie Haskell ML Miranda U alle objektorientierten Sprachen wie Java C LJ dynamisch nicht statisch getypte Sprachen wie Lisp Smalltalk Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 130 Grundlagen der objektorientierten Modellierung rera systeme Beispiel f r Polymorphie iii Die Operation gibEinkommen ist Alter polymorph da sie auf Objekten der Klassen Person Mitarbeiter und erhoheAlter Chef aufgerufen werden kann ZN Mitarbeiter Chef Besitzer Gehalt erh heGehalt gibEinkommen gibEinkommen Firma Einkommen Gehalt Prof Dr Andy Sch rr TU Darmsta
181. en Schemata Sichten f r verschiedene Anwendungen Benutzergruppen Trennung Schema Instanz Schema Beschreibung der Daten Metadaten Instanz Anwenderdaten Datenbankzustand auspr gung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 261 Von der OO Analyse zum Datenbank Entwurf Eon A systeme Gr nde f r die Drei Schichten Schemaarchitektur LJ physische Datenunabh ngigkeit konzeptuelles Schema sch tzt Anwendungen vor nderungen des internen Schemas gt Tuning Ma nahmen am internen Schema leicht er m glich gt Anwendungen sind von Tuning Ma nahmen nicht betroffen nur Abbildung konzeptuelles auf internes Schema ndert sich logische Datenunabh ngigkeit externe Schemata sch tzen Anwendungen vor nderungen des konzeptionellen Schemas lt gt Umbenennungen logische Reorganisationen Erweiterungen einer Daten bank leicht er m glich logische DB Reorganisationen f r eine Gruppe von Anwendungen betref fen nicht andere Anwendungsgruppen nur Abbildung externes auf konzeptuelles Schema ndert sich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 262 Von der OO Analyse zum Datenbank Entwurf Echtzeit Mich systeme Entwicklungslinien Historie der Datenbanksysteme ab 60er Jahre Datenbanksysteme basierend auf hierarchischem Modell Netzwerkmodell Zeigerstrukturen zwischen Daten gt schwache Tre
182. en Sprachmitteln m ssten wir genau eine Reihenfolge des Einlesens Abfragens der Reservierungsdaten festlegen die Behandlung von Sonderf llen wird in Form von Fallunterscheidungen in den normalen Ablauf eingebaut entgegen Ratschl ge in Abschnitt 5 2 die Beschreibung einzelner Anwendungsf lle mit Aktivit tsdiagrammen hat den Vorteil dass sie pr ziser als Flie text sind haupts chlich werden heute aber Aktivit tsdiagramme f r die Beschreibung des Zusammenspiels der zeitlichen Abfolge einzelner Anwendungsf lle benutzt die Aktionen Prozeduren in den einzelnen Aktivit tsknoten sind noch keinen Klassen zugeordnet diese fehlen zum gro en Teil noch Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 237 Objektorientierte Anforderungsanalyse Echte dec systeme Modellierung nebenl ufiger Aktivit ten Reserve readClientNo readCategory MakeReservation readPeriod Beginn der Nebenl ufigkeit Ende der Nebenl ufigkeit fork Verzweigungsknoten join Vereinigungsknoten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 238 jektorienti u Echuet AS Objektorientierte Anforderungsanalyse systeme Nebenl ufige Aktionen mit Objektfluss Verzweigung mit Vereinigung mit Kontrollfluss Objektfluss Reserve readClientNo 1 readCategory readPeriod Auch die umgekehrte Situation ist denkbar Verzweigung mit
183. en anschlie end nicht mehr aktiviert sind Ist eine Markierung m eines Petri Netzes lebendig dann gilt f r jede m gliche Schaltreihenfolge und damit erreichbare Markierung m ausgehend von m keine Transition ist tot es gibt also ausgehend von m f r jede Transition eine Schaltreihenfolge die diese Transition wieder aktiviert Ist eine Markierung m eines Petri Netzes verklemmungsfrei dann gilt f r jede m gliche Schaltreihenfolge und damit erreichbare Markierung m ausgehend von m es gibt immer mindestens eine aktivierte Transition Ist eine Markierung m eines Petri Netzes tot so ist keine seiner Transitionen aktiviert und damit gibt es keine von m aus erreichbaren anderen Markierungen mehr Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 221 Objektorientierte Anforderungsanalyse Gegenbeispiel f r Tote Transitionen im Petri Netz Verf gbare PKWs Tankgutscheine R ckgabe Ausgeliehene PKWs Anzahl R ckgaben Fachgebiet f Echtzeit systeme Z Verfugbare Vans Ausgeliehene Vans F r die obige Markierung ist keine Transition tot da drei Transitionen direkt aktiviert sind und fiir die nicht aktivierte vierte Transition eine Schaltfolge existiert sodass sie dann aktiviert ist Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 222 Objektorientierte Anforderungsanalyse Echtzeit 2 systeme Gegenbeispiel Le
184. en aus statistischen Prozesskontrolle verbessert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 610 Management der Software Entwicklung Eon A systeme Konsequenzen f r die eigene Software Entwicklung Im Rahmen von Studienarbeiten Diplomarbeiten k nnen Sie keinen CMM Level 5 Software Entwicklungsprozess verwenden aber LJ Einsatz von Werkzeugen f r Anforderungsanalyse Modellierung und Projektplanung in dieser Vorlesung behandelt Einsatz von Konfigurations und Versionsmanagement Software wird in Software Engineering II behandelt Einsatz von Werkzeugen f r systematisches Testen Messen der Produktqualit t wird in Software Engineering II behandelt Einsatz von Extreme Programming Techniken siehe Software Praktikum und z B Be99 vom Erfinder Kent Beck Einsatz von Techniken zur Verbesserung des pers nlichen Vorgehensmodells siehe Hu96 ber den Personal Software Process Buchautor Humphrey ist einer der Erfinder von CMM Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 611 Management der Software Entwicklung Eon ES systeme 10 6 Projektpl ne und Projektorganisation Am Ende der Machbarkeitsstudie steht die Erstellung eines Projektplans mit Identifikation der einzelnen Arbeitspakete Terminplanung zeitliche Aufeinanderfolge der Pakete gt Ressourcenplanung Zuord
185. en die prim ren Funktionen Features des Software Systems bzw das Ein Ausgabeverhalten des Systems nichtfunktionale Anforderungen gt Produktanforderungen Benutzbarkeitsanforderungen Effizienzanforde rungen Zuverl ssigkeitsanforderungen Portierbarkeitsanforderungen Unternehmensanforderungen Lieferanforderungen Umsetzungsanforde rungen Vorgehensanforderungen Externe Anforderungen Kompatibilit tsanforderungen Ethische Anforde rungen Rechtliche Anforderungen Datenschutz Sicherheit es gibt noch andere Arten von Anforderungen aber die obige Einteilung ist die am weitesten verbreitete Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 75 Requirements Engineering und Machbarkeitsstudie Taxonomy nichtfunktionaler Anforderungen Performance requirements Space requirements aus EiSE Skript Michael Eichberg Fachgebiet Echizeit systeme Safety requirements Privacy requirements Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 76 Requirements Engineering und Machbarkeitsstudie Echizeit g systeme 3 2 Methoden zur Ermittlung von Anforderungen Bereits mehrfach wurde auf die Schwierigkeit der Ermittlung der aller Anforderun gen an ein Software Produkt hingewiesen Trotzdem wurde bislang nicht erkl rt wie man Anforderungen ermittelt In WW00 werden u a folgende Techniken zur Ermittlung von
186. en eigentlich immer sp ter vorgestellte Statecharts verwendet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 244 Objektorientierte Anforderungsanalyse Echtecit systeme 5 6 Aufbau und Funktion eines Pflichtenheftes Der IEEE ANSI Standard 830 1993 schl gt in etwa folgenden Aufbau f r Pflichten heft vor insgesamt 31 Seiten Text 1 Einleitung mit Ziel des Anforderungsdokumentes purpose Anwendungsbereich des Produkts scope Definitionen Akronyme Abkiirzungen definitions Referenzen auf andere Quellen references berblick ber Rest des Dokumentes overview 2 Allgemeine Beschreibung Produktionfunktionen Benutzercharakteristika etc 3 Spezifische Anforderungen gt nicht funktionale Anforderungen Schnittstellenbeschreibungen etc 4 Anh nge mit Index Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 245 Objektorientierte Anforderungsanalyse Eon A systeme Aufbau eines Pflichtenheftes nach Ba96 Aus Ba96 bernehmen wir einen Vorschlag f r den Aufbau eines Pflichtenheftes der U das Pflichtenheft als Erweiterung des Lastenheftes ansieht also die in Abschnitt 3 3 vorgeschlagene Gliederung eines Lastenheftes erweitert fast alle wichtigen Punkte der IEEE ANSI Norm in etwas anderer Anordnung bernimmt sich auf die Beschreibung der Software eines Gesamtsystems konzentriert der vorerst die Beschreibung von Tes
187. en nicht wirklich durchf hren sondern nur Mar kierungen setzen im Beispiel wurde der Iterator auf einer Hierarchie von Rental Objekten definiert trotzdem liefert 1m Beispiel der Iterator nur die direkten Kinder eines CompositeRental Objektes gt es kann auch leicht ein Iterator definiert werden der die gesamte Teil Hierarchie unterhalb eines CompositeRental Objektes durchl uft U Verwandte Muster Composite Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 494 Objektorientierter Softwareentwurf one ip systeme Das Entwurfsmuster Composite stark verk rzte Beschreibung LJ Name Composite LJ Absicht die Anordnung von Objekten in Hierarchien ist ein Standardproblem beim Entwurf von Softwaresystemen die vorgeschlagene L sung behandelt zusammengesetzte Objekte und atomare Objekte einer Hierarchie gleich Motivation oft k nnen Objekthierarchien beliebig tief geschachtelt werden und auf den zusammengesetzten wie auf den atomaren Objekten Bl ttern der Hierar chie werden dieselben Operationen zur Verf gung gestellt Beispiele f r solche Operationen sind L schen von Unterb umen und Bl ttern einer Hierarchie gt Ausgeben Drucken Malen einer Hierarchie gt Aufsummieren von Werten auf einer Hierarchie bei uns Charge und F requent R enter P oints gt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 495 Objekto
188. end gt gt N 7 client null 7 after 4 after 9 vehicleSet null N N a siiiaiaile handleOverbooke Clerk MVRS Aufruf von makeReservation gibt Name eines Kunden ein erfragt Kundenname n sucht Client n in Datenbank gibt Zeitraum p ein erfragt Fahrzeugkategorie C bestimmt freie Fahrzeuge zu p und C 10 erfragt gew nschtes Fahrzeug 10 w hlt gew nschtes Fahrzeug aus 11 tr gt Reservierung in Datenbank ein 12 ruft Anwendungsfall sendMail 2 4 5 erfragt Reservierungszeitraum p a 9 gibt Fahrzeugkategorie C ein Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 373 Von der OO Analyse zum Software Entwurf Eet de S systeme Z Pr zisierung von Anwendungsfall mit einfachem Sequenzdiagramm Visual Par m for UML Standard Edition TU Darmst nn a N der Klasse MVRS amen acier aClerk Clerk MakeReservation theClient Client und Klasse Clerk getClient returnClient aktives Objekt Lebenslinie 4 eines getPeriod Ce Objektes Nachricht returnPeriod VOR eK getCategory an MVRS OS SS See Nachricht von MVRS asynchrones returnCategory an sich selbst un q fnaVehicies ein synchroner selectVehicle Operationsaufruf Fortschreiten returnSelectedVehicle der Zeit addReservation sendMail Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 374 Von der OO Analyse zum Software Entwurf Echtesit system
189. ende kleine Transformationsschritte Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 524 Objektorientierter Softwareentwurf Eon ES systeme 8 7 Weitere Literatur A177 Alexander Ch A Pattern Language Towns Buildings Construction Oxford University Press 1977 1216 Seiten Die Inspirationsquelle aus dem Fachgebiet Architektur auf die sich die Software Muster Gemeinde bezieht es geht um Architekturstile und vorgefertige Teill sungen f r den Entwurf von Geb uden BCK98 Bass L Clements P Kazman R Software Architecture in Practice Addison Wesley 1998 452 Seiten Von Praktikern geschriebenes Buch das anhand verschiedenster Beispiele aus der realen Welt das Thema Softwarearchitekturen ausgiebig diskutiert Leider spielt Objektorientierung kaum eine Rolle und UML wird nicht einmal erw hnt BM 98 Brown W H Malveau R C McCormick II H W Mowbray Th J Anti Patterns Refactoring Software Architectures and Projecst in Crisis John Wiley amp Sons 1998 309 Seiten Eines der wenigen B cher bislang zum Thema Anti Pattern also erwiesenerma en ungeeignete Software Entwurfsmuster BMR96 Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern orientierte Softwarearchitektur Addison Wesley 1996 Ein Standardwerk zum Thema Softwareentwurf mit Mustern Im Gegensatz zu GH 94 werden hier nicht nur Entwurfsmuster fiir kleine Teile einer Softwarearchitek
190. er 3 8244 2021 X Sch rr 3 8244 2021 X Radermacher 3 8244 2075 9 Z ndorf 3 8244 2075 9 Radermacher B cher ISBN Titel Verlag 0 8053 1753 8 Principles of Database Systems Benj Cummings 3 8244 2021 X Operationales Spezifizieren mit Deutscher Universit ts Verlag 3 8244 2075 9 PROgrammierte GRaphERsetzungsSysteme Deutscher Universit ts Verlag Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 311 Fachgebiet Von der OO Analyse zum Datenbank Entwurf systeme Einfachste SQL Anfrage SELECT FROM Autoren Ausleihe bildet kartesisches Produkt der beiden Tabellen alle m glichen Kombina tionen aller Zeilen beider Tabellen und selektiert mit alle Spalten der resultierenden Tabelle Ausleihe ISBN Name 0 8053 1753 8 0 8053 1753 8 0 8053 1753 8 0 8053 1753 8 Autoren ISBN Autor 0 8053 1753 8 0 8053 1753 8 3 8244 2021 X Sch rr 3 8244 2075 9 Z ndorf Elmasri Schmitz Navathe Schmitz Schmitz Schmitz 0 8053 1753 8 Elmasri 0 8053 1753 8 Derichsweiler 0 8053 1753 8 Navathe 0 8053 1753 8 Derichsweiler 3 8244 2021 X Sch rr 0 8053 1753 8 Derichsweiler 3 8244 2075 9 Z ndorf 0 8053 1753 8 Derichsweiler 0 8053 1753 8 Elmasri 3 8244 2021 X Radermacher Echtzeit Ap Prof
191. er Entwicklungskosten Erlauterungen zum Teufelsquadrat f r Software Entwicklungsprozess werden Qualit t und Quantit t der Software sowie Entwicklungsdauer und kosten gemessen Q die Messwerte werden auf den vier Skalen von den Ecken zur Mitte verlaufend eingetragen und die Punkte miteinander verbunden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 44 Software Technik Was ist das coho ae systeme Das Teufelsquadrat nach Sneed Sn87 Qualitat der Software Quantitat Umfang Entwicklungsdauer Entwicklungskosten Erlauterungen zum Teufelsquadrat Q Fl che des Quadrats Produktivit t ist invariant Ver nderung ggf durch Mitarbeiterschulung besseres Vorgehensmodell L Erh hung der Qualit t und Reduktion der Entwicklungsdauer geht nur mit Reduktion des Produktumfanges und oder Erh hung der Entwicklungskosten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 45 Software Technik Was ist das ee systeme Wartbarkeit von Software Maintenability Software Wartung nderungen an der Software aufgrund von Fehlern oder ge n derten Anforderungen Gut wartbare Software ist leicht korrigierbar modifizierbar und erweiterbar Wartbarkeit wird unterst tzt durch U gute Systemstruktur Modularisierung der Software U gute Dokumentation O kontrollierte nderungsprozeduren Achtung Jede Wartung reduziert die W
192. er OO Analyse zum Software Entwurf Fachgebiet Echtzeit iyo systeme z Deutung von Zustandsdiagramm als Klassenimplementierung Lebenszyklus f r ReservationContrIN stark vereinfacht create contractld this contractld contractld setClient client this client client setCategory category this catego category a setPeriod period this period period confirm Period Category defined fulfill signal condition action Bedeutung der Transitionsbeschriftung 1 wenn signal eintrifft schaltet Transition 2 falls condition ber Attributen erf llt ist 3 und f hrt dabei ununterbrechbare action aus die Attributwerte ndern k nnen Merke Viele CASE Tools k nnen aus solchen Zustandsdiagrammen guten Code generieren Alle Teile der Aufschrift sind optional 1 Transition ohne Aufschrift feuert sofort sobald Zustand erreicht 2 Transition nur mit Bedingung feuert sobald Bedingung erf llt ist 3 Transition mit Signal feuert sobald Signal eintrifft 4 Transition mit Signal und Bedingung feuert sobald Signal eintrifft falls Bed dann erf llt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 390 Von der OO Analyse zum Software Entwurf Echtzeit g systeme Statecharts erweiterte Zustandsdiagramme Ha37 amp Problem Zustandsdiagramme werden in realistischen Anwendungen gro L sung Hierarchisierung der Zustandsdiagramme UML Stat
193. ern Insert Anomalie nur ein Tupel mit Stichwort ER in Relation einf gen Delete Anomalie nur ein Tupel egal welches l schen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 288 Von der OO Analyse zum Datenbank Entwurf Echtzeit die systeme Entfernung der Redundanzen im Beispiel E E E E Was passiert wenn man Auflage in Nr und Jahr zerlegt E Was passiert wenn man auch Adresse von Autoren speichern will E E Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 289 Von der OO Analyse zum Datenbank Entwurf Ente gg systeme Funktionale Abh ngigkeiten FD Functional Dependency Eine funktionale Abh ngigkeit X Y f r Attributmengen X und Y gilt f r eine Rela tion r dann wenn die Attributwerte f r X die Attributwerte f r Y festlegen Im Beispiel B cher gilt gt Es gilt z B nicht gt ISBN Autor gt ISBN gt Stichwort Es gilt z B trivialerweise gt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 290 Von der OO Analyse zum Datenbank Entwurf Echtzeit dich systeme Schl ssel als Spezialfall einer funktionalen Abh ngigkeit Eine Attributmenge X c R ist Schl ssel des Relationenschemas R wenn f r alle zul ssigen Relationen 7 R die FD gilt X gt R gt X ist minimal er Schl ssel f r r also I X cX X OR F r die Definition z
194. erne Eingabedaten External Input El Eingabedaten f r Elementarprozess der Daten oder Steuerinformationen des Anwenders verarbeitet aber keine Ausgabedaten liefert Es handelt sich dabei um den kleinsten selbst ndigen Arbeitsschritt in der Arbeitsfolge eines Anwenders als etwa Produktfunktionen des Lastenheftes in der Machbarkeitsstudie Use Cases aus Pflichtenheft in der Analysephase Gez hlt werden f r jeden Elementarprozess die Anzahl seiner als Eingabe verwende ten Entit tstypen Klassen S tze und deren Datenelementtypen Attribute Felder Anhand dieser Z hlung wird Komplexit t des Elementarprozesses wie folgt bestimmt einfach 3 FPs mittel 4 FPs oder komplex 6 FPs Externe Eingabe Anzahl Attribute lt 4 4 lt Anzahl Attribute lt 15 Anzahl Attribute gt 15 Anzahl Klassen lt 1 einfache Komplexit t einfache Komplexit t mittlere Komplexit t Anzahl Klassen 2 einfache Komplexit t mittlere Komplexit t hohe Komplexit t Anzahl Klassen gt 2 mittlere Komplexit t hohe Komplexit t hohe Komplexit t Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 633 Management der Software Entwicklung Echte die systeme Beispiel f r die Bewertung externer Eingabedaten LJ Reservierungsvertrag neu erstellen mit Beginn und Endedatum gew nschter Fahrzeugkategorie Kaution Kunde und Fahrzeug eine eindeutige Vertragsnum
195. erwecken Hinzuf gen Aufrufe der Methode m ssen Ausnahme abfangen LI viele weitere Beispiele f r inkompatible Schnittstellen nderungen in RLO4 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 480 Objektorientierter Softwareentwurf one AS systeme 8 5 Design Pattern und Anti Pattern Bisher haben wir durch Refactoring systematisch schlechte Programm in gute umgebaut Dabei wurde die Frage wie man schlecht und gut definiert nur angerissen und der Schwerpunkt auf die Beschreibung von Umbauma nahmen gelegt Hier f hren wir LJ Design Pattern gute Entwurfsmuster als systematische Beschreibungsmittel f r gute Programmkonstruktionsprinzipien Anti Pattern schlechte Entwurfsmuster als systematische Beschreibungsmittel f r schlechte Programmkonstruktionsprinzipien ein Zu beachten gilt dass Design Pattern urspr nglich von dem Architekten Christopher Alexander eingef hrt wurden A177 und sich nicht nur f r den Entwurf guter Programme eignen sondern auch f r die Analysephase oder das Projektmanage ment Man spricht dann von Analyse Pattern Zudem werden Entwurfsmuster in der Architektur dem Maschinenbau in Form von Entwurfsregeln eingesetzt Das gilt ebenfalls f r das Gegenst ck der Design Pattern die Anti Pattern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 481 Objektorientierter Sof
196. erzweigungsknoten siehe Seite 238 und Seite 239 viele weitere Details k nnen noch geregelt werden werden aber nicht von allen Werkzeugen unterst tzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 233 Objektorientierte Anforderungsanalyse cnet N systeme Datenspeicherung in Aktivit tsdiagrammen MakeReservation Speicher clname cn Datenbank L f r Objektmengen oft nur einer lt lt selection gt gt bestimmten Klasse vs collection of v with v category c _ FindClienti nDB lt lt datastore gt gt VehicleDB lt lt selection gt gt rs collection of r with r vehicle v lt lt datastore gt gt ReservationDB Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 234 Objektorientierte Anforderungsanalyse Echuet fips systeme Erlauterungen zu Datenspeicherung in Aktivitatsdiagrammen LJ Aktivit tsparameter und Pins besitzen i a die F higkeit Objekte zwischen zuspeichern Kapazit t kann definiert werden und in definierbarer Reihen folge weiterzugeben aber immer nur an eine Aktion Aktivit t so genannte datastores Datenspeicher k nnen gr ere Objektmengen persistent dauerhaft speichern auf sie kann in mehreren Diagrammen von mehreren Aktionen aus zugegriffen werden so genannte centralBuffer tempor re Datenspeicher k nnen gr ere Objektmengen tempor r zw
197. eter has Assoziation package MVRS Model LegalEntities import MVRS Model Vehicles Motorvehicle public class RentalOffice extends Company private Employee InkEmployee private Motorvehicle InkMotorVehicle n package MVRS Model Vehicles import MVRS Model LegalEntities RentalOffice public class Motorvehicle private RentalOffice InkrevRentalOffice der Ruckwartsverweis at Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 435 Objektorientierter Softwareentwurf Echte dec systeme Eigenschaften von Paketen und Sichtbarkeiten E E ein Paket U kann Unterpaket eines Pakets P sein und besitzt dann den Namen P U mit beliebiger Schachtelung alle Inhalte eines Paketes Unterpakete Klassen Assoziationen besitzen Sichtbarkeiten viele CASE Tools und Programmiersprachen unterst tzen das aber nicht im vollen Umfang die Sichtbarkeiten wurden bereits eingef hrt und sind public durch Import sichtbar protected durch Vererbung sichtbar nur in Klassen sinnvoll private nur lokal sichtbar manchmal auch local genannt package nur im umgebenden Paket sichtbar nur in Klassen f r Attribute und Methoden sinnvoll ein Unterpaket sieht alles was seine umfassenden Pakete sehen Sichtbarkeit von Elementen wird also in Kindpakete vererbt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 436
198. ethoden mit dem selben Namen werden geerbt Konfliktaufl sung durch unterschiedliche Parametertypen die selbe Methode mit unterschiedlich redefinierter Implementierung Konflikte werden in OO Programmiersprachen unterschiedlich aufgel st Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 137 Grundlagen der objektorientierten Modellierung Echtzeit ip systeme Mehrfachvererbungskonflikt durch Mehrfachdeklaration Landfahrzeug Wasserfahrzeug void fahre Kmh v void fahre Knoten v E Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 138 Grundlagen der objektorientierten Modellierung Echte ed systeme Mehrfachvererbungskonflikt durch Redefinition String getF hrerschein String getF hrerschein String getFuhrerschein return Klasse3 return Klasse2 String getF hrerschein return Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 139 Fachgebiet Grundlagen der objektorientierten Modellierung Echtzeit po systeme Varianten des Klassenbegriffs Q Klassen als Konzept sie werden zur Dokumentation von Begriffen Konzepten eines Anwendungsbereiches zusammen mit Glossar verwendet in der Analysephase haupts chlich verwendeter Klassenbegriff Klassen als Objektmenge sie fassen eine Menge gleichartiger Objekte zusam men ihre Extension Extension einer
199. f this InkMotorvehicle null Motorvehicle oldMotorvehicle this InkMotorvehicle this InkMotorvehicle null oldMotorvehicle setReservationContract null H if newMotorvehicle null this InkMotorvehicle newMotorvehicle newMotorvehicle setReservationContract this Achtung die Methode MotorVehicle setReservationContract und die Methode ReservationContract setMotorVehicle rufen sich gegenseitig auf Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 336 Von der OO Analyse zum Software Entwurf Eon ES systeme Java Code f r Assoziation mit Konsistenzbewahrung 2 class Motorvehicle public ReservationContract getReservationContract return InkrevReservationContract public void setReservationContract ReservationContract newReservationContract if this InkrevReservationContract newReservationContract if this InkrevReservationContract null ReservationContract oldReservationContract this InkrevReservationContract this InkrevReservationContract null oldReservationContract setMotorvehicle null if newReservationContract null this InkrevReservationContract newReservationContract newReservationContract setMotorvehicle this Achtung die Methode MotorVehicle setReservationContract und die Methode ReservationContract setMotorVehicle rufen sich gegenseitig auf Prof Dr Andy Schiirr TU Darmstadt FB 18
200. fgabe auf kritischem Pfad Anfangs und Endzeiten liegen fest fr heste Anfangszeit sp teste Anfangszeit sp teste Endzeit Dauer 1 sp teste Endzeit fr heste Endzeit fr heste Anfangszeit Dauer 1 kritische Kante auf kritischem Pfad zwischen zwei kritischen Aufgaben gt fr heste Endzeit Kantenquelle 1 sp teste Anfangszeit Kantensenke Pufferzeit nichtkritischer Aufgabe Zeit um die Beginn verschoben werden kann Pufferzeit sp teste Endzeit fr heste Endzeit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 620 Management der Software Entwicklung Eon ES systeme Probleme mit der Planung des Beispiels U zu viele Aufgaben liegen auf kritischen Pfaden wenn kritische Aufgabe l nger als gesch tzt dauert schl gt das auf Gesamtprojektlaufzeit durch an einigen Stellen zus tzliche Pufferzeiten einplanen um Krankheiten Fehlsch tzungen auffangen zu k nnen einige eigentlich parallel ausf hrbare Aufgaben sollen von der selben Person bearbeitet werden gt Ressourcenplanung f r Aufgaben durchf hren gt Aufgaben serialisieren um Ressourcenkonflikte aufzul sen gt oder weitere Personen im Projekt besch ftigen Umrechnung auf konkrete Datumsangaben fehlt noch gt Ber cksichtigung von Wochenenden 5 Arbeitstage pro Woche gt ggf auch Ber cksichtigung von Urlaubszeiten Prof Dr Andy Sch rr TU Darmstadt FB 18 Inst
201. g 10 Tage 10 Taye Update operationen A 34 Tag A 16 Ta 10 Tage Benutzer g Online Hilfe oberfl che 15 Tage 19 Tage A 34 Tag 0 Tage Analyse i Abnahme Manual 20 Tage Vorw rtsberechnung von Startdatum f r Aufgabe fr heste Anfangszeit Max fr heste Vorg ngeranfangszeit Vorg ngerdauer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 617 Fachgebiet Echtzeit ly systeme 2 Management der Software Entwicklung Planung von Arbeitspaketabh ngigkeiten sp teste Endzeiten A 1 E 10 A 11 E 15 A 16 E 33 Listen aufbau 6 Tage A 16 E 33 Datenbank A 34 E 43 Anfrage operationen 0 Tage A 44 E 53 A 54 E 63 Integration Analyse Design 10 Tage i Abnahme Systemtest 10 Tage A 34 E 53 Online Hilfe 15 Tage A 34 E 53 Manual schema 10 Tage A 34 E 43 Update operationen 10 Tage 5 Tage 10 Taye A 16 E 33 Benutzer oberflache 18 Tage 20 Tage R ckw rtsberechnung von Enddatum f r Aufgabe sp teste Endzeit Min sp teste Nachfolgerendzeit Nachfolgerdauer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 618 Management der Software Entwi
202. g Administration Hilfe o Breu Bearbeite Z aktusliciere X L schen IM Anpasser 3 Projekt 2 Eintr ge 8 7 MVRS Motor Vehicle Re E Eire i Masa Colcol mel WC TTS E 2 5 Glossare 1 Eintrag MAATEN E Eea Ro ze Ue B version 0 9 vom 1 S Pflichtenhefte 1 Eintr Version 0 9 vom 1t astenhefte 1 Eintrag Version 0 9 Version 0 9 vom 11 Autor Andy Sch rr E Seminarorganisation Dn PORAS Glossare 1 Eintrag u aare flichtenhefte 1 Eintr astenhefte 1Eintrac A Vorlage 0 Eintr ge Zielbestimmung Ty Historie Das Programm MYRS soll eine kleine Autovermietung mit genau einer Rete Niederlassung in die Lage versetzen die Buchung und erleihung ihrer Favoriten 0 Eintr ge verschiedenen Wagentypen Arten Kategorien zu verwalten Drucken Produkteinsatz Das Produkt wird im Verkaufsraum und im B ro der Firma vom Besitzer der Firma und oft wechselnden Aushilfskr ften bedient bersicht 5 Lastenheft Version 0 9 vom 10 04 2005 Produktfunktionen TE nr Autor Andy Sch n 0 Ersterfassung nderung und L schung von Fahrzeugen RA Ersterfassung von Fahrzeugtypen Version Ersterfassung von Fahrzeugreservierungen Status in Arbeit akzeptiet freigegeben Produktdaten 9 Folgende Daten sind zu jedem Fahrzeug zu speichern Typ Farbe oll LAMA 2Einsatz 3 Ubersicht 4 Funktionen 5 Daten 6 Leistungen 7 Qualit t 8 Erg nzungen 20 Folgende Daten sind bei jede
203. g und Testverfahren Echtzcit systeme Zur Erinnerung Metriken fur Bewertung der Zuverlassigkeit 1 rate of failure occurrence ROFOC H ufigkeit von nicht erwartetem Verhalten z B bei der Benutzung des Fahrzeugreservierungssystems MVRS treten pro Monat zwei Fehlfunktionen auf mean time to failure MTTF mittlerer Zeitabstand zwischen zwei Fehlern z B Fahrzeugreservierungssystem funktioniert im Mittel zwei Wochen fehlerfrei availability AVAIL mittlere Verf gbarkeit der Software z B an 2 von 1000 Arbeitsstunden ist das Fahrzeugreservierungssystem wegen Fehlerbehebungs oder Wartungsma nahmen oder nicht benutzbar Eine neue Metrik 4 probability of failure on demand POFOD Wahrscheinlichkeit der fehlerhaften Ausf hrung mit unerwartetem bzw nicht erw nschtem Ergebnis eines angeforderten Dienstes z B jede tausendste Fahrzeugreservierung wird falsch durchgef hrt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 530 Qualit tssicherung und Testverfahren Eon ES systeme Verl sslichkeit ein neuer Begriff In So01 wird Verl sslichkeit eines Software Systems als umfassender und syste matischer definiertes Qualit tsmerkmal eingef hrt Die Verl sslichkeit eines Systems ergibt sich aus der Kombination folgender Eigen schaften 1 Verf gbarkeit F higkeit des Systems Dienste auf Anforderung zu liefern
204. g vom aktuellen Zustand kann nicht ver ndert werden nur der Zustand eines Objekts ist ver nderbar Objektidentitat Objektgleichheit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 121 Grundlagen der objektorientierten Modellierung Echo ec systeme Beispiel fur Objektidentitat 2 Timo und Hannah haben ein Mountainbike beide sind Besitzer desselben Fahrrads zwei Verweise auf dasselbe Fahrrad Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 122 Grundlagen der objektorientierten Modellierung Echo ec systeme Beispiel fur Objektgleichheit Timo und Hannah haben ein Mountainbike beide sind Besitzer eines eigenen Fahrrads zwei Objekte mit dem gleichen internen Zustand Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 123 Grundlagen der objektorientierten Modellierung Echte dec systeme Objektzustand der Zustand eines Objektes wird durch seine Attributwerte festgelegt LJ Attributwerte k nnen primitive Datentypwerte sein z B int Zeiger auf andere Objekte sein LJ der Zustand eines Objektes kann sich ndern Alter 9 Alter 7 Hannah schenkt Timo zum Geburtstag ihr Fahrrad Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 124 Grundlagen der objektorientierten Modellierung Eon ES systeme
205. gebiet Anforderungen Objekte und Abl ufe im Umfeld einer Autovermietung korrekte Implementierung des Motor Vehicle Umsetzung Reservation Systems Programm fj Seite 104 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Grundlagen der objektorientierten Modellierung Echte dpc systeme Vom Problem zum Programm Problemgebiet 5a Objekte und Abl ufe im Umfeld oo te I ao S ei ee einer Autovermietung b 8 N de Mg a was f r Objekte und Abl ufe i sind f r das Programm relevant Analysemodell und wie sehen sie abstrahiert aus welche Objekte und Abl ufe werden im Programm realisiert wie werden die Objekte Koment im Programm dargestellt i und wie werden die Entwurfsmodell Abl ufe durch Funktionen realisiert unterst tzt E Motor Vehicle Serea Reservation Systems Achtung Programm jj Abl ufe werden durch das Verhalten miteinander i kooperierender Objekte festgelegt Implementierung des Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 105 u jektorienti ieru Eche ipo Grundlagen der objektorientierten Modellierung systeme Strukturierte Softwareentwicklungsmethode der 80 90er Jahre Problem Datenaspekte Verhaltensaspekte Analyse Entity Relationship Diagramme H l Datenflussdiagramme Entwurf relationales DB Schema s Funktionsb ume Codierung SQL Schema Anwendungsprogramm
206. geh riger Aufgaben und Verantwortlichkeiten zu einem Arbeitsbereich geh rt eine Menge voneinander abh ngiger Artefakte ArtifactKind die als Eingabe ben tigt oder als Ausgabe produziert werden Aufgaben zur Bearbeitung von Artifakten werden von Personen in bestimmten Rollen gebunden an einen Arbeitsbereich durchgef hrt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 588 Fachgebiet Management der Software Entwicklung Echtzeit dp systeme Anmerkungen zu den Arbeitsbereichen Workflows des RUP L Business Modeling befasst sich damit das Umfeld des zu erstellenden Software systems zu erfassen Gesch ftsvorf lle Abl ufe LJ Requirements Capture befasst sich damit die Anforderungen an ein Software system noch sehr informell zu erfassen Analysis Design pr zisiert mit grafischen Sprachen Klassendiagramme etc die Anforderungen und liefert Systemarchitektur Implementation Test entspricht den Aktivit ten in den Phasen Codierung bis Integrationstest des Wasserfallmodells Deployment entspricht Auslieferung und Installation des Wasserfallmodells Configuration Management befasst sich mit der Verwaltung von Softwareversio nen und varianten siehe Vorlesung Software Engineering II Project Management mit der Steuerung des Entwicklungsprozesses selbst Environment bezeichnet die Aktivit ten zur Bereitstellung ben tigter Ressourcen Rechner Werkzeuge
207. gen Schaltet eine Transition dann nimmt sie von allen ihren Vorpl tzen Marken weg und f gt all ihren Nachpl tzen Marken hinzu Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 217 Objektorientierte Anforderungsanalyse Echust ed systeme Eine mogliche grafische Darstellung von Petri Netzen 3110 Pl tze mit Kapazit t n 1 u m aktuellen Marken ti Kante die k Marken 1 nimmt oder gibt 01 2 Transition nicht aktiviert r aktivierte Transition t at im aktuellen Zustand des Petri Netzes k nnen Transitionen t1 und t2 feuern LJ wenn t1 gefeuert hat dann haben Vorplatze nur noch 2 v 10 bzw 1 v 2 Marken Q damit kann dann Transition t2 nicht mehr feuern daf r aber t3 und nochmal t1 Ly Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 218 Objektorientierte Anforderungsanalyse Konkretes Beispiel f r Petri Netz Verf gbare PKWs Tankgutscheine R ckgabe Ausgeliehene PKWs Anzahl R ckgaben Die Ausf hrung des Netzes terminiert wenn entweder keine Tankgutscheine mehr da sind Fachgebiet f Echtzeit systeme Verf gbare Vans Ausgeliehene Vans oder die Anzahl der R ckgaben die Zahl 100 erreicht hat Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 219 Objektorientierte Anforderungsanalyse Eon A system
208. gsprozesse geeignet sondern werden ganz allgemein f r die Steuerung komplexer technischer Entwicklungsprozesse eingesetzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 564 Management der Software Entwicklung Eon ES systeme Aufgaben des Managements LJ Planungsaktivit ten Ziele definieren Vorgehensweisen ausw hlen Termine fest legen Budgets vorbereiten Vorgehensmodelle Kostensch tzung Projektpl ne Organisationsaktivit ten Strukturieren von Aufgaben Festlegung organisatori scher Strukturen Definition von Qualifikationsprofilen f r Positionen Rollenmodelle Team Modelle Projektpl ne Personalaktivit ten Positionen besetzen Mitarbeiter beurteilen weiterbilden nicht Thema dieser Vorlesung Leitungsaktivit ten Mitarbeiter f hren motivieren koordinieren nicht Thema dieser Vorlesung Kontrollaktivit ten Prozess und Produktstandards entwickeln Berichts und Kontrollwesen etablieren Prozesse und Produkte vermessen Korrekturen gt Qualitit tsmanagement insbesondere f r Software Entwicklungsprozesse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 565 Management der Software Entwicklung coho die systeme Ziele des Managements Hauptziel des Projektmanagements ist die Erh hung der Produktivit t Allgemeine Definition von Produktivit t Produktivit t Produktwert Aufwand
209. gt der Wert NULL f r definiert undefiniert zu einzelnen Spalten k nnen Integrit tsbedingungen definiert werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 302 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit systeme Beispiel fur einfache Tabellendefinition CREATE TABLE B cher ISBN CHAR 10 NOT NULL PRIMARY KEY Titel CHAR 200 NOT NULL Verlagsname CHAR 30 DEFAULT Oldenbourg Probleme mit dieser Definition LJ wie legt man sinnvoll eine feste Anzahl von Zeichen f r Buchtitel Namen etc fest siehe Strings variabler L nge in SQL 92 LJ wie definiert man einen aus mehreren Attributen zusammengesetzten Prim r schl ssel siehe n chste Folie LJ wie bringt man zum Ausdruck da zu einem Verlagsnamen in einer weiteren Tabelle zus tzliche Informationen abgelegt sind siehe n chste Folie Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 303 Von der OO Analyse zum Datenbank Entwurf Echtzeit fick systeme Syntax von SQL DDL Teil 2 lt table constraint definition gt lt unique constraint definition gt lt referential constraint definition gt lt check constraint definition gt wird nicht behandelt lt unique constraint definition gt lt unique specification gt lt unique column list gt lt unique column list gt lt column name gt lt column name gt
210. gte und die angebotene Schnittstelle m ssen entweder gleich sein oder die angebotene Schnittstelle eine Spezialisierung der ben tigten auf Schnittstellen gibt es Generalisierungshierarchien Mehrfachvererbung eine Schnittstelle erbt alle Operationen der spezialisierten Schnittstellen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 346 Von der OO Analyse zum Software Entwurf Eon ES systeme Simulation der Mehrfachvererbung mit Interfaces Visual Paradigm for UML Standard Edition TU Darmst Interface besitzt keine lt Implementierung definiert nur Operationen f r Klasse Interface Operationen Klasse Ca implementiert Simulation in Java notwendig da keine Mehrfachvererbung f r Klassen Vererbung von Code von MotorVehicle auf Car auf Van nicht m glich mehr zum Einsatz von Interfaces f r Klassen im folgenden Kapitel Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 347 Von der OO Analyse zum Software Entwurf Echtzeit ED systeme Mehrfachvererbung versus Objektrollen meist gt besser Employee Noch besser Employee und Client als Komponenten der Klasse Person modellieren Probleme mit linker L sung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 348 Fachgebiet Von der OO Analyse zum Software Entwurf Echtzeit systeme Vererbung versus Komposition name S
211. h Einf hrung von or und and Zust nden nie Zust nde verwenden die Informationen zu mehreren Eigenschaften repr sentieren z B Zustand Auto ausgeliehen und Inspektion f llig Kopplung der Teildiagramme eines and Zustandes ber in State Bedingungen W chter nur berlegt einsetzen f hrt oft zu schwer verst ndlichen Diagrammen anstelle eines Objektes mit and Zustand oft lieber mehrere Objekte mit einfachen Statecharts verwenden die ber Schnittstellenoperationen kommunizieren an die Verwendung ereignisloser Transitionen denken die bei Erf lltsein einer Bedingung schalten z B Kilometerstand eines Autos gr er als Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 404 Von der OO Analyse zum Software Entwurf Echtzeit g systeme Von sequentiellen Zustandsdiagrammen zu parallelen Statecharts LJ Zustandsdiagramme beschreiben sequentielle Abl ufe in einem Objekt zu einem Zeitpunkt l st ein Ereignis maximal einen Zustands bergang aus ein Event l st maximal eine Aktion aus U and Zust nde normaler Statecharts beschreiben fast nebenl ufige Abl ufe zu einem Zeitpunkt l st ein Ereignis maximal eine Transition im Pro duktautomaten aus und damit gleichzeitig Menge von Teiltransitionen Aktionen der Teiltransitionen werden in beliebiger Reihenfolge ausgef hrt Aber LJ UML Statecharts erlauben auch echt parallele Abl ufe mit fork join
212. herung von Daten lt gt Updates der entsprechenden Relationen f hren zu Inkonsistenzen redun danter Daten es wird nur an einer Stelle ge ndert statt an allen Stellen L sung des Problems LU Funktionale Abh ngigkeiten 1 n Assoziationen im Klassendiagramm liefern die Basis f r die Erkennung von Redundanzen LJ Normalformen charakterisieren verschiedene Formen von Redundanzen auf der Basis von funktionalen Abh ngigkeiten Transformationsverfahren helfen bei der Elimination der Redundanzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 287 Von der OO Analyse zum Datenbank Entwurf Eon A systeme Beispiel f r Relation mit Redundanzen B cher ISBN Titel Autor Auflage Stichwort Verlag 0 8053 1753 8 Princ of DBS Elmasri 1 1989 RDB Benj Cummings 0 8053 1753 8 Princ of DBS Navathe 1 1989 RDB Benj Cummings 0 8053 1753 8 Princ of DBS Elmasri 2 1994 RDB Benj Cummings 0 8053 1753 8 Princ of DBS Navathe 2 1994 RDB Benj Cummings 0 8053 1753 8 Princ of DBS Elmasri 1 1989 Lehrbuch Benj Cummings 0 8053 1753 8 Princ of DBS Navathe 1 1989 Lehrbuch Benj Cummings 0 8053 1753 8 Princ of DBS Elmasri 2 1994 Lehrbuch Benj Cummings 0 8053 1753 8 Princ of DBS Navathe 2 1994 Lehrbuch Benj Cummings Beispiele f r Anderungsanomalien Update Anomalie nur in einem Tupel RDB in relationale DB nd
213. hiedener Klassen Es werden hierarchische Zustandsdiagramme benutzt die eine Variante von Harel s Statecharts sind Ha87 Vorgehensweise Identifikation semantisch sinnvoller Objektzust nde Zuordnung von Operationen zu Zust nden welche Operationen k nnen in welchem Zustand bearbeitet werden Bestimmung des Objektlebenszyklus als zul ssige Zustandsfolgen Operationsaufrufe Signale als Ereignisse l sen Zustands berg nge aus Zuordnung von Aktionen zu Zustands berg ngen vollst ndige Ausprogrammierung der Objektimplementierung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 386 Von der OO Analyse zum Software Entwurf Echtesit systeme Erstes Beispiel fur Zustandsdiagramm Zustandsdiagramm f r new N destroyed ReservationContract create fulfill cancel Initial Confirmed i a i sailen setPeriod setCategory an Peri WithClent zen setCategory setPeriod re setCategory setClient aa LI teilweise werden hnliche Notationselemente wie bei Aktivit tsdiagrammen verwendet f r Markierung Anfangszustand Endzustand Q UML Zustandsdiagramme sind deterministische endliche Automaten mit einer Reihe zus tzlicher Schreibabk rzungen bliche Bezeichnung FSM Finite State Machine Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 387 Von der OO Analyse zum Software Entwurf Echtzeit dich sy
214. hlbarkeit nach Programminspektion und seine Varianten sind u a ein Versuch diese psychologi schen Probleme in den Griff zu bekommen Rolle des Moderators ist von entscheidender Bedeutung f r konstruktiven Verlauf von Inspektionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 543 Qualit tssicherung und Testverfahren Eon ES systeme Vorgehensweise bei der Programminspektion Inspektionsteam besteht aus Moderator Autor passiv Gutachter n Protokoll f hrer und ggf Vorleser nicht dabei sind Vorgesetzte des Autors Gutachter sind in aller Regel selbst in anderen Projekten Entwickler Inspektion berpr ft ob gt Dokument Spezifikation erf llt Implementierung konsistent zu Modell f r Dokumenterstellung vorgeschriebene Standards eingehalten wurden Inspektion hat nicht zum Ziel zu untersuchen wie entdeckte Fehler behoben werden k nnen Beurteilung der F higkeiten des Autors lange Diskussion ob ein entdeckter Fehler tats chlich ein Fehler ist Inspektionsergebnis gt formalisiertes Inspektionsprotokoll mit Fehlerklassifizierung Fehlerstatistiken zur Verbesserung des Entwicklungsprozesses Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 544 Qualit tssicherung und Testverfahren Eon ES systeme Ablauf einer Inspektion Ausl sung der Inspektion durch Autor eines Dokumentes z B durch Freigabe Eingangspr
215. hlfunktionen failure Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 538 Qualit tssicherung und Testverfahren Eon ES systeme Verschiedene Arten von Codierungsfehlern LJ Berechnungsfehler Komponente berechnet falsche Funktion Rundungsfehler bei der Berechnung einer Formel gt Schnittstellenfehler Inkonsistenz beziiglich erwarteter Funktionsweise zwischen Aufrufsstelle und Deklaration Ubergabe falscher Parameter Vertauschen von Parametern Verletzung der Randbedingungen unter denen aufgerufene Komponente funktioniert z B Division durch Null LJ Kontrollflussfehler Ausf hrung eines falschen Programmpfades gt Vertauschung von Anweisungen gt falsche Kontrollbedingung z B kleiner statt kleiner gleich off by one Schleife wird einmal zuwenig oder zu oft durchlaufen UL Initialisierungsfehler falsche oder fehlende Initialisierung einer Variablen Variable wird auf einem vieler m glicher Programmpfade nicht initialisiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 539 Qualit tssicherung und Testverfahren Echo LJ Datenflussfehler falscher Zugriff auf Variablen und Datenstrukturen falsche Arrayindizierung Zuweisung an falsche Variable Zugriff auf Null Pointer Zugriff auf bereits freigegebenes Objekt Zeitfehler gefordertes Zeitverhalten nicht eingehalten hier nicht bet
216. hmus berpr ft Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 599 Management der Software Entwicklung Echtzeit systeme Bewertung von ISO 9000 lenkt die Aufmerksamkeit des Managements auf Qualit tssicherung ist ein gutes Marketing Instrument reduziert das Produkthaftungsrisiko Nachvollziehbarkeit von Entscheidungen Nachvollziehbarkeit und Dokumentation von Prozessen reicht aus keine Aussage ber Qualit t von Prozessen und Produkten f r kleine Firmen nicht bezahlbarer b rokratischer Aufwand Qualifikation der Zertifizierungsstellen umstritten oft gro e Abweichungen zwischen zertifiziertem Prozess und realem Prozess Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 600 Management der Software Entwicklung Fachgebiet Echtzeit systeme Das Capability Maturity Model CMM Referenzmodell zur Beurteilung von Softwarelieferanten vom Software Engineering Institute entwickelt http www sei cmu edu cmm cmms html Softwareentwicklungsprozesse werden in 5 Reifegrade unterteilt Reifegrad maturity entspricht Qualit tsstufe der Softwareentwicklung h here Stufe beinhaltet Anforderungen der tieferen Stufen Stufe 1 chaotischer initialer Prozess ihr Stand vor dieser Vorlesung LJ Prozess Charakteristika unvorhersehbare Entwicklungskosten zeit und qualit t kein Projektmanagement nur K nstler am Werke
217. hrt include besitzen mehrere Anwendungsf lle gleiche Teilabl ufe wie das Nachrichtenverschicken so k nnen diese Teilabl ufe separat beschrieben werden es wird also Funktionalit t ausgelagert und wiederverwendet bzw aufge rufen der Aufrufer kennt den aufgerufenen Anwendungsfall Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 171 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit po systeme Exkurs zu Diagrammannotationen der Form xxx Annotationen der Form include gt werden Stereotypen genannt und erweitern die Sprache UML pr ziser das Metamodell von UML LI sie erlauben die Unterscheidung verschiedener Unterarten eines Modellierungselementes z B verschiedene Benutzt Beziehungen zwischen Anwendunsgsf llen manche Stereotypen sind durch den UML Standard vorgegeben es gibt Standarderweiterungen f r bestimmte Anwendungsbereiche z B Modellierung von Echtzeitsystemen mit weiteren Stereotypen schlie lich kann der UML Anwender selbst neue Stereotypen einf hren und ggf eine neue Darstellung definieren Definition neuer Stereotypen wird von UML Werkzeugen sehr unterschiedlich unterst tzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 172 Objektorientierte Anforderungsanalyse Echtzeit A systeme Anwendungsf lle f r Systemmissbrauch Misuse Cases MVRS_Clients ManipulateC lent
218. ice motorVehicle gt includesAll self rentalContract motorVehicle inv N self age gt 18 normale Invariante muss immer gelten Initialisierung eines derive Attributs age if motorVehicle age lt 10 then motorVehicle price 10 motorVehicle age div 100 else 0 endif f r ein neues Auto wird ein Zehntel des Neupreises als Kaution verlangt f r ein 10 Jahre altes Auto nichts Definition eines abgeleiteten Attributs deposit dieses besitzt immer diesen berechneten Wert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 370 Von der OO Analyse zum Software Entwurf Echtzeit ich systeme Zusammenfassung der Verwendung von OCL LJ OCL ist eine umfangreiche Sprache basierend auf der Pr dikatenlogik die nur in Ausz gen hier vorgestellt wurde LJ Invarianten beziehen sich immer auf eine Klasse und m ssen f r alle Instanzen dieser Klasse zu allen Zeiten gelten mit derive kann man den Wert eines abgeleiteten Attributes durch eine Formel festlegen bei jedem lesenden Zugriff auf das Attribut wird die Formel berechnet mit init kann man einen initialen Wert f r ein Attribut festlegen der sp ter durch Zuweisungen berschrieben werden kann des weiteren kann OCL dazu verwendet werden Vor und Nachbedingungen an Methoden zu formulieren die vor dem Aufruf und nach der Durchf hrung einer gerufenen Methode gelten m ssen OCL wird manchmal auch in anderen Diagr
219. iche Aufeinanderfolge der Pakete Ressourcenplanung Zuordnung von Personen zu Paketen Hier wird am deutlichsten dass eine Machbarkeitsstudie ohne ein grobes Design der zu erstellenden Software nicht durchf hrbar ist da Arbeitspakete ergeben sich aus der Struktur der Software Abh ngigkeiten und Umfang der Pakete ebenso Realisierungsart der Pakete bestimmt ben tigte Ressourcen Konsequenz Projektplanung und organisation ist ein fortlaufender Prozess Zu Projektbeginn hat man nur einen groben Plan der sukzessive verfeinert wird siehe Kapitel 10 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 99 Requirements Engineering und Machbarkeitsstudie Echtzeit g systeme 3 6 Eine abschlie ende Checkliste Eine Machbarkeitstudie sollte in der Regel nur wenige Tage dauern Gegebenenfalls ist ein Vorprojekt sinnvoll in dem technische Risiken etc studiert werden Es m ssen folgende Punkte gekl rt sein LJ Sind die Angaben des Lastenheftes mit allen ma geblichen Parteien auf Kun denseite abgestimmt Vorsicht mit Interessensgegens tzen auf Kundenseite Ist das Produkt mit den eingeplanten Ressourcen technisch realisierbar Gibt es eine hinreichend vertrauensw rdige Kostensch tzung Ist Produktentwicklung wirtschaftlich interessant oder politisch notwendig Ist ein realistischer Zeitplan vorhanden mit Datumsangaben f r alle Phasen ber s nge Da
220. ielen kaum eine Rolle Pakete beim Entwurf komplexe Teilsysteme wie in der Analyse benutzte Pakete Sichtbarkeiten sind aber sehr wichtig Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 425 Fachgebiet Objektorientierter Softwareentwurf Echtzeit dp systeme Standard Bauplan eines interaktiven Softwaresystems 1 Benutzerschnittstelle ee ea 2 fachliches Modell Fachfunktionen Analysemodell Bunsenejsjnejqy A O g 3 gt a a D Q 4 5 a _D 3 Schichten 3 Datenverwaltung Architektur Prinzipien f r die Zerlegung in Teilsysteme LJ drei Hauptschichten Benutzerschnittstelle Fachfunktionen Datenhaltung LJ Ablaufsteuerung regelt Zusammenspiel Benutzerschnittstelle und Fachfunktionen LJ Kommunikationsdienste erlauben Kommunikation zwischen Teilsystemen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 426 Objektorientierter Softwareentwurf Echtsslt o systeme Aufgaben der Teilsysteme am sogenannten MVC Muster Beispiel L Benutzerschnittstelle View Sicht auf Daten V aus MVC alle Bestandteile des Systems die mit Benutzeroberfl che zu tun haben Realisierung mit einer Benutzeroberfl chenbibliothek awt Swing Fachliches Modell Model Logik M aus MVC verfeinertes Ergebnis der Analysephase nutzt Datenverwaltung f r die Speicherung von Fachda
221. iertes Verfahren bei dem Dokument nach genau festgelegter Vorgehensweise durch Gutachterteam untersucht wird Review weniger formale manuelle Pr fmethode weniger Aufwand als bei Programminspektion hnlicher Nutzen gt Walkthrough unstrukturierte Vorgehensweise Autor des Dokuments liest vor Gutachter stellen spontan Fragen Pair Programming Programm wird von vornherein zu zweit erstellt Empirische Ergebnise zu Programminspektion Pr faufwand liegt bei ca 15 bis 20 des Erstellungsaufwandes 60 bis 70 der Fehler in einem Dokument k nnen gefunden werden gt Nettonutzen 20 Ersparnis bei Entwicklung 30 bei Wartung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 542 Qualit tssicherung und Testverfahren Een EX systeme Psychologische Probleme bei analytischen Testverfahren amp Entwickler sind in aller Regel von der Korrektheit der erzeugten Komponenten berzeugt ihre Komponenten werden h chstens falsch benutzt Komponententest wird als l stige Pflicht aufgefasst die Folgearbeiten mit sich bringt Fehlerbeseitigung Glauben in die eigene Unfehlbarkeit ersch ttert Entwickler will eigene Fehler unbewusst nicht finden und kann sie auch oft nicht finden da ggf sein Testcode von denselben falschen Annahmen ausgeht Fehlersuche durch getrennte Testabteilung ist noch rgerlicher die sind zu doof zum Entwickeln und weisen mir permanent meine Fe
222. igend Fehler beintr chtigt weder Systemstatus oder noch Daten 3 F r jede Fehlerklasse wird mit einer der eingef hrten Zuverl ssigkeitsmetriken die erforderliche Zuverl ssigkeit festgelegt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 560 Qualit tssicherung und Testverfahren Echtzeit systeme Beispiel f r eine Zuverl ssigkeitsspezifikation Fehlerklasse Beispiel Zuverl ssigkeitsmetrik permanent MVRS funktioniert nie am ROFOC 1 Vorfall 1000 Tage 29 Februar eines Schaltjahres gelegentlich Fahrzeugreservierungsfunktion POFOD 1 Vorfall 500 Aufrufe nicht wird abgebrochen wenn nicht besch digend innerhalb von 5 Minuten alle Eingabedaten vorliegen gelegentlich Ausmusterung eines Fahrzeugs nicht quantifizierbar sollte nie besch digend mit vorliegenden Reservierungen auftreten l scht diese Reservierungen Anmerkung F r das Minibeispiel countVowels macht eine Zuverl ssigkeitsspezifikation keinen Sinn deshalb hier R ckgriff auf unser MotorVehicleReservationSystem Beispiel Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 561 Qualit tssicherung und Testverfahren Echtzeit systeme Messung der Zuverl ssigkeit eines Softwaresystems 1 Es wird ein Betriebsprofil erstellt das Systemeingaben Anforderungsf lle in Klassen unterteilt und H ufigkeiten f r diese Klassen festlegt Ein hinreichend gro er
223. iirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 41 Software Technik Was ist das Eet systeme Effiziente Software Efficiency Effiziente Software nutzt Hardware Ressourcen hinreichend konomisch sodass auf der verf gbaren Hardware die Software benutzbar ist Ben tigte Ressourcen Rechenzeit gt Speicherbedarf trade off Wie ermittelt man Effizienz LI theoretische Komplexit tsanalyse O von Rechnungen LJ Simulationsmodelle Messungen am realen System profiling Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 42 Software Technik Was ist das coho ae systeme Effizienz des Software Erstellungsprozesses Effiziente Software Herstellung produktive Software Herstellung also mit m g lichst wenig Mitarbeitern in m glichst kurzer Zeit m glichst gute Software herstellen Problem Produktionszeit gt gt Software Qualit t trade off Software Effizienz L sung LJ Wiederverwendung von Software Komponenten Vorgehensweisen LJ Einsatz von sehr hohen Programmiersprachen Codegeneratoren E Wie misst man Produktivit t in keinem Fall durch LOC Lines of Code Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 43 Software Technik Was ist das coho ae systeme Das Teufelsquadrat nach Sneed Sn87 Qualitat der Software 4 Quantitat Umfang Entwicklungsdau
224. ineering U Machbarkeitsstudie fiir Software Entwicklungsprojekt LJ Sch tzmethoden fiir Produktumfang und Entwicklungskosten Achtung Einige Themen dieses Kapitels insbesondere die Projektplanung und Kostensch tzung werden hier nur angerissen Eine Vertiefung der Themen erfolgt im Kapitel 10 der Vorlesung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 68 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit u systeme Beispiel Kundenbeschreibung eines Softwareprodukts Motor Vehicle Reservation System MVRS A rental office lends motor vehicles of different types The assort ment comprises cars vans and trucks Vans are small trucks which may be used with the same driving license as cars Some client may reserve motor vehicles of a certain category for a certain period He or she has to sign a reservation contract The rental office guaran tees that a motor vehicle of the desired category will be available for the requested period The client may cancel the reservation at any time When the client fetches the motor vehicle he or she has to sign a rental contract and optionally an associated insurance contract Within the reserved period at latest at its end the client returns the motor vehicle and pays the bill Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 69 Requirements Engineering und Machbarkeitsstudie
225. inition gt lt table constraint definition gt wird im Folgenden behandelt lt column definition gt lt column name gt lt data type gt lt default clause gt lt column constraint gt lt data type gt lt character string type gt lt exact numeric type gt lt default clause gt DEFAULT lt literal gt USER NULL lt column constraint gt NOT NULL lt unique specification gt lt check constraint definition gt wird nicht behandelt lt references specification gt wird im Folgenden behandelt lt unique specification gt UNIQUE PRIMARY KEY Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 301 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Erlauterungen zur SQL Syntax Teil 1 Q der authorization identifier legt den Eigent mer des deklarierten Schemas fest der Zugriffsrechte weiter vergeben kann die privilege definition bestimmt die Zugriffsrechte im Detail mit einer view definition kann man Sichten auf den deklarierten Basistabellen ein richten die das Ergebnis von Anfragen sind ein Schema umfa t eine Menge von Tabellendefinitionen die wiederum aus einer Menge von Spaltendefinitionen bestehen bei jeder Spalte kann neben dem Datentyp der Elemente ein Defaultwert Initialwert angegeben werden eine Konstante literal gt der authorization identifier der Person die das Tupel eintr gt USER
226. inschr nkungen vorgesehen gt sind gleichzeitiges Make und CancelReservation erlaubt d rfen mehrere Reservierungen gleichzeitig durchgef hrt werden die vielen Beziehungen im vorigen Beispiel machen das Diagramm un bersichtlich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 162 Objektorientierte Anforderungsanalyse Echtzeit ec systeme Systemkontextdiagramm als Variante des Anwendungsfalldiagramms MVRS System betrachtetes System Nachbarsystem wird vorausgesetzt Kontextdiagramm beschreibt die Umgebung des zu entwickelnden Systems es gibt verschiedene M glichkeiten in UML Kontextdiagramme zu malen in der Analysephase ist es am sinnvollsten s e als Spezialfall von Anwendungsfalldiagrammen zu aufzufassen Accounting System ist ein System das mit unserem MVRS System interagiert und bereits existiert oder sp ter realisiert wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 163 Objektorientierte Anforderungsanalyse Echtzeit systeme Zerlegung in Teilsysteme zur Strukturierung von Anwendungsf llen MVRS_Clients _ Adaclient 2 Erstes Release hat noch keine separate N Verwaltung von Kundenstammdaten Kommentare MVRS_Reservations _MakeReservation 2 Fahrzeug wird f r einen bestimmten Zeitraum reserviert CancelReservation 2 Reservierung wird gel scht Beziehungen A
227. ischenspeichern auch auf sie kann in mehreren Diagrammen von mehreren Aktionen aus zugegriffen werden nicht gezeigt mit Selektionsbedingungen selections in Form von Kommentaren an Objektfl ssen kann definiert werden welche Objekte aus einem datastore oder aus einem centralBuffer herausgeholt werden sollen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 235 Fachgebiet f Objektorientierte Anforderungsanalyse Echtzeit 3 systeme Alternative Darstellungen von Fallunterscheidungen r MakeReservation Kontrollfluss ist Spezialfall von Datenfluss d mit Dummy Token Werten FindClientInDB ee cn m cl m cd null lt gt cl til cl null a gt res DR gt Kontrolifiuss impliziter as vs Q Kontrollfluss ge E iod gt SelectFreeVehicle P bedingter v null lt lt datastore gt gt Objektfluss ReservationDB lesender u schreibender Zugriff auf Ar Speicher CreateMessage message d m CreateReservation p J r Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 236 Objektorientierte Anforderungsanalyse Echtzeit systeme Kommentare zu vorigem Aktivit tsdiagramm LI die Erhebung der Reservierungsdaten clientNo category und period muss bereits vor der Durchf hrung der Aktivit t MakeReservation erfolgt sein LJ mit den bisherig
228. it ts und Produktivit tssteigerung des gesamten Softwareentwicklungsprozesses auf Softwareentwicklung zugeschnitten dynamisches Modell mit kontinuierlichem Verbesserungsdruck ISO Norm SPiCE http www sgi gu edu au SPICE integriert und vereinheit licht CMM und ISO 9000 als ISO IEC 15504 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 605 Management der Software Entwicklung Echtzeit systeme SPICE Software Process Improvement and Capability dEtermination Internationale Norm f r Prozessbewertung und Verbesserung Sie bildet einheitlichen Rahmen f r Bewertung der Leistungsf higkeit von Organisationen deren Aufgabe Entwicklung oder Erwerb Lieferung Einf hrung und Betreuung von Software Systemen ist Norm legt Evaluierungsprozess und Darstellung der Evaluierungsergebnisse fest Unterschiede zu CMM U orthogonale Betrachtung von Reifegraden und Aktivit tsbereichen LJ deshalb andere Definition der 5 Reifegrade z B 1 alle Aktivit ten eines Bereiches sind vorhanden Qualit t der Aktivit ten noch unerheblich jedem Aktivit tsbereich oder Unterbereich kann ein anderer Reifegrad zugeordnet werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 606 Management der Software Entwicklung Echtzeit ick systeme Aktivit tsbereiche von SPiCE L Customer Supplier Bereich Aquisition eines Projektes Angebotserste
229. it dem betrachteten Kunden verbundenen Objekte der Klasse RentalOffice zur ckliefert entsprechend ist motorVehicle eine Methode der Klassen RentalOffice und RentalContract sowie rentalContract eine weitere Methode der Klasse Client Collection gt entspricht immer einem Methodenaufruf auf einer Kollektion Set Sequence Bag von Objekten includesAll wird auf einer Kollektion mit einer zweiten Kollektion als Parameter aufgerufen und liefert genau dann true zur ck wenn die zweite Kollektion voll st ndig in der ersten Kollektion enthalten ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 354 Von der OO Analyse zum Software Entwurf Echtesit systeme Verschiedene Arten von OCL Ausdr cken Jeder OCL Ausdruck besitzt entweder eine Klasse oder eine Operation oder ein Attri but bzw eine Assoziation als Kontext Es gibt folgende Arten von OCL Ausdr cken die entweder direkt an eine Klasse Methode oder Attribut Assoziation als Kommentar in einem Diagramm angeheftet sind oder aber separat in einer Textdatei mit explizit angegebenem Kontext definiert werden 1 Invarianten zu Klassen Boole sche Bedingungen die auf allen Instanzen einer Klasse immer erf llt sein m ssen context Client inv age gt 18 oder self age gt 18 Definition von Hilfsattributen und operationen in mehreren OCL Ausdr cken ben tigte Teilausdr cke k nnen auf diese Weise ausgelagert definiert werden ohne
230. ite 266 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit dp systeme Einschub zur Definition von kartesischem Produkt und Relation LI Das kartesische Produkt zweier Mengen M und N ist die Menge aller Tupel die als erste zweite Komponente ein Element aus M N enthalten MxN m n ImeM neN Beispiel mit AUTOR Heuer Saake Uderzo Goscini TITEL DB Asterix AUTOR x TITEL Heuer DB Heuer Asterix Saake DB Saake Asterix Uderzo DB Uderzo Asterix Goscini DB Goscini Asterix LI Eine n stellige Relation ber Mengen M4 M ist eine Teilmenge des kartesischen Produktes dieser Mengen Beispiel f r 2 stellige bin rer Relation ber AUTOR und TITEL Heuer DB Uderzo Asterix c AUTOR x TITEL Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 267 Fachgebiet f Von der OO Analyse zum Datenbank Entwurf Echtzeit 3 systeme Relationale Daten bank Definition mit Datenbankschema AUSLEIHE Schlisselattribut gt INV_NR NAME gt lt an en mi oe a Spalten Attribute 1201 Schulz Zeilen Tupel 0007 Miiller Relation 4712 Meyer Instanz des Relationen BUCH schemas TITEL ISBN AUTOR lt Attributnamen Asterix der Gallier 3 125 Uderzo Objektbanken 3 111 Heuer Datenbanken 3 765 Vossen Datenbanken 3 891 Ullman PASCAL 3 999 Wirth
231. itektur nach ANSI SPARC standardisierte Datenbanksprache SQL Structured Query Language gt Einbettung von SQL in kommerzielle Programmiersprachen gt Werkzeuge f r interaktive Definition Anfrage und Darstellung von Daten Entwurf von Anwendungsprogrammen Benutzeroberfl chen kontrollierter Mehrbenutzerbetrieb Datenschutz und Datensicherheit Beispiele echter RDBMS ORACLE DB2 Ingres Informix Beispiele fur Pseudo RDBMS MS Access dBASE es fehlen u a Drei Ebenen Architektur Optimierungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 265 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme Einschub zur Definition von Menge und Tupel Eine Menge ist eine Ansammlung Kollektion unterscheidbarer Dinge die ihre Elemente genannt werden Eine Menge enth lt kein Element doppelt Notation einer Menge TITEL Datenbanken Geoinformatik Asterix der Gallier Element nicht aus Menge Datenbanken e TITEL Dr No TITEL Vereinigung Durchschnitt Differenz von Mengen U N Ein n Tupel ist eine geordnete Folge von genau n Elementen seinen Komponenten hier oft genannt Spalten Attribute Beispiele f r 4 Tupel Quadrupel 0001 Asterix der Gallier 3 125 Uderzo 1201 Objektbanken 3 111 Heuer 4711 Datenbanken 3 765 Vossen Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Se
232. itskritische komplexe Funktionen beschreiben mit Hilfe neuer riskanter Technologien zu realisieren sind iiber lebensnotwendige Gesch ftsfunktionen darstellen sie erh hten Gewinn versprechen einfach zu realisieren sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 179 Objektorientierte Anforderungsanalyse Eon ES systeme Anmerkungen zu Anwendungsf llen LJ wiederkehrende Teile von Anwendungsf llen werden ber include Beziehung in eigene Anwendungsf lle ausgelagert aber nur wenn wirklich notwendig LI die include Beziehung hat die Semantik eines Prozeduraufrufes der Aufruf wird in der Beschreibung des rufenden Anwendungsfalles niedergeschrieben ein Anwendungsfall beschreibt den Normalfall eines konkreten Ablaufes Ausnahmef lle oder Varianten werden ber extends Beziehung ausgelagert ein Anwendungsfall abstrahiert von einer Anzahl konkreter Szenarien wie etwa Kunde Franklin Turtle reserviert f r den 28 April 2006 einen Smart statt textueller Beschreibung eines Ablaufs werden auch Sequenzdiagramme siehe Abschnitt 7 3 oder Aktivit tsdiagramme siehe Abschnitt 5 5 eingesetzt die extends Beziehung entspricht einem bedingten versteckten Prozeduraufruf der erweiternde Anwendungsfall wird an einem Punkt oder in einem Bereich des skizzierten Ablaufs des Basisanwendungsfalles aktiv wenn Bedingung erf llt ist U jeder Anwendungsfall sollte auf eine Lastenheftf
233. itut f r Datentechnik Seite 203 Objektorientierte Anforderungsanalyse Echtzeit systeme Probleme mit Navigation bei Assoziationen auf einer Klasse Reservation Contract isBossOf Klassendiagramm Objektdiagramm Tobias Clier isBossOf Andy Clierf SS isBossOf isBossOf Problem wenn Leserichtung von isBossOf unklar ist dann weiss man nicht ob man mit InklsBossOf von Andy zu Margot oder zu Tobias und Alexander navigiert Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 204 Objektorientierte Anforderungsanalyse Eehtzeit gd systeme Eigenschaften von Assoziationen 3 LJ Rollennamen Namen f r Leserichtungen Rollennamen beginnen immer mit einem Kleinbuchstaben gt Default Wert f r Rollenname ist Klassenname z B client f r Client Assoziationen mit selber Start und Zielklasse m ssen Rollennamen haben Assoziationsname selbst darf fehlen Default Wert Regel nicht definiert Reservation client contract Contract isBossOf Rollennamen werden f r den Zugriff auf benachbarte Objekte ben tigt Im folgen den Kapitel 7 werden wir sehen wie Rollennamen innerhalb von pr dikatenlogi schen Ausdr cken und in der Implementierung von Klassen verwendet werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 205 Objektorientierte Anforderungsanalyse Bene fp systeme Eigenschaften von Assoziationsenden Di
234. itut f r Datentechnik Seite 621 Management der Software Entwicklung Echtzeit systeme Verfeinerung von Abh ngigkeiten und Zeitplanung Bislang wird bei allen abh ngigen Aktivit ten vorausgesetzt Finish to Start Folge FS Normalfolge Nachfolgeaktivit t kann erst bearbeitet werden wenn Vorg ngeraktivit t vollst ndig abgeschlossen ist Manchmal lassen sich aber abh ngige Aktivit ten auch parallel bearbeiten gt Start to Start Folge SS Anfangsfolge Aktivit ten m ssen gleichzeitig beginnen gt Finish to Finish Folge FF Endfolge Aktivit ten m ssen gleichzeitig enden gt Start to Finish Folge SF Sprungfolge Umkehrung der Nachfolgebeziehung relativ sinnlose Beziehung Des weiteren sind manchmal zus tzliche Verz gerungszeiten sinnvoll fr hestm glicher Beginn einer Aktivit t wird um Verz gerungszeit lag nach vorne oder hinten verschoben f r feste Puffer berlappungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 622 Fachgebiet f Management der Software Entwicklung Echtzeit 3 systeme Balkendiagramm Gantt Chart 1917 von Henry Gantt erfunden Idee 14 4 03 28 4 03 5 5 03 19 5 03 2 6 03 16 6 03 30 6 03 11 7 03 1 Analyse 2 Design sd 3 1 DB Schema ss 3 2 DB Updates 3 3 DB Queries 3 4 Listen 3 5 Benutzeroberflache 5 1 Manual 5 2 Online Hilfe 4 Integration Systemtest
235. jekt zuriickgeliefert Ansonsten wird genau einmal ein neues Movie Objekt erzeugt in dem statischen Attribut instance abgespeichert und zuriickgeliefert Alternativ kann man bereits vor dem ersten Aufruf von createlnstance die stati schen Attribute mit den entsprechenden Objekten initialisieren Statt drei verschiedene Attribute anzulegen sollte man vielleicht besser ein Array einen Vector von MovieState Objekten verwenden Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 504 Objektorientierter Softwareentwurf Eon ES systeme Das Entwurfsmuster Abstract Factory U Name Abstract Factory LJ Absicht eine Abstract Factory f hrt eine weitere Abstraktionsstufe f r die Erzeu gung von Objekten ein Der Auswahlprozess erfolgt zweistufig zun chst wird eine konkrete Factory ausgew hlt die dann bestimmte Objektinstanzen erzeugt Motivation bei der Objekterzeugung soll nicht nur verborgen bleiben zu welcher Unterklasse einer abstrakten Oberklasse ein Objekt geh rt sondern dar ber hinaus soll der Algor thmus zur Auswahl einer Unterklasse zur Laufzeit austauschbar sein Dies geschieht durch die Verwendung einer anderen konkreten Factory Beispiel eine Implementierung des Videoverleihsystems soll zur Laufzeit nder bare Schemata f r die Preisgestaltung und Berechnung von Bonuspunkten haben F r jedes Preisschema wird eine konkrete Factory realisiert die dann die dazu pas se
236. jektorientierte Anforderungsanalyse Echtzeit systeme Von bin ren zu n ren Assoziationen Sind Personen gleichzeitig Angestellte mehrerer Firmen dann kann man mit bin ren isBossOf Assozationen nicht ausdr cken in welcher Firma eine Person Vorgesetzter einer anderen Person ist Deshalb gibt es auch n re Assoziationen die mehr als zwei Objekte verbinden boss 0 1 0 Semantik der Multiplizit ten n rer Assoziationen Wenn man n 1 Enden festh lt konkrete Objekte in einer Beziehung betrachtet dann legt die Multiplizit t des verbleibenden Endes fest wieviele Links zu Partnerobjek ten es f r die festgelegten Objekte geben kann Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 208 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit systeme Beispiel f r die Semantik von Multiplizit ten f r n re Assoziationen boss 0 1 0 sub 0 LJ eine Person in einer bestimmten Firma hat maximal einen direkten Vorgesetzten LJ eine Person in einer bestimmten Firma hat beliebig viele Untergebene LJ eine Person A kann in beliebig vielen Firmen Vorgesetzte einer Person B sein Die hier gew hlte Interpretation von Multiplizit ten ist vielleicht nicht auf den ersten Blick intuitiv aber eine Verallgemeinerung des Falles n 2 bin re Relationen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 209 Ob
237. jektorientierte Anforderungsanalyse Eehtzeit gd systeme Aggregation Reservation gt ee Insurance Contract hasInsurance gt Contract LJ bin re Assoziation mit vage definierter Zusatzsemantik part of Beziehung Aggregationsbeziehungen bilden keine Zyklen Kreise Q ein Objekt darf Teil mehrerer Elternobjekte ReservationContracts sein Komposition Reservation a Insurance Contract hasInsurance Contract LI Spezialform der Aggregation propagiert L schen von Eltern zu Kindern L schen von ReservationContract l scht seinen InsuranceContract mit U Objekt darf h chstens ein Elternobjekt besitzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 210 Objektorientierte Anforderungsanalyse Echtzeit systeme Regeln f r die Verwendung von Aggregation Komposition Aggregation und Komposition m ssen in der Analysephase nicht verwendet werden da sie sich kaum von normalen Assoziationen unterscheiden Einsatz von Aggregation Komposition ggf wenn ein Objekt von anderem Objekt existenzabh ngig ist InsuranceContract von RentalContract ein Objekt offensichtlich logischer physikalischer Bestandteil eines anderen ist Gesamtreservierungssystem enth lt alle Daten Eigenschaften des Elternobjekts sich auf die Kinder bertragen Farbe eines Autos auf seine Karrosserie Bestandteile Operationen auf dem Elternobjekt zu den Kindern propagiert werden s
238. kation Ent wurf Entwicklung Test und Wartung von Software zu einem n tzlichen und geachteten Beruf zu machen In bereinstimmung mit ihren Verpflichtungen gegen ber Gesundheit Sicherheit und dem Wohlergehen der ffentlichkeit sol len Software Entwickler sich an die folgenden acht Prinzipien halten 1 ffentlichkeit Software Entwickler sollen in bereinstimmung mit dem ffentlichen Interesse handeln 2 Kunde und Arbeitgeber Software Entwickler sollen auf eine Weise han deln die im Interesse ihrer Kunden und ihres Arbeitgebers ist und sich mit dem ffentlichen Interesse deckt 3 Produkt Software Entwickler sollen sicherstellen dass ihre Produkte und damit zusammenh ngende Modifikationen den h chstm glichen professionel len Standards entsprechen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 30 Software Technik Was ist das ee systeme Ethische Regeln Fortsetzung 4 Beurteilung Software Entwickler sollen bei der Beurteilung eines Sach verhalts Integrit t und Unabh ngigkeit bewahren 5 Management F r das Software Engineering verantwortliche Manager und Projektleiter sollen sich bei ihrer T tigkeit ethischen Grunds tzen ver pflichtet f hlen und in diesem Sinne handeln 6 Beruf Software Entwickler sollen die Integrit t und den Ruf des Berufs in bereinstimmung mit dem ffentlichen Interesse f rdern 7 Kollegen Software Entwic
239. ketten suchen mit dem null Pr dikat berpr ft man ob eine bestimmte Spalte eines Tupels einen Wert un gleich NULL hat mit dem quantified Pr dikat berpr ft man ob alle einige Eintr ge einer Spalte der Tabelle gleich ungleich einem bestimmten Wert sind das exist Pr dikat berpr ft ob eine Teilanfrage eine leere Tabelle liefert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 315 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit u systeme Einige Beispiele f r SQL Pr dikate SELECT ISBN FROM B cher WHERE Preis BETWEEN 20 0 AND 100 0 gt SELECT FROM B cher WHERE Verlagsname LIKE Ben Cummings gt SELECT Titel FROM B cher WHERE Radermacher IN SELECT Name FROM Ausleihe WHERE ISBN B cher ISBN Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 316 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme SQL als Datenmanipulationssprache F r die Manipulation von Tabellen Relationen gibt es in SQL die insert Anweisung f r das Einf gen eines einzelnen Tupels oder einer Menge von Tupeln die einzuf genden Tupel mit ihren Werten werden gt entweder explizit angegeben gt oder durch eine Query bestimmt die delete Anweisung f r das L schen eines einzelnen Tupels oder einer Menge von Tupeln die zu l schenden Tupel werden gt durch eine Query bestimmt die update Anweisung f r
240. klassen und Polymorphie eingesetzt werden z B in Movie Replace Type Code with State gt Replace Conditional with Polymorphism U lazy class eine Klasse hat nicht mehr genug Aufgaben ggf wegen Refactoring Collapse Hierarchy um nutzlose Klasse in Oberklasse aufgehen zu lassen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 471 Objektorientierter Softwareentwurf one AS systeme Gr nde f r Refactoring 3 L message chains eine Methode holt sich mit gettern ein Objekt eines Objekts eines um darauf eine Berechnung durchzuf hren Extract Method und Move Method um Berechnung zum geholten Objekt zu bringen anstelle dieses Objekt zur Berechnung middle man fast alle Methoden einer Klasse delegieren ihre Aufrufe an Methoden einer anderen Klasse kann z B Folge der Elimination von message chains sein Inline Method um Methodenaufruf durch Implementierung zu ersetzen gt refused bequest Unterklasse C1 ben tigt viele Methoden und Attribute ihrer Oberklasse C nicht gt neue Oberklasse C der Klasse C einf hren und mit Pull Up nicht in C1 ben tigte Methoden und Attribute von C nach C bringen sowie C1 in Unterklasse von C statt C umwandeln Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 472 Fachgebiet Objektorientierter Softwareentwurf Echtzeit dp systeme G
241. kler sollen sich ihren Kollegen gegen ber fair und hilfsbereit verhalten 8 Selbst Software Entwickler sollen sich einem lebenslangen Lernprozess in Bezug auf ihren Beruf unterwerfen und anderen eine ethische Aus bung ihres Berufes vorleben aus ACM IEEE CS Joint Task Force on Software Engineering Ethics and Professio nal Practices sinngem e bersetzung aus So07 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 31 Software Technik Was ist das ee systeme 1 4 Software Qualit tsmerkmale Ziel der Software Technik Effiziente Entwicklung messbar qualitativ hochwertiger Software die korrekt bzw zuverl ssig arbeitet robust auf Fehleingaben Hardwareausfall reagiert effizient konomisch mit Hardwareressourcen umgeht benutzerfreundliche Oberfl che besitzt wartbar und wiederverwendbar ist Wir unterscheiden externe Qualitatsfaktoren sichtbar fiir Benutzer des Systems interne Qualit tsfaktoren sichtbar f r Entwickler des Systems Achtung es gibt auch die Qualit t des Software Entwicklungs Prozesses Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 32 Fachgebiet f Software Technik Was ist das Echtzeit systeme Beispiel f r fehlende Software Qualit ten program SORT var a b file of integer Feld array 1 10 of integer i j K integer begin open a usr s
242. ktiviert sondern der letzte Unterzustand aus dem Diagramm beim letzten Mal verlassen wurde f r Ausnahmebehandlungen Eintritts und Austrittsaktionen entry exit actions von Zust nden nicht nur Transitionen sind mit Aktionen verbunden sondern auch Eintritt in oder Austritt aus Zustand kann Aktionen ausl sen Eintritts und Austrittspunkte entry exit points komplexer Zust nde will man Unterzust nde an mehreren Stellen wiederverwenden so m ssen diese Schnittstellen besitzen ber die sie betreten und verlassen werden Terminierungsknoten terminate erreicht man diesen Knoten so wird das Objekt zu dem das Statechart geh rt sofort gel scht und nicht erst dann wenn Endezustand ganz au en erreicht wurde Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 408 Von der OO Analyse zum Software Entwurf Echtesit systeme Beispiel fur History Mechanismus create fulfill Initial Incomplete History WithPeriod WithClient WithCategor confirm Wenn man mit undoClear den Zustand Incomplete wieder betritt landet man in dem Unterzustand von dem aus man mit clear den Zustand verlassen hatte sonst im Anfangzustand WithClient Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 409 Von der OO Analyse zum Software Entwurf Echtzeit dip systeme Statechart mit den weiteren Sprachelementen r StateMachine Entry Point Refere
243. ktmodellierungssprache anwenden Addison Wesley 1998 188 Seiten Mein Favorit unter den vielen neuen B chern die die objektorientierte Softwareentwicklung mit UML zum Thema haben Sch n kompakt leicht lesbar und mit vielen wertvollen Literaturhinweisen B Henderson Sellers Object Oriented Metrics Measures of Complexity Prentice Hall 1996 Eines der ersten B cher das sich mit der Definition von Softwaremetriken f r objektorientierte Pro gramme Modelle befa t So01 I Sommerville Software Engineering Addison Wesley Pearson Studium 6 Auflage 2001 711 Seiten Wieder aktuelles in Deutsch bersetztes Lehrbuch das sehr umfassend alle wichtigen Themen der Soft ware Technik knapp behandelt Empfehlenswert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 563 Fachgebiet f Qualitatssicherung und Testverfahren Echtzeit 3 systeme Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 564 Management der Software Entwicklung Echte die systeme 10 Management der Software Entwicklung Themen dieses Kapitels U Fehlende Phasen des Wasserfallmodells bessere modernere Prozessmodelle Verbesserung Qualit t von Softwareprozessmodellen Kostensch tzung Zeitplanung f r Entwicklungsprozesse E E E E Projektmanagement werkzeuge Achtung Viele im folgenden vorgestellten berlegungen sind nicht ausschlie lich f r Software Entwicklun
244. len zu viele Fehlermeldungen wenn vor lesendem Zugriff auf Variable auf jedem Programmpfad Zuweisung gefordert wird zu wenige Fehlermeldungen wenn vor lesendem Zugriff auf Variable nur auf einem Programmpfad Zuweisung gefordert wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 548 Qualit tssicherung und Testverfahren Echtzeit ip systeme Auf Kontrollflussgraph basierende Softwaremetriken PROCEDURE countVowels s Sentence VAR count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER Kontrollflussgraph BEGIN mit 7 Knoten count 0 i 0 8 Kanten WHILE s i DO IF sli a OR sli e OR s il i OR slil o OR sli u THEN count count 1 END i i 1 END countVowels Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 549 Qualit tssicherung und Testverfahren Echtzeit g systeme Lines of Code LOC LOC Komponente Anzahl der Knoten im Kontrollflussgraphen dazu Beispiel LOC countVowels 7 Idee dieser Ma zahl lt gt Komponenten mit hoher LOC sind zu komplex no separation of concerns und deshalb fehlertrachtig Komponenten mit geringer LOC sind zu klein und f hren zu unn tigen Schnittstellenproblemen Probleme mit dieser Ma zahl Kanten Kontrollflusslogik spielen k
245. len Identifikation der Grenze zwischen Softwaresystem und Au enwelt Skizze der zugeh rigen Benutzeroberfl che ggf Prototypbau Zusammenfassung hnlicher Szenarien zu Anwendungsf llen Use Cases manchmal auch Nutzf lle genannt berblick ber Anwendungsf lle durch Anwendungsfalldiagramme Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 155 Objektorientierte Anforderungsanalyse rg J g y systeme Bestimmung geeigneter Szenarien oder Anwendungsf lle LJ man nehme die Produktfunktionen aus dem Lastenheft verschiebt Problem U alle Verben in einer Softwareproduktbeschreibung markieren Motor Vehicle Reservation System A rental office lends motor vehicles of different types The assort ment comprises cars vans and trucks Vans are small trucks which may be used with the same driving license as cars Some client may reserve motor vehicles of a certain category for a certain period He or she has to sign a reservation contract The rental office guaran tees that a motor vehicle of the desired category will be available for the requested period The client may cancel the reservation at any time When the client fetches the motor vehicle he or she has to sign a rental contract and optionally an associated insurance contract Within the reserved period at latest at its end the client returns the motor vehicle and pays the bill Prof Dr Andy Sch rr TU Darmstadt FB 1
246. llung gt Engineering Bereich Software Entwicklung Anforderungsanalyse Systemintegration Software Wartung Support Bereich Qualit tssicherung gt Management Bereich Projekt Management gt Organisations Bereich Prozess Verbesserung gt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 607 Fachgebiet Management der Software Entwicklung Echtzeit dp systeme CMMI Capability Maturity Model Integration neue Version von CMM CMMI ist die neue Version des Software Capability Maturity Model Es ersetzt nicht nur verschiedene Qualit ts Modelle f r unterschiedliche Entwicklungs Diszipli nen z B f r Software Entwicklung oder System Entwicklung sondern integriert diese in einem neuen modularen Modell Dieses modulare Konzept erm glicht zum einen die Integration weiterer Entwicklungs Disziplinen z B Hardware Entwick lung und zum anderen auch die Anwendung des Qualit tsmodells in bergreifenden Disziplinen z B Entwicklung von Chips mit Software Geschichte von CMM und CMMI gt 1991 wird Capability Maturity Model 1 0 herausgegeben 1993 wird CMM berarbeitet und in der Version 1 1 bereitgestellt 1997 wird CMM 2 0 kurz vor Verabschiedung vom DoD zuriickgezogen 2000 wird CMMI als Pilotversion 1 0 herausgegeben 2002 wird CMMI freigegeben Ende 2003 ist die Unterstiitzung CMM ausgelaufen Prof Dr Andy Schiirr TU Darmstadt FB 18
247. lt database gt gt bei Datenbankanwendungen oder Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 432 Objektorientierter Softwareentwurf Dann Zerlegung des Klassenmodells der Analyse Model has Reservation Contracts hasVehicles gt disjoint 4S M 3 x Vehicle 7 overlapping 4S Behandlung paketuber reifender ssoziationen Fachgebiet Echizeit systeme Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 433 Objektorientierter Softwareentwurf Echtsslt systeme Pakete fur fachliches Modell package MVRS Model LegalEntities Contract import ReservationContract MVRS Model Vehicles RentalContract i A er oder nur Motorvehicle importieren Bill import Vehicles Motorvehicle Motorvehicle LegalEntity Car Company Truck Person Van RentalOffice Employee Client Referenz auf Klasse aus Paket Vehicles Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 434 Objektorientierter Softwareentwurf Echte dec systeme Achtung bei Assoziationen ber Paketgrenzen hinweg Ist eine Assoziation gerichtet dann muss nur Paket der Quellklasse die Zielklasse importieren ansonsten ben tigt man Import in beide Richtungen Das sollte man wenn m glich vermeiden und Klassen in einem Paket deklarieren Beispiel mit ungericht
248. mbenennung oder Verschieben in ein anderes Paket Klasse kann nicht mehr benutzt werden Klasse l schen kann nicht mehr benutzt werden Klasse hinzuf gen ggf Namenskonflikte mit gleichnamigen Klassen Oberklassen hinzuf gen neue abstrakte Methoden zu realisieren Oberklassen l schen bislang geerbte Methoden und Attribute fehlen O nderungen an Interfaces Methoden von Klassen Umbenennen f hrt zu hnlichen Problemen wie Umbenennen von Klassen L schen betroffene Methoden k nnen nicht mehr gerufen werden Hinzuf gen eines Interfaces betroffene Methoden m ssen erst noch neu implementiert werden es kann Namenskonflikte geben Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 479 Objektorientierter Softwareentwurf Eon A systeme Beispiele f r nicht abw rtskompatible Schnittstellen nderungen 2 O nderungen an Methoden Hinzuf gen abstrakter Methode muss in Unterklassen realisiert werden Umbenennen L schen Sichtbarkeit einschr nken Methode kann ggf nicht mehr gerufen werden Sichtbarkeit erweitern von private auf protected in Unterklassen kann es zu Konflikten mit gleichnamigen Methoden kommen Methode von nicht final auf final setzen gt O nderungen an Ausnahmen von Methoden lt gt Umbenennen L schen Aufrufer der Methode d rfen die Ausnahme nicht mehr abfan gen Redefinitionen der Methode k nnen Ausnahme nicht mehr
249. ment der Software Entwicklung Eon ES systeme Bewertung des evolution ren Modells es ist sehr fr h ein durch Kunden evaluierbarer Prototyp da Kosten und Leistungsumfang des gesamten Softwaresystems m ssen nicht zu Beginn des Projekts vollst ndig festgelegt werden Projektplanung vereinfacht sich durch berschaubarere Teilprojekte Systemarchitektur muss auf Erweiterbarkeit angelegt sein es ist schwer Systemarchitektur des ersten Prototypen so zu gestalten dass s e alle sp ter notwendigen Erweiterungen erlaubt Prozess der Prototyperstellung nicht festgelegt Spiralmodell von Berry B hm integriert Phasen des Wasserfallmodells evolution re Entwicklung der Anforderungsdefinition birgt Gefahr in sich dass bereits realisierte Funktionen hinf llig werden Endresultat sieht ggf wie Software nach 10 Jahren Wartung aus Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 582 Management der Software Entwicklung Echte dec systeme Rapid Prototyping Throw Away Prototyping Mit Generatoren ausf hrbaren Spezifikationssprachen Skriptsprachen etc wird Prototyp des Systems seiner Benutzeroberfl che realisiert dem Kunden demonstriert und anschlie end weggeschmissen Bewertung erlaubt schnelle Kl rung der Funktionalit t und Risikominimierung Vermeidung von Missverst ndnissen zwischen Entwickler und Auftraggeber fr her Test der Benutzerschnittstelle
250. ments Pflichtenheft mit detailierter Beschreibung der Aufgaben der neu zu entwickelnden Software immer noch steht was f r Funktionalit t ben tigt wird und nicht wie die gew nschte Funktionalit t zu realisieren ist im Vorder grund siehe Kapitel 5 Software Requirements Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 73 f Fachgebi Requirements Engineering und Machbarkeitsstudie Echtzeit gg systeme Anzahl und Auswirkung von Anforderungsfehlern WW00 20 0 Wartung In Phase X beseitigte Fehler k nnen aus I Phase X stammen oder Folgefehler von Fehlern in einer fr heren Phase sein 5 0 Akzeptanztest Fazit Fast 1 4 aller Anforderungsfehler bleibt bis zur Auslieferung unentdeckt Die 2 0 MDOLNERN Beseitigung dieser Fehler bei der 1 0 Codierung Wartung statt bei der Analyse ist 5 Design 200 Mal so teuer 0 1 Analyse zeitlicher Projektverlauf Phasen Cc oO x O x 2 ta LL Cc oO gt Cc rep O x Fehlerursprung relative Fehlerzahl Eliminationsrate ausgelieferte Fehler Analyse Design Codierung Sonstige Insgesamt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 74 hgebi Requirements Engineering und Machbarkeitsstudie Een ES systeme Arten von Anforderungen LI funktionale Anforderungen beschreib
251. mer double totalAmount 0 int frequentRenterPoints 0 Enumeration rentals _rentals elements String result Rental Record for getName n while rentals hasMoreElements double thisAmount 0 Rental each Rental rentals nextElement determine amounts for each line switch each getMovie ee case Movie REGULAR thisAmount 2 if each getDaysRented gt 2 thisAmount each getDaysRented 2 1 5 break case Movie NEW_RELEASE thisAmount each getDaysRented 3 break case Movie CHILDREN thisAmount 1 5 if each getDaysRented gt 3 thisAmount each getDaysRented 3 1 5 break Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 449 Objektorientierter Softwareentwurf Echteslt systeme Beispielprogramm Fortsetzung still inside the while statement add frequent renter points frequentRenterPoints add bonus for a two day new release rental if each getMovie getPriceCode Movie NEW_RELEASE amp amp each getDaysRented gt 1 frequentRenterPoints show figures for this rental result t each getMovie getTitle t String valueOf thisAmount n totalAmount thisAmount add footer lines result Amount owed is String valueOf totalAmount n result You earned String valueOf frequentRenterPoints frequent renter points return
252. mte Zeit au ese viert u MakeRese CancelReservation gt Reservierung wird gel scht MVRS_Vehicles D 5 i 2 tae D i Neues Fahrzeug wird in Fuhrpark aufgenommen __AddVehicle gt g p g _FetchVehice_ 2 Fahrzeug wird abgeholt _ReturnVehicle_ gt Fahrzeug wird zur ckgebracht _RemoveVehicle_ gt Fahrzeug wird ausgemustert N Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 166 Objektorientierte Anforderungsanalyse Echtzeit systeme Kommentare zu Beziehungen zwischen Akteuren LI solche Beziehungen sieht man nur selten da in der Regel nur die Akteure modelliert werden die mit dem System direkt interagieren LJ manchmal ist es aber sinnvoll auch indirekte Kunden eines Systems aufzuf hren und sie mit den eigentlichen Akteuren zu verbinden die Beziehung Assoziation zwischen Client und Clerk deutet an dass Clerks bei der MVRS Se ne mit Clients interagieren wieviele Clients inter wieviele Clerks inter agieren mit einem a gt agieren mit einem Clerk gleichzeitig IN 4 Client gleichzeitig LI die zus tzliche Multiplizit ten Zahlen an der Beziehungslinie deuten an dass ein Clerk mit maximal 2 Clients gleichzeitig interagieren darf aber auch mal keinen Kunden haben kann gt ein Client mit genau einem Clerk interagiert das ist der Standard fall der normalerweise nicht dargestellt wird Prof Dr Andy
253. n Software Engineering Een ES systeme Wichtige Literaturquellen Ba96 H Balzert Lehrbuch der Software Technik Band 1 Software Entwicklung Spektrum Akademischer Verlag 2000 2 te Auflage 1136 Seiten Sehr umfangreiches und gut lesbares Nachschlagewerk mit CD Auf der CD findet man Werkzeuge Videos bungsaufgaben mit L sungen aber nicht unsere H Balzert Lehrbuch der Objektmodellierung Analyse und Entwurf Spektrum Akademischer Verlag 1999 573 Seiten Im gleichen Stil wie Ba96 geschriebenes Buch das eine gute Erg nzung zu Kapitel 5 und 6 der Vorle sung darstellt Wieder ist eine CD mit Werkzeugen beigelegt S007 I Sommerville Software Engineering Addison Wesley Pearson Studium 6 Auflage 2007 875 Seiten In Deutsch bersetztes Standardlehrbuch das sehr umfassend alle wichtigen Themen der Software Tech nik Knapp behandelt Empfehlenswert St05 H St rrle UML2 f r Studenten Pearson Studium 2005 320 Seiten Leider bislang nur in Deutsch verf gbare Einf hrung in UML2 die Standard Softwaremodellierungs sprache Version 2 beschr nkt sich auf wichtige Sprachelemente und verwendet ein durchg ngiges Beispiel hnlich wie diese Lehrveranstaltung Das Buch ist ohne Vorkenntnisse gut zu verstehen GH95 E Gamma R Helm und R E Johnson Design Patterns Elements of Reusable Object Oriented Soft ware Addison Wesley 1995 385 Seiten Der Klassiker zum Thema wiederverwendbarer Sof
254. n benutzt werden Es besteht aus einer Datenbasis in der die Daten abgelegt werden und dem Ver waltungsprogramm Datenbasismanagement das die Daten entsprechend der vorgegebenen Beschreibung abspeichern auffinden oder weitere Operationen durchf hren kann Informatikduden Eine Datenbank ist eine Sammlung von Informationen zu einem bestimmten Thema oder Zweck wie z B dem Verfolgen von Bestellungen oder dem Ver walten einer Musiksammlung Wenn Ihre Datenbank nicht oder nur teilweise in einem Computer gespeichert ist miissen Sie die Informationen aus den ver schiedenen Quellen selbst koordinieren und organisieren MS Access Online Hilfe Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 256 Von der OO Analyse zum Datenbank Entwurf Echizeit ick systeme Typische Beispiele fur Datenbankanwendungen Informationssysteme LI Soziale Netze Wissens Datenbanken Facebook Google Anfange der Datenbanken Speicherung dauerhafter Informationen Anfang der 60er Jahre elementare und anwendungsspezifische Dateien Ende der 60er Jahre Dateiverwaltungssysteme Sequential Access Memory Index Sequential Access Memory als Betriebssystem Aufs tze 70er Jahre erste echte Datenbanksysteme seitdem einerseits Standards andererseits viele Speziall6sungen fiir bestimmte Anwendungsbereiche wie viele Terabytes Datenverwaltung bei Google Prof Dr Andy Sch rr TU Darms
255. n result public int getTotalCharge int result 0 Enumeration rentals _rentals elements while rentals hasMoreElements result Rental rentals nextElement getCharge return result F public int getTotalFrequentRenterPoints int result 0 Enumeration rentals _rentals elements while rentals hasMoreElements result Rental rentals nextElement getFrequentRenterPoints gt return result is Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 459 Fachgebiet Objektorientierter Softwareentwurf Echtzeit dp systeme Nachteile der neuen Implementierung LI die Methode getCharge wird f r jedes Rental bzw Movie Objekt zweimal aufge rufen einmal in statement und einmal in getTotalCharge U anstelle einer Schleife ber alle Rental Objekte gibt es nunmehr in drei verschiedenen Methoden jeweils eine eigene Schleife Refactoring Schritte zur Effizienzsteigerung U Charge eines Rental Objektes wird bei Erzeugung berechnet und gespeichert getCharge liefert dann nur gespeicherten Wert zur ck dieser Schritt nennt sich Caching von Methoden bzw Funktionswerten in Attributen gleiches k nnte man f r TotalCharge und TotalFrequentRenterPoints tun f r neuen Kunden sind beide Werte gleich 0 sie werden f r jedes neu hinzukom mende Rental Objekt danach erh ht Achtung effizienzsteigernde Refactoring Schritte nur dann durchf hren
256. n zu befreien Anmerkung Die Firma Rational wurde von IBM aufgekauft Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 147 Grundlagen der objektorientierten Modellierung one ipo systeme Die Historie des OO Modellierungsstandards UML Oktober 1994 Rumbaugh wechselt von GE zu Rational Booch Oktober 1995 Unified Method 0 8 OMT Rumbaugh OOD Booch Herbst 1995 Jacobson wechselt von Objective zu Rational damit sind die Three amigos vereint Juni 1996 Unified Modeling Language 0 9 mit Use Cases von Jacobson und Unterstiitzung durch DEC HP IBM Microsoft Oracle Januar 1997 UML 1 0 wird zur Standardisierung bei OMG Object Management Group eingereicht September 1997 UML 1 1 mit erweiterter Beschreibung und Erg nzungen insbesondere logikbasierte Object Constraint Language OCL November 1997 OMG akzeptiert berarbeitete UML als Standard August 2005 UML 2 0 wird als Standard verabschiedet seitdem UML 2 1 2007 UML 2 2 2009 UML 2 3 2010 UML 2 4 Beta 2011 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 148 Grundlagen der objektorientierten Modellierung Een ES systeme St rken und Schw chen von UML ein so genanntes Metamodell in Form von Klassendiagrammen lest relativ pr zise die Syntax der unterst tzten Diagrammarten fest die Semantik der Diagrammarten wird noch weitgehend in Prosa erl
257. nalyse Echtzeit systeme Identifikation von Klassenkandidaten im Flie text Q alle Substantive in einer Softwareproduktbeschreibung markieren Motor Vehicle Reservation System A rental office lends motor vehicles of different types The assort ment comprises cars vans and trucks Vans are small trucks which may be used with the same driving license as cars Some client may reserve motor vehicles of a certain category for a certain period He or she has to sign a reservation contract The rental office guaran tees that a motor vehicle of the desired category will be available for the requested period The client may cancel the reservation at any time When the client fetches the motor vehicle he or she has to sign a rental contract and optionally an associated insurance contract Within the reserved period at latest at its end the client returns the motor vehicle and pays the bill Synonyme identifizieren wie Type und Category in dem obigen Text Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 189 jektorienti u Echuet AS Objektorientierte Anforderungsanalyse systeme Identifikation von Klassenkandidaten im Flie text 2 LJ irrelevante Klassenkandidaten streichen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 190 Objektorientierte Anforderungsanalyse Eenzet ES systeme Aufbau von Klassen Name ReservationContract falls
258. nalyse zum Entwurf Problemgebiet Objekte und Abl ufe im Umfeld gt Autovermietung Produktfunktionen und daten aus Anwendersicht Produktfunktionen und daten aus Entwicklersicht Entwurfsmodell Architektur des Produkts L_ Motor Vehicle S Reservation Systems Implementierung des Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 418 Objektorientierter Softwareentwurf Echteslt systeme Typische Bestandteile einer Softwarearchitektur LJ anwendungsspezifische Funktionen und Daten in Analyse betrachtet Details der Benutzungsoberfl che Standards GUI Bibliotheken Ablaufsteuerung mit Transaktionen Datenhaltung in Dateien Datenbanken Infrastrukturdienste f r Objektverwaltung Garbage Collection Prozesskommunikation Sicherheitsfunktionen Verschl sselung Passwortschutz Zuverl ssigkeitsfunktionen Fehlererkennung und behebung Systemadministration Statistiken Installation Sicherungen weitere Basisbibliotheken f r ar thmetische Funktionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 419 Fachgebiet f Objektorientierter Softwareentwurf Echtzeit 3 Zur Erinnerung Panung Kundenanforderungen z B als Lastenheft siehe Abschnitt 3 3 Analyse konzept Datenmodell UML Class Diagrams siehe Abschnitt 5 3 feines Klassenmodell Cla
259. nd Professoren nicht garantiert wird dass es zu jeder Vorlesung mindestens einen Professor gibt das geht auch ber Prim r und Fremdschl ssel nicht es wird garantiert dass es zu jeder Kombination aus Student und Vorlesung die er tats chlich h rt genau einen Professor gibt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 284 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Kapazitatserhohende Abbildung von Assoziation auf eigene Relation Variante 1 Variante 2 B Ay A B A und B als Schl ssel jeweils f r sich A B Relationenschema R A R hat nur A als Schl ssel K Beispiele f r Relationen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 285 Von der OO Analyse zum Datenbank Entwurf Ente Q systeme Kapazit tsvermindernde Abbildung von Assoziation auf eigene Relation Variante 1 Variante 2 R A B Relationenschema R A B K A K R hat A als Schl ssel A B Paar A B als Schl ssel Beispiele f r Relationen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 286 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme 6 4 Funktionale Abh ngigkeiten und Normalformen Aus Klassendiagrammen abgeleitete oder direkt entworfene Relationenschemata erz wingen oft Redundanzen bei der Speic
260. nden MovieState Klassen erzeugt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 505 Objektorientierter Softwareentwurf Echtzeit A systeme Struktur des Abstract Factory Musters een 5 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 506 Objektorientierter Softwareentwurf Echteslt systeme Erl uterungen zum Abstract Factory Muster Q Ein Client bekommt eine Instanz der Klasse AbstractFactory bergeben die ent weder zur Unterklasse ConcreteFactory1 oder ConcreteFactory2 geh rt Erzeugung einer Instanz einer dieser beiden Unterklassen k nnte wieder durch ein Factory Entwurfsmuster geregelt werden Wenn die Client Instanz ein Objekt der Klasse AbstractProductA oder der Klasse AbstractProductB ben tigt ruft sie die entsprechenden Methoden der bergebe nen AbstractFactory Instanz auf Die createProduct lt x gt Methoden der ConcreteFactory lt i gt erzeugen dann Instanzen der Unterklasse ConcreteProduct lt x gt lt i gt Die Client Instanz wei aber nur dass Instanzen der abstrakten Klassen AbstractProduct lt x gt erzeugt werden So kann man mit Hilfe einer Abstract Factory die Algorithmen zur Auswahl der Klasse zu erzeugender Objekte f r mehrere abstrakte Produktklassen gleichzeitig ausw hlen und umschalten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 507 Objektorie
261. ndy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 251 bi Objektorientierte Anforderungsanalyse Eon A systeme Aufbau eines Pflichtenheftes 6 10 Nichtfunktionale Anforderungen neuer Abschnitt Alle in den bisherigen Kapiteln nicht unterzubringenden Anforderungen werden hier aufgef hrt einzuhaltende Gesetze Normen Sicherheitsanforderungen Technische Produktumgebung neuer Abschnitt Die Umgebung wird beschrieben in der das zu erstellende Produkt eingesetzt wird Dabei wird wie folgt unterteilt gt Hardware auf der Produkt l uft meist werden zur Beschreibung entwe der Flie text oder diverse Diagrammarten wie Datenfluss Diagramme s Seite 110 oder UML Deployment Diagramme siehe Kapitel 7 eingesetzt Software die Produkt voraussetzt mit Beschreibung von Schnittstellen meist werden zur Beschreibung Flie text oder UML Klassendiagramme eingesetzt ggf auch UML Komponentendiagramme s Kapitel 7 Orgware organisatorische Randbedingungen die erf llt sein m ssen Achtung bei eingebetteten Systemen direkt nach Kapitel 3 oder Kapitel 4 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 252 Objektorientierte Anforderungsanalyse Eon ES systeme Aufbau eines Pflichtenheftes 7 12 Entwicklungsumgebung neuer Abschnitt Die Umgebung wird beschrieben in der das zu erstellende Produkt entwickelt wird Entwicklungsplattform
262. neering Lehrveranstaltungen bilden und Interesse an dieser Thematik wecken solides Handwerkszeug f r Durchf hrung von Bachelor Arbeiten etc vermitteln dabei Konzentration auf objektorientierte Standardmodellierungssprache UML erste Erfahrungen mit Computer Aided Software Engineering Werkzeugen die Erhebung Analyse und Dokumentation von Anforderungen lernen mit halbformalen Methoden mit grafischen Notationen das Design von Software Architekturen und Umsetzung in Code ben Einblick in das Design von Datenbanken erhalten formale re Grundlagen von UML Teilen durch Petri Netz Exkurs Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 3 Einf hrung in Software Engineering Echtzeit systeme bungen LJ Organisation als Teams von jeweils etwa 3 bis 4 Studenten es gibt korrigierte Hausaufgaben bungsaufgaben E LJ in Pr senz bungen werden Aufgaben anhand von Musterl sungen besprochen E Einsatz eines CASE Tools in Rechnerpools oder zum Selberinstallieren Bonussystem maximaler Bonus von 0 4 auf Klausurnote falls bestanden gt jedes Ubungsblatt mit mindestens 50 der Punkte ergibt 0 05 Bonus gt maximal 8 von insgesamt 11 bungsbl tter werden also ber cksichtigt Betreuer Erhan Leblebici erhan leblibici es tu darmstadt de Gergely Varro gergely varro es tu darmstadt de Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 4
263. nen Stakeholder Gruppen ist es die Aufgabe des Software Entwicklers diese zu schlichten moderieren aufzul sen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 78 Requirements Engineering und Machbarkeitsstudie Echtzeit g systeme Interviews mit verschiedenen Interessentengruppen Durch Interviews Fragen vorher vorbereiten oder Fragebogenaktionen wird Bestandsaufnahme Domain Analyse der Umgebung in der Software Produkt eingesetzt werden soll durchgef hrt Man versucht Antworten auf etwa folgende Fragestellungen zu erhalten Profil des Kunden Aufgaben Produkte Erfolgsma e LJ Probleme des Kunden welche Abl ufe sind ineffizient fehlertr chtig wie werden die beschriebenen Probleme bisher gel st wie in Zukunft Umgebung des Kunden welche Benutzer was f r Hardware Plattform erwartete Eigenschaften des Software Produktes Funktionen Zuverl ssigkeit Support Installation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 79 Requirements Engineering und Machbarkeitsstudie Echtecit systeme Viewpoint getriebenes Requirements Engineering LJ durch Interessentengruppen definierte Sichten auf ein Software System sind ein effektives Hilfsmittel den Prozess der Anforderungsanalyse zu organisieren andere m gliche Arten von Sichten Viewpoints sind Orientierung an Funktionsgruppen R
264. nik Seite 275 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme Konzeptioneller Entwurf Erste formalere Beschreibung des Fachproblems der zu speichernden Daten heute in aller Regel mit Klassendiagrammen Vorgehensweise LJ Modellierung von Sichten z B je Fachabteilung oder Benutzergruppe eine Sicht LJ Analyse der vorliegenden Sichten in Bezug auf gt Namenskonflikte Homonyme Kunde Synonyme Auto lt gt KFZ Typkonflikte verschiedene Strukturen f r das gleiche Element Wertebereichskonflikte verschiedene Wertebereiche f r ein Attribut Bedingungskonflikte z B verschiedene Schl ssel oder Kardinalit ten gt Modellierungskonflikte gleicher Sachverhalt unterschiedlich modelliert LJ Integration der Sichten in ein konzeptionelles Gesamtschema Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 276 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit systeme Logischer Entwurf Umsetzung des konzeptionellen Entwurfs in Datenmodell des Realisierungs DBMS in aller Regel heute immer noch das relationale Modell Vorgehensweise 1 automatische Transformation des konzeptionellen Schemas also Klassendiagramme ER Modelle relationale Modelle Verbesserung des relationalen Schemas anhand von G tekriterien Normalformen durch entsprechende Normalisierungsalgorithmen Es entsteht so ein logisches relationales Datenbankschema das Datenred
265. nik Seite 500 Objektorientierter Softwareentwurf Echteslt systeme Das Entwurfsmuster Singleton verk rzte Beschreibung LJ Name Singleton LJ Absicht Realisierung einer Klasse mit genau einer Instanz LJ Motivation anstelle von Klassen mit einer Instanz werden ggf nicht instanziier bare Klassen mit statischen Attributen und Methoden verwendet Oft ben tigt man jedoch aus technischen Gr nden Vererbung bergabe der Objekte als Parameter Objekte solcher Klassen Die Implementierung muss aber sicherstellen dass es nur genau eine Instanz der entsprechenden Klasse gibt Singleton _instance null _instance Singleton Singleton getInstance if instance null getinstance Singleto oo new Singleton return _instance Singleton Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 501 Objektorientierter Softwareentwurf Een ie systeme Das Entwurfsmuster Factory verk rzte Beschreibung U Name Factory LJ Absicht eine Factory verkapselt die Erzeugung von Objekten Der Anwender ruft eine Operation der Factory zur Erzeugung von Objekten einer anderen Klasse auf anstatt direkt den Konstruktor der anderen Klasse zu rufen Motivation oft soll bei der Objekterzeugung verborgen bleiben zu welcher Unterklasse einer abstrakten Oberklasse ein Objekt geh rt um so einen Algorithmus f r die Auswahl der Unterklasse in einer eigenen Klasse zu versteck
266. nmerk auf parallel durchf hrbare Aktionen gerichtet wird erster Zusammenhang zwischen Objekten und Aktionen geschaffen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 226 Objektorientierte Anforderungsanalyse Echte d systeme Vorbemerkungen zu den Aktivit tsdiagrammen U Aktivit tsdiagramme sind die j ngste Diagrammart der UML Familie und wurden in UML 2 0 komplett neu definiert LJ sie sind ein Hybrid aus den alten Datenflussdiagrammen siehe Abschnitt 4 1 Seite 110 gt den hoffentlich aus dem Studium bekannten Kontrollflussdiagrammen gt den gerade vorgestellten Petri Netzen sie werden gt sowohl als visuelle Programmiersprache f r die Implementierung einzelner Operationen von Klassen gt als auch zur Modellierung von Gesch ftsprozessen eingesetzt Zusammenhang von Anwendungsfallen und Detailierung LJ es handelt sich also um eine prinzipiell ausf hrbare Diagrammart im Gegensatz zu den bisherigen Diagrammarten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 227 Fachgebiet f Echtzeit amp Objektorientierte Anforderungsanalyse systeme Aktivit tsdiagramm MakeReservation f r einfachen Anwendungsfall Aktivit t MakeReservation Anfang Kontroll fluss Aktion FindClientInDB FindVehicles determines set of all vehicles vs of category c Selects free vehicle v for SelectFreeVehicle given period
267. nnerhalb desselben Pakets k nnen auf das Attribut zugreifen L Name irgendeine Attributbezeichnung die innerhalb der Klasse eindeutig ist ist dem Namen ein vorangestellt so ist es ein abgeleitetes Attribut Wert bestimmt sich durch Rechenvorschrift und nicht durch Zuweisung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 194 hgebi Objektorientierte Anforderungsanalyse Eon ES systeme Aufbau einer Attributdeklaration 2 Typ eines Attributs in Programmiersprache definierter Typ wie int float Name einer Hilfs Klasse f r Attributwerte die einfache Objekte sind Q Multiplizitat mit Aufbau lt untere Grenze gt lt obere Grenze gt oder lt Zahl gt 0 1 optionales Attribut mit erlaubtem null Wert 0 mengenwertiges Attribut auch leere Menge m n Attributmenge mit m bis n Elementen n genau n Elemente enth lt das mengenwertige Attribut 1 genau ein Wert der Normalfall wenn keine Multiplizit t sichtbar ist Q Wert Rechenvorschrift f r Attribut oft eine Konstante bei normalen Attributen gibt Ausdruck Initialwert an bei abgeleiteten Attributen die Berechnungsvorschrift Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 195 Objektorientierte Anforderungsanalyse Echte dec systeme Aufbau einer Attributdeklaration 3 L Menge von Attribu
268. nnung interne konzeptuelle Ebene navigierende Anfragesprachen entlang Zeigerstrukturen amp Trennung Datenbanksprache Programmiersprache ab 70er Jahre relationale Datenbanksysteme Daten in Tabellenstruktur 3 Ebenen Konzept externe konzeptuelle interne Ebene deklarative standardisierte Datenbanksprache SQL Trennung Datenbanksprache Programmiersprache Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 263 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme ab 80er Jahre Wissensbanksysteme deduktive Datenbanken Daten in Tabellenstruktur stark deklarative Anfragesprachen logikbasiert integrierte Datenbankprogrammiersprache objektorientierte graphartige Datenbanksysteme Daten in komplexeren Objektstrukturen navigierende oder deklarative Anfragesprache oft OO Programmiersprache Datenbankprogrammiersprache oft keine vollst ndige Ebenentrennung geographische Datenbanksysteme meist spezielle Erweiterungen relationaler oder objektorientierter Systeme neben normalen Daten gibt es geometrische Daten 2D 3D gt spezielle Indexstrukturen unterst tzen r umliche Anfragen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 264 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Relationale Datenbank Management Systeme RDBMS Gemeinsame Merkmale Drei Ebenen Arch
269. nsistenz sind die beschriebenen Anforderungen widerspruchsfrei oder kann ein System mit diesen Anforderungen nicht realisiert werden Vollst ndigkeit fehlen Beschreibungen von Anforderungen f r wichtige Funktionen oder Beschreibungen von Teilaspekten einzelner Funktionen Machbarkeitspr fung kann ein System das die beschriebenen Anforderungen erf llt in einem realistischen Zeitraum mit vetretbaren Kosten realisiert werden berpr fbarkeit kann man die beschriebene Anforderung durch einen Abnahmetest bei der Auslieferung des Systems berpr fen Verfolgbarkeit sind die Gr nde Motivation f r die Aufnahme einer bestimmten Anforderung bekannt stichhaltig und dokumentiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 83 Requirements Engineering und Machbarkeitsstudie Een A systeme 3 3 Aufbau und Funktion eines Lastenheftes Ein Lastenheft f r ein Software Produkt ist nach Ba96 wie folgt aufgebaut Zielbestimmung welche Ziele sollen mit dem Software Produkt erreicht werden Produkteinsatz Anwendungsbereiche und Stakeholders werden genannt Produktfunktionen Hauptfunktionen werden beschrieben Stakeholdergruppen zugeordnet und in 10er Schritten durchnummeriert LF nn Produktdaten permanent gespeicherte Hauptdaten werden festgelegt und in 10er Schritten durchnummeriert LD nn Produktleistungen besondere Anforderungen an Hauptfunktionen oder Haupt daten Ausf hrung
270. nszeit von Movie Objekt ndert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 464 Objektorientierter Softwareentwurf Echtzeit ec systeme Refactoring Schritt Replace Type Code by State Class f r Movie public class Movie public static final int CHILDREN 2 private String _title private MovieState _movieState public Movie String title int priceCode _title title setPriceCode priceCode public void setPriceCode int arg switch arg case Movie REGULAR _movieState new RegularMovie break case Movie NEW_RELEASE _movieState new NewMovie break case Movie CHILDREN _movieState new ChildrenMovie break public int getPriceCode return _movieState getPriceCode public double getCharge int daysRented hat sich berhaupt nicht ge ndert da alle Zugriffe auf PriceCode ber Methode getPriceCode realisiert waren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 465 Objektorientierter Softwareentwurf Echteslt systeme Die neuen State Klassen fur Movie abstract class MovieState abstract int getPriceCode class RegularMovie extends MovieState int getPriceCode return Movie REGULAR class NewMovie extends MovieState int getPriceCode return Movie NEW_RELEASE class ChildrenMovie extends MovieState int getPriceCode return Movie CHIL
271. ntal getDaysRented gt 3 result aRental getDaysRented 3 1 5 break return result i Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 454 Objektorientierter Softwareentwurf Echte dec systeme Dritter Refactoring Schritt MoveMethod Die Methode amountFor der Klasse Customer f hrt ausschlie lich Berechnungen auf Attributen der Klasse Rental durch Sie ist deshalb in der falschen Klasse deklariert Eine Verschiebung der Methode erfolgt in vier Schritten mit Test dazwischen die Klasse Rental erh lt eine Kopie der Methode amountFor der Klasse Customer Implementierung alter Methode wird durch Aufruf der neuen Methode ersetzt ggf werden Aufrufe der alten Methode durch Aufrufe der neuen Methode ersetzt alte Methode wird gel scht sobald sie nicht mehr aufgerufen wird public class Customer i i public class Rental public double getCharge double result 0 switch getMovie getPriceCode A return result Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 455 Objektorientierter Softwareentwurf Echte dec systeme Die ver nderte Methode statement von Customer public String statement creates listing text output with all available information about given customer double totalAmount 0 int frequentRenterPoints 0 Enumeration rentals _rentals elements String result Rental
272. ntechnik Seite 511 Objektorientierter Softwareentwurf Echteslt systeme Das Entwurfsmuster Chain of Responsibility verkurzte Beschreibung Name Chain of Responsibility Absicht die Durchf hrung einer Berechnung wird teilweise an eine Kompo nente der betrachteten Klasse delegiert Motivation auf diese Weise lassen sich komplexe Berechnungen in eigene leichter nderbare Klassen auslagern und der Aufrufer der Berechnung wird von der Durchf hrung der Berechnung entkoppelt Zwischenstationen k nnen zus tzliche Teilberechnungen einf hren Beispiel get Total Charge und get Total F requent R enter P oints Implementierung die Delegation von Aufrufen an vorhandene Klassen wird oft beispielsweise anstelle der Vererbung und Redefinition von Methoden als besseres Entwurfsmittel eingesetzt aber berm ige Verwendung langer Verantwortlich keitsketten f hrt zu ineffizienter und schwer zu ndernder Software siehe zu eliminierende middleman Klassen beim Refactoring Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 512 Objektorientierter Softwareentwurf Chains of Responsibility im Beispiel getCharge double getFRP int Bien en RentalComponent _dateRange String RentalComponent getDateRange Strin getCharge doubie getFRP int D r y _movie Movie I _daysRented int I charge double iterate Rentallteratc Vee first Index
273. ntierter Softwareentwurf Een EX systeme Das Entwurfsmuster Flyweight verk rzte Beschreibung Q Name Flyweight Fliegengewicht LJ Absicht ben tigt man sehr viele kleine und immer identische Objekte so erzeugt man diese nur einmal speichert sie an geeigneter Stelle in einer Factory und verwendet sie immer wieder Motivation oft werden in einem Programm viele kleine Objekte angelegt die alle denselben Zustand besitzen Mit dem Flyweight Pattern erzeugt man je ben tigtem Zustand nur ein Objekt und verwendet diese immer wieder shared objects Man spart sich so die Laufzeit f r die Erzeugung und L schung der Objekte sowie den Speicherplatz f r die sonst angelegten Duplikate Beispiel die f r die PriceCode Behandlung eingef hrten MovieState Objekte besitzen alle keinen eigenen Zustand Je Unterklasse muss also nur genau ein Objekt angelegt werden das von der MovieStateFactory verwaltet wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 508 Objektorientierter Softwareentwurf Eon 6 systeme Beispiel f r Flyweight Muster O Me Movie getTitle String getCharge double getFRP int CHILDREN int REGULAR int NEWint getCharge double instanceChild ChildMovie REN instanceReg RegularMovie instanceNew NewMovie createlnstance MovieState createlnstance hat D PriceCode Param mit Wert aus CHILDREN NEW REGULAR Prof Dr Andy Schiir
274. nung von Personen zu Paketen Hier wird am deutlichsten dass eine Machbarkeitsstudie ohne ein grobes Design der zu erstellenden Software nicht durchf hrbar ist da Arbeitspakete ergeben sich aus der Struktur der Software Abh ngigkeiten und Umfang der Pakete ebenso Realisierungsart der Pakete bestimmt ben tigte Ressourcen Konsequenz Projektplanung und organisation ist ein fortlaufender Prozess Zu Projektbeginn hat man nur einen groben Plan der sukzessive verfeinert wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 612 Management der Software Entwicklung Echtzeit systeme Terminologie Q Prozessarchitektur grunds tzliche Vorgehensweise einer Firma f r die Beschreibung von Software Entwicklungsprozessen Notation Werkzeuge LJ Prozessmodell Vorgehensmodell von einer Firma gew hlter Entwicklungs prozess Wasserfallmodell oder RUP oder Projektplan an einem Prozessmodell sich orientierender Plan f r die Durchf h rung eines konkreten Projektes Vorgang Aufgabe Arbeitspaket abgeschlossene Aktivit t in Projektplan die bestimmte Eingaben Vorbedingungen ben tigt und Ausgaben produziert amp Personal und sonstige Betriebsmittel f r Ausf hrung braucht eine bestimmte Zeitdauer in Anspruch nimmt und Kosten verursacht und oder Einnahmen bringt Phase Zusammenfassung mehrerer zusammengeh riger Vorg nge zu einem globalen Arbeit
275. nz Incomplete Initial Exit Point Referenz Exit Point Objektzerst rung Terminate Verfeinerung Incomplete enterClient X Entry Point NormalEntry J J NormalExit enterCategory enterPeriod undoCancel CancelExit Reentry Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 410 Von der OO Analyse zum Software Entwurf Echtesit systeme Erlauterungen zu dem neuen Beispiel LI der separat definierte XOr Zustand Incomplete k nnte in mehreren Statechart Diagrammen an verschiedenen Stellen eingesetzt referenziert werden er besitzt zwei Eintritts und zwei Austrittspunkte die bei der Verwendung durch Transitionen referenziert werden dadurch kann man Transitionen von au en zu bestimmten internen Zust nden f hren ohne diese zu kennen Incomplete muss beim ersten Mal ber NormalEntry betreten werden verl sst man Incomplete ber NormalExit aus Zustand Complete oder ber CancelExit aus beliebigem Zustand wird der vorher erreichte Zustand vermerkt als History State betritt man den Zustand Incomplete wieder ber Reentry so landet man in dem Zustand in dem man beim letzten Verlassen von Incomplete am Ende gewesen war die Transition kill von Complete aus l scht sofort das zugeh rige Objekt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 411 Von der OO Analyse zum Software Entwurf Echtesit systeme
276. o wie etwa l schen bewegen im Zweifelsfall streitet man sich ob eine Beziehung eine normale Assoziation ist oder eine Aggregation bzw Komposition dann ist es eine Assoziation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 211 Objektorientierte Anforderungsanalyse EAcHOphiet Echizeit systeme Verschiedene Darstellungen der Komposition a normale UML Variante 1 4 5 2 40 doors Door b mit Schachtelung als Montagediagramm Kompositionsstrukturdiagramm LI jede Instanz der Klasse Car enth lt 4 bis 5 Wheel Instanzen die ber den Rollen wheels Wheel 4 5 namen wheels angesprochen werden LI jede Instanz der Klasse Car enth lt 2 bis 5 Door Instanzen die iiber den Rollenna men doors angesprochen werden doors Door 2 5 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 212 Objektorientierte Anforderungsanalyse Echtzeit ES systeme Aufbau von Klassenhierarchien U jede Klasse kann im Allgemeinen mehrere Oberklassen besitzen LI besitzt sie h chstens eine Oberklasse spricht man von Einfachvererbung sonst von Mehrfachvererbung U jede Klasse besitzt im Allgemeinen mehrere Unterklassen LJ Unterklassen erben und erweitern Mengen von Attributen Operationen Beispiel f r Einfachvererbung single inheritance Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 213
277. ogik des Systems in einer Klasse und einer Methode zu verankern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 520 Objektorientierter Softwareentwurf Eon ES systeme Das Anti Entwurfsmuster Poltergeist Fortsetzung LI Beispiel unser Videoverleihsystem enth lt keine solche Klasse LJ Neue L sung die Klasse wird gel scht und ihr Verhalten auf meist bereits existierende bislang von ihr kontrollierte Klassen verteilt Falls das nicht m glich ist kann man zumindest das dauernde Erzeugen und L schen der Poltergeister durch Einsatz des Flyweight Patterns vermeiden LJ Erlaubte Ausnahmen keine sagt BM 98 gt Koordinationsklassen deren Instanzen nicht dauernd erzeugt und gel scht werden und die eigene Attribute besitzen und keine Schleimmonster sind Kapselung von Algorithmen zum Zwecke der Wiederverwendung Aus tauschbarkeit und vor allem bergabe als Parameter an Methoden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 521 Objektorientierter Softwareentwurf Eon ES systeme Abschlie ende Anmerkungen zu Anti Patterns in BM 98 findet man noch eine ganze Reihe weiterer Anti Patterns bislang gibt es Dutzende von B chern ber Design Patterns wie z B BMR96 GH 94 aber es gibt nur sehr wenige B cher ber Anti Pattern zudem befassen sich die meisten Anti Pattern B cher nicht nur gar nicht mit Anti Patterns
278. ollen Extreme Programming XP radikale Abkehr von bisherigen Vorgehens modellen und Ersatz durch best practices der Programmierung Be99 Agile Prozessmodelle Versuche herk mmliche Prozessmodelle auf das unbedingt notwendige zur ckzuschneiden und situationsbedingt flexibel und schnell agil voranzuschreiten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 591 Management der Software Entwicklung Eon ES systeme Grundideen von XP E Verzicht auf Phasen der Softwareentwicklung Arbeitsbereiche keine eigenst ndigen Analyse oder Designaktivit ten vor der Codierung keine Erstellung getrennter Dokumentationsdokumente Modelle der gut kommentierte Code ist seine eigene Dokumentation aber gro es Gewicht auf sorgf ltige Testplanung Tests werden immer zusammen mit oder gar vor Code geschrieben nach jeder nderung werden alle Tests durchlaufen Regressionstests unbedingtes Einhalten der 40 Stunden Woche Auftraggeber soll permanent neue Anforderungen aufstellen und priorisieren sehr kurze Iterationszyklen h ufige Releases Pair Programming Teams E E E E E E E E E E E Subsets obiger Ideen d rfen nicht XP genannt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 592 Management der Software Entwicklung Eon ES systeme Randbedingungen LJ maximal 5 bis 10 Programmierer an einem Projekt be
279. on oder gt eigenen Transaktionsobjekten zugeordnet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 330 Von der OO Analyse zum Software Entwurf Echtesit systeme Ubersetzung in Java Code public class ReservationContract public static ReservationContract StartContractCreation Number id ReservationContract reservationContract new ReservationContract reservationContract contractld id return reservationContract public DateRange getPeriod return period public void setPeriod DateRange period this period period public void cancelContractCreation Verweise auf Contract l schen public void FinishContractCreation noOfContracts public void CancelContract noOfContracts Verweise auf Contract l schen private ReservationContract der Konstruktor der Klasse private Number contractld readonly private DateRange period private CatType category private Currency deposit 500 private static int noOfContracts 0 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 331 o zu ware Entwu Echtzeit g Von der OO Analyse zum Software Entwurf systeme Von CASE Tool generierter Java Code public class ReservationContract public static ReservationContract StartContractCreation Number id ReservationContract reservationContract new ReservationContract rese
280. on der OO Analyse zum Software Entwurf Echtzeit Mich systeme 7 2 Spezifikation von Integrit tsbedingungen mit OCL F r die pr zise Beschreibung von Konsistenzbedingungen Integrit tsbedingungen bzw Constraints auf Klassendiagrammen f r Attributwerte und Links von Objekten Bedingungen f r den Aufruf von Methoden gt Auswirkungen des Aufrufs von Methoden wurde die so genannte Object Constraint Language OCL entwickelt die eine angeblich gut lesbare Java hnliche Syntax f r pr dikatenlogische Ausdr cke anbietet Es handelt sich dabei um eine dreiwertige Logik mit den Werten true false undefined der Wert undefined steht f r unbekannter Wert und Rechenregeln der Form true and undefined undefined false and undefined false true or undefined true false or undefined undefined Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 351 Von der OO Analyse zum Software Entwurf Echtzeit ES systeme Verfeinerung von Klassendiagrammen um Konsistenzbedingungen Nur wenige Konsistenzbedingungen lassen sich durch die bisherigen Sprachmittel aus dr cken und wurden deshalb bislang umgangssprachlich formuliert siehe Seite 341 Beispiel Kunde kann nur Autos mieten die zum Wagenpark seiner Autovermietung geh ren P hasRentalCont hasClient ract 123 AVIS un motorVehicle hasVehicle verboten hasVehicle Prof Dr Andy Schiirr TU
281. ontract InkrevReservationContract R ckw rts Link auf Client Vertrag Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 333 o zu ware Entwu Echtzeit di Von der OO Analyse zum Software Entwurf systeme Kritik an dieser Umsetzung in Code Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 334 Von der OO Analyse zum Software Entwurf Eenzet A systeme Warum ist der generierte Code naiv r1 ReservationContra r2 ReservationContra Eu zu Fahrzeug v1 Motorvehich soll Reservierung ia v1 Motorvehicl geandert werden u 6 nderung von v1 InkrevReservationContract von r1 auf r2 mit der Methode setLnkReservationContract zieht nicht automatisch gt nderung von r1 InkMotorvehicle auf null gt nderung von r2 InkMotorvehicle von v2 auf v1 gt nderung von v2 RentalContract auf null nach sich oder umgekehrt 6 Im brigen Beispiel ist nicht sinnvoll da es zu einem Motorvehicle mehr als einen RentalContract geben wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 335 Von der OO Analyse zum Software Entwurf Echtesit systeme Java Code fur Assoziation mit Konsistenzbewahrung 1 class ReservationContract public Motorvehicle getMotorvehicle return InkMotorvehicle public void setMotorvehicle Motorvehicle newMotorvehicle if this InkMotorvehicle newMotorvehicle i
282. otorVehicle gt includesAll self rentalContract motorVehicle mit union intersection Operationen f r Vereinigung und Durchschnitt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 367 Von der OO Analyse zum Software Entwurf Echtesit systeme Operationen zur Iteration auf Mengen und Selektion von Elementen LI Die Iteration ber einer Menge setzt zun chst eine Akkumulator Variable auf einen Initialwert und berechnet dann fiir jedes Element einer gegebenen Kollektion den Wert auf Basis des bisherigen Wertes neu context RentalOffice def valueOfAllCars motorVehicle gt iterate vehicle Vehicle totalValue Integer 0 vehicle value totalValue der Preis aller Fahrzeuge der Firma wird berechnet LJ Die Auswahl von Elementen aus einer Kollektion die eine Bedingung erf llen context RentalOffice def oldClients client gt select age gt 60 LJ Die Elimination von Elementen aus einer Kollektion die eine Bedingung erf llen context RentalOffice def oldClients client gt reject age lt 60 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 368 Von der OO Analyse zum Software Entwurf Echtesit systeme Behandlung von Kollektionen bei Navigation Q self rentalOffice liefert aufgerufen auf einem Objekt der Klasse Client eine Kollektion Sequenz von Rental Office Objekten zuriick Q rentalOffice motorVehicle ist eine
283. ozess beteiligter Stakeholders Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 81 Requirements Engineering und Machbarkeitsstudie Eon A systeme Storyboard Techniken Anwendungsf lle und Rollenspiele Allen diesen Techniken liegt die Idee zugrunde dass man die wichtigsten Funktionsab l ufe des Software Produkts durchspielt Provokation von yes but U Anwendungsfalle Use Cases amp Misuse Cases alle Funktionen Features des Systems werden als exemplarische Abl ufe beschrieben erw nschte und unerw nschte Anwendungsf lle zentrales Element von UML f r Anforderungsanalyse siehe Kapitel 5 LJ Storyboarding wurde in der Filmindustrie zum ersten Mal f r die Produktion von Schneewittchen und die sieben Zwerge eingesetzt gt auf einer gro en Tafel werden mit grob skizzierter Benutzeroberfl che Anwendunegsfalle durchgespielt wie Fahrzeugreservierung LI Rollenspiele verschiedene Personen bernehmen die Rollen unterschiedlicher Teile des Software Systems oder von Benutzern und spielen Abl ufe durch Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 82 bi Requirements Engineering und Machbarkeitsstudie Een ES systeme berpr fung von Anforderungen LI Validit t haben wir die richtigen Anforderungen aufgestellt ist die beschriebene System Funktionalit t die ben tigte LJ Ko
284. p that is 2 not reserved during p CreateReservation CreateMessage Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 228 Fachgebiet f Echizeit amp Objektorientierte Anforderungsanalyse u Aktivit tsdiagramm MakeReservation mit Fallunterscheidung f MakeReservation client not in DB FindClientI nDB client in DB FindVehicles determines set of all J vehicles vs of category c SelectFreevenice Selects free vehicle v for SelectFreeVehicle given period p that is F A J allunterscheidung not reserved during p Bedingungen sollten sich free vehicle found N gegenseitig ausschlie en CreateMessage no free vehicle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 229 Objektorientierte Anforderungsanalyse Echtzeit systeme Erl uterungen zu einfachen Aktivit tsdiagrammen einfache Aktivit tsdiagramme entsprechen den alten Kontrollflussdiagrammen Aktionsknoten k nnen beliebige Anweisungen Texte enthalten dazu geh rt der Aufruf eines anderen Aktivit tsdiagramms die Ausf hrung beginnt mit der Ablage einer Marke Token am Anfangsknoten jeder Ausf hrungsschritt setzt die Marke entlang einer Kontrollflusskante zum n chsten Knoten an einem Bedingungsknoten Raute wird die Marke entlang einer Kontrollflusskante propagiert deren Bedingung wahr ist Text in es sollte immer
285. punkt sind die Produktanforderungen des Kunden entweder als Flie text oder als strukturiertes Lastenheft LJ Ergebnis ist ein erweitertes Pflichtenheft mit semiformalen Definitionen der Produktfunktionen und daten als UML Diagramme Umfang des Einsatzes von UML umstritten U Extremposition eines UML Protagonisten UML wird als visuelle grafische Programmiersprache eingesetzt erstelltes Analysemodell ist als Prototyp ausf hrbar man spricht vom ausf hrbaren Pflichtenheft LJ Extremposition eines UML Antagonisten gt Pflichtenheft ist nur in strukturiertem Englisch Deutsch geschrieben grafische Modellierungssprachen wie UML werden erst im Design genutzt wenn berhaupt eigentlich reichen textuelle Programmiersprachen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 154 Objektorientierte Anforderungsanalyse Echtzeit systeme 5 2 Produktfunktionen und Anwendungsf lle UML Use Cases Aufgabe Ausgehend von den Produktfunktionen im Lastenheft oder einer Flie text beschreibung des Softwareprodukts werden seine Funktionen anhand konkreter Fallbeispiele Szenarien detailierter beschrieben Verwandte Szenarien werden zu Produktfunktionen Anwendungsfalle zusammengefasst siehe auch Techniken zur Ermittlung von Anforderungen in Abschnitt 3 2 Vorgehensweise gt gt gt gt gt Skizze konkreter Benutzungsszenarien mit Akteuren mit Rollenspie
286. quentRenterPoints int daysRented return F Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 462 Objektorientierter Softwareentwurf Echtzeit ec systeme Effizientere Klasse Rental mit Caching von Methodenwerten public class Rental private Movie _movie private int _daysRented private double _charge private int _frequentRenterPoints public Rental Movie movie int daysRented _movie movie _daysRented daysRented _charge movie getCharge daysRented _frequentRenterPoints movie getFrequentRenterPoints daysRented public double getCharge return _ charge i public int getFrequentRenterPoints return _frequentRenterPoints Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 463 Objektorientierter Softwareentwurf Echte Pd systeme Noch notwendiger Umbau Elimination des Switch Statements public class Movie public double getCharge int daysRented double result 0 switch getPriceCode case Movie REGULAR result 2 if daysRented gt 2 result daysRented 2 1 5 break case Movie NEW_RELEASE result daysRented 3 break case Movie CHILDREN result 1 5 if daysRented gt 3 result daysRented 3 1 5 break return result Achtung Ansatz mit neuen Klassen RegularMovie NewMovie und ChildrenMovie scheitert da sich PriceCode w hrend Lebe
287. r Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 379 Von der OO Analyse zum Software Entwurf Ente ee systeme Akurate Darstellung rekursiver Operationsaufrufe Visual ca for UML Standard Edition TU Darmst aClerk Clerk makeReservation getClient pS NI returnClient cn theClient Client theClient findClient cn getPeriod x der rekursive Aufruf wird Se aufwandiger grafisch returnPeriod p PSS nn vs findVehicles p v selectVehicle vs returnSelectedVehicle v r addReservation cn p c v sendMail r Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 380 Fachgebiet f Von der OO Analyse zum Software Entwurf Echtzeit A systeme Behandlung von Sonderf llen in Sequenzdiagrammen Visual Fa UML Standard Edition TU Darmstad aClerk Clerk makeReservation getClient returnClient cn theClient findClient cn Bedingter optionaler Teil des Ablaufs mit Bedingung in theClient null getClientName returnClientName name addClient name theClient Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 381 Von der OO Analyse zum Software Entwurf Eon ES systeme Weitere Interaktionsoperatoren Mit opt haben wir einen ersten Interaktionsoperator f r Sequenzdiagramme kennen gelernt der sich ber mehrere Lebenslinien erstreckt Es gibt des weiteren LJ loop m n die
288. r TU Darmstadt FB 18 Institut f r Datentechnik Seite 21 Fachgebiet f Software Technik Was ist das a A Gr e eingebetteter Software Mobiltelefon Android BS Code Umfang 12 Mio Zeilen Code Fehlerquote 0 78 Fehler auf 1000 Zeilen also gesch tzt ca 9 000 Fehler Quelle Chip Online 2011 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 22 Software Technik Was ist das Gr e eingebetteter Software Rasierapparat Fachgebiet f Echtzeit amp systeme Code Umfang 0 1 Mio Zeilen Code Quelle Philips ca 2005 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 23 Software Technik Was ist das Eon A 1 3 Software Technik Geschichte und Definition U Ausl ser f r Einf hrung der Software Technik war die Software Krise von 1968 Der Begriff Software Engineering wurde von F L Bauer im Rahmen einer Study Group on Computer Science der NATO gepr gt LJ Bahnbrechend mit Abstrichen war die NATO Konferenz Working Conference on Software Engineering vom 7 10 Oktober 1968 in Garmisch vor 40 Jahren al ra 7 sei Der Kar gt fi x MO a The NATO Software Engineering Conference The NATO Software Engineering Conference http nomepages cs ncl ac uk brian randell NATO N1968 index html http homepages cs ncl ac uk brian randell NATO N 1968 index html Prof Dr Andy Sch rr TU
289. r TU Darmstadt FB 18 Institut f r Datentechnik Seite 474 Objektorientierter Softwareentwurf Echte die systeme Extract Method LJ Vorbedingung es gibt ein Codefragment das sich vom umstehenden Code abhebt Kurzbeschreibung Codefragment wird zu Methode mit sinnvollem Namen Beispiel vorher void printOwing double amount printBanner print all the details System out printin name _name System out printin amount amount Beispiel nachher void printOwing double amount printBanner printDetails amount void printDetails double amount print all the details System out printin name _name System out printin amount amount Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 475 Objektorientierter Softwareentwurf Echteslt systeme Extract Method Kochrezept erzeuge eine neue Methode mit sinnvollem Namen in der selben Klasse kopiere den zu extrahierenden Code von der alten zur neuen Methode suche im extrahierten Code nach Parametern und lokalen Variablen die nicht mit dem extrahierten Code kopiert wurden fiihre fiir alle diese Parameter und Variablen in der neuen Methode Parameter ein stelle fest ob die betroffenen Parameter und Variablen in der neuen Methode ver andert werden wird kein Parameter und keine Variable ver ndert ist die neue Methode void wird genau ein Parameter oder eine Variable ver
290. r TU Darmstadt FB 18 Institut fiir Datentechnik Seite 509 Objektorientierter Softwareentwurf Eon A systeme Struktur des Flyweight Musters 1 FlyweightFactory Flyweight createlnstance Flyweight SharedFlyweight1 SharedFlyweight1 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 510 Objektorientierter Softwareentwurf Echteslt systeme Implementierungshinweise zu Flyweight LJ die Kompositionsbeziehung von FlyweightFactory zur abstrakten Klasse Flyweight deutet an dass ein Vector Array oder eine andere Datenstruktur zur Speicherung Cashing von erzeugten Flyweight Instanzen benutzt wird die Unterklasse SharedFlyweight1 steht repr sentativ fiir viele Unterklassen der abstrakten Klasse Flyweight nicht alle Unterklassen m ssen am Sharing unbe dingt teilnehmen nur im einfachsten Fall gibt es von jeder Flyweight Unterklasse genau eine Instanz oft gibt es unver nderliche Attribute mit kleinem Wertebereich und es wird je Attributwert eine Instanz angelegt und in der FlyweightFactory vermerkt Client Objekte erzeugen nie selbst Flyweight Instanzen sondern machen das immer ber die FlyweightFactory es ist ein Implementierungsgeheimnis der FlyweightFactory welche Objekte neu erzeugt werden und welche fter verwendet und daher von mehreren Client Objek ten verwendet werden sharing Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Date
291. r nde f r Refactoring 4 L comments Kommentare im Methodenrumpf sind notwendig um diesen zu verstehen Extract Method f hrt eigene Methode mit vern nftigem Namen und Kommentierung f r schwer verst ndlichen Methodenteil ein data class Klasse die nur Daten enth lt und auf diesen keine Berechnungen durchf hrt insbesondere dann wenn Attribute Felder public sind Encapsulate Attribute f hrt Get und Set Methoden f r nunmehr private Attribute ein Move Method bringt Berechnungen zu den Attributen Achtung widerspricht etwas der Empfehlung zur strikten Trennung von Daten haltungs und Berechnungsklassen siehe lt lt Entity gt gt Steoreotyp solche Klassen machen Sinn falls sie von einem Speichermechanismus abstrahieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 473 Objektorientierter Softwareentwurf Echte dec systeme Aufbau der Beschreibung von Refactoring Schritten L Name des Refactoring Schrittes Vorbedingung die fiir die Anwendung erfiillt sein muss Kurzbeschreibung des Refactoring Schrittes Minimalbeispiel das das Prinzip klar macht Motivation f r die Durchf hrung einer solchen Programmtransformation Kochrezept f r die Durchf hrung der Transformation mechanics mit Einzel schritten Fallstricken zu berpr fenden Randbedingungen weitere Beispiel e f r die Anwendung der Transformation Prof Dr Andy Sch r
292. r Fahrzeugreservierung zu speichern Z Kunden Zielbestimmung Das Programm MYRS soll eine kleine Autovermietung mit genau einer Produktleistungen Niederlassung in die Lage versetzen die Buchung und Verleihung ihrer 7 a a verschiedenen Wagentypen Arten Kategorien zu verwalten 10 Beider Listenausgabe der Funktionen LF40 werden zun chst n 20 Das System erzwingt die regelm ige Erstellung von Datensicherung Qualit t Funktionalit t Benutzbarkeit Zuverl ssigkeit Effizienz paat J Gbemetimen Abbrechen zur ck weiter FP Bewertung Drucken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 95 Requirements Engineering und Machbarkeitsstudie ea Echizeit systeme Erstellung von Glossar mit Process otris Software AG Dortmund EIPROCESS Pflichtenheftgenerator Anwendung Stammdatenlisten Ersterfassung Administration Hilfe FE Neu G Bearbeite 2 Aktualisiere X L schen M Anpasser W Projekt 2 Eintr ge MVRS Motor Vehicle Re el EcH La Miia ooa elite Mcleod ic WG Glossare 1 Eintrag SEEN WIN i B version 0 9 vom 1 iF Pflichtenhefte 1 Eintr i E version 0 9 vom 1 AE Lastenhefte 1 Eintrag Version 0 9 B Version 0 9 vom 1 Autor Andy Sch rr Seminarorganisation DAUM SUEZ 47 Glossare 1 Eintrag P in Arbeit 3 Pflichtenhefte 1 Eintr Lastenhefte 1 Eintrac Beare 4 Vorlage 0 Eintr ge By Historie eae ae Firma r er
293. r Prozess LJ Prozess Charakteristika gt quantitative Basis f r Kapitalinvestitionen in Prozessautomatisierung und verbesserung LJ notwendige Aktionen kontinuierlicher Schwerpunkt auf Prozessvermessung und verbesserung zur Fehlervermeidung Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 603 Management der Software Entwicklung Echtzeit systeme Stand von Organisationen im Jahre 2000 2007 an vom Soltware Engineering Institute SEI aus dem Jahr 2000 2007 unter Die Daten in Klammern betreffen das Jahr 2007 f r den en mit dem Stand im Jahr 2000 der unter obiger URL nicht mehr dokumentiert ist U 32 3 1 7 der Organisationen im Zustand initial 39 3 32 7 der Organisationen im Zustand wiederholbar 19 4 36 1 der Organisationen im Zustand definiert 5 4 4 2 der Organisationen im Zustand kontrolliert 3 7 16 4 der Organisationen im Zustand optimierend Genauere Einf hrung in CMM findet man in Dy02 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 604 Management der Software Entwicklung Echtzeit systeme ISO 9000 und CMM im Vergleich Schwerpunkt der ISO 9001 Zertifizierung liegt auf Nachweis eines Qualit ts managementsystems im Sinne der Norm allgemein fiir Produktionsabl ufe geeignet genau ein Reifegrad wird zertifiziert CMM konzentriert sich auf Qual
294. rachtet lt gt Implementierung ist nicht effizient genug wichtige Interrupts werden zu lange blockiert Neue Fehlerart im Zuge der objektorientierten Programmierung LJ Redefinitionsfehler geerbte Operation wird nicht semantikerhaltend redefiniert ein Nutzer der Oberklasse geht von Eigenschaften der aufgerufenen Operation aus die Redefinition in Unterklasse nicht mehr erf llt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 540 Qualit tssicherung und Testverfahren Echtzeit Mich systeme Beispiel f r fehlerhafte Prozedur PROCEDURE countVowels s Sentence VAR count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER BEGIN count 0 WHILE sli DO IF s i a OR sli OR s i 0 OR sli u THEN count count 2 END count i 1 END countVowels countVowels to be or not to be count Achtung Diese in Pseudo Pascal geschriebene Prozedur wird im Folgenden als durchg ngiges Beispiel verwendet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 541 Qualit tssicherung und Testverfahren Eon ES systeme 9 3 Manuelle statische Testverfahren Systematische Verfahren zur gemeinsamen Durchsicht von Dokumenten wie z B erstellte UML Modelle implementierten Klassen Programminspektion stark formalis
295. rderungsanalyse Eontzeit systeme Beispiele f r Attributdeklarationen Client ReservationContract Vehicle Attributes Attributes kttributes clientld Number i 1 contracti d Number surname String period DateRange firstNames StringSet category CatType Birthday Date deposit Currency vehicleld Number category CatType een 3 Multiplizitatsangabe oft auch als firstNames String 1 3 Sie ice Menge von Strings mindestens einer hochstens drei sichtbar Achtung Sichtbarkeiten werden hier zwar kurz eingef hrt aber erst im folgenden Kapitel 8 genauer diskutiert geh ren zum Design und nicht zur Analyse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 193 Objektorientierte Anforderungsanalyse Echte dec systeme Aufbau einer Attributdeklaration UML Standard lt Sichtbarkeit gt lt Name gt lt Typ gt lt Multiplizit t gt lt Wert gt lt Eigenschaften gt Sichtbarkeit definiert Sichtbarkeit eines Attributs au erhalb der Klasse public oder expliziter schreibender und lesender Zugriff von au en erlaubt das sollte man eigentlich nie verwenden protected oder nur Klasse selbst und ihre Unterklassen d rfen in ihren Methoden auf das Attribut zugreifen private oder nur Implementierung der Klasse selbst darf auf Attribut schreibend und lesend zugreifen package local oder alle Klassen i
296. rea Bestandteile M der Ul Klasse GUI Designelemente Inspector m Properties Constraints Everts R Fe S R2 eex lt gt a gt Name System exit D tionCommand ok private Label labell new Label peeled private TextField textFieldl new TextField private Label label2 new Label private TextField textField2 new TextField private Label label3 new Label private Choice choicel new Choice private Button buttonl new Buttoni private Button button2 new Button Canvas d Eigenschaften von Button i generierter Code EN AWT Menu Swing General Swing Text Swing Containers Press Ctri Alt to finish editing and close Inspector Reservation java X 497 Y 80 button Bounds Left 36 Top 96 Width 57 Height 25 Skript 88 Adobe Frametiaker stru 7 Together 6 MVRS Y Adobe Acrobat userGu OE E 22 Ln 73 Cot 4 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 159 jektorienti u Eche P Objektorientierte Anforderungsanalyse systeme Anwendungsfalldiagramm mit Systemgrenze MVRS __MakeReservation CancelReservation _ AddClient I Anwendungsfall RermoveClient Use Case i Systemgrenze T Addvehicie des MVRS
297. result public String htmIStatement creates html output with all available information about given customer diese Methode sieht fast wie statement Methode aus Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 450 Objektorientierter Softwareentwurf Echuet ed systeme Kritik an dem erstellten Programm LJ Customer Klasse f hrt dauernd Berechnungen ber Daten aus Movie durch Zusammenfassung der Kritik U no separation of concern low cohesion bei Customer Klasse U high coupling zwischen Customer und Movie Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 451 Fachgebiet f Objektorientierter Softwareentwurf Echtzeit 3 systeme Erster Refactoring Schritt ExtractMethod while rentals hasMoreElements double thisAmount 0 Rental each Rental rentals nextElement determine amounts for each line switch each getMovie getPriceCode We add frequent renter points Methode statement nach Refactoring while rentals hasMoreElements double thisAmount 0 Rental each Rental rentals nextElement thisAmount amountFor thisAmeunt each add frequent renter points Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 452 Objektorientierter Softwareentwurf Echteslt systeme Extrahierte Methode amountFor private double amo
298. richt Auslieferung bei Wasserfallmodell Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 579 Management der Software Entwicklung Eon ES systeme Bewertung des V Modells erfasst auch Systemkomponenten die nicht in Software realisiert werden Standarddefinition ausserordentlich umfangreich mit vielen Teilaktivit ten Qualit tssicherung Konfigurationsmanagement wird auch unterst tzt korrespondierende Phasen des Wasserfallmodells einander zugeordnet allumfassende Wartungsphase entf llt zu recht grunds tzliche Schw chen der strikten Phaseneinteilung des Wasserfallmodells bleiben auf den ersten Blick erhalten iterativ inkrementelle Vorgehensweise wird aber unterst tzt in der Gesamtentwicklung in Produktzyklen unterteilt wird Anwender beklagen zu starke Reglementierung und Papierflut Variantenbildung wird aber unterst tzt die Anpassungen an Produktum fang Firmenkultur erlaubt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 580 Management der Software Entwicklung Eonzeit fp S systeme Evolution res Modell evolution res Prototyping Planung und erste Produktdefinition Prototyperstellung Validierung durch Anwender Modifikation der Produktdefinition Prototyp ok A Auslieferung und Einsatz Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 581 Manage
299. rientierten Modellierung Ent ae systeme Beispiele f r konkrete Objekte der realen Welt eine konkrete Person U eindeutig identifizierbar LJ hat verschiedene Eigenschaften die den aktuellen Zustand bestimmen verweist ggf auf andere Objekte kennt ein dynamisches Verhalten Telefon im Y R E4 324 oa Projektor in F1 110 das Fahrrad von Timo Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 119 Grundlagen der objektorientierten Modellierung Echt al Beispiel fur Laufzeitobjekte in Programmen Swing GUI Elementega Id Adresse in JVM Zustand Position jButto jTextAreat Verhalten ea gt jRadioButton1 jToggleButto jTextPanel _ jCheckBox1 jLabel1 jTextField1 Table column 1 Table column 2 ell 0 0 Cell 1 0 ell 0 1 Cell 1 1 Echizeit A systeme eee colors CJ sports Combobox ttem1 v FI food ScrollPane jEditorPane1 ProgressBar jPanelt jPanel2 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 120 Grundlagen der objektorientierten Modellierung gt Echizeit systeme Objektidentitat und Objektgleichheit LI jedes Objekt ist systemweit eindeutig identifizierbar LI es besitzt einen Objektbezeichner object identifier oid LJ Objektbezeichner wird bei der Geburt vergeben ist unabh ngi
300. rientierter Softwareentwurf Eon ES systeme Struktur des Composite Musters Component Geerbte Operation wird aul allen Kindern ausgef hrt Composite iterate lterato addChild void Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 496 Objektorientierter Softwareentwurf Eon ES systeme Beispiel f r Composite Muster lt lt Component gt gt RentalComponent _dateRange String RentalComponent getDateRange String getCharge double getFRP int lt lt Leaf gt gt lt lt Aggregate gt gt RentalLeaf RentalComposite movie Movie Die geerbten Operationen getCharge und get FRP daysRentedi int werden auf allen Kindern ausgef hrt und die dabei RentalComposite getCharge double getFRP int addChild void iterate Rentallterator first Index next lndex current Rentallterator _charge double gelieferten Ergebnisse werden aufsummiert _frequentRenterPoints int RentalLeaf getMovie Movie getCharge double getFRP int Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 497 Objektorientierter Softwareentwurf Echte dec systeme Das Entwurfsmuster State verk rzte Beschreibung Name State Absicht zustandsabh ngige komplexe Berechnungen insbesondere mit switch Statements werden in eigene Klassen ausgelagert Motivation oft besitzen Objekt eine kleine Anzahl an Zust nden die auf ihr Ver
301. rte der entsprechenden Spalte festlegt String Int LY Attribut INVENTARNR ist Prim r Schl ssel von BUCH in BUCH keine zwei Tupel mit demselben INVENTARNR Wert Attribut INVENTARNR ist auch Prim rschl ssel von AUSLEIHE gt in AUSLEIHE keine zwei Tupel mit demselben INVENTARNR Wert globale Integrit tsbedingungen Attribut INVENTARNR ist Fremdschl ssel von AUSLEIHE jeder INVENTARNR Wert von AUSLEIHE mu auch in BUCH auftreten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 270 Fachgebiet f Von der OO Analyse zum Datenbank Entwurf Echtzeit systeme Anfrageoperationen LI Selektion Zeilen Tupel ausw hlen SEL NAME Meyer AUSLEIHE ergibt INV_NR NAME 4711 Meyer 4712 Meyer LJ Projektion Spalten Attribute ausw hlen PROJ INV_NR TITEL BUCH ergibt INV_NR TITEL 0001 Asterix der Gallier 1201 Objektbanken 4711 Datenbanken 4712 Datenbanken 4717 PASCAL Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 271 Von der OO Analyse zum Datenbank Entwurf Echizeit g systeme Anfrageoperationen Fortsetzung LJ Verbund natural join Tabellen verkn pfen ber gleichbenannten Spalten und gleichen Werten PROJ INV_NR TITEL BUCH JOIN SEL NAME Meyer AUSLETHE ergibt INV_NR TITEL 4711 Datenbanken 4712 Datenbanken
302. rtung als eigener Entwicklungsprozess zu Projektbeginn sind nur ungenaue Kosten und Ressourcensch tzungen m glich gt Methoden zur Kostensch tzung anhand von Lastenheft Pflichtenheft ein Pflichtenheft kann nie den Umgang mit dem fertigen System ersetzen das erst sehr sp t entsteht Risikomaximierung gt andere Prozessmodelle mit Erstellung von Prototypen Anforderungen werden fr h eingefroren notwendiger Wandel aufgrund organisa torischer politischer technischer nderungen nicht eingeplant gt andere Prozessmodelle mit evolution rer Software Entwicklung strikte Phaseneinteilung ist unrealistisch R ckgriffe sind notwendig gt andere Prozessmodelle mit iterativer Vorgehensweise Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 576 Management der Software Entwicklung Eehtzeit gd systeme 10 2 Andere Vorgehensmodelle Die naheliegendste Idee zur Verbesserung des Wasserfallmodells ergibt sich durch die Einf hrung von Zyklen bzw R ckgriffen Sie erlauben Wiederaufnehmen fr herer Phasen wenn in sp teren Phasen Probleme auftreten Machbarkeits studie KI Anforderungs R ckgriff b analyse System entwurf Weitere Vorgehensmodelle LJ das V Modell umgeklapptes Wasserfallmodell LJ das evolution re Modell iteriertes Wasserfallmodell U Rapid Prototyping Throw Away Prototyping Prof Dr Andy
303. rvationContract contractld id return reservationContract public DateRange getPeriod return period public void setPeriod DateRange period this period period public void cancelContractCreation Verweise auf Contract l schen public void FinishContractCreation noOfContracits public void CancelContract noOfContracts Verweise auf Contract l schen private ReservationContract der Konstruktor der Klasse private Number contractld addonly private DateRange period private CatType category private Currency deposit 500 private static int noOfContracts 0 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 332 Von der OO Analyse zum Software Entwurf Echtzeit g systeme Unvollst ndiger naiver generierter Java Code f r Assoziationen Client der ee Supplier Assoziation der Assoziation public class ReservationContract public Vehicle getLnkVehicle return InkVehicle public void setLnkVehicle Vehicle InkVehicle this InkVehicle InkVehicle private Vehicle InkVehicle Vorw rts Link auf Supplier Fahrzeug public class Vehicle public ReservationContract getLnkRevReservationContract return InkrevReservationContract public void setLnkReservationContract ReservationContract InkrevReservationContract this InkrevReservationContract InkrevReservationContract private ReservationC
304. s Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 91 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit fp systeme 4 Produktdaten LD10 Folgende Daten sind zu jedem Fahrzeug zu speichern Typ Farbe gefahrene Kilometer letzte Inspektion LD20 Folgende Daten sind bei jeder Fahrzeugreservierung zu speichern Zeitraum gew nschter Typ vorreserviertes Fahrzeug Adresse des Kunden LD30 Produktleistungen LL10 Bei der Listenausgabe der Funktionen LF40 werden zun chst nur die ersten n Treffer ausgegeben weitere Treffer nur auf Wunsch LL20 Das System erzwingt die regelm ige Erstellung von Datensicherungen f r die Daten LD20 LL30 100 Fahrzeuge und 1000 Reservierungen werden maximal gespeichert LF30 Die Bearbeitung einer Fahrzeugreservierung dauert nicht l nger als 10 Sekunden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 92 Requirements Engineering und Machbarkeitsstudie rera systeme 6 Qualit tsanforderungen Produktqualit t sehr gut normal irrelevant Funktionalit t Zuverl ssigkeit Benutzbarkeit Effizienz nderbarkeit Portierbarkeit X Die Benutzbarkeit der Funktionen LF10 und LF20 muss gut sein da sie allein vom Besitzer der Firma verwendet werden Die Benutzbarkeit aller brigen Funk tionen m
305. s Anwendersicht logisch zusammengeh rige Gruppe vom Softwaresystem verwalteter Daten also z B eine Gruppe von Produktdaten des Lastenheftes in der Machbarkeitsstudie Klassen mit Attributen u Beziehungen eines Paketes aus Modellen im Pflichtenheft in der Analysephase Es werden Datenelementtypen Attribute sowie Entit tstypen Klassen S tze und zus tzlich Beziehungstypen Assoziationen gez hlt Anhand dieser Z hlung wird Komplexit t eines Datenbestandes wie folgt bestimmt einfach 7 FPs mittel 10 FPs oder komplex 15 FPs Interne Entit ten Anzahl Attribute lt 19 19 lt Anzahl Attribute lt 50 Anzahl Attribute gt 50 Klassen Assoz lt 1 einfache Komplexitat einfache Komplexitat mittlere Komplexitat 2 lt Klassen Assoz lt 5 einfache Komplexitat mittlere Komplexitat hohe Komplexitat Klassen Assoz gt 5 mittlere Komplexit t hohe Komplexit t hohe Komplexit t Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 630 Fachgebiet f Management der Software Entwicklung Echtzeit systeme Beispiel f r Bewertung eines internen Datenbestandes ContractNo int periodFrom Date Datenbasis mit name String ha periodTo Date frequent boolear category catTyp Vertr gen o i deposit Currenc reservedVehicle name String category CatTyp address Add Id String Die Datenbasis bes
306. s Movie public static final int CHILDREN 2 public static final int REGULAR 0 public static final int NEW _RELEASE 1 private String _ title private int _priceCode regular movie or for children or public Movie String title int priceCode _title title _priceCode priceCode public int getPriceCode return _priceCode public void setPriceCode int arg _priceCode arg public String getTitle return _title F Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 447 Fachgebiet f Objektorientierter Softwareentwurf Echtzeit 3 systeme Beispielprogramm Klasse Customer public class Customer private String _name private Vector _rentals new Vector public Customer String name _name name F public void addRental Rental arg _rentals addElement arg public String getName return _name public String statement creates listing text output with all available information about given customer i public String htmlStatement creates html output with all available information about given customer Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 448 Objektorientierter Softwareentwurf Echtsslt systeme Beispielprogramm Methode statement public String statement creates listing text output with all available information about given custo
307. s funktionierendes Sch tzverfahren Abweichungen trotzdem gro insbesondere bei Einsatz fremder Kurven Anpassung an OO Vorgehensmodelle moderne Benutzeroberfl chen notwendig moderne Varianten in Form von Object Point Methode sind noch nicht standardisiert und haben sich wohl noch nicht durchgesetzt Sch tzungsfehler in der Machbarkeitsstudie sind nicht immer auf fehlerhafte Sch tzmethode zur ckzuf hren sondern ggf auch auf nicht im Lastenheft vereinbarte aber realisierte Funktionen oder zus tzliche Umbauma nahmen bisher geschilderte Vorgehensweise nur f r Neuentwicklungen geeignet ohne umfangreiche Umbauma nahmen im Zuge iterativer Vorgehensweise Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 652 Management der Software Entwicklung Echtzeit systeme Problematik der FP Berechnung bei iterativer Vorgehensweise Bei Projekten zur Sanierung oder Erweiterung von Softwaresystemen bzw bei einer stark iterativ gepr gten Vorgehensweise mit Umbauma nahmen werden einem System nicht nur Funktionen hinzugef gt sondern auch Funktionen ver ndert bzw entfernt Damit ergibt sich der Aufwand f r Projektdurchf hrung aus Aufwand inMM Aufwand f r hinzugef gte Funktionen Aufwand f r gel schte Funktionen Aufwand f r ge nderte Funktionen Vorgehensweise LJ man ben tigt modifizierte Regeln f r die Berechnung von FPs f r gel schte Funktionen L schen etw
308. se etwas anders dargestellt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 241 Objektorientierte Anforderungsanalyse Echtzeit systeme Erl uterungen zu bersichts Aktivit tsdiagrammen mit Ereignissen LJ es werden nicht Abl ufe einzelner Systemfunktionen beschrieben sondern es wird skizziert wie alle Funktionen des Systems zusammenspielen Q berg nge Transitionen zwischen Aktionen werden oft durch externe Ereignisse ausgel st wie fetchEvent Kunde kommt ins B ro um Auto abzuholen Ablauf einer bestimmten Zeitspanne Timeout Kann auch ein Ereignis sein das die Ausf hrung einer nachfolgenden Aktion ausl st lt lt exception gt gt Transitionen brechen den normalen Ablauf in einem Bereich ab und f hren zur sofortigen Ausf hrung der Zielaktion berg nge zwischen Aktionen k nnen auch Ereignisse ausl sen wie hier SendAlertMessage das woanders wieder eine Transition ausl st gehen aus einer Aktion mehrere Kontrollflusskanten zu Ereignissen aus dann feuert die Kante deren Ereignis zuerst eintritt Swimlanes Bereiche werden zur bersichtlicheren Strukturierung der Dia gramme verwendet und zur Definition eines Wirkungsbereiches f r Ausnahmen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 242 Objektorientierte Anforderungsanalyse Echtzeit ED systeme Zusammenfassung f r Aktivit tsdiagramme Aktivit
309. seln und Fremdschl sseln so auszuw hlen dass 1 alle Anwendungsdaten aus den Basisrelationen hergeleitet werden k nnen 2 nur semantisch sinnvolle konsistente Anwendungsdaten dargestellt werden k nnen 3 die Anwendungsdaten m glichst nicht redundant dargestellt werden Im Folgenden steht Forderung 3 im Vordergrund LJ die auf den n chsten Seiten definierten Normalformen charakterisieren lokale Redundanzen innerhalb einer Relation LJ mit einer minimalen Anzahl von normalisierten Relationen vermeidet man globale Redundanzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 293 Von der OO Analyse zum Datenbank Entwurf Ente 422 Die erste Normalform 1NF systeme Relationenschemata in erster Normalform d rfen nur atomare Attribute besitzen Bemerkung Diese Forderung f hrt zu zus tzlichen Redundanzen die durch die nachfolgenden Normalformen charakterisiert werden Beispiel ISBN Titel Autoren 0 8053 1753 8 Princ of DBS Elmasri Navathe wird zu ISBN Titel Autor 0 8053 1753 8 Princ of DBS Elmasri 0 8053 1753 8 Princ of DBS Navathe Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 294 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Die zweite Normalform 2NF LJ Die zweite Normalform 2NF fordert 1NF und verbiete
310. sen der direkt darunterliegenden Schichten benutzen gt Verletzungen findet man in fast allen gro en Softwaresystemen Reparaturen erfordern oft ebenfalls gr ere Refactoring Ma nahmen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 523 Objektorientierter Softwareentwurf Echtssit systeme 8 6 Zusammenfassung Der systematische Umbau und die Bewertung von Software wurde in diesem Kapitel vertieft Fiir den Alltag der Softwareentwicklung sollte man sich folgendes merken Der Begriff Softwarearchitektur wird in der Literatur und Praxis sehr unter schiedlich definiert siehe hier aufgez hlte Architektursichten Oft sind strukturelle Sichten gemeint wie z B UML Klassen und Paket Diagramme Achtung bei Architekturbeschreibungssprachen wird oft gefordert dass deren Basiskomponenten Schnittstellen anbieten und fordern k nnen und dass Schnitt stellen Konnektoren eigenst ndige Implementierungsobjekte sind F r die Abbildung von Software auf Hardware k nnen in UML Einsatzdia sramme verwendet werden werden aber nicht so oft bislang genutzt Pattern und Anti Pattern sind das Mittel der Wahl f r die Dokumentation und Weitergabe von Erfahrungswissen ber gute und schlechte Softwareentw rfe Refactoring ist eine wichtige Technik zur systematischen Sanierung schlecht strukturierter Software dabei wird die Gefahr des Einbaus von neuen Fehlern minimiert durch verhaltensbewahr
311. sequentiell Operationsaufruf LJ email asynchron und parallel Signalverschickung telefonieren synchron und parallel Signalverschickung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 143 Grundlagen der objektorientierten Modellierung Echtecit systeme Parallelitat und Nebenlaufigkeit von parallelen Aktivit ten parallel activities spricht man wenn tats chlich zwei verschiedene Objekte zeitgleich Operationen ausf hren LJ von Nebenlaufigkeit concurrency spricht man wenn zwei verschiedene Objekte m glicherweise parallel Operationen ausf hren Beispiel f r Nebenl ufigkeit Zwei verschiedene aktive Personen Timo und Hannah leihen sich ein Fahrrad nebenl ufig aus folgende M glichkeiten der Abarbeitung gibt es 1 Timo und Hannah leihen tats chlich gleichzeitig ein Fahrrad aus zwei Angestellte bedienen Timo und Hannah gleichzeitig Timo leiht vor Hannah sein Fahrrad aus Hannah muss warten Hannah leiht vor Timo ihr Fahrrad aus Timo muss warten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 144 Grundlagen der objektorientierten Modellierung Enten al systeme Persistenz von Objekten Persistenz ist die Eigenschaft eines Objektes die Lebenszeit des erzeugenden Programmes zu berleben durch Serialisierung n Datei oder Speicherung in Datenbank von einem Adressbereich Programm Computer zu ein
312. siehe auch ive S Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 55 Vorgehensmodelle der Software Entwicklung Echte die systeme Machbarkeitsstudie feasibility study Projektdefinition Die Machbarkeitsstudie sch tzt Kosten und Ertrag der geplanten Software Ent wicklung ab Dazu grobe Analyse des Problems mit L sungsvorschl gen U Aufgaben siehe auch Abschnitt 3 2 Problem informell und abstrahiert beschreiben verschiedene L sungsans tze erarbeiten Kostensch tzung durchf hren Angebotserstellung LJ Ergebnisse Lastenheft sehr grobes Pflichtenheft Projektkalkulation gt Projektplan Angebot an Auftraggeber Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 56 Vorgehensmodelle der Software Entwicklung Echtzeit systeme Anforderungsanalyse requirements engineering In der Anforderungsanalyse wird exakt festgelegt was die Software leisten soll aber nicht wie diese Leistungsmerkmale erreicht werden LJ Aufgaben siehe auch Kapitel 5 gt genaue Festlegung der Systemeigenschaften wie Funktionalit t Leistung Benutzungsschnittstelle Portierbarkeit im Pflichtenheft Bestimmen von Testf llen Festlegung erforderlicher Dokumentationsdokumente LJ Ergebnisse Pflichtenheft Anforderungsanalysedokument Akzeptanztestplan Benutzungshandbuch 1 te Version Prof Dr Andy
313. sondern mit sch dlichen Praktiken des Projektmanagements Konfigurationmanagements allerdings befassen sich auch Refactoring B cher mit unerw nschten Entwurfs mustern die ja durch systematische Umbauten eliminiert werden LJ ein interessantes Buch ber Anti Patterns beim Programmieren in Java ist Ta02 Fazit Auf diesem Gebiet wird sich in den n chsten Jahren noch einiges tun auch wenn die Niederschrift schlechter Entwurfsmuster erfahrungsgem schwieriger und weniger popul r ist als die Ver ffentlichung guter Entwurfsmuster Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 522 Objektorientierter Softwareentwurf Echteslt systeme Grenzen der Bewertung von Softwaregute durch Anti Pattern Pattern und Anti Pattern betrachten immer die Giite von Software lokal globale Eigenschaften einer Softwarearchitektur werden nicht beriicksichtigt Beispiele f r globale Bad Smells einer Softwarearchitektur U zyklische Benutzt Beziehungen Importe ber Teilsysteme Pakete hinweg wechselseitige direkte oder indirekte Benutzungen f hren dazu dass die betroffenen Teilsysteme Pakete nicht mehr unabh ngig austauschbar sind Reparaturen erfordern oft gr ere Refactoring Ma nahmen U Verletzungen einer Schichtenarchitektur Pakete Klassen werden Schichten eines Softwaresystems zugeordnet Pakete Klassen einer Schicht d rfen immer nur Pakete Klas
314. ss Diagram mit Ops siehe Abschnitt 6 1 Analyse gt Design systeme Anwendungsf lle UML Use Cases iehe Abschnitt 5 2 siehe Abschnitt 5 2 Workflow Modell UML Activity Diagrams siehe Abschnitt 5 5 feines Verhaltensmodell UML Interaction Diag siehe Abschnitt 6 2 reaktives Verhalten UML State Machines siehe Abschnitt 6 3 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 420 Objektorientierter Softwareentwurf Echten systeme Bereits bekannte Architektursichten auf ein Softwareprodukt UL klassische Struktur Sicht Klassenhierarchien mit Beziehungen mit Klassendiagrammen haupts chlich hier verwendete Architektursicht LJ Datenfluss Sicht wie flie en Daten von Aktion zu Aktion durch das System mit Aktivit tsdiagrammen Kontrollfluss Sicht welche Operationen Klassen rufen sich gegenseitig in wel cher Reihenfolge auf mit Aktivit ts und Sequenzdiagramme Prozess Sicht Beschreibung dynamischer Aspekte mit Festlegung sequentieller und potentiell paralleler Abl ufe Kommunikationsarten etc mit Sequenzdiagrammen Statecharts Merke Architektur eines Softwareprodukts ist mehr als Zerlegung in Teilsysteme Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 421 Objektorientierter Softwareentwurf Echtsslt systeme Neue Architektursichten auf ein Softwareprodukt
315. sschritt Meilenstein Ende einer Gruppe von Vorg ngen Phase mit besonderer Bedeu tung f r die Projekt berwachung und wohldefinierten Ergebnissen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 613 Management der Software Entwicklung Echtzeit systeme Annahmen f r MVRS Projektplanung ber Grob Design der Software LJ es wird eine sehr einfache Dreischichtenarchitektur verwendet U alle Daten werden in einer Datenbank gespeichert Datenbankschema muss entworfen werden gt Anfrageoperationen setzen auf Schema auf und geben Ergebnisse in Listenform aus gt Update Operationen setzen auf Datenbankschema auf und sind unabh ngig von Anfrageoperationen die Realisierung der Benutzeroberfl che ist von der Datenbank entkoppelt f r den sinnvollen Modultest der Operationen braucht man aber die Oberfl che um das Beispiel nicht zu kompliziert zu gestalten wird das Wasserfallmodell mit Integration der einzelnen Teilsysteme im Big Bang Testverfahren verwendet gedruckte Manuale und Online Hilfe enthalten Screendumps der Benutzer oberfl che teilweise parallele Bearbeitung trotzdem m glich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 614 Management der Software Entwicklung Echtzeit systeme Aufteilung des MVRS Projekts in Arbeitspakete Aufgaben MVRS 1 Anal gt Desi 3 Codierung 4 Integration er sole as ak aici Modultes
316. st robust auf Fehleingaben Hardwareausfall Angriffe reagiert effizient konomisch mit Hardwareressourcen umgeht benutzerfreundliche Oberfl che besitzt gt Achtung Im Folgenden befassen wir uns vor allem mit Ma nahmen zur Erh hung der Zuverl ssigkeit von Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 528 Qualit tssicherung und Testverfahren Eon ES systeme Zur Erinnerung Definitionen einiger Qualit tsmerkmale LJ zuverl ssige Software funktioniert meistens Zuverl ssigkeit ist also ein Ma f r die Wahrscheinlichkeit gt dass ein Software System sich in einem bestimmten Zeitraum so verh lt wie es von ihm erwartet wird gt oder dass ein Software System einen angeforderten Dienst wie erwartet ausf hrt korrekte Software ist Software die sich immer so verh lt wie in den Anforderun gen festgelegt wurde ob sie sich damit so verh lt wie man der Anwender das erwartet bleibt damit offen korrekte Software muss also nicht zuverl ssig sein vertrauensw rdige Software verursacht niemals Katastrophen also auch dann nicht wenn sie sich nicht korrekt verh lt robuste Software funktioniert bzw reagiert auch unter unvorhergesehenen Umst nden vern nftig z B auf unerwartete Fehleingaben oder zuf llige bzw beabsichtige Angriffe Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 529 Qualit tssicherun
317. steme Anmerkungen zur FSM LI die Operationen setVehicle und setDeposit wurden weggelassen um das Diagramm berschaubar zu halten die Rechtecke sind die Zust nde der FSM es gibt immer einen Anfangszustand und meist genau einen Endzustand die Pfeile definieren die bergangsfunktion von einem Zustand zum n chsten sie werden Transitionen genannt und sind mit Signalen beschriftet die bergangsfunktion ist partiell da man nicht mit jedem Signal Ereignis aus einem Zustand in einen anderen kommt die FSM ist deterministisch da f r jedes Paar aus Zustand und Signal die ber gangsfunktion maximal einen neuen m glichen Zustand festlegt die FSM ist finite endlich da sie nur eine endliche Menge von Zust nden besitzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 388 Von der OO Analyse zum Software Entwurf Echtzeit dip systeme Deutungen von Zustandsdiagramm als Lebenszyklus Lebenszyklus f r ReservationContrIN stark vereinfacht create setCategory fulfill setClient a confirm Period Category defined setPeriod iS Ereignis mit Bedingung LJ Diagramm beschreibt in welcher Reihenfolge die Operationen der Klasse ReservationContract aufgerufen werden d rfen LJ das Diagramm ist keine Implementierung der Klasse LJ man spricht von Lebenszyklus oder Protokoll der Klasse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 389 Von d
318. steme Kommentare zu Generalisierung von Anwendungsf llen LJ Anwendungsf lle mit gemeinsamen Eigenschaften wie Beziehungen zu Akteuren k nnen von einem generalisierten Anwendungsfall abgeleitet werden und die Eigenschaften von diesem erben man kann so Diagramme bersichtlicher gestalten sinnvolle Gruppierungen von Anwendungsf llen schaffen und sich Schreibarbeit sparen zudem kann man so beispielsweise zum Ausdruck bringen dass Clerk zu jedem Zeitpunkt nur eine der beiden Systemfunktionen AddClient oder RemoveClient verwenden kann generelle Anwendungsf lle wie ManipulateClient k nnen abstrakt sein kursiver Name wenn sie keine eigenst ndigen Systemfunktionen darstellen sondern nur zur Vererbung von Eigenschaften eingef hrt wurden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 170 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit systeme Weitere Beziehungen zwischen Anwendungsf llen MVRS_Reservations _ManipulateReservation _ gt __ MakeReservation _ CancelReservation gt lt lt extend gt gt lt lt include gt gt no car available N Send Message gt Overbooked gt FAR V 7 eT Client LJ extend Varianten Ausnahmen eines Anwendungsfalles werden als eigene F lle beschrieben es wird also Funktionalit t zu einem Anwendungsfall hinzugef gt der erweiternde Fall kennt dabei den Basisanwendungsfall aber nicht umgeke
319. stitut f r Datentechnik Seite 48 Software Technik Was ist das ee systeme Software Maintenance die Pflege und Weiterentwicklung der Software nach Auslieferung Software Configuration Management die Verwaltung von Software Versionen und Konfigurationen Software Engineering Management Projekt Management von Personen Organisationen Zeitpl nen Software Engineering Process Definition und Verbesserung von Software Entwicklungsprozessen Software Engineering Tools and Methods Werkzeuge und Methoden f r die Software Entwicklung Software Quality Messen und Verbessern der Software Qualit t Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 49 Software Technik Was ist das ee gt systeme Methoden in der Softwaretechnik U Richtlinien zum Umgang mit einzelnen Sprachen Richtlinien zum Umgang mit einzelnen Werkzeugen Werkzeuge Computer Aided Software Engineering CASE Tools LJ Editoren Texteditor syntaxgest tzter Editor Diagrammeditor Ausf hrungswerkzeuge bersetzer Interpreter Testwerkzeuge Debugger Testdatengenerator Testrahmengenerator Programmanalysewerkzeuge statische Analysen dynamische Analysen E E E E Vorgehensmodell Vereinfachte Beschreibung eines Software Entwicklungsprozesses mit Regeln zum koordinierten Einsatz von Werkzeugen Methoden und Sprachen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r
320. struktur schaffen Probleme Datenstruktur hat Operationen first und next und merkt sich intern einen Zeiger auf gerade aktuelles Element damit sind mehrere Iterationen ber derselben Datenstruktur gleichzeitig nicht m glich Anwendbarkeit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 487 Objektorientierter Softwareentwurf Echteslt systeme Fortsetzung des lterator Entwurfsmusters Struktur Ellipse instantiierbares Teildiagramm Index i ist Index in Vector in Aggregate IN oder Zeiger auf mit nachstem Element 0 verkettetes Element 0 6 Aggregate Aggregate iterate lterator Iterator addChild void nn first Index next voi next Index a current Element Fevone Dooa first next und current haben in Java package local Sichtbarkeit in C w rde man private Sichtbarkeit und friend Beziehung von Iteratur zu Aggregate einsetzen current und next haben nicht sichtbaren Parameter Index i Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 488 Objektorientierter Softwareentwurf Echteslt systeme Fortsetzung des lterator Entwurfsmusters Klassen in der Struktur Teilnehmer Rollen des Musters Aggregate eine Kollektion bzw Ansammlung von Elementen auf der mehrere parallele Durchl ufe bzw Iterationen durchgef hrt werden sollen diese Klasse erzeugt neue Iterator Objekte f r diesen Zweck Element
321. szeit Datenumfang werden aufgez hlt LL nn Qualit tsanforderungen allgemeine Eigenschaften wie gute Zuverl ssigkeit hervorragende Benutzbarkeit normale Effizienz werden festgelegt Erg nzungen alles was nicht in obiges Schema passt und trotzdem wichtig ist Glossar alle in Punkt 1 bis 7 verwendeten wichtigen Begriffe werden erl utert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 84 Requirements Engineering und Machbarkeitsstudie Echtecit systeme Sonstige Eigenschaften des Lastenheftes LJ Adressaten Auftraggeber und Auftragnehmer Projektleiter Form bersichtliche Gliederung pr gnante S tze in nat rlicher Sprache Inhalt fundamentale Eigenschaften des Produktes aus Kundensicht Erstellungszeitpunkt vor Abschluss eines Vertrages ggf als Grundlage daf r Umfang wenige Seiten Kategorisierung der Funktionen Daten und Leistungen Bei s mtlichen Funktionen Daten und Leistungen Anforderungen Requirements die im Lastenheft aufgef hrt sind ist ihre Wichtigkeit anzugeben blicherweise wird wie folgt unterteilt LI absolut notwendig high priority primary LI ziemlich wichtig medium priority secondary Schnickschnack low priority optional frill Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 85 Requirements Engineering und Machbarkeitsstudie one AS systeme Weitere bli
322. t daysRented 2 1 5 return result class NewMovie extends MovieState double getCharge int daysRented return daysRented 3 class ChildrenMovie extends MovieState double getCharge int daysRented double result 1 5 if daysRented gt 3 result daysRented 3 1 5 return result Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 468 Objektorientierter Softwareentwurf Echte ec systeme ReplaceConditional with Polymorphism Fortsetzung abstract class MovieState double getFrequentRenterPoints int daysRented return 1 the points policy introduced above is currently valid for all movies except of new releases class NewMovie extends MovieState double getFrequentRenterPoints int daysRented return daysRented gt 1 2 1 public class Movie public double getFrequentRenterPoints int daysRented return _movieState getFrequentRenterPoints daysRented Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 469 Objektorientierter Softwareentwurf Eon ES systeme Gr nde f r Refactoring 1 LI duplicate code fast derselbe Code findet sich an n Stellen Fehler an n Stellen beheben wie etwa bei statement und htmlStatement Extract Method um identische Codeteile an einer Stelle zu konzentrieren long class method eine Klasse oder Methode
323. t Systemtest Saale 3 4 Listen 8 1 Datenbank 51M aufbau schema ARE 3 5 Benutzer 3 2 Anfrage 5 2 Online oberfl che operationen Hilfe 3 3 Update operationen Im obigen Bild fehlen noch die Angaben f r die gesch tzten Arbeitszeiten zur Bearbei tung der einzelnen Teilaufgaben des Motor Vehicle Reservation System Projekts Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 615 Management der Software Entwicklung Eehtzeit die systeme Planung von Arbeitspaketabh ngigkeiten mit PERT Charts Idee Listen aufbau 6 Tage g Anfrage operationen T Datenbank W ee Integration _schema_ Systemtest gt meneame 10Tage 5STage 10Tage _ Update operationen 10 Tage p Online Hilfe Benutzer g Online Hilfe f oberfl che RTT Analyse Design 18 Tage Manual 20 Tage PERT Chart Project Evaluation and Review Technique Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 616 Management der Software Entwicklung Eenzet A systeme Planung von Arbeitspaketabh ngigkeiten fr heste Anfangszeiten A 16 Tag Listen aufbau A 34 Tag Anfrage operationen 6 Tage A 1 Tag A 16 Tag A 44 Tag A 54 Tag Datenbank Integration schema Systemtest A 34 Ta 10 Tage 10 Tage
324. t siehe Abschnitt 3 3 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 174 Objektorientierte Anforderungsanalyse Eon A systeme Textuelle Ablaufbeschreibung Actor Action System Response 1 Anwendungsfall beginnt mit Aufruf der Hauptfunktion 1 im Men 2 gibt die Nummer eines Kunden ein 3 sucht Client in Datenbank und erfragt wird ggf vorab bestimmt Reservierungszeitraum T 4 gibt Zeitraum T ein 5 erfragt Fahrzeugkategorie K 6 gibt Fahrzeugkategorie K ein 7 bestimmt freie Fahrzeuge zu T und K 8 w hlt aus freien Fahrzeugen eines 9 tr gt Reservierung in Datenbank ein nach Kundenwunsch aus und ruft Anwendungsfall SendMail Achtung Fallunterscheidungen Iterationen und andere Programmierkonstrukte vermeiden Lieber Varianten eines Ablaufs als eigene Anwendungsf lle beschreiben Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 175 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit s Erweiterung eines Anwendungsfalles Use Case Overbooked Purpose Ausnahmebehandlung falls Reservierungswunsch nicht erf llbar Extends ReserveVehicle At Point Nach Schritt 7 von ReserveVehicle Entry Cond Schritt 7 hat leere Liste von Fahrzeugen geliefert Overview Es wird f r den vorgegebenen Zeitraum T eine Liste der Fahr zeuge der n chsth heren Kategorie K 1 bestimmt Exit Cond potientiell wieder leere Liste von Fahr
325. t in vielen Varianten Explosion der Variantenvielfalt Software greift in bestehende Arbeitsabl ufe ein gt Akzeptanzprobleme viele Software Produkte sind einzigartig keine Massenware Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 18 Software Technik Was ist das ee systeme Moore s Law und Softwaretechnik transistors Pentium 4 Processor 100 000 000 1970 1975 1980 1995 2000 Quelle http www intel com research silicon mooreslaw htm Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 19 Software Technik Was ist das Echtesit systeme Moore s Law auch fur Software 1960 1970 1980 1990 2000 60 MOI fm EWSD Elektronisches W hlsystem Digital Mi Space EHE EWSD BB ISDN Shuttle m Software fiir Raumfahrt MOI Million Object Code E Lunar Instructions Mission E Apollo DI EWSD APS WM 4 2 Quelle Ba96 FR aus Boehm Improving Software Productivity a Or oe AS Computer 1987 43 57 DBP 14 E Mercury und aus Siemens Unterlagen zum Seminar Indu strielle Software Technik Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 20 Software Technik Was ist das Bone ip systeme Gr e eingebetteter Software 100Hz Fernseher Code Umfang Quelle Philips ca 2005 2 Mio Zeilen Code Prof Dr Andy Sch r
326. t werden In welcher Reihenfolge m ssen oder d rfen Berechnungen stattfinden und wie oft wie lange rechnet ein Prozess Wie wird auf die Datenbanken zugegriffen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 111 f Fachgebi Grundlagen der objektorientierten Modellierung Echtzeit systeme Probleme mit der klassischen Softwareentwicklungsmethode amp starke Trennung zwischen Daten und Verhaltensaspekten gt resultiert in enormen Konsistenzhaltungsproblemen ggf werden nur Daten oder Verhalten modelliert verschiedene Konzepte und Sprachen in den einzelnen Entwicklungsphasen gt resultiert in enormen Konsistenzhaltungsproblemen allerdings gew nschte Trennung von Analyse und Entwurf wird erzwungen Voraussetzung fur erfolgreiche Softwareentwicklung LJ Modellierungssprachen mit wohldefinierter Syntax und Semantik LJ pr zise sprach bergreifende Konsistenz und Abbildungsregeln Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 112 Grundlagen der objektorientierten Modellierung Echtzeit d systeme Neue Idee des integrierten Modellierungsansatzes U enge Integration von Daten und Verhaltensbeschreibung U ein Konzept f r alle Phasen der Software Entwicklung Das Zauberwort Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 113 Grundlagen der objektorientierten Modellierung
327. t zus tzlich partielle Abh ngigkeiten zwischen einem Schl ssel und weiteren Nicht Primattributen LI Eine partielle Abh ngigkeit liegt vor wenn ein Attribut bereits von einer echten Teilmenge eines Schl ssels funktional abh ngt LJ Ein Nicht Primattribut ist ein Attribut das nicht Bestandteil eines Schliissels einer Relation ist mu nicht Bestandteil des Prim rschl ssels sein Beispiel Mit InvNr Autor als Prim r Schl ssel zu Beispiel auf voriger Seite gilt gt InvNr Autor gt InvNr Titel ISBN Autor gt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 295 Von der OO Analyse zum Datenbank Entwurf Echtesit systeme Herstellung der zweiten Normalform Sei 2NF verletzt im Relationenschema R durch X A mit Schl ssel K X c K sowie Nicht Primattribut A Dann eliminiert man die Verletzung durch R X U A Beispiel Die dritte Normalform 3NF LJ Die dritte Normalform 3NF fordert 1NF und verbietet zus tzlich transitive Abh ngigkeiten zwischen einem Schl ssel und weiteren Nicht Primattributen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 296 Von der OO Analyse zum Datenbank Entwurf Echtzeit Mick systeme LI Eine transitive Abh ngigkeit liegt vor wenn Attributmenge X funktional von Schl ssel X abh ngt und Nicht Primattributmenge Y funktional von X abh ngt also gilt K gt X und X gt Y mt K X LJ
328. tadt FB 18 Institut f r Datentechnik Seite 257 Von der OO Analyse zum Datenbank Entwurf Echtzeit ich systeme Probleme bei Datenverwaltung ohne Datenbanksysteme Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 258 Von der OO Analyse zum Datenbank Entwurf Enten gg systeme Die neun Codd schen Anforderungen f r Datenbanksysteme Integration Operationen Katalog Benutzersichten Konsistenz berwachung Datenschutz Transaktionen Synchronisation Datensicherung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 259 Von der OO Analyse zum Datenbank Entwurf Echtzeit u systeme Grundbegriffe der Datenbankwelt LJ Datenbanksystem DBS Q Dauerhafter Datenbestand LJ Datenbankschema LJ Datenbank DB LJ Datenbankmanagementsystem DBMS Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 260 Fachgebiet Von der OO Analyse zum Datenbank Entwurf Echtzeit z i systeme Drei Schichten Schemaarchitektur nach ANSI SPARC Datenvisualisierun externes Schema 1 g konzeptuelles Schema internes Schema tt P WW externes Schema n Anfragebearbeitung Datenbankschema besteht aus einem internen Schema Datenverwaltung auf Platte Indexstrukturen einem konzeptuellen Schema Beschreibung der Gesamtstruktur Integrit tsbedingungen 1 a mehreren extern
329. tatechart jede Klasse besitzt maximal ein eigenes Implementierungs Zustandsdiagramm plus ggf Lebenszyklus Zustandsdiagramm zu Schnittstellen Ereignisse sind Operationen der Klasse wie Vererbung von Zustandsdiagrammen handhaben Aktivit tsdiagramm lt gt noch immer etwas unklar Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 415 Von der OO Analyse zum Software Entwurf Eon ES systeme 7 6 Weitere Literatur BC89 Alhir S UML in a Nutshell A Desktop Quick Reference O Reilly 1998 H lt leider nicht das was es verspricht Preiswerte und relativ vollst ndige Pr sentation von UML aber sowohl als Einf hrung als auch als Nachschlagewert nicht sonderlich gut geeignet BC89 K Beck W Cunningham A Laboratory For Teaching Object Oriented Thinking in Proc OOPSLA 89 SIGPLAN Notices Vol 24 No 10 ACM Press 1989 1 6 Die Originalquelle zum Thema CRC Karten die f r die Identifikation von Klassen benutzt werden BD00 B Bruegge A H Dutoit Object Oriented Software Engineering Prentice Hall 2000 553 Seiten Basiert auf den Erfahrungen mit der Durchf hrung von Praktika zur objektorientierten Softwareentwick lung an der TU M nchen und der Carnegie Mellon University Beschreibt eine ganze Reihe von Faustre geln f r Projektmanagement Anforderungsanalyse Erstellung von UML Diagrammen Es ist schade dass die verwendeten Beispiele dauernd wechseln Harel
330. te nderbarkeit des so erstellten Codes ber gesamte Projektlaufzeit hinweg nicht hinreichend empirisch belegt nur f r kleine Projekte in nicht sicherheitskritschen Anwendungsbereichen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 594 Management der Software Entwicklung Echtzeit systeme Lineare Kostenkurve Wasserfallmodell XP Ansatz Cc Cc ab D D Cc C gt gt go go Cc lt lt x S S S S Cc Cc 3 i O lt X _ Analyse Design Impl Test Wartung 1 Release 2 Release 3 Release zeitlicher Projektverlauf zeitlicher Projektverlauf tats chlich vermutet Bei klassischen Projekten steigen die Kosten f r ge nderte Anforderungen mit Abschluss jeder Phase deutlich an bei XP verspricht man sich eine konstante Kosten kurve f r die Durchf hrung gew nschter nderungen da nur Code zu ndern ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 595 Management der Software Entwicklung Echtzeit systeme 10 5 Verbesserung der Prozessqualit t Ausgangspunkt der hier vorgestellten Ans tze sind folgende berlegungen Softwareentwicklungsprozesse sind selbst Produkte deren Qualit t ber wacht und verbessert werden muss bei der Softwareentwicklung sind bestimmte Standards einzuhalten Ent wicklungsprozess muss dokumentiert und nachvollziehbar sein es bedarf
331. te Fehler Fehler Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 535 Qualit tssicherung und Testverfahren Echtecit systeme Konstruktives Qualitatsmanagement zur Fehlervermeidung Q technische Ma nahmen Sprachen wie z B UML f r Modellierung Java f r Programmierung gt Werkzeuge UML CASE Tool wie Together oder organisatorische Ma nahmen Richtlinien Gliederungsschema f r Pflichtenheft Programmierrichtlinien Standards f r verwendete Sprachen Dokumentformate Management gt Checklisten wie z B bei Ende einer Phase m ssen folgende Dokumente vorliegen oder Softwareprodukt erf llt alle Punkte des Lastenheftes Einhaltung von Richtlinien Standards und berpr fung von Checklisten kann durch Werkzeugeinsatz technische Ma nahmen erleichtert erzwungen werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 536 Qualit tssicherung und Testverfahren Echtecit systeme Analytisches Qualitatsmanagement zur Fehleridentifikation analysierende Verfahren der Pr fling Programm Modell Dokumentation wird von Menschen oder Werkzeugen auf Vorhandensein Abwesenheit von Eigenschaften untersucht Inspektion Review Walkthrough organisiertes Durchlesen in Gruppe statische Analyse werkzeuggest tzte Ermittlung von Anomalien formale Verifikation werkzeuggest tzter Beweis
332. technik Seite 558 Qualit tssicherung und Testverfahren Echtzeit systeme Testen testen wann ist Schluss damit Zitat von Fowler FS98 The older I get the more aggressive I get about testing I like Kent Beck s rule of thumb that a developer should write at least as much test code as production code Testing should be a continuous process No code should be written until you know how to test it Once you have written it write the tests for it Until the test works you cannot claim to have finished writing the code Wann h rt man auf mit Testen eines der definierten Test berdeckungskriterien ist erf llt spezifizierte Zuverl ssigkeit ist garantiert siehe n chste Folie gt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 559 Qualit tssicherung und Testverfahren Echtzeit systeme Spezifikation der Zuverl ssigkeit eines Softwaresystems 1 Identifikation aller m glichen Fehlfunktionen eines Softwaresystems soweit m glich aus Black Box Sicht Klassifikation der gefundenen Fehlfunktionen z B unter Verwendung der folgen den Attribute vor bergehend gelegentlich Fehler treten nur bei gewissen Eingaben auf permanent st ndig Fehler treten bei allen Eingaben auf gt nicht wiederherstellbar ohne nur mit Eingreifen des Benutzers kann System nach Fehler wieder in funktionsf higen Zustand zur ckkehren gt nicht besch d
333. teht aus Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 631 Management der Software Entwicklung Fachgebiet Echizeit lye systeme Referenzdateien External Interface File EIF Externe Entitaten Unter einer externen Gesch fts Entit t definiert die IFPUG eine aus Anwender sicht logisch zusammengeh rige Gruppe vom System benutzter aber nicht selbst ver walteter Daten Wieder werden Datenelementtypen Attribute sowie Entit tstypen Klassen S tze und zus tzlich Beziehungstypen Assoziationen gez hlt Anhand dieser Z hlung wird Komplexit t eines Datenbestandes wie folgt bestimmt einfach 5 FPs mittel 7 FPs oder komplex 10 FPs Externe Entit ten Anzahl Attribute lt 19 19 lt Anzahl Attribute lt 50 Anzahl Attribute gt 50 Klassen Assoz lt 1 einfache Komplexitat einfache Komplexitat mittlere Komplexitat 2 lt Klassen Assoz lt 5 einfache Komplexitat mittlere Komplexitat hohe Komplexitat Klassen Assoz gt 5 mittlere Komplexitat hohe Komplexitat hohe Komplexitat Es werden weniger FPs als bei internen Entit ten vergeben da die betrachteten Daten best nde nur eingelesen aber nicht verwaltet werden m ssen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 632 Management der Software Entwicklung Fachgebiet Echtzeit systeme Ext
334. teigenschaften wie etwa gt readonly auf Attribut nur lesend nach Initialisierung zugreifen gt unique das Attribut ist eine Kollektion deren Elemente alle nur einmal auftreten gt ordered das Attribut ist eine Kollektion deren Elemente in einer bestimmten Reihenfolge gespeichert sind Kombinationen von unique und ordered unique true und ordered true es handelt sich um eine Liste von Elementen die jeweils nur einmal in der Liste auftreten d rfen sequence unique true und ordered false es handelt sich um eine Menge set unique false und ordered true es handelt sich um eine Liste im blichen Sinne unique false und ordered false es handelt sich um eine Kollektion deren Elemente ungeordnet sind und mehrfach auftreten d rfen bag Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 196 Objektorientierte Anforderungsanalyse Echtzeit systeme Instanz und Klassenattribute Attribute k nnen f r jede Instanz einer Klasse einen eigenen Wert besitzen oder aber f r alle Instanzen der gegebenen Klasse einen eigenen Wert U alle bisher vorgestellten Attribute sind Instanzattribute U Klassenattribute in Java static genannt werden unterstrichen Beispiele firstNames String 0 3 emptySet readonly unique ordered gt noOfClients int self instances gt size gt Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datent
335. teiligt Beschr nkung auf relativ kleine Projekte Kommunikation zwischen Programmierern und mit dem Kunden sehr intensiv keine r umlich verteilten Teams Kunde verzichtet auf separate Dokumentation der Software I zugunsten einer durch ausf hrliches Testen unterst tzten Rapid Prototyping Vorgehensweise Programmierer versuchen nicht bei der Realisierung des aktuellen Releases bereits k nftige Releases mit zu ber cksichtigen Programmierer sind aber zum st ndigen Umbau Redesign der bereits erstellten Software bereit Prinzip des Refactorings von Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 593 Fachgebiet Management der Software Entwicklung Echtzeit systeme Bewertung von XP systematisches Hacking Kompromiss zwischen Wirklichkeit der Programment wicklung in vielen F llen und sehr aufw ndigen Vorgehensmodellen Betonung der menschlichen Komponente 40 Stunden Woche intensive Kommu nikation Pair Programming Empfehlungen fiir Arbeitsumgebung systematisches evolution res Rapid Prototyping durch Testen und Refactoring Software Sanierung in kleinen Schritten versucht man Nachteile zu vermeiden Endprodukt besitzt ausser Kommentaren im Quellcode und Testfalle keine Dokumentation Entwicklung des ben tigten Gesamtsystems wird durch schnelle Produktion vieler kleiner Releases nicht unbedingt sehr zielgerichtet sein Grundannahmen z B leich
336. temen Moduln Pakete O Lokalisierung vorhersehbarer nderungen an einer Stelle Schaffung wiederverwendbarer Softwarebestandteile LJ Voraussetzung f r Parallelisierung von Entwicklungst tigkeiten Beispiel Paket mit Implementierung des Datentyps Datum LJ Umstellung von zwei auf vierstellige Repr sentation von Jahreszahlen geschieht in genau einem Paket statt an allen Programmstellen die Datum bearbeiten LJ Datumsmodul l sst sich wiederverwenden Fehler bei der Berechnung von Schalt jahren etc werden nicht in jedem Softwareprodukt neu gemacht Erwartung Modularisierung erh ht Produktivit t und senkt Fehlerrate Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 429 Objektorientierter Softwareentwurf Echteslt systeme Beispiele f r typische nderungen Wechsel von Algorithmen z B Sortieralgorithmus Quicksort gt Mergesort U Wechsel von Datenstrukturen z B Mengenimplementierung mit linearer Liste gt Bit Array Wechsel von Hardware z B neue Ein und Ausgabeger te neue Rechner Wechsel von abstrakten Maschinen z B neues Betriebssystem Fenstersystem andere Datenbank Wechsel der Benutzeroberfl che z B Benutzeroberfl che f r Gro rechnerterminal grafische Oberfl che auf PC Wechsel des sozialen Umfelds z B Erh hung der Mehrwertsteuer Umstellung von DM auf Euro Prof Dr Andy Sch rr TU Darmstadt FB 1
337. ten Ablaufsteuerung Control Kontrolle C aus MVC gt regelt das Zusammenspiel zwischen Model und View gt steuert Ausf hrungsreihenfolge von Funktionen Datenverwaltung optionale Erg nzung des MVC Musters speichert alle Daten in Dateien oder einer Datenbank Kommunikationsdienste Klebstoff f r die MVC Bestandteile unterst tzen Kommunikation ber Prozess oder Rechnergrenzen hinweg Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 427 Fachgebiet Objektorientierter Softwareentwurf Echtzeit systeme Aufgaben eines Teilsystems Paket Modul im allgemeinen LJ dient einem klar umrissenen Zweck separation of concerns fasst eng zusammengeh rige Dienste Daten Funktionen zusammen high cohesion hohe Koh sion innerhalb eines Teilsystems besitzt ein Geheimnis verborgene Implementierungsdetails gt information hiding benutzt wenige Dienste anderer Teilsysteme gt low coupling lose Kopplung zwischen Teilsystemen besteht aus Schnittstelle angebotene Dienste und Rumpf ihre Realisierung l sst sich als eigenst ndige Einheit entwickeln bersetzen und testen bildet ein sinnvolles Arbeitspaket f r eine Person oder Gruppe Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 428 Objektorientierter Softwareentwurf Eehtzeit dec systeme Hauptnutzen von Teilsys
338. testdokument Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 61 Vorgehensmodelle der Software Entwicklung Echte dec systeme Wartung Maintenance Nach der ersten Auslieferung der Software an die Kunden beginnt im Zuge des Betriebs der Software das Elend der Software Wartung das ca 60 der gesamten Software Kosten ausmacht LJ Aufgaben siehe LV Software Engineering Wartung und Qualit tssicherung m ca 20 Fehler beheben corrective maintenance ca 20 Anpassungen durchf hren adaptive maintenance gt ca 50 Verbesserungen vornehmen perfective maintenance LJ Ergebnisse Software Problemberichte bug reports gt Software nderungs und Renovierungsvorschl ge neue Software Versionen Die Wartungsphase endet mit der Stilllegung der Software und Ersatz durch vollst ndig neue Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 62 Vorgehensmodelle der Software Entwicklung one AS systeme Probleme mit dem Wasserfallmodell zu Projektbeginn sind nur ungenaue Kosten und Ressourcensch tzungen m glich ein Pflichtenheft kann nie den Umgang mit dem fertigen System ersetzen das erst sehr sp t entsteht Risikomaximierung es gibt F lle in denen zu Projektbeginn kein vollst ndiges Pflichtenheft erstellt werden kann weil Anforderungen nicht klar Anforderungen werden fr h eingefroren notwendiger Wand
339. tf llen fehlt siehe Kapitel 8 und von uns optional um eine Einleitung erg nzt wird die die erwartete Leserschaft des Pflichtenheftes festlegt die Versionsgeschichte des Pflichtenheftes erl utert gt auf andere relevante Dokumente wie das Lastenheft verweist gt und den Aufbau des Pflichtenheftes beschreibt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 246 Objektorientierte Anforderungsanalyse Eon ES systeme Aufbau eines Pflichtenheftes 1 1 Einleitung neu war f r kompaktes Lastenheft nicht unbedingt notwendig siehe vorige Folie 2 Zielbestimmung Verfeinerung des entsprechenden Lastenheftkapitels Das Warum steht im Vordergrund es wird in Form zu erreichender Ziele Kriterien f r die Softwarefunktionalit t festgehalten Musskriterien unbedingt zu erreichende Ziele Wunschkriterien nicht unabdingbare aber sehr w nschenswerte Ziele Abgrenzungskriterien was soll mit der Software nicht erreicht werden 3 Produkteinsatz Verfeinerung des entsprechenden Lastenheftkapitels Anwendungsbereiche Aufgabenfelder die unterst tzt werden Zielgruppen Stakeholders die mit Softwaresystem umgehen werden Betriebsbedingungen wo und unter welchen Randbedingungen wird die Software eingesetzt B ro mobiler Einsatz Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 247 Objek
340. tion an der TH Darmstadt erfunden Inzwischen gibt es eine fast un berschaubare Vielzahl von Varianten Petri Netze in ihrer einfachsten Form werden hier vorgestellt da sie eine geeignete Basis f r die pr zise Beschreibung der Semantik der UML Aktivita tsdiagramme des n chsten Abschnitts darstellen c jeder Ingenieur zumindest einmal in seinem Leben diese Form der Modellierung von Systemen mit nebenl ufigem und ggf auch nichtdeterministischem Verhalten gesehen haben sollte gt wegen des lokalen Bezugs zur TH TU Darmstadt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 216 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit po systeme Grundkonzepte von Petri Netzen U Ein Petri Netz ist ein bipartiter zweigeteilter Graph mit zwei Arten von Knoten Pl tze Stellen Places speichern den Zustand eines verteilten Systems in Form von Marken Token Transitionen Transitions beschreiben Zustands berg nge des Systems Gerichtete Kanten Arcs verbinden Pl tze mit Transitionen und Transitionen mit Pl tzen aber niemals direkt Pl tze mit Pl tzen oder Transitionen mit Transitionen Eine Transition kann schalten bzw feuern bzw ist aktiviert wenn auf allen ihren Vorpl tzen Pl tze verbunden mit einlaufenden Kanten gen gend Marken liegen gt auf allen ihren Nachpl tzen Pl tze verbunden mit auslaufenden Kanten noch nicht zu viele Marken lie
341. torientierte Anforderungsanalyse Eon A systeme Aufbau eines Pflichtenheftes 2 4 Produkt bersicht neuer Abschnitt Gibt einen berblick ber das Produkt seine Funktionen sowie seine Rolle in allen relevanten Gesch ftsprozessen Verarbeitungsprozessen Neben Flie text werden haupts chlich folgende UML Diagrammarten eingesetzt Aktivit tsdiagramme f r die Beschreibung von Gesch ftsprozessen Aktivit tsbereiche werden f r die Zuordnung von Aktivit ten System funktionen zu Anwendungsbereichen verwendet Anwendungsfall Paketdiagramme f r die Unterteilung von Pro duktfunktionen in Gruppen orientiert an Anwendungsbereichen etc Anwendungsfall Diagramme mit Hauptfunktionen des Produkts als prim re Anwendungsf lle und den Zielgruppen als Akteure plus andere Teilsysteme Sensoren etc bei eingebetteten Systemen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 248 Objektorientierte Anforderungsanalyse Echtzeit systeme Aufbau eines Pflichtenheftes 3 5 Produktfunktionen Verfeinerung des entsprechenden Lastenheftkapitels Wie im Lastenheft durchnummeriert werden alle Produktfunktionen hier detailier ter beschrieben mit Verweis auf damit umgesetzte Muss oder Wunschkriterien die Gliederung Paketstruktur wird aus der Produkt bersicht bernommen und ggf verfeinert jede Hauptfunktion prim rer Anwendungsfall wird mit Hilfe eines Text schemas
342. touch a running system Umbauten k nnten unbeabsichtigt Programmver halten ndern und damit neue Fehler einbauen aber transformierte Programme sind leichter zu verstehen und damit leichter nderbar aber Regressionstests helfen dabei unbeabsichtigte Verhaltens nderungen zu erkennen aber Refactoring Werkzeuge helfen bei der Durchf hrung verhaltensbe wahrender Programmtransformationen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 445 Objektorientierter Softwareentwurf Echteslt systeme Beispielprogramm Kernteile eines Videoverleihsystems Achtung Refactoring eines so kleinen Programmes ist weitgehend sinnlos gezeigt werden hier nur die Prinzipien des Refactorings an einem berschaubaren Java Bei spiel aus Fo00 es handelt sich um ein Video Verleihverwaltungssystem also ein hnliches Beispiel wie wie unser MVRS Bei gro en Softwaresystemen ist die Vor gehensweise aber genau die gleiche public class Rental private Movie _movie private int _daysRented public Rental Movie movie int daysRented _movie movie _daysRented daysRented public int getDaysRented return _daysRented public Movie getMovie return _movie i Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 446 Objektorientierter Softwareentwurf Echuet ed systeme Beispielprogramm Klasse Movie public clas
343. tricked a person easily cheated 2 Mary gave birth to an antelope 5 Mary ate a little of the lamb Konsequenzen fur die Erhebung von Anforderungen LJ Aus einer nat rlichsprachlichen informellen Anforderungsdefinition alle vermutlich wichtigen bedeutungstragenden W rter heraussuchen f r alle wichtigen und oder m glicherweise unklaren Begriffe ein Glossar anlegen das Lastenheft und sp ter Pflichtenheft erg nzt LJ mehr Informationen zu Techniken f r pr zisere semiformale Beschreibung von Anforderungen mit Hilfe von UML in Kapitel 5 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 90 Fachgebi Requirements Engineering und Machbarkeitsstudie Eenzet ipo systeme Zuruck zum Lastenheft des Software Produkts 1 Zielbestimmung Das Programm MVRS soll eine kleine Autovermietung mit genau einer Niederlassung in die Lage versetzen die Buchung und Verleihung ihrer verschiedenen Wagentypen Arten Kategorien zu verwalten Produkteinsatz Das Produkt wird im Verkaufsraum und im Biiro der Firma vom Besitzer der Firma und oft wechselnden Aushilfskr ften bedient Produktfunktionen LF10 Ersterfassung nderung und L schung von Fahrzeugen LF20 Ersterfassung von Fahrzeugtypen LF30 Ersterfassung von Fahrzeugreservierungen LF40 Ausgabe verf gbarer Fahrzeuge eines Typs in einem bestimmten Zeitintervall mit folgenden Daten HEP SOF s
344. tring addr Address A Me l name String Rental Office addr Address Po Qualifier hasClient rs 1 RentalOffice Client a hasClient clientNo Numbei bei Implementierung problematische Qualifizierung von hasClient eliminiert Client Rolle richtig als eigene Klasse implementiert Eigenschaften einer Person ber mehrere Objekte verstreut Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 349 Fachgebiet Von der OO Analyse zum Software Entwurf Echtzeit systeme Weitere Eigenschaften von Assoziationsenden wie bei Attributen Q readonly Links d rfen nur zusammen mit der Erzeugung des beteiligten Objekts angelegt werden der Defaultwert ist false U unique es gibt keine zwei Links zwischen den selben Objekten der Default ist true Wird der Wert auf false gesetzt so sind zwei verschiedene Links zwischen den selben beiden Objekten erlaubt in Praxis wird immer mit Default gearbeitet ordered die Menge der Links die von einem Objekt ausgehen zu dem geordne ten Assoziationsende hin besitzen eine Ordnung wie diese berechnet wird kann nur als Kommentar angegeben werden der Default ist false 0 ordered derived die Assozation wird durch Formel aus anderen Assozationen berechnet zur Kennzeichnung wird dem Namen vorangestellt Default ist false Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 350 V
345. ttenen Vorgehensmodells der Softwareentwicklung eine Variante des hier vorgestellten Rational Unified Objectory Prozesses C Jones CASE s Missing Elements IEEE Spektrum Juni 1992 S 38 41 IEEE Computer Society Press 1992 Enth lt u a ein vielzitiertes Diagramm ber Produktivit ts und Qualit tsverlauf bei Einsatz von CASE OHJ99 B Oestereich Hrsg P Hruschka N Josuttis H Kocher H Krasemann M Reinhold Erfolgreich mit Objektorientierung Vorgehensmodelle und Managementpraktiken f r die objektorientierte Softwareent wicklung Oldenbourg Verlag 1999 Ein von Praktikern geschriebenes Buch mit einer F lle von Tipps und Tricks Es enth lt eine kurze Einf h rung in den Unified Software Development Process sowie in das V Modell Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 655
346. tumsangaben f r Einzelaktivit ten k nnen noch fehlen Gibt es f r alle Phasen einen Phasenverantwortlichen Zuteilung von Ressour cen zu Einzelaktivit ten kann noch fehlen Wurde Risikoabsch tzung durchgef hrt Ausfall v Gruppenmitgliedern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 100 Requirements Engineering und Machbarkeitsstudie one AS systeme 3 7 Weitere Literatur A198 A J Albrecht Measuring Application Development Productivity in Guide Share eds Proc of th eIBM Applications Development Symposium Monterey Ca 1979 83 92 Die Originalquelle f r die Function Point Methode zur Kostensch tzung H Balzert Lehrbuch der Software Technik Band 1 Software Entwicklung Spektrum Akademischer Verlag 1996 Der Aufbau von Lastenheften und die Darstellung der Function Point Methode zur Kostensch tzung wurde aus diesem Buch f r die Vorlesung bernommen De98 T DeMarco Der Termin Ein Roman ber Projektmanagement Hanser Verlag 1998 266 Seiten Mein Lieblingsbuch f r eine Einf hrung in die Probleme des Managements von Software Projekten In der Form eines Krimis geschrieben Hauptdarsteller ist ein Methodenberater der in osteurop isches Land zur Sanierung der dortigen Software Industrie entf hrt wird Als Abendlekt re sehr empfehlenswert SZ98 G Snelting A Zeller Einf hrung in Software Engineering Folien einer Vorlesung an der TU Braunsch
347. tur Ba99 H Balzert Lehrbuch der Objektmodellierung Analyse und Entwurf Spektrum Akademischer Verlag 1999 573 Seiten Brauchbare Einf hrung in die Softwareentwicklung mit UML insbesondere werden Themen wie die Gestaltung von Benutzeroberfl chen und der Einsatz objektorientierter Datenbanken mit angesprochen BC89 K Beck W Cunningham A Laboratory For Teaching Object Oriented Thinking in Proc OOPSLA 89 SIGPLAN Notices Vol 24 No 10 ACM Press 1989 1 6 Die Originalquelle zum Thema CRC Karten die f r die Identifikation von Klassen benutzt werden BD00 B Bruegge A H Dutoit Object Oriented Software Engineering Prentice Hall 2000 553 Seiten Basiert auf den Erfahrungen mit der Durchf hrung von Praktika zur objektorientierten Softwareentwick lung an der TU M nchen und der Carnegie Mellon University Beschreibt eine ganze Reihe von Faustre geln f r Projektmanagement Anforderungsanalyse Erstellung von UML Diagrammen Es ist schade dass die verwendeten Beispiele dauernd wechseln La98 Larman C Applying UML and Patterns Prentice Hall 1998 Eines der ersten UML B cher das anhand eines durchg ngigen Beispiels ein Vorgehensmodell zum Ein satz von UML vorstellt Eine vereinfachte und abge nderte Version dieses Vorgehensmodells wird in die ser Vorlesung benutzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 255 Von der OO Analyse zum Datenbank Entwurf
348. tur beschrieben sondern auch Modellierungs stile die eine Softwarearchitektur als Ganzes betreffen Schichtenarchitektur Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 525 Objektorientierter Softwareentwurf Eon ES systeme F097 Fowler M Analysis Patterns Addison Wesley 1997 357 Seiten Ein erster Versuch die Prinzipien der Softwareentwicklung mit Mustern patterns von der Entwurfs auf die Analysephase zu bertragen Fo00 Fowler M Refactoring Wie Sie das Design vorhandener Software verbessern Addison Wesley 2000 Das Standard Buch zum Thema Refactoring auf das dieses Kapitel aufbaut GH 94 Gamma E Helm R Johnson R Vlissides J Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1994 Das Standardbuch neben BMR96 das den Entwurf von Softwarearchitekturen mit einer Familie von Standardentwurfsmustern design patterns vorstellt La98 Larman C Applying UML and Patterns Prentice Hall 1998 Eines der ersten UML B cher das anhand eines durchg ngigen Beispiels ein Vorgehensmodell zum Ein satz von UML vorstellt Eine vereinfachte und abge nderte Version dieses Vorgehensmodells wird in die ser Vorlesung benutzt RLO4 Roock St Lippert M Refactorings in gro en Softwareprojekten dpunkt verlag 2004 272 Seiten Nomen est omen Es geht in diesem Buch um die Sanierung umfangreicher Softwaresysteme anstelle
349. tware Entwurfsmuster Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 7 Einf hrung in Software Engineering Een ES systeme Erg nzende Literaturquellen Ka98 H Balzert Lehrbuch der Software Technik Band 2 Software Management Software Qualitdtssiche rung Unternehmensmodellierung Spektrum Akademischer Verlag 1998 769 Seiten Hier findet man fast alles ber das Gebiet Software Technik was nicht bereits in Ba96 abgehandelt wurde Wieder ist eine CD mit den entsprechenden Werkzeugen bungsaufgaben Musterl sungen beigelegt R V Beizer Testing Object Oriented Systems Models Patterns Tools Addison Wesley 2000 1191 Seiten Die zur Zeit umfassendste Quelle zum angesprochenen Thema Gut geschrieben und umbedingt empfeh lenswert falls man die Thematik Testen vertiefen will BRJ99 G Booch J Rumbaugh I Jacobson Das UML Benutzerhandbuch Addison Wesley 2006 543 Seiten Das offizielle UML Einf hrungsbuch der drei UML V ter Es beschreibt die verschiedenen Diagram marten aus Benutzersicht allerdings ohne gr ere zusammenh ngende Beispiele zu verwenden Allge meine Software Techniken bleiben aussen vor Nicht meine Empfehlung GJM91 C Ghezzi M Jazayeri D Mandrioli Fundamentals of Software Engineering Prentice Hall 1991 573 Seiten Klassisches Software Technikbuch mit st rker lehrbuchartigem Charakter im Vergleich zu Ba96 Naturgem
350. twareentwurf Echteslt systeme Unser Videothek Beispiel aktueller Stand nach Refactoring Customer CHILDRENSiint movie Movie _name String REGULARiint daysRented int oS NEW RELEASE iint 3 _priceCode int lt gt Rental Customer _title String getDaysRented int addRental void _frequentRenterPoints int getMovie Movie getName String _charge double getCharge double printStatement String getFrequentRenterPoints i htmlStatement String Movie getTotalCharge double getPriceCode int getTotalFrequentRenterPoints setPriceCode void getTitle String getCharge double getFrequentRenterPoints i Sieht man von der noch nicht vollzogenen Einf hrung von State Klassen anstelle des Preiscodes ein haben alle bisherigen Refactoring Schritte die Klassendiagramm Struktur des Programms nicht ver ndert Bei Hinzuf gen neuer Funktionalit t werden wir deshalb erneut in Probleme laufen und nunmehr den Einsatz bekannter Entwurfs muster demonstrieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 482 Objektorientierter Softwareentwurf Eon A systeme Gew nschte Programmerweiterungen LI Es soll eine Klasse Videoshop eingef hrt werden die alle Kunden plus allgemeine Daten und Verantwortlichkeiten aufnimmt L Zudem brauchen wir eine Gruppierung von Ausleihvorg ngen nach Jahren Eingesetzte Design Pattern F r die neue Klasse Videoshop mit genau einer
351. twarekomponenten und ihrer Abh ngigkeiten mit Artefakten Beschreibung der Zielumgebung target system und der Verteilung von Komponenten auf Zielumgebung mit Knoten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 438 Objektorientierter Softwareentwurf Eenzet EX systeme Die Standard Architektur zur Erinnerung MotorVehicleReservationSystem Unterpaket von MVRS x Contracts LegalEntities Vehicles UserInterfaceSoftware Platform CommunicationSoftwa Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 439 Objektorientierter Softwareentwurf Echte ER systeme Bildung von Artefakten mit Verteilungsdiagramm isual Paradigm for UML Community Edition not for commercial use o 7 lt lt manifest gt gt 7 lt lt manifest gt gt Artefakten fassen ber manifest Abhangigkeiten Pakete Klassen zu verteilbaren Dateien z B als jar Dateien oder Bin rdateien zusammen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 440 Objektorientierter Softwareentwurf Echtzeit A systeme Verteilungsdiagramm deployment diagram als Netzwerkbeschreibung Visual rcial use Verbindung Association zwischen Knoten Knoten Node Es gibt zwei PCs und einen Datenbank Server die ber Ethernet LAN miteinander ber eine Firewall mit dem Internetverbunden sind und ber Fire Ein
352. ul ssiger Relationen erweitert man das bisherige Relationen schema R um einen Schl ssel K oder eine Menge von Schl sseln also R R K ist erweitertes Relationenschema mit Attributen R und K c R Beispiele JO m Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 291 Von der OO Analyse zum Datenbank Entwurf Een EX systeme Relation zur Darstellung von Personen Personen PANr Vorname Nachname PLZ Ort Stra e Geb datum 4711 Andreas Heuer 18209 BHS 15 31 10 1958 5588 Gunter Saake 39106 MD STS 55 05 10 1960 0007 Andy Sch rr 82024 TK AS 12 03 08 1961 7154 Andreas M ller 18205 RS 31 25 02 1976 8832 Tamara Jagellovsk 38106 BS GS 12 11 11 1973 9912 Antje Hellhof 18059 21 04 04 1970 9999 Christa Loeser 69121 HD TS 38 10 05 1969 Q Das k nstliche Attribut PANr wurde eingef hrt da es sonst keinen wirklich sinnvollen Prim r Schl ssel f r die Relation gibt Q Es gibt aber nicht nur die funktionale Abh ngigkeit aller Attribute von PANr sondern auch funktionale Abh ngigkeiten zwischen den Bestandteilen der Adresse siehe folgende Folien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 292 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme Ziel des Datenbankentwurfs Das Ziel des relationalen Datenbankentwurfes ist es Relationenschemata mit ihren Prim r Schl s
353. umschlossenen Interaktionen werden mindestens m mal h chstens n mal ausgef hrt zus tzlich kann es Iterationsbedingung geben LI alt eine Reihe von Interaktionsbereichen Alternativen besitzen jeweils eine Bedingung und werden ausgef hrt falls diese Bedingung erf llt ist die Bedingungen sollten sich gegenseitig ausschlie en par eine Reihe von Interaktionssequenzen k nnen nebenl ufig entweder sequen tiell verschr nkt oder echt parallel in beliebiger Reihenfolge ausgef hrt werden ref es wird eine separat definierte Interaktionssequenz aufgerufen referenziert die ber mehrere Lebenslinien hinweg definiert sein kann Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 382 Fachgebiet f Von der OO Analyse zum Software Entwurf Echtzeit 3 Beispiel fur Schleife und Aufruf eines anderen Interaktionsdiagramms Moglichkeit zur Definition einer einfachen Anweisung Visual ca UML Standard Edition TU Darmstad Erzeugung einer Menge aClerk Clerk von Objekten vs findVehicles p c Schleife die maximal 0 vs size so oft ausgefuhrt wird wie vs Elemente enthalt Bedingung fur Fortfuhrung der Schleife Aufruf eines anderen Interaktionsdiagramms Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 383 Von der OO Analyse zum Software Entwurf Echtzeit dick systeme Zusammenfassung wichtiger Elemente von Sequenzdiagrammen Objekter
354. undanzen weitgehend vermeidet Konsistenzbedingungen aus dem ER Modell weitgehend erh lt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 277 Von der OO Analyse zum Datenbank Entwurf Eon ES systeme Verteilungsentwurf Sollen die Daten auf mehreren Rechnern verteilt vorliegen mu Art und Weise der verteilten Speicherung festgelegt werden Verteilungsarten bei Relationen Kunde KNr Name Adresse PLZ Kontostand horizontale Verteilung Kunde1 KNr Name Adresse PLZ Kontostand where PLZ lt 50 000 und Kunde2 KNr Name Adresse PLZ Kontostand where PLZ gt 50 000 vertikale Verteilung KundeAdr KNr Name Adresse PLZ und KundeKonto KNr Kontostand Verbindung kann ber KNr Attribut hergestellt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 278 Von der OO Analyse zum Datenbank Entwurf Echtzeit Mich systeme Datendefinition Umsetzung des logischen Schemas in ein konkretes Datenbankschema mit Data Definition Language DDL Data Manipulation Language DML eines konkreten DBMS Oracle MS Access Vorgehensweise LJ Datenbankdeklaration mit DDL LI Realisierung der Integrit tssicherung in LJ Definition der Benutzersichten Definition von Update Operationen Anfragen Auswertungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 279 Von der
355. ung des Alters statt gt 18 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 359 Von der OO Analyse zum Software Entwurf one ip systeme Unzul ssige Verfeinerung von OCL Bedingungen bei Vererbung context Client2 incrementFrequentRenterBonus bonusilInteger Integer Client2 sei eine direkte Unterklasse von Client pre bonus gt 0 and currentBonus bonus lt 30 unzul ssige Einschr nkung der Vorbedingung post currentBonus lt bonus currentBonus pre unzul ssige Aufweichung der Nachbedingung post result currentBonus context Client2 inv age gt 17 unzulassige Lockerung der Altersvorschrift statt gt 18 Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 360 Von der OO Analyse zum Software Entwurf Eontzeit systeme OCL Navigationsausdr cke Rental mel Ir nasorens chen myClients name String age Integer context Client inv self age gt 18 alle Kunden sind mindestens 18 Attributzugriff context RentalOffice self myClients Kollektion aller Kunden Linktraversierung Angabe des Rollennamens context Client self rentalOffice liefert ein Objekt zu einer Person Linktraversierung Angabe des Klassennamens mit kleinem Anfangsbuchstaben context RentalOffice self myClients age Kollektion aller Altersangaben aller Kunden Prof Dr Andy Sch rr
356. unktion Bezug nehmen und in seiner Beschreibung Begriffe aus Glossar verwenden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 180 Objektorientierte Anforderungsanalyse Echtzeit ec systeme Probleme bei der Verwendung von Anforderungsfallen LJ Wie findet man Anwendungsf lle und wer sind die Akteure Achtung Manche Experten raten zur Verwendung weniger Anwendungsfalle und Vermeidung von Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 181 Objektorientierte Anforderungsanalyse Enten gg Echizeit systeme Pakete zur hierarchischen Strukturierung von Anwendungsfallen ReservationAdministration _ lfsub clements Paket das nur Client Anwendungsf lle Clerk an MRS Reservations enth lt import Beziehung Dependency ClientAdministration VehicleAdminstration Paketdiagramme wurden eigentlich f r die Organisation vieler Klassen eines Projektes eingef hrt wie packages in Java sie werden aber inzwischen f r die hierarchische Organisation beliebiger UML Artefakte eingesetzt mit ihrer Hilfe lassen sich also auch die Anwendungsf lle eines Projekts bersichtlich anordnen weiteres hierzu in Kapitel 8 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 182 Objektorientierte Anforderungsanalyse Echtzeit A systeme Zusammenfassung der Anwendungsfalldiagrammelemente Sub Systemgrenz
357. untFor deuble thisAmeuntRental each determine amounts for each line double thisAmount 0 switch each getMovie getPriceCode case Movie REGULAR thisAmount 2 if each getDaysRented gt 2 thisAmount each getDaysRented 2 1 5 break case Movie NEW_RELEASE thisAmount each getDaysRented 3 break case Movie CHILDREN thisAmount 1 5 if each getDaysRented gt 3 thisAmount each getDaysRented 3 1 5 break return thisAmount Anmerkung die Methode ist mit Eingabeparameter thisAmount von CASE Tool automatisch extrahiert worden da aber Parameter thisAmount immer mit Wert 0 vor Aufruf initialisiert wird kann man eine lokale Variable daraus machen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 453 Objektorientierter Softwareentwurf Echte dec systeme Zweiter Refactoring Schritt Rename Vern nftige Namen f r Variablen Methoden Klasssen sind wichtig f r die Lesbarkeit von Programmen Deshalb sind Umbenennungen wie each in aRental oder thisAmount in result kein berfl ssiger Luxus private double amountFor Rental aRental determine amounts for each rental object double result 0 switch aRental getMovie getPriceCode case Movie REGULAR result 2 if aRental getDaysRented gt 2 result aRental getDaysRented 2 1 5 break case Movie CHILDREN result 1 5 if aRe
358. up http www standishgroup com ver ffentlich in regelm igen Abst nden den sogenannten Chaos Report mit folgenden Ergebnissen f r 2012 LJ 18 aller betrachteten IT Projekte sind gescheitert fr her 25 L 43 aller betrachteten IT Projekte sind dabei zu scheitern fr her 50 signifikante berschreitungen von Finanzbudget und Zeitrahmen U 39 aller betrachteten IT Projekte sind erfolgreich fr her 25 Hauptgr nde f r Scheitern von Projekten Unklare Anforderungen und Abh ngigkeiten sowie Probleme beim nderungsmanagement Bekannte Beispiele aus den letzten Jahren Toll Collect Hessische Schul Software LUSD Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 17 Fachgebiet Software Technik Was ist das Echtzeit fp systeme Warum ist Softwareerstellung so schwierig Q Kommunikationsprobleme mit dem Anwender wenig Anwendungswissen bei Entwicklern in Konflikt stehende Anforderungen Software ist immateriell und wird nicht durch physikalische Gesetze begrenzt Modellbildung f r relevanten Weltausschnitt schwierig Software l sst sich leicht er modifizieren als Hardware Anforderungen ndern s ch w hrend Entwicklungszeit Software unterliegt keinem Verschleiss altert aber trotzdem Wartungsprobleme Jahr 2000 Problem Software muss auf verschiedenen Plattformen laufen gt Portabilit tsprobleme Software existier
359. uss sehr gut sein da sie von wechselnden Aushilfskr ften bedient werden Erg nzungen wie z B Abgrenzungskriterien Die Zuordnung verf gbarer Fahrzeuge zu Reservierungen erfolgt in der ersten Version manuell Buchhaltungsfunktionen geh ren nicht zum Leistungsumfang Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 93 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit systeme Glossar zu Lastenheft Das Glossar ist entweder Bestandteil des Lastenheftes oder auch ein separates Dokument da es sp ter weiterverwendet wird Es erl utert alle wichtigen Begriffe der Welt der Anwender Stakeholders knapp aber pr zise Beispiele f r Begriffe Q Fahrzeug ein Automobil das entweder mit F hrerschein Klasse 3 oder F hrer schein Klasse 2 gefahren werden darf Fahrr der Motorr der Schiffe werden nicht betrachtet LJ Fahrzeugtyp ein bestimmtes Fabrikat eines Herstellers wie Smart Corsa LY Aushilfskraft f r einen beschr nkten Zeitraum und maximal 12 Stunden pro Woche in der Autovermittlung am Kundenschalter arbeitende Person E Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 94 Fachgebiet Requirements Engineering und Machbarkeitsstudie Echtzeit systeme Erstellung von Lastenheft mit Process otris Software AG Dortmund IE PROCESS Pflichtenheftgenerator Anwendung Stammdatenlisten Ersterfassun
360. ut f r Datentechnik Seite 635 Management der Software Entwicklung Eott gt systeme Beispiel fur die Bewertung externer Ausgabedaten LJ Daten zu einem Reservierungsvertrag mit Vertragsnummer anzeigen mit Name des Kunden und tats chlicher Fahrzeugkategorie zus tzlich zu Kundennummer und Fahrzeugnummer alle Reservierungsvertr ge zu einem Kunden mit Kundennummer anzeigen die Kosten f r alle Reservierungsvertr ge eines Kunden anzeigen Es wird wie folgt gez hlt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 636 Management der Software Entwicklung Eon A systeme Externe Abfragen External Inquiry EQ Betrachtet werden Elementarprozesse Produktfunktion Use Case die anhand von Eingaben Daten des internen Datenbestandes ausgeben ohne auf diesen Daten kom plexe Berechnungen durchzuf hren Nach den Regeln f r Externe Eingaben werden die Eingabedaten bewertet nach den Regeln f r Externe Ausgaben die Ausgabedaten anschlie end wird die h here Komplexit t bernommen und wie folgt umgerechnet einfach 3 FPs mittel 4 FPs oder komplex 6 FPs Achtung ein Elementarprozess der Eingabedaten zur Suche nach intern gespeicher ten Daten ben tigt und vor der Ausgabe komplexe Berechnungen durchf hrt wird anders behandelt In diesem Fall wird nicht das Maximum gebildet sondern die Summe der FPs von Externe Eingabe und Externe Ausgabe
361. utert einige Konsistenzregeln werden in OCL definiert es gibt etwa 12 Diagrammarten die teilweise gegeneinander konkurrieren verschiedene Diagramme k nnen f r hnliche Zwecke eingesetzt werden das Metamodell ist leicht erweiterbar was uns eine F lle von UML Dialekten Profile genannt mit entsprechenden Werkzeugen beschert Weiterf hrende Literatur zu UML Zu UML gibt es unz hlige B cher sehr unterschiedlicher Qualit t Siehe Anfang des Vorlesungsskripts f r Empfehlungen und Literaturliste am Ende dieses Kapitels Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 149 Grundlagen der objektorientierten Modellierung Modell und Metamodell Typ Metaklasse Klasse Metaklasse Auto Klasse preis Euro ort String Verk uflich Typ gibPreis Euro be gibPreis Euro bewege M V 6120 Auto preis 30 000 ort M nchen DA T 4378 Auto preis 20 000 ort Darmstadt Fachgebiet f Echtzeit systeme 2 Bestandteile meiner Modellierungssprache Metamodell Beweglich Typ bewege Modell meines Programms zur Entwicklungszeit Objekte meines Programms zur Laufzeit Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 150 Fachgebiet Grundlagen der objektorientierten Modellierung Echtzeit po systeme 4 4 Weitere Literatur BHK04 M Born E Holz O Kath Soft
362. voll normale Assoziationen sind bidirektional und k nnen in beiden Richtungen traversiert werden unidirektionale Assoziationen mit Pfeilspitze an einem Ende und Kreuz am anderen Ende k nnen nur in einer Richtung traversiert werden im Beispiel Client verweist auf viele ReservationContracts aber ein ReservationContract kennt den zugeh rigen Client nicht LJ Navigierrichtung diesmal verkehrt herum Client Reservation Contract jetzt kennt ein ReservationContract den zugeh rigen Client aber ein Client weiss nicht welche Reservierungen er hat gt Bedeutung von Assoziationsende ohne Pfeil und Kreuz nicht festgelegt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 202 Objektorientierte Anforderungsanalyse Eehtzeit gd systeme Navigierrichtung Abk rzungsregel 1 Reservation Contract wir interpretieren eine solche Assoziation als nur in einer Richtung navi gierbar Kreuz wird beim Client erg nzt Navigierrichtung Abk rzungsregel 2 has gt Client Reservation Contract wir interpretieren eine solche Assoziation als in beiden Richtungen navigierbar Pfeile werden auf Seiten beiden erg nzt Navigierrichtung diese Variante verwenden wir nicht has gt R Client H lt eservation 1 Contract beidseitig nicht navigierbare Assoziation als eigene Datenstruktur sinnvoll Prof Dr Andy Sch rr TU Darmstadt FB 18 Inst
363. von Eigenschaften testende Verfahren der Pr fling wird mit konkreten oder abstrakten Eingabewerten von Menschen oder Werkzeugen ausgef hrt dynamischer Test Simulation Ausf hrung mit konkreten Eingaben symbolischer Test Interpretation mit symbolischen Eingaben die oft unendliche Mengen m glicher konkreter Eingaben repr sentieren Schreibtischtest Ausf hrung mit Papier und Bleistift Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 537 Qualit tssicherung und Testverfahren Eon ES systeme Wann kann welches Verfahren eingesetzt werden konstruktives Qualitit tsmanagement reduziert menschliche Fehler errors und senkt damit a priori die Anzahl der Fehler faults LJ analytisches Qualit tsmanagement erh ht die Fehlereliminationsrate dient also der Entdeckung und Behebung von Fehlern faults Softwareinspektion l sst sich in allen Phasen der Softwareentwicklung zur Elimination von Fehlern faults einsetzen die statische Analyse erfordert Modelle mit pr zise definierten Konsi stenzbedingungen z B UML Diagramme oder Code sie liefert in aller Regel nur Hinweise auf Fehler faults formale Verifikation erfordert ausf hrbaren Code oder ausf hrbares Modell und beweist die Abwesenheit von fehlerhaften Programmstellen faults Testen erfordert ausf hrbaren Code oder ausf hrbares Modell und findet Programmfehler faults durch Ausl sen von Fe
364. wareentwicklung mit UML2 Addison Wesley 2004 293 Seiten Bereits Ende 2003 fertiggestelltes Buch ber UML2 das deshalb die allerletzten nderungen im Standard noch nicht nachvollzogen hat Besonderheit erl utert nicht nur umgangssprachlich UML2 son dern befasst sich auch mit der Definition der Sprache durch Metamodellierung Modellierungselemente und Metamodellausschnitte werden abwechselnd pr sentiert Bu98 T Budd Object Oriented Programming with JAVA Addison Wesley 1998 Sch ne Java Einf hrung die zudem die Konzepte der objektorientierten Programmierung erkl rt B094 G Booch Object Oriented Analysis and Design with Applications 2nd Ed Benjamin Cummings 1994 lteres Standardwerk zur objektorientierten Softwareentwicklung von dem Haupt Vater der UML HK05 M Hitz G Kappel E Kapsammer W Retschitzegger UML Work 3 te Auflage dpunkt verlag 2005 422 Seiten Sehr sch n geschriebenes UML Buch mit durchg ngigem Beispiel das auch auf die d steren Seiten der UML eingeht und umstrittene Sprachkonstrukte ausf hrlich diskutiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 151 Objektorientierte Anforderungsanalyse Echtzeit systeme 5 Objektorientierte Anforderungsanalyse Themen dieses Kapitels LJ Beschreibung von Anwendungs Nutzf llen mit Use Case Diagrammen Datenmodellierung mit UML Objekt und Klassendiagrammen Modellierung von Abl ufen
365. weig Dieser Vorlesung wurden die Regeln f r die Erstellung lesbarer Dokumente entnommen WWO00 D L Well D Widdrig Managing Software Requirements A Unified Approach Addison Wesley 2000 491 Seiten Diesem Buch wurden einige Beispiele und Techniken zur Ermittlung von Anforderungen an ein Software System entnommen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 101 Grundlagen der objektorientierten Modellierung Echte d systeme 4 Grundlagen der objektorientierten Modellierung Themen dieses Kapitels strukturierte versus objektorientierte Softwaremodellierung LJ Grundbegriffe der Objektorientierung Klasse Vererbung Geschichte der Standard OO Modellierungssprache UML Achtung Dieses Kapitel ist keine Einf hrung in die objektorientierte Programmierung daf r gibt es ein Praktikum und eigene Vorlesungen Hier werden nur die Grundideen der objektorientierten Softwareentwicklung zusammengefasst Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 102 Grundlagen der objektorientierten Modellierung anti systeme Mittel der Softwaretechnik der Regenbogen Vorgehensmodelle Methode by Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 103 Fachgebiet f Echizeit amp Grundlagen der objektorientierten Modellierung systeme 4 1 Modellierung von Software Systemen Problem
366. wicklungsprozesses die Entwicklung einer Produktgeneration dauert h chstens 18 Monate eine Vorbereitungsphase dauert 3 6 Wochen und besteht aus einer Iteration eine Entwurfsphase dauert 1 3 Monate und besteht aus bis zu 2 Iterationen eine Konstruktionsphase dauert 1 9 Monate und besteht aus bis zu 7 Iterationen eine Einf hrungsphase dauert 4 8 Wochen und besteht aus einer Iteration jede Iteration dauert 4 8 Wochen ggf exklusive Vorbereitungs und Nachberei tungszeiten die mit anderen Iterationen berlappen d rfen das gew nschte Ergebnis Software Release einer Iteration ist sp testens bei ihrem Beginn festgelegt oft Abh ngigkeit von Ergebnissen vorheriger Iterationen die geplante Zeit f r eine Iteration wird nie h chstens um 50 berschritten innerhalb der Konstruktionsphase wird mindestens im w chentlichen Abstand ein internes Software Release erstellt mindestens 40 Reserve an Projektlaufzeit f r unbekannte Anforderungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 587 Management der Software Entwicklung Echtzeit systeme Rollenbasierte Softwareentwicklung und Arbeitsbereiche Wiederholung eine Rolle WorkerKind beschreibt eine Menge von eng zusammengeh rigen Aufgaben und Verantwortlichkeiten oft auch notwendige Qualifikationen Personen im Extremfall auch Werkzeuge nehmen Rollen ein ein Arbeitsbereich ActivityKind umfasst eine Menge eng zusammen
367. wird Wird Aggregat als verzeigerte Datenstruktur Liste realisiert so zeigt Index immer auf das n chste Element Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 490 Objektorientierter Softwareentwurf Echteslt systeme Fortsetzung des lterator Entwurfsmusters LI Beispiel fiir Iterator Instanziierung eigene Notation mit Stereotypen lt lt Element gt gt RentalComponent _dateRange String RentalComponent getDateRange String getCharge double getFRP int first next getCurrent haben N Index _ current ist entweder Zahl Index f r Vector package local Sichtbarkeit oder Zeiger auf n chste RentalComponent lt lt Aggregate gt gt lt lt lterator gt gt RentalComposite Rentallterator BER currentiindex RentalComposite ea first void addChild void next void Rentallterator current RentalComponent iterate Rentallterator isDone boolean first Index next Index current Rentallterator Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 491 Objektorientierter Softwareentwurf Eenzet PA systeme Beispiel f r Iterator Instanziierung UML Notation RentalComponent _dateRange String RentalComponent getDateRange String getCharge double getFRP int Iterator RentalComposite Rentallterator NEE _eurrent index RentalComposite h F l ptt mn first void addChild void next void Rent
368. y 1999 Die Einf hrung in das Thema XP geschrieben vom Erfinder Papst selbst Selbst habe ich das Buch nie in H nden gehalten und werde es auch in Zukunft nicht lesen BEM92 A W Brown A N Earl J A McDermid Software Engineering Environments Automated Support for Software Engineering McGraw Hill 1992 Etwas trockenes und nicht mehr ganz aktuelles Buch zum Thema Software Entwicklungsumgebungen Beschreibt Anforderungen an Umgebungen liefert aber keine Informationen zu aktuellen CASE Tools JBR99 I Jacobson G Booch J Rumbaugh The Unified Software Development Process Addison Wesley 1999 Pr sentation des auf die UML zugeschnittenen Vorgehensmodells der Software Entwicklung eine Vari ante des hier vorgestellten Rational Unified Objectory Prozesses OHJ99 B Oestereich Hrsg P Hruschka N Josuttis H Kocher H Krasemann M Reinhold Erfolgreich mit Objektorientierung Vorgehensmodelle und Managementpraktiken f r die objektorientierte Software Ent wicklung Oldenbourg Verlag 1999 Ein von Praktikern geschriebenes Buch mit einer F lle von Tipps und Tricks Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 67 Requirements Engineering und Machbarkeitsstudie Echtzeit g systeme 3 Requirements Engineering und Machbarkeitsstudie Themen dieses Kapitels LJ Vorbereitung und Planung eines Software Entwicklungsprojektes L Methoden der Anforderungsbestimmung Requirements Eng
369. ysteme Softwareumfang Lines of Code Die Lines of Code als Ausgangsbasis f r die Projektplanung und damit auch zur berwachung der Produktivit t von Mitarbeitern zu verwenden ist fragw rdig da Codeumfang erst mit Abschluss der Implementierungsphase bekannt ist gt selbst Architektur auf Teilsystemebene noch unbekannt ist Wiederverwendung mit geringeren LOC Zahlen bestraft wird gr ndliche Analyse Design Testen zu geringerer Produktivit t f hrt Anzahl von Codezeilen abh ngig vom pers nlichen Programmierstil ist Handb cher schreiben ungen gend ber cksichtigt wird Achtung Die starke Abh ngigkeit der LOC Zahlen von einer Programmiersprache ist zul ssig da Programmiersprachenwahl gro en Einfluss auf Produktivit t hat Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 627 Einfluss von Programmiersprache auf Produktivit t Management der Software Entwicklung Fachgebiet Echizeit systeme Analyse Design Codierung Test Sonstiges C 3 Wochen 5 Wochen 8 Wochen 10 Wochen 2 Wochen Smalltalk 3 Wochen 5 Wochen 2 Wochen 6 Wochen 2 Wochen Konsequenzen f r die Gesamtproduktivit t Programmgr e Aufwand Produktivit t C 2 000 LOC 28 Wochen 70 LOC Woche Smalltalk 500 LOC 18 Wochen 27 LOC Woche Fazit Produktivit
370. zeugen wurde berechnet Return To Aufrufstelle in ReserveVehicle falls Liste nicht leer Ende von ReserveVehicle falls Liste leer Category niedrige Priorit t erspart nur Neustarten der Reservierung Cross Ref auf LF 30 aus Lastenheft siehe Abschnitt 3 3 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 176 Objektorientierte Anforderungsanalyse Echtzeit ec systeme Notation von Erweiterungspunkten Liste von Erweiterungs zus tzliche won punkten eines Aktivierungs 0 step7 JS Anwendungsfalles bedingung an al l lt lt extend gt gt after step 7 referenzierter Erweiterungspunkt Problem mit Erweiterungspunkten LJ der erweiterte Anwendungsfall soll nichts von seinen Erweiterungen wissen also muss er an jeder beliebigen Stelle erweiterbar sein extension points besitzen E LJ f hrt zu einer nichtssagenden langen Liste von Erweiterungspunkten E Syntax f r die Referenzierung von Erweiterungspunkten nicht im Standard after before viele Werkzeuge unterst tzen das alles nur mit Trickserei Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 177 Objektorientierte Anforderungsanalyse Echtzeit systeme Varianten der Anwendungsfallbeschreibung aus St05 Es gibt nicht die Standardstruktur f r die textuelle Beschreibung von Anwendungs f llen sondern jedes Buch jede Firma hat ihr eigenes Template daf r
371. zeugung Erzeugungsnachricht rekursiver Aufruf Return Bedingung asynchrones Signal Objektzerst rung SO ref Sequence Diagram2 Aufruf eines Sequenzdiagramms Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 384 Fachgebiet Von der OO Analyse zum Software Entwurf Echtzeit dp systeme Anmerkungen zu Sequenzdiagramme LJ Sequenzdiagramme werden manuell erstellt oder generiert gt vom Modellierer manuell oft in fr hen Phasen der Softwareentwicklung gt von Werkzeugen generiert als Visualisierungen von Testl ufen Hauptanwendungsgebiete von Sequenzdiagrammen sind detaillierte Beschreibung von Anwendungsfallen Festlegung von Testf llen k nnen mit generierten Diagrammen bei Testl ufen verglichen werden MSCs Message Sequence Charts Diagramme sind verwandter ITU T Standard der Telekommunikationsindustrie mit etwa den selben Konstrukten Werkzeuge unterst tzen Sequenzdiagramme sehr unterschiedlich umfangreich ich kenne kein Werkzeug das UML Sequenzdiagramme vollst ndig realisiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 385 Von der OO Analyse zum Software Entwurf Echtesit systeme 7 4 Zustandsautomaten UML Statecharts Aufgabe Beschreibung des Verhaltens der Objekte einer Klasse und nicht Zusammenspiel der Objekte versc
372. ziationen Beziehungen und Attribute zu den identifizierten Klassen optional Vererbungsbeziehungen ggf zun chst Erstellung konkreter er Objektdiagramme und dann Erstellung abstrakter er Analyse Klassendiagramme meist werden noch keine Operationen bei Klassen festgelegt alle gefundenen Klassen Beziehungen auch im Glossar auff hren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 184 Objektorientierte Anforderungsanalyse Von der realen Welt zum Klassendiagramm Objektdiagramm Helga Clie name Helga worksFor DeadFishlnc worksFor Abstraktion Fachgebiet f Echtzeit A systeme Klassendiagramm Contract F Attribute reale Welt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 185 Objektorientierte Anforderungsanalyse Echte ed systeme Einfaches Klassendiagramm Contract Bkttrivutes contractNo Attribute frequentClient Assoziation Company ff attributes name Ursprung Entity Relationship Modell siehe Abschnitt 4 1 Seite 108 es legt die Objekt und Beziehungsarten Assoziationen des Anwendungsbereichs mit ihren wichtigsten Attributen fest Klassen werden in dieser Phase meist ohne Operationen definiert Grund Prof Dr Andy Schiirr TU Darmstadt FB 18 Institut fiir Datentechnik Seite 186 Fachgebiet Objektorientierte Anforderungsanalyse Echtzeit fp

komplette Skript - Fachgebiet Echtzeitsysteme

Contents

Download Pdf Manuals

Related Search

Related Contents