Home

Softwaretechnik ¨Uberblick I - FB3 - Uni Bremen

1. EIF InProceedings Article Booktitle Volume Definition Number Datenelementtypen DET Data Month Element Type fiir Benutzer erkennbares eindeutig bestimmbares o RET 2 nicht rekursives Feld DET 7 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 70 395 Softwaretechnik Kosten und Aufwandsschatzung Function Points 2006 07 19 Hier werden die Daten abgesch tzt Beispiel Komplexit tsgewichte w f r ELF und ILF Beispiel Komplexit tsgewichte w f r ELF und ILF Definition Satzarten RET Record Element Type ennbare Function Points zusammenfassen Parameter Z hler DET Gewicht ILFy ELF 1 1 Parameter Ely EQ EQ Zahler DET Gewicht Unadjusted Function Points UFP Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 71 395 Komplexit tsgewichte w f r El EO EQ Definition Referenzierte Datenbest nde FTR File Type Referenced von Transaktion verwendeter Datenbestand ILF ELF Beispiel Datenbank oder Textdatei die bei der Ausgabe von Kundendaten herangezogen wird Beispiele f r DETs im Kontext Transaktionen Eingabe Ausgabefelder GUI Spalten u A bei Berichten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 73 395 Softwaretechn
2. DrawingEditor gt gt BoundingBox _ GetExtent A text 3 return text GetExtent Line TextShape i BoundingBox BoundingBox f Library Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 321 395 L sung Objekt Adapter ag Target Adaptee Request SpecificRequest adaptee Adapter adaptee Request a1 SpecificRequest Konsequenzen o erlaubt Anpassung von Adaptee und all seine Unterklassen auf einmal o Overriding von Adaptees Methoden schwierig Ableitung von Adaptee Adapter referenziert auf Ableitung o f hrt Indirektion ein Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 322 395 L sung Klassen Adapter een es Target Adaptee Request SpecificRequest A implementation Adapter Request zes ee Konsequenzen o keine Indirektion o setzt Mehrfachvererbung voraus o passt nur Adaptee an nicht seine Unterklassen o Overriding von Adaptees Methoden einfach Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 323 395 Problem Some text Ci callback Rainer Koschke Uni Bremen L sung in C Klient void YesButtonPressed void NoBu
3. Software Architektur Komponenten Konnektoren f Konfiguration gt Konzeptioneller Blickwinkel a Laufzeit Komponenten Modul beschr nk 5 hend beschr nkungen ungen g onfiguration Module E gt 2 O O Modulblickwinkel 2 lt neue D a Module Reue DORIA z Subsysteme Modula risierung 2 5 Schichten risierung Laufzeit zZ elemente gt Code Blickwinkel nderungen an Laufzeit elementen Einfluss Quell Code R ckkopplung j Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 229 395 Funktionalit t versus Qualit t Definition Funktionalit t Umsetzung der funktionalen Anforderungen die F higkeit eines Software Systems auf eine Eingabe die erwartete Ausgabe zu produzieren Funktionalitat kann durch beliebige Strukturen umgesetzt werden ist damit weitgehend unabh ngig von Struktur Software Architektur schr nkt m gliche Strukturen ein aufgrund anderer Qualit tsattribute Definition Qualit t ist der Grad in dem ein Satz inh renter Merkmale Anforderungen erf llt EN ISO 9000 2005 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 232 395 Beispiele f r Software Qualit tsaspekte o nderbarkeit o Testbarkeit o Sicherheit Robustheit o Gebrauchstauglichkeit Usability o Performanz o Verf gbarkeit o Skalierbarkeit o Portierbarkeit Rainer Koschke Uni Bremen
4. Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 306 395 Lernziele o Verstehen was Entwurfsmuster sind o Verschiedene Enwurfsmuster kennen und anwenden k nnen o Qualit ten und Einsetzbarkeit der Entwurfsmuster kennen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 307 395 Entwurfsmuster Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use this solution a million times over without ever doing it the same way twice Christopher Alexander Architekt und Mathematiker A pattern language 1977 Definition Entwurfsmuster Musterlosung f r ein wiederkehrendes Entwurfsproblem Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 309 395 Zusammengesetzte Fahrradelemente Artikel tentfernen entfernen Laufrad entfernen tentfernen Wir wollen o Teil von Hierarchien f r Artikel bilden o Verwender von Artikeln sollen den Unterschied zwischen Kompositionen und Einzelelementen ignorieren k nnen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 310 395 Modellierung der Teil von Hierarchie Artikel entfernen Verwender gt hinzuf gen Artikel alleTeile list of Artikel Blatt entfer
5. FTRs ELF 1 19 20 50 51 RETs 2 5 5 6 T FTRs Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 76 395 Beispiel Function Points zusammenfassen El BibTeX Datei importieren EO Abfrage ber Taxonomie anzeig EQ Artikel ber Suchmaske abfrage ILF 1 Referenzen Datenbank ELF externe Bib TeX Datei 8 en lassen n Parameter Z hler R ET Gewicht ILFy 7 ELF 5 ET D 2 T 2 T Parameter FTR DET Gewicht El 2 T 4 EQ 1 T 4 EQ Unadjusted Function Points UFP 23 Rainer Koschke Uni Bremen Softwaretechnik FP Gewichtete Function Points Systemmerkmale Datenkommunikation o Verteilte Verarbeitung o Leistungsf higkeit o Begrenzte Kapazit t 9 Transaktionsrate o Interaktive Dateneingabe o Benutzerfreundlichkeit Bewertung 0 kein Einfluss 5 starker Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 77 395 Interaktive nderung Komplexe Verarbeitung Wiederverwendbarkeit Installationshilfen Betriebshilfen Mehrfachinstallation nderungsfreundlichkeit Einfluss Sommersemester 2006 79 395 Konkrete Fragen Does the system require reliable backup and recovery 3 o Are data communications required 2 o Are there distributed processing functions 0 o Is performance critical 1
6. Skalenhierarchie Rainer Koschke Uni Bremen Nominalskala 4 Ordinalskala gt Intervallskala Rationalskala Absolutskala absoluter Vergleich Softwaretechnik Skalenhierarchie Nominalskala 1 Nominalskala Rainer Koschke Uni Bremen Operationen Statistiken H ufigkeit ungeordnete 1 1 Abbildung Transformationen beliebige 1 1 Beispiel Programmiersprachen C C Softwaretechnik Sommersemester 2006 25 395 Java Sommersemester 2006 26 395 Skalenhierarchie Ordinalskala 2 Ordinalskala o dazu vollst ndige Ordnung o Transformationen streng monoton steigend o Operationen lt gt o Statistiken Median Beispiel Priorit ten niedrig lt mittel lt hoch Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 27 395 Skalenhierarchie Intervallskala 3 Intervallskala o dazu Distanzfunktion Transformationen M aM b a gt 0 Operationen Statistiken Mittelwert Standardabweichung Beispiel Temperatur 5 T Celsius 9 T Fahrenheit 32 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 28 395 Definition Metrik Metrik Distanzfunktion d A x A IR mit d a b gt 0 Ya b A d a b 0 lt a b d a b d
7. Metrik Messung kommt nicht naher Sommersemester 2006 erweitern akzeptieren kommt naher 372 395 o Datenerfassung mit Frageb gen oder ethnographische Studien o k nnen auch a posteriori durchgef hrt werden o dienen oft der Bildung von Hypothesen f r nachfolgende Fallstudien oder kontrollierte Experimente o fundierte Methoden zur Datenerhebung und validierung notwendig entstammen den Sozialwissenschaften und kognitiven Wissenschaften Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 374 395 Untersuchungsmethoden Fallstudien Quasi Experimente o In Vivo Experiment oder Feldstudien mit Hypothese o eingebettet in echte Projekte und damit weniger kontrolliert o Herausforderung zu messen ohne den Verlauf zu verf lschen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 375 395 Untersuchungsmethoden kontrollierte Experimente In Vitro Experiment o finden in kontrollierter Testumgebung statt o Hypothese wird falsifiziert oder best tigt mit einer gewissen Wahrscheinlichkeit o unabh ngige Variablen Eingabeparameter die im Experiment variiert werden o abh ngige Variablen Ausgabeparameter die gemessen werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 376 395 Bestandteile eines Experiments 1 Festlegung der Ziele Aspekte Objekt der Studie
8. class Strategy virtual void Algorithm 0 class Strategyl Strategy virtual void Algorithm Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 362 395 Architekturmechanismen f r Variabilit ten Generierung z B Yacc Grammatik Code und aspektorientierte Programmierung aspect SetsInRotateCounting int rotateCount 0 before call void Line rotate double rotateCount o Wie oft wird Methode Line rotate aufgerufen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 363 395 Architekturmechanismen f r Variabilit ten Definition Anwendungsrahmenwerke Frameworks A framework is a set of classes that embodies and abstract design for solutions to a family of related problems Johnson und Foote 1988 run TestResult TestCase TestSuite TestResult run TestResult run TestResult TestResult runTest addTest setUp tearDown TestMyClass runTest setUp tearDown ucus lt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 364 395 Anwendungsrahmenwerke Frameworks TInstantiation Tool Classes Data Code Classes Cole Framework White box framework Black box framework Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 365 395 Schwierigkeiten bei Produktlinien nderung der Organis
9. Aufgaben o unterst tzt Evaluationsleiter die Prozessschritte richtig auszuf hren Eigenschaften o erfahrener Anwender der Methode o diskreter Ratgeber Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 274 395 Rollen im ATAM Evaluations Team Fragesteller Aufgaben o wirft Aspekte auf an die die Stakeholders nicht gedacht haben Eigenschaften o hat fundiertes Architekturwissen o hat Einsicht in die Belange der Stakeholders o hat Erfahrung mit Systemen in hnlichen Dom nen o ohne Angst auch umstrittene Belange aufzuwerfen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 275 395 Resultate von ATAM Prim re Resultate o pr zise Beschreibung der Architektur o Artikulation der Gesch ftsziele o Qualit tsanforderungen in Form von Szenarien o Verbindung von Entwurfsentscheidungen und Qualit tsanforderungen Liste von Einfl ssen Sensitivity Points und Kompromissen Tradeoff Points Liste von Risiken Risks und Nichtrisiken Nonrisks Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 276 395 Einfl sse Kompromisse Definition Sensitivity Point Entwurfsentscheidung mit merklichem Einfluss auf ein Qualit tsattribut Bsp Backup Datenbank soll verwendet werden positiver Einfluss auf Zuverl ssigkeit Definition Tradeoff Point Sensitivity Point mit merklichem Einfluss auf mehrere Qualit tsatt
10. Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 369 395 Experimente in der Softwaretechnik Experimentation in software engineering is necessary but difficult Common wisdom intuition speculation and proofs of concept are not reliable sources of credible knowledge V R Basili 1999 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 370 395 Motivation o Wir wollen genau wissen ob und unter welchen Randbedingungen eine Methode funktioniert Forschung o beweist durch logische Schl sse o oder aber beobachtet experimentiert und misst Messung ist sorgf ltige Beobachtung mit gr tm glicher Pr zision Zuverl ssigkeit und Objektivit t Messungen identifizieren neue Ph nomene testen Hypothesen oder leiten uns bei der Anwendung von Modellen und Methoden Empirische Untersuchungen Methoden die von Menschen angewandt werden k nnen nur empirisch untersucht werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 371 395 Wissenserwerb in Wissenschaft und Engineering akzeptieren ndern ndern 7 Theorie l Operationale Version l ndern Hypothese l nd rn Experiment passt nicht passt Rainer Koschke Uni Bremen Softwaretechnik Untersuchungsmethoden Umfragen und Erhebungen Engineering Ziel Methode Prozess
11. Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 266 395 267 395 Rollen im ATAM Evaluations Team Gruppenleiter Aufgaben o bereitet Evaluation vor o h lt Kontakt zum Kunden o formiert Evaluations Team o stellt sicher dass Endbericht ausgeliefert wird Eigenschaften o Organisationsgabe o Managementf higkeiten o gute Interaktion mit Kunden o zuverl ssig in Zeitpl nen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 268 395 Rollen im ATAM Evaluations Team Evaluationsleiterin Aufgaben o leitet Evaluation o unterst tzt Auswahl der Szenarien o organisiert Szenarioauswahl und priorisierung o unterst tzt Evaluation Eigenschaften o erfahren in Architektur o kann pr sentieren o kann moderieren Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 269 395 Rollen im ATAM Evaluations Team Szenario Schreiber Aufgaben o h lt Szenarien fest w hrend der Auswahl Flipchart 0 A o h lt Terminologie fest o besteht auf klarer Formulierung LN Eigenschaften er Sy 5 o besteht darauf die Dinge auf den Punkt zu bringen o kann die Essenz einer Diskussion aufnehmen und sie pr gnant zusammenfassen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 270 395 Rollen im ATAM Evaluations Team Protokollant Aufgaben o protokolliert initia
12. Softwaretechnik Prof Dr Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universit t Bremen Sommersemester 2006 berblick Vorbemerkungen Software Metriken Kosten und Aufwandssch tzung Entwicklungsprozesse Komponentenbasierte Entwicklung Software Architektur Entwurfsmuster berblick II Software Produktlinien Empirische Softwaretechnik Vorbemerkungen Vorbemerkungen Themen der Vorlesung bersicht bungen und Ressourcen Scheinbedingungen Beispielsystem Literatur oo O Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 4 395 bersicht Metriken Entwicklungsprozesse SESAM Schulung Kosten und Aufwandssch tzung Komponentenbasierte Entwicklung Entwurfsmuster Software Architektur Software Produktlinien Rainer Koschke Uni Bremen SESAM Softwaretechnik Sommersemester 2006 5 395 File Options Model Protocol H j SESAM 2 rs Ba 1 Cafeteria v Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 6 395 bungen und Ressourcen Dozent o http www informatik uni bremen de koschke o Sprechstunde nach Vereinbarung Ressourcen o annotierte Folien unter http www informatik uni bremen de st lehredetails php id amp
13. im weiteren Sinn o Anwendungen in einem Betriebssystem o Plugins o Verbunddokumente Office Dokumente mit OLE HTML im engeren Sinn CORBA COM JavaBeans Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 191 395 Eigenschaften erfolgreicher Komponentenmodelle o Infrastruktur mit guter Basisfunktionalit t Komponenten werden von unterschiedlichen Herstellern angeboten und von Kunden eingesetzt Komponenten von verschiedenen Anbietern arbeiten in einer Installation zusammen Komponenten haben eine Bedeutung f r den Klienten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 193 395 Allgemeine Dienste meist durch Komponentenmodelle als Schnittstelle festgelegt Anbieter der Komponentenmodelle bietet auch diese Komponenten an besonders wichtig f r verteilte Systeme Beispiele Verzeichnisdienst Persistenz Nachrichtendienst Transaktionsmanagement Sicherheit Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 194 395 Schnittstellen o erm glichen o Zusammenarbeit zwischen fremden Komponenten o Austauschbarkeit Anbieter und Benutzer o Identifizierung der Abh ngigkeiten o interner Zustand nicht ffentlich alle Zugriffe ber Schnittstelle o Qualit t von h chster Bedeutung eine Komponente kann Serviceprovider f r mehr als eine Schnittstelle sein provides o eine Komponente
14. Plattformkomplexit t F higkeiten des Personals Erfahrung des Personals Zeitplan Infrastruktur EM Effort Multiplier o Korrekturfaktor PM bei viel generiertem Code h here Produktivit t nicht weiter diskutiert hier Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 93 395 Faktoren f r Exponent E o Erfahrung mit Anwendungsbereich PREC Erfahrung mit vorliegendem Projekttyp 5 keine Erfahrung 0 vollst ndige Vertrautheit o Entwicklungsflexibilit t FLEX Grad der Flexibilit t im Entwicklungsprozess 5 Prozess vom Kunden fest vorgegeben 0 Kunde legt nur Ziele fest o Risikomanagement RESL Umfang der durchgef hrten Risikoanalyse 5 keine Risikoanalyse 0 vollst ndige und genaue Risikoanalyse Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 94 395 Faktoren f r Exponent E Il o Teamzusammenhalt TEAM Vertrautheit und Eingespieltheit des Entwicklungsteams 5 schwierige Interaktionen 0 integriertes und effektives Team ohne Kommunikationsprobleme Prozessreife EPML Reife des Entwicklungsprozesses z B CMM beabsichtigt gewichteter Anteil der mit ja beantworteten Fragen im CMM Fragebogen pragmatisch CMM Level 5 niedrigster CMM Level 0 h chster CMM Level Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 95 395 Effort Multiplier RCPX Product Reliability and Complexity RELY Required rel
15. Progress Build Build Coded Final Quality Test Waterfall 7 Integration Begins py Build Ve sy 100 ES 90 80 70 60 50 40 30 20 Build Build 10 V Vv Waterfall Late Design Breakage gt Iterative Development 5 10 15 20 25 30 35 40 45 50 Time Months Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 132 395 Spiralmodell von Boehm 1988 Mehrere Iterationen der folgenden Schritte Bestimmung der Ziele und Produkte des Durchlaufs Ber cksichtigung von Alternativen z B Entwurfsvarianten und Restriktionen z B Zeitplan Bewertung der Risiken f r alle Alternativen Entwicklung von L sungsstrategien zur Beseitigung der Ursachen Arbeitsschritte durchf hren um Produkt zu erstellen Review der Ergebnisse und Planung der n chsten Iteration Rainer Koschke Uni Bremen Softwaretechnik Softwaretechnik Entwicklungsprozesse almed ES spiralmedell von Boehm 1988 2006 07 19 Sommersemester 2006 133 395 Spiralmodell von Boehm 1988 n Entwicklung von L igung der Ursachen Arbeitsschritte durchf hren um Produkt zu erstellen Review der Ergebnisse und Planung der n chsten Iteration Das Spiralmodell kann fiir sehr groBe und komplexe Projekte verwendet werden da es der Komplexitat durch das risikogesteuerte Vorgehen Rechnung tr gt Die Anzahl der Durchl ufe ergibt sich erst w hrend des Projekts und wird durch die auft
16. Prozessen Methoden und Wiederverwendung SITE Telefon prinzipiell vorhanden und Post individuelles Telefon und Fax E Mail niedrige Bandbreite elektronische Kommunikation mit gro er Bandbreite 8 elektronische Kommunikation mit groBer Bandbreite gelegentliche Videokonferenzen Interaktive Multimedia Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 101 395 Effort Multiplier SCED Schedule Es besteht Notwendigkeit den Zeitplan zu straffen bzw es wird mehr Zeit als notwendig einger umt SCED Verk rzung bzw Verl ngerung des nominalen Zeitplans 75 85 100 130 160 EMscep 143 114 1 00 1 00 1 00 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 102 395 Effort Multiplier SCED Schedule Softwaretechnik Kosten und Aufwandssch tzung Es besteht Notwendigkeit den Zeitplan zu straffen bzw es wird mehr Zeit COCOMO als notwendig einger umt SCED Verk rzung bzw Verl ngerung des nominalen Zeitplans ar Multiplier SCED Schedule ee es 2006 07 19 This rating measures the schedule constraint imposed on the project team developing the software The ratings are defined in terms of the percentage of schedule stretch out or acceleration with respect to a nominal schedule for a project requiring a given amount of effort Accelerated schedules tend to produce more effort in the later phases of development because more issues are left to be determined due to la
17. Schwierigkeiten o Wiederholungsfragen Q Q Q Q Q Q Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 336 395 Lernziele Software Produktlinien o Definition und Bedeutung o Vor und Nachteile o Technische Aspekte Organisatorische Aspekte N B Basiert auf Folien von Linda Northrop http www sei cmu edu productlines presentations html Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 337 395 Software Wiederverwendung 1960 Unterprogramme 1970 Module 1980 Objekte 1990 Komponenten opportunistische Wiederverwendung im Kleinen hat nicht den erwarteten Erfolg gebracht Software Produktlinien geplante Wiederverwendung auf allen Ebene f r Familien hnlicher Systeme Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 338 395 Wiederverwendbares Komponenten o Software Dokumentation o Architektur o Tests unter anderem Integrations Leistungs und Komponententests o Anforderungsspezifikation o Entwicklungsprozess Methoden und Werkzeuge o Budget Zeit und Arbeitspl ne o Handb cher o Entwickler Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 339 395 Erfolgsgeschichten CelsiusTech Familie von 55 Schiffssystemen o Integrationstest of 1 1 5 Millionen SLOC ben tigt 1 2 Leute Rehosting auf neue Plattform Betriebssystem ben tigt 3 Monate Kosten und Zeitplan werden eingehal
18. Softwaretechnik Sommersemester 2006 233 395 Software Architektur und Qualit tsattribute o Architektur ist kritisch f r die Realisierung vieler Qualit ten Qualit ten m ssen durch Konstruktion eingebaut werden Qualit ten k nnen und sollen auf Architekturebene evaluiert werden o Architektur alleine gen gt nicht zur Erreichung der Qualit ten Architektur bildet nur die Grundlage Implementierungsdetails sind ma gebend o Qualit tsattribute k nnen im Konflikt zueinander stehen Architektur ist ein Kompromiss o Qualit tsattribute m ssen objektiv und operational beschrieben sein konkrete messbare Szenarien Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 234 395 Software Architektur Qualit t von Software Architekturen Definition Qualit tsattributsszenario ist eine operationale Anforderung hinsichtlich eines Qualit tsattributs Bass u a 2003 o wenn ein bestimmtes Ereignis eintritt Stimulus o in einer bestimmten Situation Umgebung o das von einem bestimmten Ausl ser kommt Stimulusquelle und auf einen bestimmten Gegenstand einwirkt Artefakt dann soll eine geforderte Reaktion o in einer messbaren Art eintreten Reaktionsmessung O Stimulus Artefakt Reaktion unerwartete Prozess Operator Nachricht informiert Stimulusquelle Umgebung Betrieb fort Reaktionsmessung systemextern Normaler gesetz
19. t auf Anhieb erfolgreich abgeschlossen werden kann Allerdings werden z B die Anforderungen oft auch noch in sp ten Phasen des Projekts ge ndert bzw erst dann berhaupt erst richtig verstanden Dann m ssen fr he Aktivit ten wiederholt werden Striktes Wasserfallmodell Royce 1970 Eigenschaften dieses Modells o dokumenten getrieben jede Aktivit t erzeugt Dokument o streng sequenzielle Aktivit ten klar organisierter Ablauf relativ einfache F hrung hohe Qualit t der Dokumentation Entwicklung bildet langen Tunnel 90 fertig Syndrom Spezifikationsm ngel lassen sich kaum fr hzeitig erkennen Entwicklung beim Kunden wird ignoriert Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 117 395 V Modell von Boehm 1979 Zeit Anwendung amp Support Konzept Konzeptvalidierung Projektplan amp Installation amp Anforderungen g Betriebstest Anforderungen Validierung Baseline SS ett See eee e E Verifikation System Akzeptanztest entwurf Modul Integration amp entwurf Systemtest Cod Klassen ai test Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 118 395 Softwa retech n i k V Modell von Boehm 1979 Entwicklungsprozesse oe er en a I Pe nett Installation amp 5o L_v Modell ee l see N e 2 Gg S Modell von Boehm 1979 _ oO Integration amp N OO Das V Modell ist kein eigenstandiges Prozes
20. 395 Inkrementelles Modell von Basili und Turner 1975 oe un ee ay Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 129 395 Inkrementelles Modell von Basili und Turner 1975 Softwaretechnik Entwicklungsprozesse T I maven Emit ng Test Gos inkrement 5 Inkrementelle Entwicklung ee ug od K eats Enw Coding Ten Ausletonmo 5 Inkrementelles Modell von Basili und Turner 1975 Here N Das Wasserfallmodell geht davon aus dass alle Anforderungen zu Beginn erfasst werden k nnen und diese w hrend des Projekts stabil bleiben Dies ist in der Praxis selten der Fall Im Laufe des Projekts gewinnen die Entwickler ein besseres Verst ndnis der Anwendungsdom ne und entdecken Irrt mer in ihren urspr nglichen oft nur impliziten Annahmen hnlich wird auch der Kunde sich oft erst im Laufe des Projekts im Klaren was er eigentlich erwarten kann und will Auch die Rahmenbedingungen unter denen das Projekt startete k nnen sich ndern z B Gesetze oder Normen Die Anforderungen sind also selten stabil Damit wird das Wasserfallmodell in seiner strikten Auslegung fragw rdig Allerdings hat auch schon der Erfinder des Wasserfallmodells Royce empfohlen das System zweimal zu entwickeln Das erste Mal um berhaupt erst Anforderungen und m gliche L sungen auszuloten Das zweite Mal um ein ad quates und qu
21. Aufwandsabsch tzung o Prognose f r Wartungskosten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 46 395 Probleme o Datenerfassung sehr aufwendig zun chst wenig Nutzen o Datenerfassung nicht konsistent o Teilweise Messungen schwierig durchf hrbar o Zweck der Messungen muss klar sein o Integration der Datenerfassung in den normalen Arbeitsprozess o Metriken m ssen wohldefiniert und validiert sein o Beziehungen zwischen Metriken m ssen definiert sein o Gefahr der Fehlinterpretation Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 47 395 Zielorientiertes Messen GQM Goal Question Metric Basili und Weiss 1984 Nicht das messen was einfach zu bekommen ist sondern das was ben tigt wird Ziele erfassen zur Pr fung der Zielerreichung notwendige Fragen ableiten was muss gemessen werden um diese Fragen zu beantworten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 48 395 Zielorientiertes Messen Anteil der Programmierer die Aufwand Fehler Standard benutzen Code Gr e Erfahrung der Programmierer mit Standard Sprache Umgebung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 49 395 Beispiel Prozess Ziel Frage Metrik Maximiere Wie viele Probleme Kundenzufrie treten beim Kunden e Fehler FR und denheit auf nderungsw nsche AR Wie lange dauert Pro blembehebung Wo
22. Koschke Uni Bremen Softwaretechnik Sommersemester 2006 126 395 Bewusstseinsebenen Softwaretechnik Entwicklungsprozesse bemsstes Wissen 2 30 im KI Inkrementelle Entwicklung Zr im Moment nicht darbietet aber nd ist und potenziell aufgerufen werden ep ewussiseinschenen 2006 07 19 e bewusst will mit meinem Handy telefonieren e unbewusst Tastatur und Display sollen auf derselben Seite meines Handys sein e unterbewusst ich will SMS verschicken k nnen Entwicklungsprozesse Inkrementelle Entwicklung Basisfaktoren o Minimalanforderungen Kano Modell Mangel f hrt zu massiver i j Begeisternde Uhsuitiedenheit Kunde sehr zufrieden g begeistert Faktoren mehr als Zufriedenheit ist nicht m glich Leistungs Leistungsfaktoren faktoren bewusst verlangte Sonderausstattung Eidi 4 rf llungsgra bei Erf llung Kundenzufriedenheit Erwartungen sonst Unzufriedenheit nicht erf llt Basisfaktoren Begeisternde Faktoren Kunde unzufrieden unbewusste W nsche entt uscht n tzliche angenehme berraschungen steigern Zufriedenheit berproportional Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 127 395 Kosten f r nderungen Kosten f r nderung 60 100 x 1 5 6x 1x Zeit Definition Entwicklung nach Auslieferung Pressman 1997 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 128
23. Kostenschatzung o Function Points Object Points COCOMO Wiederholungsfragen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 53 395 Kostensch tzung Wichtige Fragen vor einer Software Entwicklung Wie hoch wird der Aufwand sein o Wie lange wird die Entwicklung dauern o Wie viele Leute werden ben tigt Fr hzeitige Beantwortung wichtig f r o Kalkulation und Angebot Personalplanung o Entscheidung make or buy o Nachkalkulation Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 55 395 Kostensch tzung Ans tze o Expertensch tzung o Berechnung aus fr h bekannten Gr en algorithmische Sch tzung o COCOMO Anzahl Codezeilen o Function Points Ein und Ausgaben o Analogiemethode o Top Down Sch tzung Ableitung aus globalen Gr en o z B Aufwand steht fest daraus Umfang ableiten o Bottom Up Sch tzung Dekomposition und Sch tzung der einzelnen Komponenten sowie deren Integrationsaufwand Daumen Regeln o Gesamtaufwand 1 DLOC h Delivered Line of Code o Gesamtkosten 50 Euro DLOC o Pricing to Win o Parkinsons Gesetz Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 56 395 Kostensch tzung Softwaretechnik whe 2 Expertensch tzun Kosten und Aufwandssch tzu ng ne ta GaN Sven rasan N Dee ar le Kostenschatzung es E ay ree eee ore 2006 07 19 z B Aufwand steht fest daraus Umfang ableiten 2 Botto
24. Level 5 Optimizing Anderungsmanagement f r Technologie und Prozesse Feedback von Projekten zum Prozess st ndige Verbesserung Key Process Areas o Defektvermeidung Analyse von Fehler Problemursachen Vermeiden erneuten Auftretens o Verwaltung von Technologie nderung neue Technologien bewerten evtl einf hren o Verwaltung von Prozess nderung kontinuierliche Verbesserung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 162 395 Capability Maturity Model 70 60 P 50 Initial 40 E Repeatable 30 E Defined 20 re E Optimizing 10 0 1995 1997 1999 2001 SEI Assessments Quelle SEI Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 163 395 Probleme mit CMM o Management zu teuer Wenig verbreitet ca 10 15 Nur langsame Verbesserung ca 2 Jahre Level Neue Technologien nicht ber cksichtigt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 164 395 Capability Maturity Model Management mas Optimizing a Quelle Parker 1995 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 165 395 Capability Maturity Model Integration CMMI o Viele Maturity Model Varianten CMMI Integration SEI 2000 o Angepasst an iterative Entwicklung o Generische
25. Objektivit t unabh ngig vom Messenden Validit t misst was sie vorgibt zu messen Zuverl ssigkeit Wiederholung liefert gleiche Ergebnisse o N tzlichkeit hat praktische Bedeutung o Normiertheit es gibt eine Skala f r die Messergebnisse Vergleichbarkeit mit anderen Ma en vergleichbar konomie mit vertretbaren Kosten messbar Balzert 1997 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 32 395 G tekriterien f r Metriken Softwaretechnik Software Metriken N G tekriterien f r Metriken pean an it a G tekriterien f r Metriken or o konomie mit vertretbaren Kosten messbar Balzert 1997 2006 07 19 G te entspr Qualit t Objekt kein subjektiver Einfluss durch Messenden m glich Valid misst wirklich das was sie vorgibt zu messen Zuverl Wiederholung liefert gleiche Ergebnisse N tzl hat praktische Bedeutung Norm es gibt eine Skala f r die Messergebnisse Vergl mit anderen Ma en vergleichbar kon mit vertretbaren Kosten messbar Vorgehensweise Definition eines Ma es o Zielbestimmung o Modellbildung o Skalentypbestimmung o Ma definition Validierung des MaBes o Interne Validierung o Externe Validierung Anwendung des Ma es e Konkretes Modell bilden o Messung o Interpretation o Schlussfolgerung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 33 395 Validierung von Ma
26. Produktmetriken Anwendungen o Probleme o Goal Question Metric Ansatz o Wiederholungsfragen O 0 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 15 395 16 395 Lernziele o Verstehen was eine Software Metrik ist o die Einsatzm glichkeiten von Metriken kennen o Metriken beurteilen und ausw hlen k nnen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 17 395 Literatur SECOND EDITION A Rigorous amp Practical Approach REVISED PRINTING Fenton und Pfleeger 1998 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 18 395 Bedeutung des Messens To measure is to know Clerk Maxwell 1831 1879 A science is as mature as its measurement tools Louis Pasteur 1822 1895 Miss alles was sich messen l sst und mach alles messbar was sich nicht messen l sst Galileo Galilei 1564 1642 Messen k nnen Sie vieles aber das Angemessene erkennen k nnen Sie nicht Hans Gadamer Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 19 395 Bedeutung des Messens Softwaretechnik Softwa re M et ri ke n To measure is to know Clerk Maxwell 1831 1879 A science is as mature as its measurement tools Louis Pasteur 1822 1895 Messen und MaBe Miss alles was sich messen l sst und mach alles messbar was sich nicht sen l sst Galileo Galilei 1564 1642 Bedeutung de
27. Richard JOHNSON Ralph VLISSIDES John Desig Patterns Elements of Reusable Object Oriented Software Addison Wesley 2003 2 Garlan u a 1995 GARLAN D ALLEN R OCKERBLOOM J Architectural Mismatch Why Reuse is So Hard In EEE Software 12 1995 November Nr 6 S 17 26 B Gornik 2001 GORNIK David IBM Rational Unified Process Best Practices for Software Development Teams IBM Rational Software 2001 TPO26B Rev 11 01 White Paper 4 Halstead 1977 HALSTEAD Maurice H Elements of Software Science In Operating and Programming Systems Series 7 1977 5 Hofmeister u a 2000 HOFMEISTER Christine NORD Robert SONI Dilip Applied Software Architecture Addison Wesley 2000 Object Technology Series 6 Humphrey 1995 HUMPHREY Watts S A Discipline For Software Engineering Addison Wesley 1995 SEI series in software engineering Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 392 395 Empirische Softwaretechnik Wiederholungsfragen 7 IEEE P1471 2002 IEEE Recommended Practice for Architectural Description of Software intensive Systems Std 1471 2000 ISBN 0 7381 2518 0 IEEE New York NY USA 2002 8 Jones 1995 JONES Capers Backfiring Converting Lines of Code to Function Points In EEE Computer 28 1995 November Nr 11 S 87 88 9 Jones 1996 JONES Capers Software Estimating Rules of Thumb In IEEE Computer 29 1996 March Nr 3 S 116 118 0 Kauffman und Kumar 199
28. Striktes Wasserfallmodell nach Royce 1970 System analyse System spezifikation Ist Zustand gt System entwurf Anforderungen SW Architektur Modulspez und entwurf Modul A spezifikation Codierung Modultest Programmteile Integration u isoliert getestet Systemtest Programm Einsatz u Zeit Wartung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 116 395 Striktes Wasserfallmodell nach Royce 1970 Softwaretechnik ae Entwicklungsprozesse arh Wasserfallmodell u I SW Architektur L Moduispez L_Striktes Wasserfallmodell nach Royce 1970 ser oO Bart ger N Programm Einsatz u Zeit Wartung Hier sehen wir als Beispiel das strikte Wasserfallmodell Es enth lt alle Aktivit ten in streng sequenzieller Folge Dieses Modell eignet sich wenn die Arbeitsschritte deutlich voneinander getrennt werden k nnen Alle Risiken m ssen vor Projektbeginn ausgeschlossen werden k nnen Es ist geeignet wenn die Mitarbeiteranzahl klein ist da alle Mitarbeiter gleichzeitig an einem Arbeitsschritt arbeiten k nnen Dieses Modell ist f r die allermeisten Aufgabenstellung jedoch unrealistisch Es setzt voraus dass jede Aktivit
29. Unified Process RUP als Konkretisierung des Unified Process der Firma Rational ist ein weiteres inkrementelles Modell Der Prozess insgesamt gliedert sich in vier Phasen mit einer unterschiedlichen Anzahl von Iterationen Das Produkt jeder Phase unterscheidet sich von den Produkten anderer Phasen Die Konzeptionsphase Inception erarbeitet die Anforderungen Die Elaborationsphase Elaboration erstellt einen Entwurf Die Konstruktionsphase Construction erstellt das implementierte System Die Ubergabephase Transition f hrt das System beim Kunden ein Jede Iteration gliedert sich in die Aktivitaten Geschaftsmodellierung Anforderungsanalyse Entwurf Implementierung Test und Auslieferung Jede Iteration wird durch ein formales Review abgeschlossen Die Auspr gung der einzelnen Aktivit ten ist phasenabh ngig In der Konzeptphase z B dient eine Implementierung lediglich einem Konzeptbeweis Machbarkeit kritischer Anforderungen oder einer Demonstration ein Benutzerschnittstellenprototyp Es gen gt hierf r eine weniger aufw ndige prototypische Implementierung der Prototyp sollte anschlie end weggeworfen werden Der Aufwand jeder Aktivit t variiert also in den Phasen Dies wird durch die Kurven im Schaubild veranschaulicht Die Gesch ftsmodellierung beispielsweise erzeugt in der Konzeptionsphase naturgem einen hohen Aufwand hat in der bergabephase aber keine Bedeutung mehr Alle Fl chen gemeinsam ergeben den Gesamtaufwan
30. Ziele hinzugef gt o Zus tzliche KPAs o Level 2 Measurement and Analysis o Level 3 Software Product Engineering verfeinert Risk Management Decision Analysis and Resolution o Level 4 5 nur Restrukturierungen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 166 395 Pers nlicher Softwareprozess PSP o Watts S Humphrey 1995 SEI Anwendung von CMM auf einen Entwickler Schwerpunkte Planung Qualit t Vorteile Schneller umsetzbar Konkrete Techniken angebbar Verbesserungen sofort wahrnehmbar h here Motivation oo Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 167 395 PSP Evolution Cyclic Personal Process a Personal Quality m Managmt Personal o Planning N Process Baseline Personal Process Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 168 395 PSPO Baseline Personal Process PSPO Bisherige Vorgehensweise plus o Messung o Zeit pro Phase o gefundene gemachte Fehler pro Phase o Zeit f r Fehlerbehebung o Formulare Projektplan Zeiten Fehler PSPO 1 plus o Codierrichtlinien Messung der LOC Ver nderungen o Formular Prozessverbesserung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 169 395 PSP1 Personal Planning Process PSP1 PSPO 1 plus o Gr ensch tzung mit PROBE PROxy Based Estimating o Sch tzung basiert auf
31. b a Va b A d a c lt d a b d b c Va b c A Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 29 395 Skalenhierarchie Rationalskala 4 Rationalskala dazu Ma einheit Nullpunkt Transformationen M aM a gt 0 Operationen Statistiken geom Mittel Korrelation Beispiel L nge L Meter a L Meilen 1609 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 30 395 Skalenhierarchie Rationalskala Softwaretechnik Lmeter Lmeilen 1609 2 Software Metriken I 5 L Skalen en I 5 Statistiken geom Mittel Korrelation 9 Skalenhierarchie Rationalskala een N Das geometrische Mittel zwischen zwei Zahlenwerten ist vf1 f2 Das arithmetische Mittel zwischen zwei Zahlwerten ist f1 f2 2 Skalenhierarchie Absolutskala 5 Absolutskala Metrik steht f r sich selbst kann nicht anders ausgedr ckt werden Q Transformationen nur die Identit t M M o Operationen absoluter Vergleich d h o es existiert ein nat rlicher Nullpunkt und Ma einheit ist nat rlich gegeben d h im weitesten Sinne St ck o Beispiele Z hler Anzahl Personen in einem Projekt Wahrscheinlichkeit eines Fehlers LOC f r Anzahl Codezeilen nicht LOC f r Programmlange Q e Q Q Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 31 395 G tekriterien f r Metriken
32. expressions you filled in Note that the search is case insensitive and that the entries to retrieve must have all specified attributes author a lite F keywords abstract E Start searching Clear all inputs koschke informatik uni stuttgart de Feedback Copyright 1997 University of Stuttgart Germany Revision 1 6 Last modified Mon Jun 22 16 26 16 MET DST 1998 mer en Done Sas ee A Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 Literaturreferenzen Allgemeine Literatur zur Softwaretechnik Sommerville 2004 Pressman 1997 Software Metriken Fenton und Pfleeger 1998 Aufwand und Kostenschatzung Boehm u a 2000 Software Entwicklungsprozesse Beck 2000 Kruchten 1998 auch Sommerville 2004 Pressman 1997 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 13 395 14 395 Literaturreferenzen II Komponentenbasierte Entwicklung W Szyperski u a 2002 Software Architektur Bass u a 2003 Hofmeister u a 2000 Buschmann u a 1996 Entwurfsmuster Gamma u a 2003 Software Produktlinien Clements und Northrop 2001 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 Software Metriken Software Metriken Messen und Ma e o Skalen o G tekriterien f r Metriken Vorgehensweise Klassifikation von Softwaremetriken Prozessmetriken Ressourcenmetriken
33. grober Plan f r die Iterationen RUP Elaborationsphase Elaboration Fortsetzung gt ein vorl ufiges Benutzerhandbuch optional 2006 07 19 Die Erstellung des Benutzerhandbuchs kann bereits fr hzeitig beginnen Es ist konkreter als die Anforderungsspezifikation und abstrakter als die Implementierung Somit kann es als Br cke von den Anforderungen zur Implementierung benutzt werden Das vorl ufige Handbuch dient sowohl als Spezifikation f r die Implementierung und den Test als auch f r die intensivere Auseinandersetzung mit der Benutzerf hrung Beispiel Was orthogonal und einfach zu beschreiben ist kann oft auch orthogonal und einfach implementiert werden berlegungen zur Benutzerf hrung sollten fr hzeitig gemacht werden weil nderungen gr ere Restrukturierungen nach sich ziehen k nnen RUP Konstruktionsphase Construction Ziel Fertigstellung Integration und Test aller Komponenten auslieferbares Produkt o Software Produkt integriert in die entsprechende Plattform o Benutzerhandbuch Dokumentation des gegenw rtigen Releases Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 142 395 2006 07 19 RUP Konstruktionsphase Construction Softwaretechnik Entwicklungsprozesse Ziel Fertigstellung Integration und Test aller Komponenten auslieferbares Produkt Rational Unified Process a o Benutzerhandbuch RUP Konstruktionsphase Construction SRS EECCA pole lel In d
34. kann den Service anderer Schnittstellen ben tigen requires o sp te Integration sp te Bindung Indirektion o direkte prozedural und indirekte Objekt Schnittstellen o beschrieben durch Meta Information zur Laufzeit Interface Description Language IDL oder direkt Java Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 196 395 Beispiel CORBA IDL module Bank typedef long pin_t enum KontoFehlerTyp UngenuegendeKontodeckung E exception KontoException KontoFehlerTyp typ string beschreibung interface Konto readonly attribute string name readonly attribute long kontoStand boolean isValidPin in pin_t pin void abheben in long betrag raises KontoException void einzahlen in long betrag F r Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 197 395 Vertrag o Schnittstelle als Vertrag zwischen Anbieter und Benutzer des Services o Anbieter o ber Funktionalit t z B als Vor und Nachbedingungen o ber nicht funktionale Anforderungen Service Level Ressourcen z B Standard Template Library f r C o Darstellung o informal als Text o formaler z B durch temporale Logik um Terminierung zuzusichern oder mit OCL o Kunde o Vermeidung von speziellen Eigenschaften einer bestimmten Implementierung d h nur Vertrag benutzen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 198 395 Versionen o Problem
35. kommt ihr zu Was ist eine Architektursicht bzw blickwinkel Erl utern Sie die Kategorien von Blickwinkeln von Clements et al Erl utern Sie die Siemens Blickwinkel Wozu die Trennung in verschiedene Blickwinkel Wer hat Interesse an den jeweiligen Blickwinkeln Erl utern Sie den Begriff Qualit t in Bezug auf Software Architektur Was ist ein Qualit tsattributsszenario und was bezweckt man damit Was ist eine Taktik im Zusammenhang mit Software Architektur Nennen Sie Taktiken f r nderbarkeit und Testbarkeit Geben Sie ein Szenario an f r das Qualit tsattribut Performanz Anderbarkeit Testbarkeit aber auch andere Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 304 395 Wiederholungs und Vertiefungsfragen II o Welche grunds tzlichen Techniken gibt es um Software Architekturen zu evaluieren o Erl utern Sie die Architecture Tradeoff Analysis Method ATAM o Welche Rollen sind bei ATAM vorgesehen o Erl utern Sie die Begriffe Sensitivity und Tradeoff Point Wozu wird der Unterschied gemacht o Wann betrachtet man eine Entwurfsentscheidung als Risiko Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 305 395 Entwurfsmuster Entwurfsmuster o Entwurfsmuster Composite Kategorien von Entwurfsmustern Bestandteile eines Entwurfsmusters Entwurfsmuster Singleton Entwurfsmuster Adapter Entwurfsmuster Command Entwurfsmuster Decorator Wiederholungsfragen O O
36. m glich o schrittweise Entwicklung der Core Assets mit initialer Planung der Produktlinie o entwickle Teile der Core Asset Base einschlie lich Architektur und Komponenten o entwickle ein oder mehrere Produkte o entwickle weitere Core Assets o entwickle weitere Produkte o entwickle Core Asset Base weiter Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 355 395 Bindung Produktlinien o haben Gemeinsamkeiten o und definierte Unterschiede Variabilit ten Produkt wird aus Core Assets zusammengebaut Variabilit ten werden festgelegt Bindungszeitpunkt der Variabilit ten zur bersetzungszeit o zur Bindezeit o zur Laufzeit Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 356 395 Architekturmechanismen f r Variabilit ten Kombination Ersetzung und Auslass von Komponenten auch zur Laufzeit Frontend Middle End Backend C C Java ME i386 Motorola 68000 C ME i386 C ME Motorola 68000 C ME i386 C ME Motorola 68000 Java ME i386 Java ME Motorola 68000 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 357 395 OoOo oo 9 oO A UU NBE RR ww N e O Architekturmechanismen f r Variabilit ten Parametrisierung einschlie lich Makros und Templates generic type My_Type is private with procedure Foo M My_Type procedure Apply procedure Apply is X My_
37. nderungen semantische Koh renz alle Bestandteile eines Moduls tragen zu einem gemeinsamen Zweck bei bei nderung des Zwecks m ssen nur die Elemente des Moduls angepasst werden antizipierte nderungen zuk nftige nderungen sind bereits eingeplant eingebaut verallgemeinerte Module Modul ist allgemeiner als es sein m sste und parametrisiert durch einfache Parameter bis hin zur Auspr gung des Moduls als Interpreter Begrenzung m glicher Optionen die m glichen Optionen werden eingeschr nkt damit werden beliebige nderungen ausgeschlossen z B kann man bei nderungen des Prozessors einschr nken dass er sich nur innerhalb einer Prozessorfamilie ndern darf abstrakte gemeinsame Dienste hnliche Funktionalit t in verschiedenen Modulen wird herausfaktorisiert und nur einmal implementiert als dienstleistendes Modul Vermeidung des Welleneffekts Geheimnisprinzip Dinge die sich wahrscheinlich ndern werden hinter einer abstrakten Schnittstelle verborgen Erhalt existierender Schnittstellen o mehrere Schnittstellen neu und alt o Adapter o Stumpf wenn Dienst wegf llt Restriktion von Kommunikationspfaden Anzahl der Module mit denen Daten geteilt werden wird reduziert Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 253 395 Verwendung eines Mittelsmanns Verwender V und Dienstleister D o Syntax von o Daten Format von Daten zwischen V und D Verwendung eines Rep
38. o Will the system run in an existing heavily utilized operational environment 1 Does the system require on line data entry 4 o Does the online data entry require the input transaction to be built over multiple screens or operations 3 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 80 395 Konkrete Fragen Il o Are the master files updated on line 5 o Are the inputs outputs files or inquiries complex 1 o Is the internal processing complex 1 o Is the code designed to be reusable 1 Are conversion and installation included in the design 2 o Is the system designed for multiple installations in different organizations 2 o Is the application designed to facilitate change and ease of use by the user 3 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 81 395 Softwaretechnik Kosten und Aufwandssch tzung Ls qetion Beine Konkrete Fragen 2006 07 19 Die Zahlen beziehen sich auf unser laufendes Beispiel Konkrete Fragen II igned for multiple installations in different designed to facilitate change and ease of use by the FP Gewichtete Function Points o TDI Total Degree of Influence o VAF Value Adjustment Factor Summe der Bewertungen TDI 100 0 65 Gesamteinflussfaktor 65 135 o AFP Adjusted Function Points UFP VAF Beispiel TDI 29 o VAF 29 100 0 65 0 94 o AFP 23 0 94 21 62 Rainer Koschke Uni Bremen
39. object points Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 87 395 COCOMO COCOMO Constructive Cost Model Boehm 1981 o Basiert auf Auswertung sehr vieler Projekte o Eingaben Projektkomplexit t 3 Stufen Systemgr e o Ausgaben Realisierungsaufwand Entwicklungszeit o Drei Genauigkeitsstufen steigender Aufwand Basic Aufwand a KLOC Dauer c Aufwand o Intermediate Dekomposition 15 Einflussfaktoren Kategorien Produkt Projekt Computer Personal o Advanced Einflussfaktoren pro Phase Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 88 395 COCOMO a b konstant abh ngig von Projektkomplexitat Organic PM 2 4 KDSI M o wohl verstandene Anwendungsdom ne mit kleinen Teams Semidetached PM 3 0 KDSI M o komplexere Projekte bei dem Teams nur begrenzte Erfahrungen haben Embedded PM 3 6 KDSI M o Projekte eingebettet in komplexe Systeme aus Hardware Software Vorschriften und betriebliche Abl ufe KDSI Kilo Delivered Source Instructions M ergibt sich aus Einflussfaktoren Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 89 395 COCOMO Damals o Wasserfallprozess o nur Neuentwicklung o Mainframes Heute o Inkrementelle Entwicklung o Wiederverwendung COTS Komponenten o PCs Reengineering Code Generierung COCOMO II Boehm u a 1995 Rainer Koschke Uni Bremen S
40. sie um Sequenzialisierung zu garantieren o Tools mussten aber kooperieren eigener Transaktionsmonitor musste implementiert werden o An oder Abwesenheit bestimmter Komponenten und Konnektoren Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 215 395 Konstruktionsprozess betreffend Annahmen ber Konstruktionsprozess wie Komponenten Konnektoren aus generischen Einheiten erstellt werden sowohl zur bersetzungs als auch zur Laufzeit Beispiele o Datenbank Schema muss festgelegt werden o Event System Menge der Ereignisse und Registration Annahmen ber die Reihenfolge in der Teile erstellt und kombiniert werden o nicht zueinander passende Annahmen ber den Konstruktionsprozess Umwege machten Konstruktionsprozess aufw ndig und kompliziert Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 216 395 Wiederholungs und Vertiefungsfragen o Was ist eine Komponente o Was ist die Idee der komponentenbasierten Entwicklung Welche Ziele verfolgt sie o Diskutieren Sie Vor und Nachteile ma gefertigter Software versus Software von der Stange o Was ist ein Komponentenmodell Was von einem solchen blicherweise festgelegt bzw zur Verf gung gestellt o Was ist eine Schnittstelle und welche Bedeutung kommt diesem Konzept im Kontext komponentenbasierter Entwicklung zu o Wie k nnen vorgefertigte Komponenten angepasst werden Welches Problem tritt be
41. sind Fla schenh lse Rainer Koschke Uni Bremen Beispiel Produkt Softwaretechnik Zuverl ssigkeit Break Fix Verh ltnis Verh ltnis und Dauer offener und geschlossener FR AR Personalnutzung Nutzung anderer Ressourcen Sommersemester 2006 50 395 Ziel Frage Metrik Maximiere Wie gro ist das Sys Verst ndlichkeit tem e Anzahl Funktionen Klassen des Codes Pakete etc Wie komplex ist das System Rainer Koschke Uni Bremen Softwaretechnik Lines of Code pro Funktion Klasse Paket etc McCabe Komplexit t pro Funktion Klasse Paket etc Schachtelungstiefe pro Funktion Kopplung Anzahl Funktionsaufrufe Sommersemester 2006 51 395 Wiederholungs und Vertiefungsfragen Q Was ist ein Ma Was ist eine Metrik Was ist eine Software Metrik Welche Skalen gibt es f r Daten Welche Eigenschaften haben diese Beschreiben Sie das Vorgehen bei der Definition und Einf hrung eines Ma es Was unterscheidet die interne von der externen Validierung Wie lassen sich Software Metriken klassifizieren Nennen Sie Beispiele f r jede Klasse Was ist die Bedeutung von Metriken im Software Entwicklungsprozess Was ist die GQM Methode Erl utern Sie GQM anhand des Zieles X N B Die bungsaufgaben sind weitere Beispiele relevanter Fragen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 52 395 Kosten und Aufwandssch tzung Kosten und Aufwandssch tzung
42. sowohl Schnittstelle als auch Implementierung ndern sich unterschiedliche Versionen nicht vermeidbar o Ziel Entscheidung ob kombatibel oder nicht o zus tzlich noch Unterst tzung f r einen Bereich von Versionen sliding window L sungen L sungen o unver nderliche Schnittstellen o Schnittstellen d rfen sich ndern aber nur nach Regeln z B Parametertyp darf verallgemeinert werden o Ignorieren des Problems abw lzen auf tiefere Schicht o immer neu kompilieren Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 199 395 Beschaffung o Annahme gro er Markt von Komponenten Suche Komponenten und funktionale Anforderungen werden klassifiziert o Qualit tskriterien f r Auswahl o funktionale und nicht funktionale Anforderungen o Schnittstellenbeschreibung o Abh ngigkeiten und Kompatibilit t o Vertrauensw rdigkeit berlebenschance des Anbieters Garantien und Wartungszusicherung o Preis und Zahlungsart Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 201 395 Entstehung von Komponenten o meist aus bestehender Software o Anpassung notwendig um Wiederverwendbarkeit zu erreichen o ist Investition konomisch sinnvoll o Gr e des Einsatzgebiets o bislang angebotene Funktionalit t o potentieller Grad der Wiederverwendung Balance zwischen gro en Komponenten kleinen Komponenten bieten mehr Service an o verst ndlicher o weniger Abh ngi
43. using our forms Supporters This annotated bibliography is supported by Bauhaus Software Technologies a company providing services and tools to support reengineering maintenance and evolution of existing system Please visit the home page of our supporters BAUHAUS SOFTWARE TECHNOLOGIES Sites The reengineering bibliography is available at two sites Choose the one closest to you University of Stuttgart Germany e Georgia Institute of Technology Atlanta GA USA Contents e Introduction Leaflet Postscript Print and fold it and it will be a valuable guide in searching and adding references News Adding your references e Searching for references o via a taxonomy of reengineering related terms o via a simple search form that allows retrievals by specifying author title keywords abstract year etc The bibliography as a BibTeX database via FTP e Taxanamv mer en Kein Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 11 395 Online Bibliographie Taxonomiesuche Bibliographic References Taxonomy Mozilla Eile Edit View Go Bookmarks Tools Window Help MENS amp http Mwww iste uni stuttgart de ps reengineering taxonomy html iy Se Ns Home Bookmarks The Mozilla Org S Latest Builds Home Next Terminology Next Description Taxonomy Select elements of the following taxonomy to retrieve their references or one
44. z B Entwurf Codierung Test Zweck der Studie z B Vergleich Analyse Voraussage Fokus der Studie z B Effektivit t Effizienz Standpunkt z B Praktiker Forscher Kontext z B Erfahrung der Teilnehmer verwendete Elemente Umgebung Kontext unabh ngige Variablen Fokus abh ngige Variablen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 378 395 Bestandteile eines Experiments 2 Formulierung einer testbaren Hypothese Methode M ist geeignet f r Aufgabe A versus Methode M ben tigt weniger Zeit als Methode N um Aufgabe A zu erledigen Null Hypothese Negation der Hypothese Es gibt keinen Unterschied zwischen M und N um Aufgabe A zu erledigen Wenn Null Hypothese widerlegt ist wird Hypothese best tigt mit einem gewissen Grad an Konfidenz Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 379 395 Bestandteile eines Experiments 3 Aufbau des Experiments o Korrelation versus Kausalit t o Validit t o interne es werden tats chlich nur die Beziehungen zwischen unabh ngigen und abh ngigen Variablen gemessen z B Lerneffekte zeitliche Aspekte Auswahl der Teilnehmer externe bertragbarkeit z B Studenten versus Praktiker o Identifikation aller unabh ngiger und abh ngiger Variablen o Randomisierung viele B cher zu Standard Designs abh ngig von den Rahmenbedingungen Rainer Koschke Uni Bremen Softwar
45. 3 KAUFFMAN R KUMAR R Modeling Estimation Expertise in Object Based ICASE Environments Stern School of Business New York University Januar 1993 Report 1 Kemerer 1987 KEMERER Chris F An Empirical Validation of Software Cost Estimation Models In Comm ACM 30 1987 May Nr 5 2 Kemerer und Porter 1992 KEMERER Chris F PORTER Benjamin S Improving the Reliability of Function Point Measurement An Empirical Study In TSE 18 1992 Nov Nr 11 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 393 395 Empirische Softwaretechnik Wiederholungsfragen B Kruchten 1998 KRUCHTEN Phillipe The Rational Unified Process An Introduction Reading Mass Addison Wesley 1998 4 Lienert 1973 LIENERT G A Verteilungsfreie Methoden in der Biostatistik Meisenheim am Glan Germany Verlag Anton Hain 1973 wird leider nicht mehr aufgelegt 5 McCabe 1976 McCaBE T A Software Complexity Measure In IEEE Transactions on Software Engineering 2 1976 Nr 4 S 308 320 6 Mills u a 1987 _ Mi trs H D DYER M LINGER R Cleanroom Software Engineering In IEEE Software 4 1987 September Nr 5 S 19 25 7 Parker 1995 PARKER Burton G Data Management Maturity Model July 1995 8 Pressman 1997 PRESSMAN Roger Software Engineering A Practioner s Approach Vierte Ausgabe McGraw Hill 1997 9 Royce 1970 Royce W Managing the Development of Large Software Systems In Proceedi
46. 5 Ressourcen Metriken extern intern extern Komplexit t o McCabe Cyclomatic Complexity o Kontrollflussgraph o Datenfluss o OO Metriken Softwaretechnik Sommersemester 2006 39 395 Produktmetriken extern Software Metriken Prozess Metriken Ressourcen Metriken intern extern intern intern extern o Zuverl ssigkeit o Portierbarkeit o Verst ndlichkeit o Wartbarkeit o Benutzerfreundlichkeit o Testbarkeit o Performanz Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 40 395 Produktmetriken intern Vorteil automatische Erfassung Die Klassiker LOC Lines Of Code o Halstead 1977 McCabe 1976 o OO Metriken Chidamber und Kemerer 1994 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 41 395 Gr enmetriken LOC Lines of code LOC relativ einfach messbar starke Korrelation mit anderen MaBen ignoriert Komplexitat von Anweisungen und Strukturen schlecht vergleichbar o abgeleitet Kommentaranteil Rainer Koschke Uni Bremen Softwaretechnik Physical source lines COCOMO 2 0 Sommersemester 2006 42 395 When a line or statement contains more than one type classify it as the type with the highest precedence Statement type Precedence Included Executable No
47. 6 184 395 Vor und Nachteile II Nachteile o h here Kosten durch o komplexere Technik o durch Outsourcing h here Kosten durch Riskoabst tzung o mehr Aufwand um vergleichbare Systemstabilit t zu erreichen o offene Probleme o Vertrauensw rdigkeit der Implementierung o Zertifizierung der Implementierung o gew nschte Anforderungen vs verf gbare Komponenten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 185 395 Prozess Anpassung des Entwicklungsprozesses Anforderungen erfassen Identifizierung von Komponentenkandidaten suchen ausw hlen berpr fen Anpassen der Anforderungen an gefundene Kandidaten Design der Architektur berpr fung der Komponentenkandidaten und event neue Suche Erstellen der nichtabgedeckten Funktionalit t Zusammenstellen des Systems aus Komponenten mit Verbindungscode Glue Code Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 186 395 Komponentenmodelle o Sicherstellen der Interoperabilit t o Standards f r Schnittstellen o Schnittstellenbeschreibung o spezielle Schnittstellen o Interaktion zwischen Komponenten Informationen zur Verwendung Namensregeln o Individualisieren Zugriff auf Metadaten Einsatz o Verpackung o Dokumentation o Evolutionsunterst tzung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 190 395 Beispiele f r Komponentenmodelle
48. Abweichung von der nominalen Entwicklungdauer TDEV TDEVns x SCED 100 Wir verkiirzen auf 75 TDEV 18 26 x 75 100 10 3 Monate Chef Super Wir setzen SCED 75 in PM Formel ein PM 2 94 x 1001 x 1 0 x 1 43 440 23 Erh hung des Aufwands 440 23 307 86 1 43 Chef 43 mehr Kosten Seid Ihr wahnsinnig Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 105 395 COCOMO II Post architecture level Ber cksichtigt o Auswirkungen erwarteter nderungen von Anforderungen o Ausma Aufwand der m glichen Wiederverwendung o Aufwand f r Entscheidung ob Wiederverwendung o Aufwand f r das Verstehen existierenden Codes o Aufwand f r Anpassungen o 17 verfeinerte lineare Einflussfaktoren o Sch tzung basiert auf LOC Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 106 395 COCOMO II Post architecture level Produktg te kompl Verl sslichkeit Datenbasisgr e Komplexit t Dokumentation Plattformkomplexitat Laufzeit Speicherbeschr nkungen Plattformdynamik F higkeiten Personal F higkeiten der Analysten Entwickler Kontinuit t des Personals Erfahrung Personal Dom nenerfahrung der Analysten Entwickler Erfahrung mit Sprache und Werkzeugen Infrastruktur Tools verteilte Entwicklung Kommunikation Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 Einflussfaktoren Cost Drivers f r Cocomo 2 o ae F P
49. F gelesen und 7 DETs von ILF geschrieben Die geschriebenen DETs kreuzen aber nicht die Systemgrenze so dass insgesamt nur 7 DETs und nicht 14 betrachtet werden Bei EQ werden 4 DETs der Suchmaske gelesen Author Title Keywords und Abstract und 7 DETs von ILF ausgegegen Aus logischer Sicht werden aber die gleichen DETs Author Title Keywords und Abstract gelesen und angezeigt so dass insgesamt nur 7 DETs und nicht 11 betrachtet werden FP Bestimmung der Komplexitatsgewichte w Komplexitatsmatrizen o Funktionstyp FTRs RETs DETs FPs o Z hlen mittels Z hlregeln pro Funktionstyp FTRs RETs Rainer Koschke Uni Bremen Softwaretechnik DETs Funktionstyp 1 bisa a 1bisb gt b 1 bis x gering gering mittel x 1 bis y gering mittel hoch gt y mittel hoch hoch Sommersemester 2006 mal gez hlt 75 395 2006 07 19 2006 07 19 FP Bestimmung der Komplexit tsgewichte w Softwaretechnik Kosten und Aufwandssch tzung Komplect tamatrizen o Funktionstyp FTRs RETs DETs FPs Z hlen mittels Z hlregeln pro Funktionst sein Sette Er Funktionstyp 1 bisa a 1bisb gt b FP Bestimmung der Komplexit tsgewichte w oe a a gt y mittel hoch hoch FTR number of files updated or referenced A record element type is a user recognizable subgroup of data elements within an ILF or EIF A data element type is a unique user re
50. N Frank MEUNIER Regine ROHNERT Hans SOMMERLAD Peter STAL Michael Pattern oriented Software Architecture A System of Patterns Bd 1 Wiley 1996 5 Chidamber und Kemerer 1994 CHIDAMBER S R KEMERER C F A Metrics Suite for Object Oriented Design In JEEE Transactions on Software Engineering 20 1994 Nr 6 S 476 493 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 390 395 Empirische Softwaretechnik Wiederholungsfragen 6 Clements u a 2002 CLEMENTS Paul BACHMANN Felix BASS Len GARLAN David IVERS James LITTLE Reed NORD Robert STAFFORD Judith Documenting Software Architecture Boston Addison Wesley 2002 V Clements und Northrop 2001 CLEMENTS Paul NORTHROP Linda M Software Product Lines Practices and Patterns Addison Wesley August 2001 ISBN 0201703327 8 Cobb und Mills 1990 Coss R H MILLS H D Engineering Software Under Statistical Quality Control In IEEE Software 7 1990 Nr 6 S 44 54 9 Endres und Rombach 2003 ENDRES Albert ROMBACH Dieter A Handbook of Software and Systems Engineering Addison Wesley 2003 0 Fenton und Pfleeger 1998 FENTON N PFLEEGER S Software Metrics A Rigorous amp Practical Approach 2nd London International Thomson Computer Press 1998 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 391 395 Empirische Softwaretechnik Wiederholungsfragen 1 Gamma u a 2003 GAMMA Erich HELM
51. Objekten Entwurf o Unterscheidet Objekte nach Typ Gr e Methoden o Daten sammeln Regressionsanalyse o Formular Testbericht PSP1 1 PSP1 plus o Aufgabenplanung o Zeitsch tzung planung o Projektverfolgung Earned Value Tracking Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 170 395 PSP2 Personal Quality Management PSP2 PSP1 1 plus Code Reviews Checklisten Design Reviews Checklisten PSP2 1 PSP2 plus o Design Templates Operational Scenario Anwendungsfall Functional Specification formale Spezifikation State Specification Zustandsdiagramm Logic Specification Pseudocode oe 8 Vermeidung von Designfehlern Beurteilung der Qualitat o Cost of Quality Behebung Bewertung Vermeidung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 171 395 PSP3 Cyclic Personal Process PSP3 o Anwendung auf gro e Projekte o Nach High Level Design Aufteilung in Module o Anwendung von PSP2 1 auf jedes Modul o Formular Issue tracking log Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 172 395 Wiederholungs und Vertiefungsfragen o Erl utern Sie die Ideen sowie Vor und Nachteile der Entwicklungsprozesse Wasserfall V Modell testgetriebene Entwicklung inkrementelle Entwicklung Spiralmodell Rational Unified Process Cleanroom Development Extreme Programming 00 8 8 o Gegeben ist das f
52. Schl sselstrategien o Formale Spezifikation Inkrementelle Entwicklung Strukturierte Programmierung Statische Verifikation Statistisches Testen o basiert auf Verwendungsprofilen die Verwendungsweise der Software in der Praxis o die h ufigsten und kritischsten Verwendungsarten werden verst rkt getestet Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 149 395 Cleanroom Development Gruppen o Spezifikationsteam o verantwortlich f r Entwicklung und Wartung der Systemspezifikation o erstellt kundenorientierte und formale Spezifikation o Entwicklungsteam o verantwortlich f r Entwicklung und Verifikation der Software o Software wird nicht ausgef hrt hierzu o verwendet Code Inspektion erg nzt durch Korrektheits berlegungen nicht streng formal o Zertifizierungsteam o verantwortlich f r statistische Tests Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 150 395 Cleanroom Development Erfahrungen Cobb und Mills 1990 o weniger Fehler als bei traditioneller Entwicklung o bei vergleichbaren Kosten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 151 395 Extreme Programming Beck 2000 Extreme Programming XP ist eine agile Methode f r o kleinere bis gr ere Entwicklerteams max 10 15 Personen o Probleme mit vagen Anforderungen o und Projekte bei denen ein Kundenrepr sentant stets gr
53. Softwaretechnik Sommersemester 2006 82 395 FP Umrechnung in Aufwand Gesucht Abbildung FPs Aufwand o Erstellung einer neuen Erfahrungskurve Z hlen abgeschlossener Projekte Regressionsanalyse o Datenbank z B ISBSG 3GL Projekte PM 0 971 AFP 4GL Projekte PM 0 622 AFP 05 basierend auf 662 Projekten PM 0 38 AFP o grobe Sch tzung mit Faustregeln Jones 1996 Entwicklungsdauer Monate AFP o Personen AFP 150 aufgerundet o Aufwand Personenmonate Personen Entwicklungsdauer Beispiel mit Jones Sch tzung Entwicklungsdauer Monate 21 62 4 3 42 o Personen 21 62 150 1 Aufwand Personenmonate 1 3 42 3 42 International Software Benchmarking Standards Group Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 83 395 gt FP Umrechnung in Aufwand Softwaretechnik Gesucht Atildng FPs Aufwand 2 Kosten und Aufwandssch tzung I eier l FP Umrechnung in Aufwand O N http www isbsg org http www isbsg org isbsg nsf weben Project 20Duration FP Umrechnung in LOC Mittlere Anzahl Codezeilen pro FP Jones 1995 Rainer Koschke Uni Bremen Sprache Assembler C FORTRAN COBOL ANSI 85 Pascal C Java Ada 95 Smalltalk SQL Softwaretechnik LOC 320 128 107 91 91 53 53 49 21 12 Bewertung der Function Point Methode Wird als beste verf gbare Methode
54. Sommersemester 2006 134 395 135 395 Bewertung Spiralmodell Meta Modell Iterationen k nnen beliebigen Modellen folgen bei un bersichtlichen Ausgangslagen wird die Entwicklung in einzelne Schritte zerlegt die jeweils unter den gegebenen Bedingungen das optimale Teilziel verfolgen schwierige Planung was jedoch dem Problem inh rent ist setzt gro e Flexibilit t in der Organisation und beim Kunden voraus Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 136 395 Rational Unified Process RUP nach Gornik 2001 Konstruktion Phasen Konzeption Elaboration terationen MEE E bergabe Konst 2 e gt Konst 3 j gt Uberg 1 e berg 2 j Aktivit ten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 137 395 Rational Unified Process RUP nach Gornik 2001 Zeit Phases Geschaftsmodellierung mes Dom nenanalyse r Anforderungsanalyse Entwurf Implementierung Test Auslieferung N Konfigurations Anderungsmanagement Projektmanagement Infrastruktur A eal ea Ge ee Iterations Aktivitaten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 138 395 Softwa retec h n i k Rational Unified Process RUP nach Gornik 2001 Entwicklungsprozesse Rational Unified Process Rational Unified Process RUP nach Gornik 2001 ai ato 2006 07 19 Der Rational
55. Sommersemester 2006 383 395 Bestandteile eines Experiments 7 Grenzen der experimentellen Forschung hoher Aufwand allerdings Lernen ohne Experimente ist auch teuer o Abh ngigkeit von menschlichen Versuchsteilnehmern o Studenten haben m glicherweise nicht die Erfahrung o Praktiker haben wenig Zeit o Transferierbarkeit der Resultate o Software Projekte haben eine Unzahl m glicher Variablen o nicht alle sind kontrollierbar o und wenn sie kontrolliert sind treffen sie m glicherweise nicht auf andere Umgebungen zu Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 384 395 Bestandteile eines Experiments 8 Beschaffenheit empirischer Forschung in der Softwaretechnik erst seit ungef hr 1980 als wesentliche Disziplin anerkannt heute Konferenzen und Zeitschriften Verschiebung weg von rein mathematischen Methoden Mehrzahl der Probleme der Softwaretechnik sind nicht mathematischer Art h ngen vielmehr von Menschen ab Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 385 395 Weiterf hrende Literatur o Endres und Rombach 2003 beschreiben wesentliche empirische Kenntnisse in der Software Technik und brechen eine Lanze f r die empirische Forschung in diesem Gebiet o Winner u a 1991 beschreiben experimentelle Designs und ihre statistischen parametrischen Auswertungen Lienert 1973 beschreibt verteilungsfreie nicht parametri
56. Type begin Foo X end Apply Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 358 395 Architekturmechanismen f r Variabilit ten Parametrisierung einschlie lich Makros und Templates typedef xFP int void Apply FP fp fp X Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 359 395 Architekturmechanismen f r Variabilit ten Selektion verschiedener Implementierung zur bersetzungszeit z B ifdef oder Makefile ifdef Kundel 2 define My_Type int 3 void Foo My_Type M 4 else 5 typedef struct mystruct mystruct 6 define My_Type mystruct 7 void Foo My_Type M s endif 9 void Apply ho My_Type X 11 ae 12 Foo X 13 ve 14 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 360 395 Architekturmechanismen f r Variabilitaten OO Techniken Vererbung Spezialisierung und Delegation Entwurfsmuster typedef enum Strategy sl s2 s3 Strategy 2 void Apply Strategy s 3 switch s 4 case sl ApplyS1 break 5 case s2 ApplyS2 break 6 case s3 ApplyS3 break 23 8 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 361 395 1 2 3 4 5 6 7 Architekturmechanismen fiir Variabilitaten OO Techniken Vererbung Spezialisierung und Delegation Entwurfsmuster class Applier Strategy _strategy void Apply _strategy gt Algorithm
57. Vision sind o Erreichung der letzten Produkt Baseline so schnell und kosteng nstig wie m glich Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 143 395 RUP bergabephase Transition Typische T tigkeiten o Beta Test um das neue System gegen die Benutzererwartungen zu validieren o Parallele Verwendung mit einem Lagacy System das durch das Produkt ersetzt werden soll Konversion aller notwendigen Daten Dateien und Datenbanken o Schulung aller Benutzer und Administratoren bergabe an Marketing Vertrieb und Verk ufer Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 144 395 RUP bergabephase Transition Softwaretechnik Entwicklungsprozesse Typische Ttigkiten I o Beta Test um das neue System gegen die Benutzererwartungen zu N 8 ars validieren ep R at 1ona U n ifi ed P rocess Parallele Verwendung mit einem Lagacy System das durch das I a Produkt ersetzt werden soll WO R U P U b b h T au g o Konversion aller notwendigen Daten Dateien und Datenbanken Ubergabephase Transition ee o bergabe an Marketing Vertrieb und Verk ufer N Wenn ein Produkt ausgeliefert wird ergibt sich in der Regel schnell die Notwendigkeit neuer Releases um Probleme zu beseitigen Features zu realisieren deren Implementierung verschoben werden musste und Erweiterungen vorzunehmen Die bergabephase beginnt wenn eine Baseline reif genug ist um beim Endbenutzer
58. acks von der unteren zur oberen Schicht oder Multi threading o Problem welche Funktionen d rfen benutzt werden o Beispiel Unix Signal Handler o nicht mit Vor und Nachbedingungen ausdr ckbar Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 209 395 Fallstudie zur komponentenbasierten Entwicklung Garlan u a 1995 Komposition eines Case Tools aus o einer objektorientierten Datenbank o Toolkit zur Konstruktion graphischer Benutzeroberfl chen o event basiertem Tool Integrations Mechanismus o RPC Mechanismus Alle Komponenten in C oder C geschrieben Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 210 395 Glaube und Wirklichkeit Sch tzung o Dauer 6 Monate o Aufwand 12 PM Tats chlich o Dauer 2 Jahre o Aufwand 60 PM f r ersten Prototyp Ergebnis o sehr gro es System o tr ge Performanz o viele Anpassungen f r die Integration notwendig o existierende Funktionalit t musste neu implementiert werden weil sie nicht exakt den Anforderungen entsprach Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 211 395 Architektur Mismatch Definition Architektur Mismatch inkompatible Annahmen von wiederzuverwendenden Komponenten ber das Systems in dem sie eingesetzt werden sollen Meist sp t entdeckt weil die Annahmen in aller Regel nur implizit sind Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 212 395 K
59. alitativ hochwertiges Produkt zu erstellen Das inkrementelle Modell f hrt diesen Gedanken fort Anstatt auf die Fertigstellung der gesamten Anforderungen zu warten werden sobald eine ausreichende Anzahl von Kernanforderungen beschrieben ist f r diese ein Entwurf und die Implementierung gestattet Je mehr Anforderungen hinzukommen desto mehr zus tzliche Inkremente werden gestartet Das inkrementelle Modell ist gut geeignet wenn Kunde die Anforderungen noch nicht vollst ndig berblickt bzw sich der M glichkeiten zur Realisierung der Anforderungen nicht bewusst ist und deshalb die Anforderungen nicht formulieren kann Es ist mit diesem Modell m glich Teile des Systems bereits vor Fertigstellung des gesamten Systems beim Kunden einzuf hren z B ein oder mehrere Subsysteme Mit diesen Teilen kann der Kunde eine eingeschr nkte Anzahl an Anforderungen realisieren Die Zeitspanne zwischen Auftragsvergabe und Einsatz von zumindest Systemteilen wird somit geringer Federt die Gefahr des Wasserfallmodells ab am Ende mit leeren H nden dazustehen Sind wenigstens die ersten Inkremente erfolgreich entstanden hat der Kunde zumindest ein partielles System W hrend der Entwicklung kann noch auf nderungen reagiert werden Das Modell steht und f llt mit der M glichkeit Kernanforderungen zu identifizieren und ausreichend zu spezifizieren Die initale Software Architektur muss f r alle Anforderungen Kernanforderungen wie alle anderen
60. ation Kern Produktaufteilung Was geh rt zum Kern nderungen im Kern haben Auswirkungen auf alle Produkte Viele Probleme sind noch nicht gel st o Test o Konfigurationsmanagement p Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 366 395 Wiederholungs und Vertiefungsfragen o Erl utern Sie die Ideen von Software Produktlinien Was verspricht man sich davon o Was sind die Vor und Nachteile o Wie wird die Entwicklung von Software Produktlinien organisatorisch h ufig strukturiert o Erl utern Sie einige essentielle Aktivit ten und ihre Besonderheiten im Kontext von Software Produktlinien o In welcher Weise k nnen Produktlinien eingef hrt werden o Beschreiben Sie Implementierungsmechanismen f r die Variabilit t in Software Produktlinien Nennen Sie hierbei den jeweiligen Bindungszeitpunkt was dr ckt der Bindungszeitpunkt aus Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 367 395 Empirische Softwaretechnik Empirische Softwaretechnik Motivation Wissenserwerb in Wissenschaft und Engineering o Untersuchungsmethoden o Bestandteile eines Experiments o Wiederholungsfragen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 368 395 Lernziele o die Notwendigkeit zur empirischen Forschung in der Softwaretechnik erkennen o prinzipielles Vorgehen verstehen irgendwann einmal empirisch forschen k nnen
61. by Bauhaus Software Technologies a company providing services and tools to support reengineering maintenance and evolution of existing system Please visit the home page of our supporters BAUHAUS SOFTWARE TECHNOLOGIES Sites The reengineering bibliography is available at two sites Choose the one closest to you e University of Stuttgart Germany e Georgia Institute of Technology Atlanta GA USA Contents Introduction Leaflet Postscript Print and fold it and it will be a valuable guide in searching and adding references News Adding your references e Searching for references o via a taxonomy of reengineering related terms o via a simple search form that allows retrievals by specifying author title keywords abstract year etc The bibliography as a BibTeX database via FTP e Tayonomy il OF m a oP Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 64 395 Online Bibliographie Taxonomiesuche Bibliographic References Taxonomy Mozilla Eile Edit View Go Bookmarks Tools Window Help il GC 9 http www iste uni stuttgart de ps reengineering taxonomy htmi a Z i 4 Home Bookmarks The Mozilla Org Latest Builds Home Next Terminology Next Description Taxonomy Select elements of the following taxonomy to retrieve their references or one of the following two items Retrieve used terminology Get a descr
62. chkeiten zur Sch tzung von Aufwand und Kosten f r die Software Entwicklung gibt es o Wann wird gesch tzt o Erl utern Sie die Function Point Methode am konkreten Beispiel o Was sind Adjusted Function Points im Unterschied zu Unadjusted Function Points o Wie errechnet sich der Aufwand aus den Function Points o Was ist die Idee von Object Points im Gegensatz zu Function Points o Erl utern Sie die CoCoMo Methode neue Version f r die Level Early Prototyping und Early Design Level o Geben Sie die grunds tzliche Formel f r den Aufwand wieder Was bedeuten die verschiedenen Parameter o Um welche Art von Parametern handelt es sich bei den Faktoren die im Exponenten auftreten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 111 395 Wiederholungs und Vertiefungsfragen II o Wozu die Unterscheidung in die verschiedene Stufen Level o Wie errechnet sich die Entwicklungsdauer aus dem Aufwand o Wie wird eine Verk rzung der nominalen Entwicklungsdauer behandelt o Vergleichen Sie die Function Point Methode mit CoCoMo N B Die bungsaufgaben sind weitere Beispiele relevanter Fragen Bei der Darstellung der Einflussfaktoren f r die Adjusted Function Points gen gt es ein paar Beispiele nennen zu k nnen und zu wissen worauf sie sich grunds tzlich beziehen System und nicht Entwicklungsteam prozess keinesfalls wird Ged chtnisleistung abgepr ft das gilt auch f r die Einflussfaktoren
63. ck of time to resolve them earlier A schedule compress of 74 is rated very low A stretch out of a schedule produces more effort in the earlier phases of development where there is more time for thorough planning specification and validation A stretch out of 160 is rated very high Stretch outs i e SCED gt 100 do not add or decrease effort Their savings bacause of smaller team size are generally balanced by the need to carry project administrative functions over a longer period of time Rechenbeispiel Nominaler Aufwand Personenmonate PMys A KLOC EM mit EMscep 1 0 mit A 2 94 und E B X w 100 mit B 1 01 Annahme es herrschen einfache Verh ltnisse Vi w 0 gt E 1 01 bester Fall nominale Effort Multiplier 1 00 Normalfall gt EM 1 00 Gesch tzte Lines of Code 100 000 PMns 2 94 x 100191 x 1 0 307 86 Monate 253 Jahre Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 Entwicklungsdauer Nominale Entwicklungsdauer Kalenderzeit in Monaten D 0 2x E B TDEVys C x PM s mit C 3 67 und D 0 28 Beispiel TDEVns 3 67 x 307 86078 0 2x0 18 26 Anzahl Entwickler N PMns TDEVns Beispiel N 307 86 18 26 17 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 103 395 104 395 Verk rzte Entwicklungsdauer Chef Wieso 18 Monate Geht das nicht schneller PMns geht von SCED 1 0 aus
64. cognizable nonrecursive field Z hlen von Datenelementtypen DET Ein Datenelementtyp DET ist aus der Benutzersicht eindeutig bestimmbares nicht rekursives Feld das von der zu bewertenden externen Eingabe EI in einem internen Datenbestand ILF gepflegt wird Z hlen Sie 1 DET f r jedes aus Benutzersicht nicht rekursive Feld das die Systemgrenze kreuzt und gebraucht wird um den Elementarprozess abzuschlie en Beispiel Ein Texteingabefeld in dem der Nachname eines neuen Kunden eingegeben wird wird als 1 DET gez hlt Gegenbeispiel Eine Dateiauswahlliste in der beliebig viele Dateien von der Festplatte des Benutzers ausgew hlt werden k nnen ist rekursiv und muss somit gesondert gez hlt werden Z hlen Sie keine Felder die durch das System gesucht und oder in einem ILF gespeichert werden wenn die Daten nicht die Systemgrenze berqueren Z hlen Sie nur 1 DET f r die F higkeit eine Systemantwort als Meldung f r einen aufgetretenen Fehler aus der Anwendung heraus zu senden bzw f r die Best tigung dass die Verarbeitung beendet oder fortgesetzt werden kann Beispiel Bei Eingabe eines Datums soll z B das Format TT MM JJJJ eingehalten werden Gibt der Bearbeiter z B 12 03 1997 ein und best tigt seine Eingabe so erh lt er die Meldung neuer Datensatz gespeichert Gibt er hingegen 12 3 97 ein Jahreszahl nicht vierstellig so erh lt er die Fehlermeldung Fehler Bitte Datum korrigieren Nur ein DET wird f r d
65. d des Projekts Die Summe der Fl chen pro Spalte ist der Aufwand pro Iteration Die Summe der Fl chen pro Zeile ist der Aufwand pro Aktivit t Die Hauptaktivit ten sind Gesch ftsmodellierung optional Anforderungsanalyse Entwurf Implementierung Test Auslieferung Die Gesch ftsmodellierung dient dazu eine gemeinsame Sprache f r die unterschiedlichen Gruppen Softwareentwickler und Betriebswirte zu finden und die Software Modelle auf die zugrunde liegenden Gesch fsmodelle zur ckzuf hren Die Gesch ftsprozesse werden durch so genannte Gesch fts Anwendungsf lle dokumentiert Sie zielen darauf ab ein gemeinsames Verst ndnis welche Gesch ftsprozesse in der Organisation unterst tzt werden sollen aller Beteiligten zu erreichen Die Gesch fts Anwendungsf lle werden analysiert um zu verstehen wie die Gesch ftsprozesse unterst tzt werden sollen RU Zie Res P Konzeptionsphase Inception l Business Case erstellen und Projektgegenstand abgrenzen ultate o Projektplan mit Phasen und Iterationen o Vision der Hauptanforderungen Schl sselfeatures und wesentliche Einschr nkungen o initiale Anwendungsf lle 10 20 vollst ndig o Glossar oder auch Dom nenmodell o initialer Business Case Gesch ftskontext Erfolgskriterien Sch tzung des erzielten Gewinns Marktanalyse etc und Finanzvorschau o initiale Risikobetrachtung o Projektplan mit Phasen und Iterationen o Business Modell falls notwendig o e
66. definitions html Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 221 395 Bedeutung von Software Architektur Kommunikation zwischen allen Interessenten o hoher Abstraktionsgrad der von vielen verstanden werden kann o Fr he Entwurfsentscheidungen nachhaltige Auswirkungen fr hzeitige Analyse Transferierbare Abstraktion des Systems Beherrschung der Komplexit t Aufgabenverteilung eigenst ndig wiederverwendbar unterst tzt Wiederverwendung im gro en Stil Software Produktlinien Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 222 395 Bedeutung von Software Architektur Softwaretechnik Software Architektur ee nn has ist Software Architektur Bedeutung von Software Architektur o Fr he Entwurfser 2006 07 19 e SA repr sentiert hohe Abstraktion eines Systems die von den meisten Interessenten verstanden werden kann und dam eine Grundlage zum gegenseitigen Verst ndnis zur Konsensbildung und zur Kommunikation darstellt e SA ist die Manifestation fr her Entwurfsentscheidungen diese fr he Fixierung kann nachhaltige Auswirkungen haben auf die nachfolgende Entwicklung Auslieferung sowie Wartung und Evolution SA ist auch die fr heste Systembeschreibung die analysiert werden kann e SA konstituiert ein relativ kleines intellektuell fassbares Modell dar ber wie das System strukturiert ist und wie seine Komponenten zusammenwirken dieses Mod
67. die im Laufe des Projekts formuliert werden tragf hig sein ansonsten ist ein hoher Restrukturierungaufwand notwendig Darum sollten am Anfang alle Anforderungen bekannt sein die sich ma gebend auf die Architektur auswirken Beispiel f r Textverarbeitung Iterationen grundlegende Funktionalitat o Datei Management Editor Textausgabe erweiterte Funktionalit t o Style Files Bearbeitung mathematischer Formeln Einbinden von Graphiken zus tzliche Funktionalit t o Rechtschreibpr fung Grammatik berpr fung berarbeitungsmodus erg nzende Funktionalit t o Tabellenkalkulation Gesch ftsgraphiken E Mail Web Browser Scanner Anbindung Flipper Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 130 395 Inkrementelles Modell von Basili und Turner 1975 Eigenschaften o Wartung wird als Erstellung einer neuen Version des bestehenden Produkts betrachtet Entwicklung erfolgt stufenweise o brauchbare Teill sungen in kurzen Abst nden Lernen durch Entwicklung und Verwendung des Systems Gut geeignet wenn Kunde Anforderungen noch nicht vollst ndig berblickt oder formulieren kann o I know it when I see it Kernanforderungen und Architekturvision m ssen vorhanden sein Entwicklung ist durch existierenden Code eingeschr nkt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 131 395 Vergleich inkrementelles Modell und Wasserfallmodell
68. dungsf llen abgeleitet o dienen als Baseline o treiben den Entwurf o treiben die Kodierung Test Teams treiben die Entwicklung statt von Entwicklern getrieben zu werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 120 395 Testgetriebene Entwicklung Sneed 2004 Anwendungs und Testf lle o Anwendungsf lle beschreiben Anforderungen o sind jedoch oft nicht detailliert genug um erwartetes Verhalten vollst ndig zu spezifizieren o Testf lle k nnen Anwendungsf lle hier komplementieren o zu jedem Anwendungsfall sollte es mindestens einen Testfall geben o Testf lle k nnen zur Kommunikation zwischen Entwickler und Kunden Anwender dienen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 121 395 Testgetriebene Entwicklung Sneed 2004 Testf lle dienen als Baseline o definieren die Vorbedingungen einer Produktfunktion o spezifizieren die Argumente einer Produktfunktion o spezifizieren das Verhalten einer Produktfunktion die Nachbedingungen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 122 395 Testgetriebene Entwicklung Sneed 2004 Testf lle treiben den Entwurf o Testfall ist ein Pfad durch die Software Architektur o Testf lle verkn pfen Anforderungsspezifikation und Architekturkomponenten o Testf lle k nnen zur Studie der zu erwartenden Performanz und anderer Systemattribute zur Entwurfszeit verwendet werden Rainer K
69. e dar Im Gegensatz zu Optionsfeldern k nnen aus einer Gruppe von Checkboxen mehrere Elemente gleichzeitig ausgew hlt werden Somit wird jedes Element als 1 DET gez hlt Beispiel Eine Gruppe von 12 Checkboxen mit der ein Pizza Belag zusammengestellt werden kann wird als 12 DETs gez hlt Eingabe und Ausgabefelder stellen Datenelemente dar Beispiel In einer Bildschirmmaske werden Vorname Nachname Stra e Hausnummer PLZ und Ort in Eingabefeldern erfasst Somit werden 6 DET gez hlt Literale stellen keine Datenelemente dar Beispiel Vor einem Feld ist die Textzeile monatliches Gehalt und dahinter in Euro Monat angegeben Beide Textzeilen sind Literale und werden nicht gez hlt Enter OK Button und Programmfunktionstaste werden insgesamt als 1 DET gez hlt da jeweils die gleiche Funktion ausgef hrt wird Beispiel Die Daten eines Dialogs werden nach Bet tigen der Enter Taste oder nach Bet tigen der Schaltfl che tibernehmen gleiche Funktion wie OK Button in einer Datenbank gespeichert Es wird 1 DET gez hlt Berichte Reports k nnen verschiedene Ausgabeformen haben So kann die gleiche Datenbasis zur Darstellung als Tortendiagramm Tabelle textuell als druckbares Format oder als Exportdatei dargestellt werden Jedes Format stellt dabei eine externe Ausgabe EO dar FP Werte der Komplexit tsgewichte w DETs El 1 4 5 15 0 1 3 3 2 3 4 4 FTRs O oO Oy amp 3 RETs
70. e of the first authors on viewpoints He proposed 6 x 6 different viewpoints Perry and Wolfe proposed a simplified version of these views distinguishing only three viewpoints Then you have the 4 1 viewpoints by Philippe Kruchten you have the four Siemens viewpoints et cetera The number of viewpoints is confusing in particular because many of them are very similar Recently the book by Clements and colleagues brought some order to this sea of viewpoints Blickwinkelkategorisierung Clements u a 2002 o M module decomposition use generalization layers oo o CC component amp connectors pipe and filter shared data publish and subscribe client server peer to peer communicating processes ee 0 0 o A allocation o deployment o implementation o work assignment Rainer Koschke Uni Bremen Softwaretechnik Softwaretechnik Software Architektur Was ist Software Architektur Blickwinkelkategorisierung Clements u a 2002 2006 07 19 Here you see their categories of viewpoints Sommersemester 2006 226 395 Blickwinkelkategorisierung Clements u a 2002 o M module decomposition rain layers o CC component amp connectors communicating processes o A allocation deployment implementation work assignment Module viewpoints show static structure and describe the decomposition layering and generalization of modules and their use dependencies A module is a code u
71. eifbar ist http www extremeprogramming org Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 152 395 Extreme Programming Beck 2000 Anerkannte Prinzipien und Praktiken werden extrem umgesetzt Code Reviews permanente Reviews durch Pair Programming o Testen st ndiges Testen Unit Tests sowie Akzeptanztests durch den Kunden Benutzer klare Struktur jeder verbessert sie kontinuierlich durch Refactoring Einfachheit stets die einfachste Struktur w hlen die die aktuellen Anforderungen erf llt Integration permanente Integration auch mehrmals am Tag Validierung o Kunde Benutzer ist stets involviert bei der Planung neuer Iterationen und verantwortlich f r Akzeptanztest o kurze Iterationen Dauer in Minuten und Stunden nicht Wochen Tage Jahre aber auch Auslassung anerkannter Prinzipien o Dokumentation m ndliche berlieferung Tests und Quellcode o Planung sehr begrenzter Horizont Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 153 395 Weitere XP Charakteristika Kunde vor Ort o eine Metapher statt einer Architekturbeschreibung o 40 Stundenwoche o Code ist kollektives Eigentum Kodierungsstandards Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 154 395 Agile versus weit voraus planende Prozessmodelle Boehm und Turner 2003 Risiken agiler Methode o Skalierbarkeit Kritikalit t Ei
72. ell ist eigenst ndig nutzbar und kann ber das spezifische System hinaus transferiert werden insbesondere kann es f r Systeme mit hnlichen Eigenschaften und Anforderungen wiederverwend werden um so Wiederverwendung im gro en Stil zu unterst tzen Stichwort Software Produktlinien Architektursichten und blickwinkel IEEE P1471 2002 un Definition Definition zur Architekturblickwinkel Viewpoint Architektursicht View Spezifikation der Regeln und Konventionen um Repr sentation eines ganzen eine Architektursicht zu konstruieren und zu Systems aus der Perspektive benutzen einer koh renten Menge von Ein Blickwinkel ist ein Muster oder eine Anliegen Vorlage von der aus individuelle Sichten entwickelt werden k nnen durch Festlegung von o Zweck o adressierte Betrachter o und Techniken f r Erstellung Gebrauch und Analyse calls Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 223 395 Architektursichten und blickwinkel IEEE P1471 2002 Softwaretechnik Software Architektur Was ist Software Architektur Architektursichten und blickwinkel IEEE P1471 2002 2006 07 19 Unterschiedliche Sichten helfen der Strukturierung Separation of Concerns Architecture design and reconstruction create architectural views for existing systems But what is a view at all One of the achievements of the IEEE P1471 is the definition of views and viewpoints A view is a r
73. en Interne Validierung Nachweis dass ein Ma eine g ltige numerische Charakterisierung des entsprechenden Attributs ist durch Nachweis der Erf llung der Repr sentanzbedingung o und Pr fung des Skalentyps Externe Validierung Vorhersagemodell o Hypothese ber Zusammenhang zwischen zwei Ma en o Erfassung der Me werte beider Ma e auf gleicher Testmenge o Statistische Analyse der Ergebnisse Bestimmung von Parametern Pr fung der Allgemeing ltigkeit Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 34 395 Klassifikation von Softwaremetriken o Was Ressource Prozess Produkt o Wo intern extern isoliert mit Umgebung o Wann in welcher Phase des Prozesses o Wie objektiv subjektiv direkt abgeleitet Ressourcen Prozess Produkt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 35 395 Klassifikation von Softwaremetriken Softwaretechnik Software Metriken o esses Wie objektiv subjektiv direkt abgeleitet AQ amp a ae ikiassifikatien von Softwaremetriken Bei den Metriken unterscheidet man zwischen internen und externen Metriken Eine interne Metrik ist dar ber definiert dass sie nur Eigenschaften innerhalb des untersuchten Objektes misst wohingegen externe Metriken die Interaktion des Objektes mit seiner Umgebung beriicksichtigen Klassifikation von Softwaremetriken 2006 07 19 Klassifikation nach Fenton u
74. en o Architekturmetriken Kopplung Koh sion etc o Simulatoren Performanz Verf gbarkeit Fragetechniken sind jederzeit anwendbar aber weniger objektiv Messtechniken setzen Architektur voraus liefern aber genaue Antworten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 263 395 Anforderungen Kontext Architekturanalysen sind schwierig o gro e Systeme haben umfangreiche Architektur o Evaluation muss Verbindung zu Gesch ftszielen herstellen o verschiedene Stakeholders haben unterschiedliche Interessen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 264 395 Architecture Tradeoff Analysis Method ATAM Vorbedingungen o klar artikulierte Ziele und Anforderungen an die Architektur o klar abgesteckter Rahmen ca f nf Ziele mit hoher Priorit t o erwarteter Nutzen bersteigt erwartete Kosten meist f r Systeme ab mittlerer Gr e erf llt o Schl sselrollen verf gbar z B Architekt o kompetentes Evaluations Team Querschnittsbereich mit Entscheidungskompetenzen o realistische und offene Erwartungen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 Teilnehmer bei ATAM Bass u a 2003 o Evaluations Team extern o Entscheider o Projekt Manager o Architekt o eventuell Vertreter des Kunden o Architektur Stakeholders o Entwickler Tester Integrierer Wartungsprogrammierer Performanztuner Benutzer Build Prozess Veranwortliche
75. en Attribute Vererbung etc o Hinzuf gen weiterer Kommandos ist einfach Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 329 395 Problem o Eigenschaften sollen einzelnen Objekten nicht ganzen Klassen zugewiesen werden k nnen o Zuweisung soll dynamisch geschehen TextView ScrollDecorator BorderDecorator Dies ist ein Text Wer das liest hat gute Augen ET Dies ist ein Text Wer das liest hat gute Augen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 330 395 Problem TextView ScrollDecorator BorderDecorator Dies ist ein Text Wer das liest hat gute Augen E Dies ist ein Text Wer das liest hat gute Augen aBorderDecorator aScrollDecorator component gt aTextView gt component Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 331 395 L sung VisualComponent i Draw A TextView component Decorator ZI Penent Draw Draw ee een component Draw A ScrollDecorator BorderDecorator N Draw DRAW seele Decorator Draw ScrollTo DrawBorder DrawBorder scrollPosition borderWidth Softwaretechnik So
76. en m ssen o Repr sentanz Darstellung als Zahl sinnvoll m glich o Eindeutigkeit viele Abbildungen m glich o Bedeutung erhalten bei Transformationen o Skalierung welche Skala Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 23 395 Fragen bei Ma en Softwaretechnik Software Metriken Messen und Ma e Fragen bei Ma en Wor ber wir uns bei der Definition von Metriken Gedanken machen m Darstellung als Zahl sinnvoll m glich viele Abbildungen m glich erhalten bei Transformationen welche Skala 2006 07 19 There are three important questions concerning representations and scales 1 How do we determine when one numerical relation system is preferable to another 2 How do we know if a particular empirical relation system has a representation in a given numerical relation system 3 What do we do when we have several different possible representations and hence many scales in the same numeric relation system Question 2 is known as the representation problem Skalen 20 Prozent Verbesserung der Qualit t Dieser Kunde ist doppelt so zufrieden wie jener Heute doppelt so warm wie gestern Temperatur gestern 10 C heute 20 C Was ist Qualit t Null Wie zufrieden sind Sie denn 10 C 20 C 3 5 denn 10 C 283 Kelvin 20 C 293 Kelvin Skala Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 24 395
77. epresentation of a whole system from the perspective of a related set of concerns Here for instance you see a part of the call graph of jikes the IBM compiler for Java Such views are formalized through viewpoints A viewpoint specifies the kind of information that can be put in a view A call graph viewpoint can be modeled by this UML diagram for instance Siemens Blickwinkel Hofmeister u a 2000 o Konzeptioneller Blickwinkel beschreibt logische Struktur des Systems abstrahiert weitgehend von technologischen Details o Modulblickwinkel beschreibt die statische logische Struktur des Systems o Ausf hrungsblickwinkel beschreibt die dynamische logische Struktur des Systems Code Blickwinkel beschreibt die anfassbaren Elemente des Systems Quelldateien Bibliotheken ausf hrbare Dateien etc Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 224 395 Verbreitete Blickwinkel a Clements Rainer Koschke Uni Bremen Softwaretechnik 2006 07 19 Softwaretechnik Software Architektur Was ist Software Architektur Verbreitete Blickwinkel Perry and Wolfe et al Sommersemester 2006 225 395 Verbreitete Blickwinkel eS L EN Zachman gt 2 L Woe Perry and Wolfe NER aut ne en Ei D a col gl X SRE or x es d A A d r wy y aan 28 Sr 3 L C Clements et al eS Viewpoints are very popular in forward engineering You likely know these Zachman was on
78. er 2006 242 395 Gesch ftsqualit ten 2006 07 19 Time To Market Kosten Nutzen anvisierte Lebensdauer Zielmarkt Auslieferungsplan Integration mit Legacy Systemen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 244 395 Gesch ftsqualit ten Softwaretechnik Software Architektur Qualit t von Software Architekturen o Zielmarkt Gesch ftsqualit ten een o Time To Market e Time To Market kurze Time To Markt zwingt zu COTS und inkrementeller Entwicklung e Kosten Nutzen hat z B auch Einfluss auf Technologien die verwendet werden k nnen Anschaffungskosten Einarbeitungszeit e anvisierte Lebensdauer hohe Lebensdauer verst rkt Bedeutung von nderbarkeit Skalierbarkeit Portabilit t e Zielmarkt bei Massenmarkt ist Portabilit t und allgemeine Funktionalit t von hoher Bedeutung e Auslieferungsplan bei inkrementeller Auslieferung muss das System leicht erweiterbar sein e Integration mit Legacy Systemen zwingt zu Integrationsmechanismen Qualit ten der Architektur selbst o Einfachheit o konzeptionelle Integrit t Gleiches wird gleich gel st Fred Brooks Kopplung minimieren Koh sion maximieren o Isomporphie zur Realit t Michael Jackson Q Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 246 395 Taktiken und Strategien Definition Taktik bezeichnet das geschickte Nutzen einer gegebenen Lage Wikipedia Strategisches Handeln ist
79. er Konstruktionsphase werden alle brigen Komponenten und Feature realisiert und in das Produkt integriert und intensiv getestet Die Konstruktionsphase ist einem gewissen Sinne ein Herstellungsprozess bei dem Wert auf das Management von Ressourcen und das Controlling gelegt wird um Kosten Zeitplan und Qualit t zu optimieren In diesem Sinne geht der Prozess nun ber von der intellektuellen Entwicklung zur Entwicklung auslieferbarer Produkte Viele Projekte sind gro genug um die Konstruktion zu parallelisieren Die Parallelisierung kann die Verf gbarkeit auslieferbarer Releases zu beschleunigen Andererseits kann sie auch die Komplexit t der Ressourcenverwaltung und der Synchronisation der Arbeitsfl sse erh hen Eine robuste Architektur und ein verst ndlicher Plan h ngen stark zusammen Deshalb ist eine kritische Qualit t der Architektur die Einfachheit ihrer Konstruktion Dies ist einer der Gr nde weshalb die ausgeglichene Entwicklung der Architektur und des Plans w hrend der Elaborationsphase so sehr betont wird Das Resultat der Konstruktionsphase ist ein Produkt das tats chlich in die H nde des Benutzers bergehen kann RUP bergabephase Transition Ziel Produkt wird der Benutzergemeinde bergeben Hauptziele im Einzelnen o Benutzer sollten sich m glichst alleine zurecht finden o Beteiligte sind berzeugt dass die Entwicklungs Baselines vollst ndig und konsistent mit den Evaluationskriterien f r die
80. ersemester 2006 177 395 Komponente Definition Software components are executable units of independent production acquisition and deployment that interact to form a functioning system Szyperski u a 2002 o to compose a system o dazu da um zusammengesetzt zu werden o N B Komponente Klasse Verteilung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 178 395 Komponentenbasierte Entwicklung o Trennung von Schnittstellen liefern benutzen und Implementierung o Standards f r Integration o einheitliche Schnittstellenbeschreibung o unabh ngig von der Programmiersprache o Infrastruktur Middleware o Entwicklungsprozess technische und nicht technische Aspekte Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 179 395 Motivation Wiederverwendung als Schl ssel o konomisch o als L sung der Softwarekrise o OO konnte die Erwartungen an Wiederverwendbarkeit und Vermarktung nicht erf llen ohne Wiederverwendung nur lineares Wachstum m glich mit Wiederverwendung superlineares Wachstum m glich so die Hoffnung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 180 395 Motivation Il Ebenen der Wiederverwendung konkrete L sungsteile Bibliotheken o Vertr ge Schnittstellen o Vertragsanbieter Komponenten o einzelne Interaktionsteile Meldungen und Protokolle Architekturen f r Interaktion Mu
81. etechnik Sommersemester 2006 380 395 Bestandteile eines Experiments 4 Analyse und Validierung der Resultate o Auswertung durch statistische Methoden Korrelationen und Regressionsanalyse o Problem des geringen Datenumfangs o parametrische statistische Tests setzen bestimmte Verteilung voraus o meist nur nicht parametrische statistische Tests ad quat weil keine Verteilung voraus gesetzt wird insbesondere f r Nominal bis Ordinalskalen o quantitative Analyse oft erg nzt durch qualitative o Validierung o Befragungen der Teilnehmer um sicher zu stellen dass sie alle Fragen verstanden haben o Untersuchung statistischer Ausrei er Benchmarking schwierig weil Firmen ihre Daten ungern ver ffentlichen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 381 395 Bestandteile eines Experiments 5 Replikation Wiederholung um Gl ckstreffer auszuschlie en o Experiment muss detailliert beschrieben sein o bedauerlicherweise schwer zu ver ffentlichen weil keine neuen Ergebnisse pr sentiert werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 382 395 Bestandteile eines Experiments 6 Ethische Fragen keine Teilnahme ohne explizite Einwilligung kein Missbrauch Anonymit t muss gew hrt werden doppelt blind kein materieller oder sonstiger Gewinn Bezahlung Gehaltserh hung gute Note etc Rainer Koschke Uni Bremen Softwaretechnik
82. etenden Risiken bestimmt Dies hat zur Folge dass zu Beginn des Projekts ein Zeit und Kostenplan nur schwer zu erstellen ist Die Risikoanalyse kann nur durch erfahrene Projektleiter durchgef hrt werden Bei zu zaghaftem Vorgehen kann sich das Projekt unn tigerweise verl ngern was zu erh hten Kosten f hrt Zu schnelles Vorgehen kann Risiken vernachl ssigen und zu Problemen in folgenden Durchl ufen f hren Beispiel eines Spiralmodells Generische Risiken o Ist das Konzept schl ssig Kann es aufgehen o Was sind die genauen Anforderungen o Wie sieht ein geeigneter Entwurf aus Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 Entwicklungsprozesse Spiralmodell Beispiel eines Spiralmodells mit vier Durchl ufen i BewerteAlternativen 2 identifiziere und beseitige Risiken Kosten BestimmeZiele Alternativen Restriktionen Risikoanalyse Risikoanalyse Risikoanalyse Zustim Risik gt betriebs analyse Proto fahiger Proto Prototyp mung typ 3 durch Fein Produkt entwurf entwurf Codieren Entwicklungs plan Anforderungs ntegration Entwurfs und Testplan 2 pr fung T Integration 3 Plane die Verbesserungsplan und Test n chste Phase aa Abnahme Entwickle das Produkt test pr fe die n chste i Produktstufe Rainer Koschke Uni Bremen Softwaretechnik
83. ewusst war dass sie unterschiedliche metrische Systeme f r ihre Software zugrunde legten Die einen interpretierten einen Wert in Zentimetern die anderen in Zoll Inch Im Glossar beschreibt der Software Entwickler was die Begriffe des Kunden bedeuten ebenso wie seine eigenen speziellen Begriffe Der Kunde begutachtet das Glossar Damit definieren beide Partein ihr Vokabular Mi verst ndnisse sollen so minimiert werden Das Dom nenmodell oft auch konzeptuelles Modell genannt beschreibt die Begriffe Objekte der Anwendungsdom ne und ihre Relationen Eine Reihe der genannten Punkte wird sicherlich in Zusammenarbeit mit Betriebswirten ausgearbeitet Softwareentwickler haben eine Liebe zur Technologie bersehen jedoch leider oft die Wirtschaftlichkeit ihrer Ideen Mit ihr steht und f llt jedoch das Projekt Die Erstellung von Prototypen hat das Ziel m gliche technologische Risiken auszuschlie en dem Kunden ein konkretes Bild der m glichen Anwendung zu vermitteln Benutzerschnittstellenprototyp Anforderungen zu konkretisieren I know it when I see it und die Machbarkeit bestimmter Anforderungen zu demonstrieren Das Business Modell erl utert wie das System eingesetzt wird um damit Profite zu erzielen RUP Elaborationsphase Elaboration Ziel Verst ndnis der Anwendungsdom ne tragf hige Software Architektur Projektplan Eliminierung der Risiken o Anwendungsfallmodell mind 80 fertig o alle Anwendungs
84. f lle und Aktoren sind identifiziert o die meisten Anwendungsfallbeschreibungen wurden entwickelt o zus tzliche nichtfunktionale Anforderungen und Anforderungen die nicht mit einem spezifischen Anwendungsfall assoziiert sind o Beschreibung der Software Architektur o ausf hrbarer Architekturprototyp Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 140 395 RUP Elaborationsphase Elaboration Softwaretechnik Entwicklun gsprozesse ZI Vena der AnmenitneetomaneRCoE sae Software Architektur Projektplan Eliminierung der Risiken R x U ifi d P o Anwendungsfallmodell mind 80 fertig lle Ar idi f lle id Akte id identifiziert oO ationa nine rocess onen u 9 zus tzliche nichtfunktionale Anforderungen und Anforderungen die R U P 2 El b m h El b n nicht mit einem spezifischen Anwendungsfall assoziiert sind oO aborations p ase aboration o Beschreibung der Software Architektur ep o ausf hrbarer Architekturprototyp N Die Elaborationsphase ist die kritischste Phase Hier entscheidet sich ob das System tats chlich gebaut wird Der Engineering Anteil ist weitgehend erbracht Bis dahin halten sich die Kosten noch in Grenzen Nun schlie en sich die teure Konstruktions und bergabephase an Die Aktivit ten der Elaborationsphase stellen sicher dass die Software Architektur die Anforderungen und Pl ne hinreichend stabil sind m gliche nderungen sind antizipiert v llig ausschlie en lassen sie sich meist
85. gespr ch z hlt zu 30 bungs Praktikumsaufgaben z hlen zu 70 Kosten und Aufwandssch tzung f r System S o Vorschlag eines Prozessmodells f r die Entwicklung von 5 o Architekturentwurf bzw analyse f r S wobei S eine Online Bibliographie f r wissenschaftliche Referenzen ist die im Software Projekt gerade durch eine Neuentwicklung ersetzt wird http www iste uni stuttgart de ps reengineering Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 10 395 Online Bibliographie Startseite Reengineering Bibliography Mozilla Eile Edit View Go Bookmarks Tools Window Help il G 9 http www iste uni stuttgart de ps reengineering index htmi a Se i 4 Home Bookmarks The Mozilla Org Latest Builds IEEE COMPUTER SOCIETY Technical Council on Software Engineering Welcome to the Reengineering Bibliography This annotated bibliography provides information on software reengineering This reengineering bibliography is an initiative of several people In their rare spare time they collected bibliographic entries and merged them into this elaborate bibliography Probably you have done the same then please mail us so that we can add your references all at once Maybe you have contributed to the field of reengineering yourself Since the originators lack the time to continuously update this bibliography we ask you to add your own references This is a very simple process when
86. gkeiten o billiger f r den Benutzer o schneller da keine cross context o mehr Freiheit f r den Benutzer Aufrufe o mehr Benutzer Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 202 395 Implementierung o defensives Programmieren da keine Integrationstests o wiederverwendbar machen entferne anwendungsspezifische Methoden generalisiere Namen f ge Methoden hinzu um Funktionalit t zu vervollst ndigen f hre konsistente Ausnahmebehandlung ein f ge M glichkeiten hinzu die Komponenten an verschiedene Benutzer anzupassen o binde ben tigte Komponenten ein um die Unabh ngigkeit zu erh hen O O 8 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 204 395 Typen o Typ als vereinfachter Vertrag mit besserer berpr fbarkeit berpr fung des Vertrages bersetzungszeittest besser als Ladezeittest besser als Laufzeittest besser als kein Test o Subtypen o Austauschbarkeit Liskovsches Substitutionsprinzip deklarative Subtypen aka Vererbung vs strukturelle Subtypen o Eingabeparameter gleicher Typ oder Supertyp Kontravarianz o Ausgabeparameter gleicher Typ oder Subtyp Kovarianz o Implementierungen k nnen den Vertrag ndern nur Vorbedingungen abschw chen oder Nachbedingungen versch rfen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 205 395 Vererbung Anpassen einer Komponente o durch Parametrisieren und Verbinden mi
87. hat the entries to retrieve must have all specified attributes author abstract Start searching Clear all inputs koschke informatik uni stuttgart de Feedback Copyright 1997 University of Stuttgart Germany Revision 1 6 Last modified Mon Jun 22 16 26 16 MET DST 1998 m Gx E Done Heel Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 66 395 Beispiel Online Bibliographie Systemgrenzen der Online Bibliographie o El BibTeX Datei importieren EO Abfrage ber Taxonomie anzeigen lassen EQ Artikel ber Suchmaske abfragen ILF Referenzen Datenbank ELF externe Bib TeX Datei Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 67 395 Function Points zusammenfassen Parameter Gewicht El Wi EO W2 EQ W3 ILF wa ELF ws Unadjusted Function Points UFP DV o zu sch tzen c und w o feinere Aufteilung ist m glich o z B 3 El mit Gewicht 6 und 4 El mit Gewicht 3 Umfang Summe FPs ungewichtete Funktionspunkte UFP Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 68 395 Beispiel Komplexit tsgewichte w f r ELF und ILF Definition Satzarten RET Record Element Type f r Benutzer erkennbare logisch zusammengeh rige Untergruppe von Datenelementen innerhalb eines Datenbestands ILF Publication Author Title Year
88. hitektur Qualit t von Software Architekturen Performanz 2006 07 19 Latenz Reaktionszeit gemessen ab Eintreffen der Nachricht Latency Deadline fester Zeitpunkt zu dem Reaktion erfolgt sein muss Versatz Variation der Reaktionszeit Jitter Durchsatz Anzahl der Ereignisse die einem bestimmten Zeitintervall bearbeitet werden k nnen Vers umnisrate Anzahl der Ereignisse die einem bestimmten Zeitintervall nicht bearbeitet werden konnten Datenverlust Umfang der Daten die verloren gingen nderbarkeit Allgemeine Szenarien Quelle Endbenutzer Entwickler Systemadministrator Stimulus Wunsch Funktionalit t hinzuzuf gen zu entfernen ab zu ndern zu variieren bzw Qualit tsaspekt zu ver ndern Artefakt System Benutzeroberfl che Plattform Umgebung koope rierendes System Umgebung Laufzeit Ladezeit bersetzungszeit Entwurfszeit Reaktion Lokalisierung nderung Test Auslieferung der Architek turkomponenten Ma Kosten in Form von Anzahl der betroffenen Komponenten Aufwand Geld Ausma des Einflusses auf andere Qua litatsattribute Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 238 395 nderbarkeit Spezielles Szenario O Stimulus Wunsch GUI zu ndern Stimulusquelle Entwickler Rainer Koschke Uni Bremen Testbarkeit Definition Artefakt Reaktion Code nderung ohne Seiten U mgebung effekte Entwurfs gemacht
89. i Anpassung durch Vererbung und Redefinition auf Wie kann man mit ihm umgehen o Was ist das Problem des Wiedereintritts o Was versteht man unter Architektur Mismatch und welche Bedeutung hat er f r die komponentenbasierte Entwicklung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 217 395 Software Architektur Software Architektur o Was ist Software Architektur Zusammenfassung aus dem Software Projekt Hofmeister Methode und Blickwinkel o Qualit t von Software Architekturen o Taktiken Evaluation von Software Architektur o Wiederholungsfragen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 218 395 Lernziele o Verstehen was Software Architektur ist o Qualit ten einer Architektur kennen o Taktiken des Software Architekturentwurfs kennen o Software Architektur beschreiben k nnen o Software Architektur bewerten k nnen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 219 395 Was ist Architektur Architecture is the human organization of empty space using raw material Richard Hooker 1996 Definition Software Architektur ist die grundlegende Organisation eines Systems verk rpert IEEE P1471 2002 o in seinen Komponenten o deren Beziehungen untereinander und zur Umgebung o und die Prinzipien die den Entwurf und die Evolution leiten Weitere ber 100 Definitionen unter www sei cmu edu architecture community_
90. iability DOCU Documentation match to life cycle needs CPLX Product Complexity DATA Data base size Grad very low low nominal high very high extra high Punkte 1 2 3 4 5 6 RCPX RELY very little little some basic strong DOCU very little little some basic strong CPLX very little little some basic strong very strong DATA small moderate large very large gt Punkte 56 78 9 11 12 13 15 16 18 19 21 EMrpcx 0 49 0 60 0 83 1 00 1 33 1 91 2 12 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 96 395 Effort Multiplier RCPX Product Reliability and Complexity Softwaretechnik RELY Required reliability DOCU Docu mate Kosten und Aufwandsschatzung oa Grad very low low nominal high very high extra high Punkte T 2 a 4 5 6 x RELY very little little 2006 07 19 Effort Multiplier RCPX Product Reliability and ae a a 2 DATA small moderate large very large Complexity SR EMrpcx 0 49 0 60 0 83 1 00 1 33 1 91 2 72 DATA This cost driver attempts to capture the effect large test data requirements have on product development The rating is determined by calculating D P the ratio of bytes in the testing database to SLOC in the program The reason the size of the database is important to consider is because of the effort required to generate the test data that will be used to exercise the program In other words DATA is capturing the effort needed to assemble and maintain the data required to complete te
91. ieren abbrechen ndern editieren modifizieren ersetzen einf gen hinzuf gen entfernen l schen erstellen konvertieren update bertragen o EO anzeigen ausgeben ansehen abfragen suchen durchsuchen darstellen drucken selektieren Anfrage Abfrage Report o EQ abfragen anzeigen ausw hlen drucken suchen durchsuchen darstellen zeigen drop down extrahieren finden holen selektieren Ausgabe Liste Report Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 62 395 Online Bibliographie Startseite al GC 9 oe amp http Mwww iste uni stuttgart de ps reengineering index html S il a amp Home Bookmarks The Mozilla Org Latest Builds IEEE COMPUTER SOCIETY Technical Council on Software Engineering Welcome to the Reengineering Bibliography This annotated bibliography provides information on software reengineering This reengineering bibliography is an initiative of several people In their rare spare time they collected bibliographic entries and merged them into this elaborate bibliography Probably you have done the same then please mail us so that we can add your references all at once Maybe you have contributed to the field of reengineering yourself Since the originators lack the time to continuously update this bibliography we ask you to add your own references This is a very simple process when using our forms Supporters This annotated bibliography is supported
92. iese F higkeit des Systems gez hlt Z hlen Sie nur 1 DET f r die M glichkeit eine Aktion durchzuf hren auch wenn es viele Methoden gibt die denselben logischen Prozess ansto en Beispiel In einem Eingabeformular gibt es einen OK Button zum Absenden der Daten Die Tastaturkombination STRG S f hrt ebenfalls zum Senden der Daten Somit wird nur ein DET gez hlt FP Bestimmung der Komplexit tsgewichte w Softwaretechnik Kosten und Aufwandssch tzung Komplete gt Funktionstyp FTRs RETs DETs FPs gt Z hlen mittels Z hlregeln pro Funktionstyp Function Points a unktionstyp isa a is FP Bestimmung der Komplexit tsgewichte w ee ne ma gt y mittel hoch hoch Fortsetzung Z hlen von referenzierte Datenbestanden FTR Ein referenzierter Datenbestand FTR ist eine vom Benutzer definierte Gruppierung zusammengeh riger Daten oder Steuerungsinformationen in einem internen Datenbestand ILF die bei der Bearbeitung der externen Eingabe gelesen oder gepflegt wird Z hlen Sie 1 FTR f r jeden referenzierten Datenbestand der w hrend der Verarbeitung der externen Eingabe gelesen wird Beispiel Es werden durch eine externe Eingabe Produktdaten in einer Datenbank gespeichert Dazu werden die Produktbezeichnungen aus einer weiteren Datenbank ausgelesen die damit zus tzlich zu der zu aktualisierenden Produktdatenbank einen weiteren Datenbestand darstellt der jedoch nur gelesen wird Z h
93. ik Kosten und Aufwandssch tzung Po Komplexit tsgewichte w f r El EO EQ 2006 07 19 Hier werden die Funktionen abgesch tzt Function Points zusammenfassen Eli BibTeX Datei importieren EO Abfrage ber Taxonomie anzeigen lassen EQ Artikel ber Suchmaske abfragen ILF 1 Referenzen Datenbank ELF externe Bib TeX Datei 0 Komplexit tsgewichte w f r El EO EQ eferenzierte Datenbest nde FTR File Type Referenced von Transaktion verwen deter Datenbestand ILF ELF Beispiel Datenbank oder Textdatei die bei der Ausgabe von Kundendaten herangezogen wird Beispiele f r DETs im Kontext Transaktionen Eingabe Ausgabefelder GUI Spalten u bei Berichten Parameter Z hler RET DET Gewicht Wert ILFy 1 2 T ELF 1 2 T Parameter Z hler FTR DET Gewicht Wert Ely 1 2 T EQ 1 1 T EQ 1 1 1 Unadjusted Function Points UFP jedes DET wird nur einmal gez hlt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 74 395 Softwaretechnik Kosten und Aufwandssch tzung Function Points 2006 07 19 Function Points zusammenfassen Function Points zusammenfassen DET Gewicht Wert j 7 E 2 2 Te r FTR DET Gewicht Wert 2 7 1 i r 1 x Unadjusted Function Points UFP jedes DET wird nur ein Bei Ely werden 7 DETs von EL
94. in oder mehrere Prototypen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 139 395 Softwa retec h n i k ae eis Inception 2 E n tw i e kl u ngsp rozesse der Hauptanforderungen N f wesentliche I Einschr nkungen Rational Unified Process ee 1 o initialer Business Case Gesch ftskontext Erfolgskriterien Sch tzung RUP Konzeptionsphase Inception Bee ern vt ane oO N o Business Modell falls notwendig o ein oder mehrere Prototypen Begleitende Aktivit ten sind das Konfigurations und nderungsmanagement und das Projektmanagement Ihr Aufwand ist in allen Phasen mehr oder minder gleich Der Aufwand f r das Konfigurations und nderungsmanagement zeigt leichte Peaks im bergang von einer Phase zur anderen wenn die Konfigurationen fest gezurrt werden und zum Teil nachgearbeitet werden muss Dem Glossar kommt eine ganz besondere Bedeutung zu Es erkl rt die Begriffe der Anwendungsdom ne Software Entwickler sind Spezialisten f r die Entwicklung von Software aber Laien in sehr vielen ihrer Anwendungsdom nen Dar ber hinaus verwenden auch Kunden oft die Begriffe uneinheitlich bzw gel ufige Worte mit einer ganz speziellen Bedeutung in ihrem Kontext Mi verst ndnisse zwischen Kunden und Softwareentwickler sind sehr h ufig und k nnen zu teuren Fehlentwicklungen f hren Eine Marssonde bei deren Entwicklung europ ische und amerikanische Organisationen mitwirkten verfehlte ihr Ziel weil den Organisationen nicht b
95. ind leichter einzubeziehen als beim Wasserfallmodell Projekt Team kann im Verlauf hinzulernen o Haupts chlich Konstruktionsphase kann inkrementell ausgestaltet werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 146 395 Bewertung des RUPs Softwaretechnik ntwicklungsprozesse Ir 8 p o bernimmt vom Spiralmodell die Steuerung durch Risiken 5 DR o Konkretisiert die Aktivit ten Spiralmodell ist ein Meta Modell oO Rational Unified Process gt And er Anforderungen sind che einzubeziehen als beim l o Proj kann im Verlauf hinzulernen Ke B ewe rt un 8 d es R U Ps Haupts chlich Konstruktionsphase kann inkrementell ausgestaltet Q werden O N Iterativ ist nicht gleich inkrementell Bei der iterativen Entwicklung werden Entwicklungsschritte wiederholt ausgef hrt Bei der inkrementellen Entwicklung geschieht dies auch jedoch immer um eine neues Release auf Basis eines vorherigen zu bauen Letzteres ist im Begriff Iteration nicht eingeschlossen Cleanroom Development Mills u a 1987 Fehlerbeseitigung Definiere Entwickle Verifiziere Software strukturiertes Code inkremente Programm formal Entwickle Verwendungs Entwerfe Teste profil statistische integriertes Tests System Spezifiziere System formal Integriere Inkrement Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 148 395 Cleanroom Development
96. installiert werden zu k nnen Das erfordert typischerweise dass zumindest eine n tzliche Teilmenge des Systems mit einer aktzeptablen Qualit t fertig gestellt werden konnte und dass die Benutzerdokumentation vorhanden ist Meist fallen mehrere Iterationen in der bergabephase an Beta Releases allgemeine Releases Bug Fix und Erweiterungsreleases Hoher Aufwand wird in die Entwickler der benutzerorientierten Dokumentation die Schulung von Benutzern Unterst tzung der Benutzer in ihren ersten Verwendungen des Produkts und Reaktion auf Benutzer Feedback investiert Man sollte sich an diesem Punkt jedoch auf den Feinschlief die Konfiguration Installation und Usability Aspekte beschr nken G nzlich neue Erweitungen sollten durch einen nachfolgenden separaten Entwicklungszyklus realisiert werden Die bergabephase kann trivial sein Software und Handbuch wird auf einen Server im Internet gelegt oder auch sehr aufw ndig und kompliziert Ersetzung einer Flugaufsichts Software Empfohlene Anzahl von Iterationen nach Kruchten 1998 Komplexit t niedrig normal och Konzeption Elaboration Konstruktion bergabe Summe OIN ww HH gt Wl FF Oo Ole N N e Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 145 395 Bewertung des RUPs bernimmt vom Spiralmodell die Steuerung durch Risiken Konkretisiert die Aktivit ten Spiralmodell ist ein Meta Modell nderungen der Anforderungen s
97. ions Sensitivity Tradeoff Risk Nonrisk Backup CPU s R8 No backup data channel R9 Watchdog N12 Heartbeat N13 Failover routing N14 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 293 395 Pen Evaluation von Software Architektur easoning o Ensures no commom mode failure by using different hardware and operating systems see Risk 8 o Worst case rollover is accomplished in 4 seconds as computing state takes that long at worst o Guaranteed to detect failure within 2 seconds based on rates of heartbeat and watchdog o Watchdog is simple and provided reliable o Availability requirement might be at risk due to lack of backup data channel see Risk 9 Architecture diagram Primar CPU OS1 m heartbeat Switch CPU y 1 sec ee 0S1 Backup CPU with Watchdog 052 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 294 395 Prozessphase Evaluation Teil II Brainstorming und Priorisierung der Szenarien o Stakeholders schlagen Szenarien vor die f r sie relevant sind falls bis dato nicht ber cksichtigt Uneinigkeit zwischen Architekt und Stakeholder entdeckt Risiko o Szenarien werden priorisiert jeder Stakeholder kann ein Drittel aller Szenarien als relevant ffentlich auserw hlen Kumulieren und Panaschieren erlaubt o Selektion der wichtigsten Szenarien z B ab einem deut
98. iption of this taxonomy e Reengineering in General o Reengineering Collections ntroductions to Reengineering Fundamentals The Pros and Cons and Risks of Reengineering Experiences o o o o o Costs o o o o Process Models Management Legality nteroperability o Business Reengineering Software Reverse Engineering o General Information on Reverse Engineering o Reverse Engineering Collections o Cognitive Processes in Human Program Understanding o Software Evolution o o Extracting Business Rules ntermediate Representations of Source Code Use of data bases a Using graphs o Preventive Measures o Formal Methods o Reverse Specification Model Generatin Software Animation Visualization of Parallel and Distributed Programs mer en z I Sel Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 65 395 Online Bibliographie Suche nach Eigenschaften Bibliography Search Mozilla Eile Edit View Go Bookmarks Tools Window Help N Q 6 Qe amp http Mwww iste uni stuttgart de ps reengineering simple search html a amp Home Bookmarks The Mozilla Org Latest Builds Home Next Regular Expressions Search for References Fill out this form you can leave out fields press the button below and you will receive all the references that contain the regular expressions you filled in Note that the search is case insensitive and t
99. l und Typ der Parameter e Semantik von Daten die Einheit der Werte ist die gleiche Meilen versus Kilometer alles schon mal dagewesen Diensten top wirft Exception wenn der Stack leer ist statt einen undefinierten Wert zur ckzugeben Verwendung eines Mittelsmanns II Softwaretechnik SRA fe A ie h ite kt ar 5 fal ce ganze von D falls es mehrere gibt gt Ort von D zur Laufzeit z B gleicher Prozessor E kuken sonm o Quality of Service Data von D Verwendung eines Mittelsmanns Il Ze men a Existenz von D Factory Muster o Ressourcenverhalten von D Resourcen Manager als Mittelsmann e Reihenfolge von Daten Netzwerkpakete kommen in der Reihenfolge ihres Abschickens an Kontrolle D muss 5 Millisekunden vor V ausgef hrt worden sein e Identit t der Schnittstelle von D D hat verschiedene Versionen seiner Schnittstelle ber die Zeit e Ort von D zur Laufzeit V und D laufen auf gleichem Prozessor mit gemeinsamem Speicher e Quality of Service Data von D die Daten des Sensors D sind in einem Toleranzbereich der Genauigkeit e Existenz von D damit V einen Dienst von D aufrufen kann muss D existieren oder V muss die M glichkeit haben D erschaffen e Ressourcenverhalten von D D gibt alle seine Resourcen wieder frei nachdem der Dienst erbracht wurde Aufschieben der Bindezeit Laufzeitregistrierung Plug and Play zur Laufzeit oder Ladezeit Konfigurati
100. langfristig taktisches Handeln mittelfristig und operatives Handeln kurzfristig angelegt Wikipedia Tactics are the specifics of strategies Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 248 395 Taktik im Architekturkontext Definition Taktik Entwurfsentscheidung die die Reaktion auf einen Stimulus bestimmt und damit ein Qualit tsattribut beeinflusst Stimulus Artefakt Reaktion Wunsch GUI oe Anderung zu ndern ohne Seiten Stimulusquelle Umgebung amp ffekte Reaktionsmessung Entwickler Entwurfs gemacht in 3 Stunden zeit Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 250 395 Taktiken f r Anderbarkeit nderbarkeit Eingrenzung Vermeidung des Aufschieben der von Anderungen Welleneffekts Bindezeit semantische Geheimnisprinzip Laufzeit Koh renz e Erhalt existierender registrierung antizipierte Schnittstellen e Konfigurations Anderungen Restriktion von dateien e verallgemeinerte Kommunikations Polymorphismus Module pfaden e Austausch von e Begrenzung Verwendung eines Komponenten moglicher Mittelsmanns Einhaltung von Optionen Protokollen abstrakte gemeinsame Dienste Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 252 395 Taktiken f r nderbarkeit Softwaretechnik Software Architektur Lee akt kch re f r nderbarkeit 2006 07 19 Eingrenzung von
101. lbar o Projektplanung und management basiert auf Erfahrung Key Process Areas o Anforderungsverwaltung u a Reviews o Projektplanung Zeitplanung Risikomgmt Prozess o Projektverfolgung und berblick Transparenz o Unterauftragsverwaltung o Qualit tssicherung QS Plan o Konfigurationsverwaltung Konsistenz nderungsverfolgung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 159 395 CMM Level 3 Defined e Organisationsweiter Prozess wird f r jedes Projekt angepasst Zust ndig Software Engineering Process Group Kosten Zeitplan und Funktionalit t im Griff Key Process Areas Organisationsweiter Prozess Prozessdefinition Ausbildungsprogramm Integriertes Softwaremanagement Anpassung auf konkretes Projekt Software Engineering Techniken Tool Unterst tzung Koordination zwischen Gruppen Peer Reviews Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 160 395 CMM Level 4 Managed o Einbeziehung quantitativer Aspekte Ziele setzen und berwachen o Prozessmessdaten werden aufgenommen archiviert analysiert e e Vorhersagbarkeit steigt Key Process Areas Quantitative Prozesssteuerung Leistung des Prozesses berwachen Software Qualitatsmanagement Messbare Ziele f r Prozessqualitat Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 161 395 CMM
102. le Szenarien sowie Motivation und Entschluss f r Szenarien o verschickt Szenarien an alle Beteiligten Eigenschaften o kann sich schriftlich gut ausdr cken o kann Information gut abrufen hat gutes Verst ndnis von Architekturfragen kann technische Aspekte gut aufnehmen ist bereit Diskussion zu unterbrechen um sein eigenes Verst ndnis eines Szenarios zu pr fen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 271 395 Rollen im ATAM Evaluations Team Zeitnehmerin Aufgaben o unterst tzt Evaluationsleiter die Zeit einzuhalten o unterst tzt die Zeit f r jedes Szenario in der Evaluationsphase festzuhalten und zu steuern Eigenschaften o bereit Diskussion mit Hinweis auf Zeit zu unterbrechen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 272 395 Rollen im ATAM Evaluations Team Prozessbeobachterin Aufgaben o entdeckt Verbesserungen des Evaluationsprozesses o eher stille Beobachtung w hrend der Evaluation kann aber Prozessvorschl ge machen o berichtet Erfahrungen und schl gt Verbesserung nach der Evaluation vor o berichtet an unternehmensweite Architekturgruppe Eigenschaften o guter Beobachter o erfahrener Anwender der Methode Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 273 395 Rollen im ATAM Evaluations Team Prozessexperte Process Enforcer
103. lehre_id 406 o Videoaufzeichnungen unter http mlecture uni bremen de News unter Stud IP unter http elearning uni bremen de bungen bungen ca alle zwei Wochen alternierend zur Vorlesung Ubungsblatt im Netz Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 7 395 Meine Grunds tze der Leistungsbewertung bungen sollten keine Pr fungsleistungen sein o praktisch anwenden ist besser als wiederk uen o umfassendes Lernen ist besser als punktuelles o Noten m ssen individuellen Beitrag wiedergeben o die Form der Pr fungsleistung muss einheitlich sein es muss einen Unterschied zwischen Modulpr fung und Schein geben Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 8 395 Formen der Pr fungsleistungen a m ndliche Pr fung b Klausurarbeit c Bearbeitung von bungsaufgaben mit Fachgespr ch d Bearbeitung von Praktikums bzw Laboraufgaben mit Fachgespr ch e m ndlicher Vortrag mit schriftlicher Ausarbeitung Referat optional mit Fachgespr ch f umfangreiche schriftliche Ausarbeitung Hausarbeit mit Fachgespr ch g Abschlussarbeit Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 9 395 Scheinbedingungen Anerkennung durch m ndliche Pr fung o 30 min tige m ndliche Pr fung ber den Stoff der Vorlesung bungsaufgaben bearbeiten lohnt sich o Wiederholungsfragen beantworten lohnt sich Ansonsten o Fach
104. len Sie 1 FTR f r jede ILF die w hrend der Verarbeitung der externen Eingabe gepflegt wird Beispiel Es wird zus tzlich zu den Aktionen des vorigen Beispiels eine Textdatei aktualisiert in der die Anzahl der Zugriffe auf die Datenbank verzeichnet wird Z hlen Sie nur 1 FTR f r jede ILF die w hrend der Verabeitung der externen Eingabe gelesen und gepflegt wird Beispiel W rden die Informationen der Textdatei ebenfalls in der Datenbank gespeichert werden so wird diese nur als 1 FTR gez hlt obwohl die Datenbank zur Ein und Ausgabe von Daten verwendet wird FP Bestimmung der Komplexit tsgewichte w Softwaretechnik 2 Kosten und Aufwandsschatzung Kompledt tsmatizen 1 o Funktionstyp FTRs RETs DETs FPs N a f Z hlen mittels Z hlregeln pro Funktionstyp o Function Points i I Funktionstyp 1 bis a a 1 bish gt b FP Bestimmung der Komplexit tsgewichte w STRET TSI kee m hoch oO gt y mittel oci oc N Fortsetzung Besonderheiten bei grafischen Benutzungsoberfl chen Besonderheiten bei grafischen Benutzungsoberfl chen Optionsfelder Radiobuttons stellen Datenelemente dar Es wird pro Gruppe von Optionsfeldern 1 DET gez hlt da innerhalb einer Gruppe nur ein Optionsfeld ausgew hlt werden kann Beispiel Eine Gruppe von 12 Radiobuttons in der ein PKW Typ ausgew hlt werden kann wird als 1 DET gez hlt Kontrollk stchen Checkboxen stellen Datenelement
105. lichen Sprung der Voten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 296 395 Prozessphase Evaluation Teil II Architekturans tze werden analysiert o Architekt erl utert gegen ber Stakeholders wie Szenarien behandelt werden o analog zu Schritt 6 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 298 395 Prozessphase Evaluation Teil II Pr sentation der Resultate o Vortrag oder schriftlicher Bericht Zusammenfassung der Ergebnisse o dokumentierte Architekturans tze priorisierte Szenarien N tzlichkeitsbaum entdeckte Risiken dokumentierte Nonrisks o Sensitivity Points und Tradeoff Points O O Zusammenfassung verwandter Risiken o z B Architektur beachtet nicht verschiedene Hardware und Softwareausf lle ungen gende Beachtung von Verf gbarkeit Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 302 395 Prozessphase Wiedervorlage Resultat wird vorgestellt bergeben Diskussion ber den Verlauf der Evaluation Prozessbeobachter berichtet Aufwand wird festgehalten Nach einigen Monaten Q Q Langzeiteffekte der Evaluation sowohl f r Architektur als auch weitere Evaluationen werden bestimmt Kosten Nutzen Abw gung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 303 395 Wiederholungs und Vertiefungsfragen Was ist Software Architektur Welche Bedeutung
106. m Up Sch tzung Dekomposition und Sch tzung der einzelnen Kostensch tzung ree ed ag gt Daumen Regeln o Gesamtaufwand 1 DLOC h Delivered Line of Code o Gesamtkosten 50 Euro DLOC o Pricing to Win a Parkinsons Gesetz mehrere Experten fragen Abweichungen diskutieren bis Konsens erreicht statistisches Kostenmodell aus Vergangenheitsdaten wird erstellt Modell wird zur Vorhersage benutzt Bezug auf historische Daten eines ahnlichen Projekts Pricing To Win Preis wird vereinbart im Zuge des Projekts einigt man sich auf Funktionsumfang Parkinsons Gesetz wenn X Zeit zur Verf gung steht wird X Zeit ben tigt Interessanterweise sind Manager gar nicht so schlecht im Sch tzen von Aufw nden schlecht sind sie jedoch in der Sch tzung von LOC Kostensch tzung Boehm 1981 4x 2x 2 T ao 0 5x 0 25x _ Machbarkeit Planung Produkt Entwurf Entwicklung t Anforderungen Design Test Entwicklungsphasen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 57 395 Function Point Methode Zweck Messen des Umfangs einer zu erstellenden Software aus Benutzersicht Umrechnung des Umfangs in personellen Aufwand o Eingabe Lastenheft Entwicklung o Autor Alan J Albrecht 1979 IBM o Heute zahlreiche Varianten o IFPUG Int l Function Point User Group Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 59 395 Function Point Methode Sof
107. m und 1 Woche Betroffene Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 280 395 Prozessphase Vorbereitung o Einf hrung ins Projekt o Er rterung der Logistik o initiale Liste der Stakeholders o Zeitplan bergabe verf gbarer Architekturdokumentation Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 281 395 ATAM Evaluationsphase Pr sentation Pr sentation der von ATAM treibenden Gesch ftsziele l Pr sentation der Identifikation der Architektur Architekturans tze D E am A Erstellung des Nutzens Analyse der der Qualit tsattribute Architekturans tze als Baum Ly Brainstorming und Analyse der Priorisierung der Architekturansatze Szenarien N oO wn oO Pr sentation der aL Resultate Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 282 395 Prozessphase Evaluation Teil Evaluationsleiter stellt ATAM Kontext Erwartungen vor Projektentscheider stellt Geschaftsziele vor o die wichtigsten Funktionen des Systems o relevante technische organisatorische konomische oder politische Randbedingungen o Gesch ftsziele und Kontext o wesentliche Stakeholders o Hauptqualit tsziele der Architektur Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 283 395 Prozessphase Evaluation Teil Architekt stellt Architek
108. men Product Quelle Linda Northrop SEI gt Core Asset Development Product Constraints Production Constraints Production Strategy Inventory of Pre existing Assets Management ud Product Line Scope Core Assets Production Plan Quelle Linda Northrop SEI Entwicklung der Core Assets Assoziierte Prozesse A Attached ye Processes Core Asset Base BE EEE Assets Core Asset Development Production Plan A AtAtA Management Quelle Linda Northrop SEI Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 350 395 Produktentwicklung Product Requi Product Line pe Product Developmen Core Assets O nooo Sey Production Plan wa 0O A A A A Products Management Quelle Linda Northrop SEI Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 351 395 Essentielle Aktivit ten Core Asset i Product Development ane al Development Ned Management Essential Activities Architecture Definition Architecture Evaluation Component Development COTS Utilization Configuration Management Data Collection Metrics and Tracking Make Buy Mine Commission Building a Business Case Customer Interface Management Implementing an Acquisition Strategy _ ee Analysis Funding Mining Existing Assets Process Definition Launching and Instit
109. mmersemester 2006 332 395 Rainer Koschke Uni Bremen Konsequenzen zu analysieren Rainer Koschke Uni Bremen h here Flexibilit t als statische Vererbung vermeidet Eier Legende Wollmilchsau Klassen Dekorator und dekoriertes Objekt sind nicht identisch vielf ltige dynamische Kombinationsm glichkeiten schwer statisch Softwaretechnik Sommersemester 2006 333 395 Weiterf hrende Literatur o Das Standardbuch zu Entwurfsmustern ist das von Gamma u a 2003 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 334 395 Wiederholungsfragen o Was ist ein Entwurfsmuster Warum sind sie interessant f r die Software Entwicklung Wie werden Entwurfsmuster von Gamma et al kategorisiert Erl utern Sie eines der in der Vorlesung vorgestellten Entwurfsmuster mit Vor und Nachteilen und Variationen Das Strategy Muster wird bei den Produktlinien vorgestellt und ist pr fungsrelevant Das Observer Muster wurde im Software Projekt vorgestellt und ist nicht pr fungsrelevant Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 335 395 Software Produktlinien Software Produktlinien Lernziele Software Wiederverwendung Erfolgsgeschichten Definition bersicht Kostenaspekte Practice Areas Entwicklung der Core Assets Produktentwicklung Essentielle Aktivit ten Einf hrung von Produktlinien Implementierungsstrategien
110. nd Pfleeger 1998 Software Metriken eu I Prozess Metriken Produkt Metriken Ressourcen Metriken Ze Pr Fr intern extern intern extern intern extern Rainer Koschke Uni Bremen Prozessmetriken Intern o Zeit Dauer o Aufwand o Anzahl von Ereignissen z B Fehler Anderungen Rainer Koschke Uni Bremen Softwaretechnik Software Metriken Sommersemester 2006 36 395 Produkt Metriken Ressourcen Metriken intern extern intern extern extern o Qualit t o Kontrollierbarkeit o Stabilit t Softwaretechnik o Kosten Sommersemester 2006 37 395 Ressourcenmetriken Software Metriken Prozess Metriken Produkt Metriken intern extern intern extern Intern Rainer Koschke Uni Bremen Personal Alter Lohn Teamgr e struktur Produktionsmaterialien Werkzeuge Methoden extern o Produktivit t o Erfahrung o Kommunikation 24 Softwaretechnik Produktmetriken intern Software Metriken Prozess Metriken extern intern Gr e o LOC o Halstead o Function Points o Bang DeMarco Rainer Koschke Uni Bremen Sommersemester 2006 38 39
111. nen Beh lter hinzuf gen Artikel for each t in Teile t entfernen t ent fernen Laufrad t ent fernen tent fernen entfernen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 311 395 Entwurfsmuster Composite operation operation children add component remove component getChild int o S H a gt l l Leaf operation operation A A s for each c in children add component remove component c operation getChild int spezifische Erweiterungen myElem myComp Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 312 395 Kategorien von Entwurfsmustern Muster f r das Erzeugen von Instanzen o Singleton o strukturelle Muster zur Komposition von Klassen oder Objekten o Composite o Adapter o Decorator o Verhaltensmuster betreffen Interaktion von Klassen oder Objekten o Command Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 313 395 Bestandteile eines Entwurfsmusters Name kurz und beschreibend Problem Was das das Entwurfsmuster l st L sung Wie es das Problem l st Konsequenzen Folgen und Kompromisse des Musters Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 314 395 Problem es soll nur eine einzige Instanz einer Klasse geben die global verf gba
112. nexecutable Declarations Compiler directives Comments On their own lines On lines with source code Banners and non blank spacers Blank empty comments Blank lines Rainer Koschke Uni Bremen Softwaretechnik 1 wW N CON DD OO gt v v Sommersemester 2006 43 395 Physical source lines COCOMO 2 0 How produced Included Programmed J Generated with source code generators Converted with automated translators J Copied or reused without change J Modified J Removed Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 44 395 Physical source lines COCOMO 2 0 Origin Include New work no prior existence y Prior work taken or adapted from s A previous version build or release J Commercial off the shelf software COTS other than libraries Government furnished software GFS other than reuse libraries Another product A vendor supplied language support library unmodified A vendor supplied operating system or utility unmodified A local or modified language support library or operating system Other commercial library A reuse library software designed for reuse Other software component or library ae Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 45 395 Anwendungen o Beurteilung des aktuellen Zustands Projekt berwachung Produktivit t Softwarequalit t Prozessqualit t CMM Q e Q o Vorhersage des zuk nftigen Zustands o
113. nfachheit des Entwurfs Personalfluktuation Personalf higkeiten Risiken weit voraus planender Prozessmodelle o Stabilit t der Anforderungen steter Wandel Notwendigkeit schneller Resultate Personalf higkeiten Generelle Risiken Unsicherheiten bei der Technologie unterschiedliche Interessengruppen komplexe Systeme Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 155 395 Capability Maturity Model o Entwickelt vom SEI 1985 91 f r DoD Beschreibt Stufen der Prozessreife Ma stab Leitfaden f r Verbesserungen Idee besserer Prozess besseres Produkt o 5 Stufen CMM Level 1 5 o Definiert Schl sselbereiche Key Process Areas o Steigende Transparenz des Prozesses Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 156 395 Optimizing Vorhersagbarkeit an Managed Einheitlichkeit Konsistenz Defined Disziplinierter Prozess Repeatable Initial Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 157 395 Capability Maturity Model st ndige Verbesserung in CMM Level 1 Initial Prozess meist v llig instabil Typisch in Krisen nur noch Code amp Fix Qualit t und Fertigstellung unvorhersagbar Erfolge nur durch gute Leute und gro en Einsatz Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 158 395 CMM Level 2 Repeatable o Projekterfolge nachvollziehbar und wiederho
114. ng Reaktionsmessung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 289 395 Prozessphase Evaluation Teil Priorisierung der Szenarien o Priorisierung der Szenarien durch Entscheider o Priorisierung der Szenarien durch Architektur bez glich der Schwierigkeit mit der die Architektur das Szenario erf llen kann o Auswahl der Szenarien f r Evaluation h icht h hrscheinlich pee We e DO PER DA Q ee Priorit t 100000 an i ee eee ee Entscheider ______ ILL LL 222 22 LL TN Sa SE SE Oe niedrig gg i rs rs a wahrscheinlich nicht wahrscheinlich niedrig Priorit t Architekt hoch Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 290 395 Prozessphase Evaluation Teil Architekturans tze werden analysiert e e in Reihenfolge aus Schritt 5 wird jedes Szenario einzeln betrachtet Architekt nimmt Stellung wie die Architektur das Szenario unterst tzt Evaluations Team insbesondere Fragesteller fragt nach den Architekturans tzen Risiken risikolose Eigenschaften Nonrisks Sensitivity Points Tradeoff Points werden dokumentiert Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 292 395 Beispielanalyse eines Architekturansatzes A12 Detect and recover from HW failure of main switch Attribute s Availability Environment Normal Operation Stimulus One of the CPUs fails Response 0 999999 availability of switch Architectural Decis
115. ngs Westcon IEEEPress 1970 S 328 339 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 394 395 Empirische Softwaretechnik Wiederholungsfragen 0 Sneed 2004 SNEED Harry Vorlesungsskriptum Software Engineering Uni Regensburg Wirtschaftsinformatik Veranst 2004 1 Sommerville 2004 SOMMERVILLE lan Software Engineering Addison Wesley 2004 2 Symons 1988 Symons C R Function Point Analysis Difficulties and Improvements In TSE 14 1988 Jan Nr 1 S 2 11 3 Szyperski u a 2002 SZYPERSKI Clemens GRUNTZ Dominik MURER Stephan Component Software Second edition Addison Wesley 2002 ISBN 0 201 74572 0 4 Winner u a 1991 WINNER B J BROWN Donald R MICHELS Kenneth M Statistical Principles in Experimental Design 3rd edition McGraw Hill 1991 Series in Psychology Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 395 395
116. nicht und Risiken sind ausreichend betrachtet so dass Kosten und Zeitplan zuverl ssig gesch tzt werden k nnen Ab hier sollte man sich auf eine Projektdurchf hrung mit festem Preis einlassen k nnen In der Elaborationsphase wird ein ausf hrbarer Architekturprototyp in ein oder mehr Iterationenj erstellt Die Anzahl der Iterationen h ngt vom Scope der Gr e der Risiken und dem Grad des Unbekannten des Projekts ab Zumindest die kritischen Anwendungsf lle sollten hierf r einbezogen werden da sie typischerweise die gr ten technischen Risiken aufwerfen Ein evolution rer Prototyp d h einer der schrittweise ausgebaut wird kann durchaus verwendet werden Man sollte jedoch auch einige explorative Wegwerfprototypen in Erw gung ziehen um spezifische Risiken wie z B Entwurfs oder Anforderungskompromisse auszuloten Sie dienen auch als Machbarkeitsstudien und Demonstrationen RUP Elaborationsphase Elaboration Fortsetzung o berarbeitete Liste der Risiken und berarbeiteter Business Case o Plan f r das gesamte Projekt sowie grober Plan f r die Iterationen und Meilensteine o ein vorl ufiges Benutzerhandbuch optional Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 141 395 RUP Elaborationsphase Elaboration Fortsetzung Softwaretechnik Entwicklungsprozesse berarbeitete Liste der Risiken und berarbeiteter Business Case Rat io na U n ified P rocess Blan das see Projekt sowie
117. nit that implements a set of responsibilities Component and connector viewpoints express runtime behavior described in terms of components and connectors A component is one of the principal processing units of the executing system a connector is an interaction mechanism for the components Allocation viewpoints describe mappings of software units to elements of the environment the hardware the file systems or the development team Architekturbegriffe im Kontext IEEE P1471 2002 Mission fulfills 1 influences has an Environment System Architecture inhabits has 4 described by 1 is addressed to i ifi Stakeholder entifies 1 d is important to 1 identifies has 1 1 Pe Concern used to cov Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 227 395 Methode von Hofmeister u a 2000 Einflussfaktoren identifizieren o Produktfunktionen und attribute o technologische Faktoren o organisatorische Faktoren konkurrierende Faktoren feststellen Kompromisse f r Faktorenkonflikte durch Strategien finden iterativer Entwurf der verschiedenen Sichten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 228 395 Software Architektur Zusammenfassung aus dem Software Projekt Hofmeister Methode und Blickwinkel
118. of the following two items Retrieve used terminology Get a description of this taxonomy e Reengineering in General o Reengineering Collections o Introductions to Reengineering o Fundamentals o The Pros and Cons and Risks of Reengineering o Experiences o Costs o Process Models o Management o Legality o Interoperability o Business Reengineering Software Reverse Engineering o General Information on Reverse Engineering o Reverse Engineering Collections o Cognitive Processes in Human Program Understanding o Software Evolution o Extracting Business Rules o Intermediate Representations of Source Code Use of data bases Using graphs o Preventive Measures o Formal Methods o Reverse Specification Model Generatin Software Animation Visualization of Parallel and Distributed Programs morm z J Keen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 12 395 Online Bibliographie Suche nach Eigenschaften ua aan ui aiaiai Bibliography Search Mozilla ciii Eile Edit View Go Bookmarks Tools Window Help Q 6 amp http www iste uni stuttgart de ps reengineering simple search html a amp Home Bookmarks S The Mozilla Org Latest Builds Home Next Regular Expressions Search for References Fill out this form you can leave out fields press the button below and you will receive all the references that contain the regular
119. oftwaretechnik Sommersemester 2006 90 395 COCOMO II Unterscheidung nach Phasen Boehm u a 2000 o Fr he Prototypenstufe Fr he Entwurfsstufe o Stufe nach Architekturentwurf Sp tere Sch tzung h here Genauigkeit Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 91 395 COCOMO II Early prototyping level Eingaben Object Points OP Produktivit t PROD Erfahrung F higkeiten der Entwickler o Reife F higkeiten der CASE Tools 0O PROD NOP Monat 4 7 13 25 50 Wiederverwendungsanteil reuse in Prozent Abgeleitete Gr en New Object Points NOP ber cksichtigen Wiederverwendung NOP OP 100 reuse 100 Aufwand in Personenmonaten PM NOP PROD Unterst tzt Prototypen Wiederverwendung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 92 395 COCOMO II Early design level o Sch tzung basiert auf Function Points LOCs werden daraus abgeleitet Personenmonate PMys A KLOC EM PM bei nominalem Zeitplan A 2 94 in initialer Kalibrierung o Exponent E o 5 Faktoren w f r Exponent E 5 sehr klein 0 sehr gro Erfahrung mit Dom ne Flexibilit t des Entwicklungsprozesses Risikomanagement Teamzusammenhalt Prozessreife E B w 100 mit B 1 01 o Effort Multiplier EM o 7 lineare Einflussfaktoren 6 Stufen Standard 1 00 in Tabelle nachschlagen Produktg te und komplexit t
120. olgende Szenario Welches Vorgehensmodell empfehlen Sie o Unter welchen Umst nden w rden Sie eher agiles Vorgehen als voraus planendes empfehlen o Stellen Sie das Capability Maturity Model dar Wozu dient es o Wie k nnen Prozesse verbessert werden o Was ist der pers nliche Software Entwicklungsprozess Wozu dient u Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 173 395 Weiterf hrende Literatur Bibliographie zu Entwicklungsprozessen Arbeitskreis der Fachgruppe 5 11 Begriffe und Konzepte der Vorgehensmodellierung http www vorgehensmodelle de giak arbeitskreise vorgehensmodelle publallg html Rational Unified Process Kruchten 1998 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 174 395 Komponentenbasierte Entwicklung Komponentenbasierte Entwicklung Lernziele Komponente Komponentenbasierte Entwicklung Komponentenmodelle Schnittstellen Beschaffung und Entstehung Herstellung Implementierungsaspekte Architektur Mismatch Wiederholungsfragen 060 8 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 175 395 Lernziele Benutzung von Komponenten Komponentenbasierte Entwicklung Komponentenmodelle Schnittstellen Komponenten Zusammenbau oo Erschaffung von Komponenten o Herstellung o Implementierungsaspekte Rainer Koschke Uni Bremen Softwaretechnik Somm
121. om Monitor zur Laufzeit beobachtet o Permanente Schnittstelle Teil der normalen Schnittstelle o Tempor re Schnittstelle nur beim Monitoring pr sent Ausgabeanweisungen im Code f rs Tracing Code Instrumentierung Makros aspektorientiertes Programmieren etc Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 259 395 Kosten von Evaluationen Erfahrungen bei AT amp T o ca 300 Architekur Reviews durchgef hrt o f r Projekte mit mindestens 700 PT Aufwand durchschnittlich 70 PT f r Evaluation Erfahrungen des SEls o 36 PT f r ATAM Evaluation nur Evaluations Team dazu noch andere Projektteilnehmer und Entscheider Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 261 395 Vorteile einer fr hen Evaluation o fr he Erkennung von Fehlern je fr her ein Fehler entdeckt wird desto billiger ist seine Beseitigung 10 Kosteneinsparung bei AT amp T Zwang zur Dokumentation der Architektur o Zwang zum Festhalten der Begr ndungen von Entwurfsentscheidungen o weitere berpr fung der Anforderungen o Verbesserung von Architekturen durch Erfahrungen die man in den Evaluationen sammelt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 262 395 Techniken zur Evaluation von Software Architektur o Fragetechniken o Frageb gen und Checklisten o Architecture Tradeoff Analysis Method ATAM o Cost Benefit Analysis Method CBAM o Messtechnik
122. omponenten betreffend Annahmen von Komponenten ber o ihre Infrastruktur die zur Verf gung gestellt werden soll bzw vorausgesetzt wird o Komponenten stellten vieles zur Verf gung was gar nicht gebraucht wurde exzessiver Code o das Kontrollmodell wer steuert den Kontrollfluss o jede Komponente nahm an dass sie die Hauptkontrollschleife darstelle aufw ndige Restrukturierung notwendig o das Datenmodell Art und Weise wie die Umgebung Daten manipuliert die von der Komponente verwaltet werden o hierarchische Datenstruktur erlaubte nderung der Teile nur ber das Ganze f r Anwendung zu unflexibel teilweise Neuimplementierung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 213 395 Konnektoren betreffend Annahmen von Konnektoren ber o Protokoll Interaktionsmuster o Semantik des synchronen Aufrufs passte nicht Ausweichung auf RPC des Betriebssystems hierf r o Datenmodell Art der Daten die kommuniziert werden o RPC des Betriebssystems nahm an C Datenstrukturen zu transportieren o wiederzuverwendenendes Event Broadcast System nahm an ASCII zu transportieren Konvertierungsroutinen wurden notwendig Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 214 395 Architekturkonfiguration betreffend Annahmen ber Architekturkonfiguration o Topologie der Systemkommunikation o Datenbank nahm an dass verbundene Tools nicht kooperieren wollen und blockierte
123. onsdateien Parameterwerte w hrend des Systemstarts Polymorphismus sp tes Binden von Methoden Austausch von Komponenten w hrend der Ladezeit Einhaltung von Protokollen Laufzeit Bindung unabh ngiger Prozesse Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 256 395 Taktiken f r Testbarkeit Testbarkeit Behandlung von Interes Eingabe Ausgabe Monitoring e Aufnahme e Eingebauter Wiedergabe Monitor Trennung von Schnittstelle und Imple mentierung e Spezialisierung von Schnitt stellen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 257 395 Behandlung von Eingabe und Ausgabe Aufnahme Wiedergabe o Information die Schnittstelle passiert wird vermerkt o kann sp ter f r Regressionstest benutzt werden Trennung von Schnittstelle und Implementierung o erm glicht Substitution der Implementierung f rs Testen o Testst mpfe k nnen vorausgesetzte Komponenten simulieren o Testtreiber simulieren Verwender Spezialisierung von Zugriffspfaden Schnittstellen o Spezialisierte Schnittstelle erlaubt Aufzeichnung und Manipulation von Attributen einer Komponente durch einen Testrahmen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 258 395 Internes Monitoring Eingebauter Monitor Zustand und andere Attribute Performanz Belastung Load Sicherheit etc werden durch Schnittstelle zur Verf gung gestellt o wird ber Schnittstelle v
124. oschke Uni Bremen Softwaretechnik Sommersemester 2006 123 395 Testgetriebene Entwicklung Sneed 2004 Testf lle treiben die Kodierung o vor Implementierung einer Klasse werden erst Testtreiber entwickelt o Testtreiber enth lt mindestens einen Test f r jede nichttriviale Methode o Testfall hilft die richtige Schnittstelle zu definieren o Testfall zwingt Entwickler ber das zu erwartende Resultat nachzudenken o Testf lle spezifizieren die Methoden zumindest partiell Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 124 395 Testgetriebene Entwicklung Sneed 2004 Tester treiben die Entwicklung o Tester sind verantwortlich f r die Auslieferung des Produkts o Tester legen Kriterien f r die Auslieferbarkeit fest o Entwickler sind Lieferanten f r die Tester o Softwareentwicklung ist eine Versorgungskette das Ende zieht anstatt gedr ckt zu werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 125 395 Bewusstseinsebenen bewusstes Wissen 20 30 o Wissen ber das man sich im Klaren ist oder das in seiner vollen Bedeutung klar erkannt wird o unbewusstes Wissen lt 40 o Wissen das sich dem Bewusstsein im Moment nicht darbietet aber dennoch handlungsbestimmend ist und potenziell aufgerufen werden kann o unterbewusstes Wissen o unbekannte W nsche die erst von au en herangetragen werden m ssen um als Anforderungen erkannt zu werden Rainer
125. ositories das Daten konvertiert o Diensten Signaturen m ssen bereinstimmen Muster Facade Mediator Strategy Proxy Factory o Semantik von o Daten konsistente Annahmen ber Semantik der Daten o Diensten konsistente Annahmen ber Semantik der Dienste semantischer Konverter o Reihenfolge von o Daten konsistente Annahme ber Reihenfolge o Kontrolle D muss vor V ausgef hrt sein in bestimmter Zeit Puffer mit Ver nderung der Reihenfolge Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 254 395 Verwendung eines Mittelsmanns II o Identit t der Schnittstelle von D falls es mehrere gibt Broker Muster Ort von D zur Laufzeit z B gleicher Prozessor Name Server o Quality of Service Data von D schwer zu berbr cken o Existenz von D Factory Muster o Ressourcenverhalten von D Resourcen Manager als Mittelsmann Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 255 395 2006 07 19 2006 07 19 Verwendung eines Mittelsmanns II Softwaretechnik o Identit t der Schnittstelle von D falls es mehrere gibt Software Architektur ee x Ort von D zur Laufzeit z B gleicher Prozessor Taktiken Verwendung eines Mittelsmanns II o Ressourcenverhalten von D Resourcen Manager als Mittelsmann Beispiele e Syntax von Daten die Sequenz von Bytes Big vs Little Endian Diensten Anzah
126. protected Singleton kann von au erhalb nicht benutzt werden private static Hashtable lt String Singleton gt registry new Hashtable lt String Singleton gt Registry f r alle Instanzen von Singleton und Unterklassen protected static String ClassKey return Singleton eindeutiger Schl ssel der Klasse muss von Unterklasse redefiniert werden oO AN Do A UU NI u N e O liefert einzige Instanz public synchronized static Singleton getlnstance return registry get ClassKey u a a PP WO muss vor Benutzung aufgerufen werden registriert Instanz muss von Unterklasse redefiniert werden public static void Init 19 fregistry put ClassKey new Singleton bo Fr oO N O Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 319 395 Spezialisierung von Singletons public class DerivedSingleton extends Singleton protected DerivedSingleton return DerivedSingleton public static void Init 1 2 3 4 5 protected static String ClassKey 6 7 8 9 registry put ClassKey new DerivedSingleton LO ni Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 320 395 Problem o eine vorhandene wiederverwendbare Komponente hat nicht die passende Schnittstelle o und der Code der Komponente kann nicht ver ndert werden use Shape 3 TextView
127. r sein soll o Beispiele o zentrales Protokoll Objekt das Ausgaben in eine Datei schreibt o Druckauftr ge die zu einem Drucker gesendet werden sollten nur in einen einzigen Puffer geschrieben werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 315 395 Entwurfsmuster Singleton Einzelst ck L sung Muster f r das Erzeugen von Instanzen Singleton static Singleton Fass static instance Singleton static Singleton getInstance Rainer Koschke Uni Bremen Softwaretechnik Code public final class Singleton private static Singleton instance speichert einzige Instanz 1 2 3 4 5 6 private Singleton 7 8 9 liefert einzige Instanz Rainer Koschke Uni Bremen Softwaretechnik ho public synchronized static Singleton Sommersemester 2006 kann von au erhalb nicht benutzt werden getInstance 11 if instance null lazy instantiation 12 instance new Singleton 13 14 return instance Sommersemester 2006 316 395 317 395 Konsequenzen Singleton hat strikte Kontrolle ber wie und wann Klienten es verwenden vermeidet globale Variablen o leicht erweiterbar um mehrere Instanzen zuzulassen Singleton kann spezialisiert werden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 318 395 Spezialisierung von Singletons public class Singleton
128. rcentile rank is the proportion of scores in a distribution that a specific score is greater than or equal to For instance if you received a score of 95 on a math test and this score was greater than or equal to the scores of 88 of the students taking the test then your percentile rank would be 88 You would be in the 88th percentile Effort Multiplier PREX Personnel Experience AEXP Applications experience PLEX Platform experience LTEX Language tool experience Grad very low low nominal high very high Punkte 1 2 PREX AEXP lt 2 Mo 6 Mo PLEX lt 2 Mo 6 Mo LTEX lt 2 Mo 6 Mo gt Punkte 3 4 5 6 7 8 Ile Ile Ile EMprex 1 59 1 33 1 22 Rainer Koschke Uni Bremen Softwaretechnik 14 15 0 62 Sommersemester 2006 99 395 Effort Multiplier FCIL Facilities TOOL Use of Software Tools SITE Multisite Development Grad very low low nominal high very high Punkte ie 3 4 5 6 FCIL TOOL 1 2 3 4 5 n chste Folie SITE 1 2 3 4 5 6 n chste Folie 5 Punkte 2 3 4 5 6 7 8 9 10 11 EMeci 1 43 1 30 1 10 1 00 0 87 0 73 0 62 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 100 395 TOOL und SITE TOOL Editor Compiler Debugger einfaches CASE Werkzeug schlechte Integration Basis Life Cycle Tools moderat integriert weitergehende reife Life Cycle Tools moderat integriert weitergehende proaktive Life Cycle Tools gut integriert mit
129. retechnik Sommersemester 2006 343 395 Schl sselkonzepte Use ofacore asset base in production of a related set of products RR 4 t3 J L Nat Wd So seo cur soa Plan scope Minton Quelle Linda Northrop SEI Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 344 395 Kostenaspekte einer Software Produktlinie o Marktanalyse muss eine Familie von Produkten betrachten Projektplan muss generisch oder erweiterbar sein um Variationen zu erlauben o Architektur muss Variation unterst tzen o Software Komponenten m ssen generischer sein ohne an Performanz einzub en m ssen Variation unterst tzen o Testpl ne f lle daten m ssen Variationen und mehrere Instanzen einer Produktlinie ber cksichtigen o Entwickler ben tigen Training in den Assets und Verfahren der Produktlinie Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 345 395 Return on Investment Current Practice Cumulative With Product Line Approach Cost Number of Products Quelle Weiss und Lai 1999 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 346 395 Zusammenspielende Komponenten Organizational SUCE ana personnel Development approach Management Quelle Linda Northrop SEI Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 347 395 y me Core Asset Management Develop
130. ribute Bsp Backup Datenbank soll verwendet werden negativer Einfluss auch auf Performanz wegen zus tzlichen Ressourcenbedarfs Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 277 395 Risiken Nichtrisiken Definition Risiko Entwurfsentscheidung mit potentiell unerw nschten Konsequenzen f r die Qualit tsattribute Nichtrisiko Entwurfsentscheidung die nach Analyse keine unerw nschten Konsequenzen f r die Qualit tsattribute hat Bsp Backup Datenbank soll verwendet werden positiver Einfluss auf Zuverl ssigkeit negativer Einfluss auch auf Performanz Wird zum Risiko erst wenn Performanz von gro er Bedeutung ist Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 278 395 Resultate von ATAM Forts Erw nschte Nebeneffekte o bessere Architekturbeschreibung Gemeinschaftsgef hl aller Beteiligter bessere und offenere Kommunikation aller Beteiligter besseres Verst ndnis der jeweiligen Anliegen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 279 395 Prozessphasen Aktivit t Teilnehmer Dauer Vorbereitung Leiter des Evaluationsteams informell ber ein Schl sselentscheider paar Wochen Evaluation Teil Evaluationsteam Architekt 1 Tag gefolgt von und Entscheider einer Pause von 2 3 Wochen Evaluation Teil II Evaluationsteam Architekt 2 Tage Entscheider Stakeholders Wiedervorlage Evaluationstea
131. roduct Attributes RELY Required reliability 0 82 0 92 1 00 1 10 1 26 DATA Data base size 0 90 1 00 1 14 1 28 CPLX Product Complexity 0 73 0 87 1 00 1 17 1 34 RUSE Required Reusability 0 95 1 00 1 07 1 15 DOCU Doc match to 0 81 0 91 1 00 1 11 1 23 life cycle needs Computer Attributes TIME Execution time constr 1 00 1 11 1 29 STOR Main storage constr 1 00 1 05 1 17 PVOL Platform volatility 0 87 1 00 1 15 1 30 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 107 395 1 74 1 24 1 63 1 46 108 395 Einflussfaktoren Cost Drivers f r Cocomo 2 O Se TFET Personell attributes ACAP Analyst capability 1 42 1 19 1 00 0 85 0 71 PCAP Programmer capability 1 34 1 15 1 00 0 88 0 76 AEXP Applications experience 1 22 1 10 1 00 0 88 0 81 PLEX Platform experience 1 19 1 09 1 00 0 91 0 85 LTEX Language tool exp 1 20 1 09 1 00 0 91 0 84 Project attributes TOOL Use of software tools 1 17 1 09 1 00 0 90 0 78 SITE Multisite development 1 22 1 09 1 00 0 93 0 86 0 80 SCED Required dev schedule 1 43 1 14 1 00 1 00 1 00 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 109 395 Zusammenfassung o alle Sch tzungen basieren auf Erfahrung kontinuierlich sch tzen o verschiedene Techniken anwenden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 110 395 Wiederholungs und Vertiefungsfragen o Welche M gli
132. rsemester 2006 388 395 Empirische Softwaretechnik Wiederholungsfragen 6 Bass u a 2003 Bass Len CLEMENTS Paul KAZMAN Rick Software Architecture in Practice 2nd ed Addison Wesley 2003 7 Beck 2000 BECK Kent Extreme Programming Explained Addison Wesley 2000 The XP Series ISBN 201 61641 6 8 Boehm 1981 BoOEHM B Software Engineering Economics Prentice Hall 1981 9 Boehm und Turner 2003 BOEHM B TURNER R Using risk to balance agile and plan driven methods In IEEE Computer 36 2003 Juni Nr 6 S 57 66 0 Boehm u a 1995 BOEHM Barry CLARK Bradford HOROWITZ Ellis MADACHY Ray SHELBY Richard WESTLAND Chris Cost Models for Future Software Life Cycle Processes COCOMO 2 0 In Annals of Software Engineering 1995 1 Boehm 1979 BoOEHM Barry W Guidelines for verifying and validating software requirements and design specification In EURO IFIP 79 1979 S 711 719 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 389 395 Empirische Softwaretechnik Wiederholungsfragen 2 Boehm 1988 BoEHM Barry W A spiral model of software development and enhancement In IEEE Computer 21 1988 Mai Nr 5 S 61 72 3 Boehm u a 2000 BoEHM Barry W ABTS Chris BROWN A W CHULANI Sunita CLARK Bradford K HOROWITZ Ellis MADACHY Ray REIFER Donald STEECE Bert Software Cost Estimation with COCOMO II Prentice Hall 2000 4 Buschmann u a 1996 BUSCHMAN
133. s Messens Messen k nnen Sie vieles aber das Angemessene erkennen k nnen Sie nicht Hans Gadamer 2006 07 19 Messen spielt in allen Ingenieurswissenschaften eine wichtige Rolle Galilei Ziel der Wissenschaft durch Messung zu verst ndlicheren und nachpr fbaren Konzepten Ergebnissen kommen Definitionen Ma Messen Metrik Definition Ma Abbildung von einem beobachteten empirischen Beziehungssystem auf ein numerisches Beziehungssystem Abbildung von Eigenschaften von Objekten der realen Welt auf Zahlen oder Symbole Definition Messen Anwendung eines Ma es auf ein Objekt Definition Metrik AbstandsmaB math Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 20 395 Definitionen f r Software Metriken A quantitative measure of the degree to which a system component or process possesses a given variable IEEE Standard Glossary A software metric is any type of measurement which relates to a software system process or related documentation lan Summerville Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 21 395 Messen und Softwaretechnik o Beschreibung kompakt und objektiv o Beurteilung Vergleich Verbesserungen Vorhersage geordnete Planung Verbesserungen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 22 395 Fragen bei Ma en Wor ber wir uns bei der Definition von Metriken Gedanken mach
134. sche statistische Tests Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 386 395 Wiederholungsfragen Welche Arten der Untersuchungsmethoden stehen zur Verf gung Nennen Sie deren Vor und Nachteile o Wozu muss man sich bei kontrollierten Experimenten jeweils Gedanken machen o Sie sollen Methode M bzw Werkzeug W bewerten Wie gehen Sie vor Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 387 395 Empirische Softwaretechnik Wiederholungsfragen 1 Albrecht 1979 ALBRECHT Alan Measuring application development productivity Monterey CA USA 1979 2 Balzert 1997 _ BALZERT Helmut Lehrbuch der Software Technik Spektrum Akademischer Verlag 1997 ISBN 3827400651 3 Banker u a 1991 BANKER R KAUFFMANN R KUMAR R An Empirical Test of Object Based Output Measurement Metrics in a Computer Aided Software Engineering CASE Environment In Journal of Management Information Systems 8 1991 Nr 3 S 127 150 4 Basili und Weiss 1984 Bas n R WEISS D M A Methodology for Collecting Valid Software Engineering Data In JEEE Transactions on Software Engineering 10 1984 November Nr 6 S 728 738 5 Basili und Turner 1975 Bas L V TURNER J Iterative Enhancement A Practical Technique for Software Development In IEEE Transactions on Software Engineering 1 1975 Dezember Nr 4 S 390 396 Rainer Koschke Uni Bremen Softwaretechnik Somme
135. smodell im eigentlichen Sinn Die Produkte im V Modell werden wie im Wasserfallmodell streng sequenziell erstellt Es fiigt dem Wasserfallmodell lediglich eine zusatzliche strukturelle Sicht hinzu n mlich dass f r jedes zu erstellende Dokument ein entsprechender Test existieren und durchgef hrt werden soll Das V Modell sieht sowohl Verifikationen als auch Validierungen vor Validierung Es wird das richtige Produkt erstellt Verifikation Das Produkt wird richtig erstellt Eine weitere Konsequenz des V Modells f r die konkrete Projektplanung ist dass man die Test und Validierungsaktivit ten fr her als die tats chliche Durchf hrung der Aktivit t vorbereiten kann Beispielsweise kann der Akzeptanztest vorbereitet werden sobald man die Anforderungen kennt Auf diese Weise k nnen Aktivit ten bei einem Projektteam parallelisiert werden Der Tester kann Testf lle f r den Akzeptanztest entwickeln auch wenn noch keine Implementierung existiert V Modell von Boehm 1979 Eigenschaften o entspricht Wasserfallmodell betont Qualit tssicherung fr he Vorbereitung von Validierung und Verifikation o zus tzliche Parallelisierung o Fehler M ngel werden fr her entdeckt alle sonstigen Nachteile des Wasserfallmodells Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 119 395 Testgetriebene Entwicklung Sneed 2004 Kennzeichen testgetriebener Entwicklung Testf lle o werden fr h aus Anwen
136. st of the program Effort Multiplier PDIF Platform Difficulty TIME STOR PVOL Grad Punkte PDIF TIME STORE PVOL Execution time constraints Main storage constraints Platform volatility low nominal high very high extra high 2 3 4 5 6 lt 50 lt 65 lt 80 lt 90 lt 50 lt 65 lt 80 lt 90 very stable stable somewhat volatile volatile gt Punkte 8 9 10 12 13 15 16 17 0 87 1 00 1 29 1 81 2 61 EMpo r Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 97 395 Effort Multiplier PERS Personnel Capability ACAP Analyst capability gemessen als Perzentil PCAP Programmer capability gemessen als Perzentil PCON Personnel continuity gemessen durch Personalfluktuation Grad very low low nominal high very high Punkte 1 2 3 4 5 PERS ACAP 15 35 55 75 90 PCAP 15 35 55 75 90 PCON 48 24 12 6 3 5 Punkte 3 4 5 6 1 8 9 10 11 1213 14 15 EMpers 2 12 1 62 1 26 1 00 0 83 0 63 0 50 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 98 395 Softwaretechnik 2006 07 19 L cocomo rar Multiplier PERS Personnel Capability Kosten und Aufwandssch tzung Effort Multiplier PERS Personnel Capability ACAP An PCAP Progr PCON Persor Perzenti Perzentil ni rch Personalfluktuation 15 35 55 75 15 35 55 75 90 48 24 12 6 3 E Punkte 3 4 56 78 9 1011 1213 1415 EMpers 212 1 62 126 100 083 063 050 A pe
137. ster Architekturen f r Teilsystem Frameworks o Gesamtsystem Systemarchitekturen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 181 395 Ma gefertigt vs Standardsoftware Ma anfertigung o optimale Anpassung an Kunde Wettbewerbsvorteil keine nderung der Kundenprozesse notwendig o unter lokaler Kontrolle Standardsoftware o billiger o schneller einsetzbar o geringeres Risiko des Scheiterns o Wartung und Evolutionsanpassung durch den Hersteller o leichtere Zusammenarbeit mit anderen Systemen Vorteile von beiden Ans tzen Ma anfertigung aus Standardkomponenten Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 182 395 Integration o Problem o Komponenten kommen aus verschiedenen Quellen o Einbau der Komponenten von Dritten o Fehlereingrenzung schwierig o keine klassischen Integrationstests da sp te Integration o System nur so stark wie schw chste Komponente o eine L sung defensives Programmieren Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 183 395 Vor und Nachteile Vorteile o verbesserte Qualit t o Wiederverwendung verringert die Dauer bis zur Auslieferung Modularisierung nur lokale nderungen Abh ngigkeiten explizit Austauschbarkeit durch Abstraktion Schnittstellen Markt innovative Produkte niedriger Preis Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 200
138. t Keine Downtime Betrieb Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 235 395 Softwa retec h n i k Gun ti z Fa a Anforderung hinsichtlich Software Architektur I Qualit t von Software Architekturen Re oO oO N Beispiel f r Verf gbarkeit Erkennung von Fehlern mit Ausnahmebehandlung f r volle Fehlertoleranz Kategorien von Software Architektur Qualit ten o Systemqualit ten Verf gbarkeit nderbarkeit Performanz Sicherheit Testbarkeit Gebrauchstauglichkeit etc o Gesch ftsqualit ten z B Time To Market o Qualit ten der Architektur selbst z B konzeptionelle Integrit t die indirekt die anderen Qualit ten beeinflussen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 236 395 Performanz Allgemeine Szenarien Quelle intern extern Stimulus periodische sporadisch stochastische Ereignisse Artefakt System Umgebung Normalbetrieb ausgelastet Reaktion Bearbeitung von Stimuli nderung von Service Levels Ma Latenz Deadline Durchsatz Versatz Versaumnisrate Da tenverlust Spezielles Szenario O Stimulus initiierte Transaktion Stimulusquelle Benutzer Rainer Koschke Uni Bremen Artefakt System Reaktion Transaktion ist Umgebung bearbeitet Reaktionsmessung Normaler Latenz von 2 sek Betrieb Softwaretechnik Sommersemester 2006 237 395 Performanz Softwaretechnik Software Arc
139. t anderen Komponenten o durch Ableiten Arten o Implementierungsvererbung o Schnittstellenvererbung Zusage der Austauschbarkeit Mehrfachvererbung o Schnittstellenvererbung kein Problem o Implementierungsvererbung problematisch Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 206 395 Zerbrechliche Basisklassen Basisklasse wird ge ndert sind erbende Klassen immer noch funktionsf hig o unvorhergesehene Aufrufgraphen unerwarteter Wiedereintritt o notwendig ist Schnittstellenvertrag zwischen Klasse und erbenden Klassen o L sungen Schutz public protected private finale override disjunkte Gruppen von Methoden und Variablen alle Instanzvariablen sind privat und die erbende Klasse f gt keine hinzu Ableiten der Klasse verbieten oo Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 207 395 Aufrufe zwischen Komponenten in verteilten Systemen Idee des lokalen Aufrufes bleibt erhalten Generierung von Stubs Aktionen des Aufrufers bei Aufruf Kontrolle geht an Stub Marshalling Serialisierung bertragung der Parameter Ausf hren auf dem Ziel bertragung des Ergebnisses Ausnahme Unmarshalling R ckgabe an den Aufrufer eo8e66006 Optimierung f r lokalen Fall Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 208 395 Wiedereintritt o Wiedereintritt als Problem o Vorkommen Callb
140. ten o Systemattribute wie Performanz k nnen vorausgesagt werden o hohe Kundenzufriedenheit Hardware Software Kostenverh ltnis ver nderte sich von 35 65 zu 80 20 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 340 395 Erfolgsgeschichten Nokia Produktlinie mit 25 30 neuen Produkten pro Jahr Produkt bergreifend gibt es o unterschiedliche Anzahlen von Tasten o unterschiedliche Display Gr en o andere unterschiedliche Produktfunktionen o 58 verschiedene unterst tzte Sprachen o 130 bediente L nder Kompatibilit t mit fr heren Produkten o konfigurierbare Produktfunktionen o nderung der Ger te nach Auslieferung Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 341 395 Software Produktlinie Definition A software product line is a set of software intensive systems o sharing a common managed set of features that satisfy the specific needs of a particular market segment or mission o and that are developed from a common set of core assets in a prescribed way Clements und Northrop 2001 Softwaretechnik Sommersemester 2006 342 395 Ubersicht tiber Produktlinien pertain to Market strategy Application domain is satisfied m Architecture used to structure CORE Product lines e take economic advantage of commonality e bound variability _Sharean _ _ _ an EHAA are built from Quelle Linda Northrop SEI Softwa
141. ttonPressed Button mybutton int main attach amp mybutton amp YesButtonPressed Ot event_loop Rainer Koschke Uni Bremen ts ar Va void NoButtonPressed void yesButtonPressed N Softwaretechnik Softwaretechnik Sommersemester 2006 Sommersemester 2006 324 395 325 395 13 L sung in C Mech typedef void Callb anismus ack typedef struct Button Callback execute int x int y Button void attach Button void event_loop xb Callback execute b gt execute execute widgets i gt execute Rainer Koschke Uni Bremen L sung mit OOP Softwaretechnik Sommersemester 2006 326 395 Command Execute ConcreteCommand Client Invoker M belongs to Receiver receiver Action S state instantiates P Rainer Koschke Uni Bremen Execute receiver Action Softwaretechnik Sommersemester 2006 327 395 L sung mit OOP new Command r Le Se ee a en gt StoreCommand c gt Execute Action 0 lt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 328 395 Konsequenzen o Entkopplung von Objekt das Operation aufruft von dem welches wei wie man es ausf hrt o Kommandos sind selbst Objekte und k nnen als solche verwendet werd
142. tur vor o technische Randbedingungen Betriebssystem Hardware Middleware andere verbundene Systeme etc o Architekturans tze Stile und Muster o Struktur der Pr sentation o Darstellung der verschiedenen Sichten z B Siemens Sichten o prinzipielle Entwurfsentscheidungen Muster Taktiken Integration von COTS Komponenten o Verfolgung von 1 3 der wichtigsten Anwendungsf lle o Verfolgung von 1 3 der wichtigsten nderungsszenarien o Risiken Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 285 395 Prozessphase Evaluation Teil Architekturans tze werden identifiziert o Muster und Taktiken werden vom Team identifiziert o und vom Protokollanten f r alle sichtbar festgehalten o erlauben sp tere Analyse bekannte Vor und Nachteile z B o Schichtenarchitektur positiv f r Portierbarkeit negativ f r Performanz Daten Repository erm glicht Skalierbarkeit Abh ngigkeiten schwerer zu durchschauen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 287 395 Prozessphase Evaluation Teil N tzlichkeitsbaum f r Qualtitatsattribute wird erstellt Szenarien werden priorisiert N tzlichkeit nderbarkeit Performanz Testbarkeit Sicherheit Transaktions Datenlatenz ee A Speicherlatenz f r 20 Video Frames Kundendatenbank pro Sekunde unter 20ms in Echtzeit Stimulus _ Artefakt Reaktion Prozess Stimulusquelle Umgebu
143. twaretechnik Kosten und Aufwandsschatzung re ae ee inne ieee Cini ak ee Function Points a Eingabe Lastenheft l Entwicklun Fu nction Point Methode s EET Albrecht 1979 IBM Heute zahlreiche Varianten O IFPUG Int l Function Point User Group N http www ifpug com fpafund htm FAQ http ourworld compuserve com homepages softcomp fpfaq htm Function Point Methode Vorgehen Z hltyp festlegen Neu Weiterentwicklung bestehendes System Systemgrenzen festlegen Identifizieren der Funktionstypen Bewerten der Komplexit t der Funktionstypen Ermittlung der gewichteten Function Points Ermittlung des Aufwands Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 60 395 FP Identifizieren von Funktionstypen Systemgrenze A EQ l EQ q4 1 gt Ts l l interne Daten I I externe Daten Transaktions Funktionstypen o Eingaben El External Input Eingabe f r ILF o Ausgaben EO External Output Ausgabe abgeleiteter Daten o Abfragen EQ External Inquiry Eingabe Anfrage Ausgabe Daten Daten Funktionstypen o Interner Datenbestand ILF Internal Logical File o Externer Datenbestand ELF External Logical File Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 61 395 FP Identifizieren von Funktionstypen Schl sselw rter geben Hinweise o El ablegen speichern de aktiv
144. utionalizing Requirements Engineering Scoping Market Analysis Software System Integration Testing Understanding Relevant Domains Technical Planning Technical Risk Management Tool Support Operations Organizational Planning Organizational Risk Management Structuring the Organization Technology Forecasting Training Software Technical Organizational Engineering Management Management Practice Areas Quelle Linda Northrop SEI Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 352 395 Einf hrung von Produktlinien Proaktiv o definiere zuerst Scope was geh rt zur Produktlinie o Scope leitet die weitere Entwicklung Entwickle zuerst Core Assets Produkte k nnen rasch entwickelt werden sobald die Produktlinie steht hohe Vorausleistung und Vorhersagef higkeit verlangt Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 353 395 Einf hrung von Produktlinien Il Reaktiv Beginne mit einem oder mehreren Produkten o Extrahiere daraus Core Assets f r die Produktlinie o Scope entwickelt sich dabei stetig niedrige Einstiegskosten gr erer Einfluss von Erfahrung Architektur k nnte suboptimal sein wird schrittweise weiterentwickelt Restrukturierungsaufwand notwendig Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 354 395 Einf hrung von Produktlinien III Inkrementell sowohl bei reaktiver als auch proaktiver Entwicklung
145. von und CoCoMo Bei der Darstellung von Function Points und CoCoMo interessieren nicht die absoluten Zahlen aber sehr wohl der grunds tzliche Aufbau der Formeln Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 112 395 Entwicklungsprozesse Entwicklungsprozesse Lernziele o Wasserfallmodell o V Modell o Testgetriebene Entwicklung o Inkrementelle Entwicklung o Spiralmodell o Rational Unified Process Cleanroom Development o Extreme Programming XP Capability Maturity Model o Pers nlicher Softwareprozess o Wiederholungsfragen o Weiterf hrende Literatur Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 113 395 Lernziele o verschiedene Software Entwicklungsprozessmodelle kennen o Vor und Nachteile Anwendbarkeit abw gen k nnen o die Besonderheit von Prozessen der Software Entwicklung kennen Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 114 395 Entwicklungsprozesse Grundlagen f r guten Prozess o Wohldefiniertheit o sonst Falsch Nicht Mehrarbeit o sonst Information nicht verf gbar oder unverst ndlich o Quantitatives Verstehen o objektive Grundlage f r Verbesserungen o Kontinuierliche nderung o sonst Prozess schnell berholt eo Angemessenheit Prozess muss dem zu l senden Problem angemessen sein o d h effektiv und effizient sein Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 115 395
146. zeit Softwaretechnik Testbarkeit Grad der Einfachheit Fehler in der Software aufzuzeigen Wahrscheinlichkeit unter der Voraussetzung dass die Software mindestens einen Fehler hat dass der n chste Test positiv ausf llt Sommersemester 2006 239 395 Reaktionsmessung in 3 Stunden Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 240 395 Testbarkeit Allgemeine Szenarien Quelle Unit Entwickler Integrator Systemverifizierer Akzeptanz tester Endbenutzer Stimulus Pr fling Analyse Architektur Entwurf Klasse Subsystem erstellt System ausgeliefert Artefakt Teil des Enwurfs oder Codes ganze Applikation Umgebung Entwurfs Entwicklungs bersetzungs Einsatzzeit Reaktion gew hrt Einblick in Zustandswerte und berechnete Werte bereitet Testumgebung vor Ma Abdeckungsgrad Wahrscheinlichkeit eines St rfalls wenn ein Fehler existiert Aufwand f r Test Dauer Vorbereitung der Testumgebung Rainer Koschke Uni Bremen Testbarkeit Spezielles Szenario Stimulus f hrt Unit test durch Stimulusquelle Unit Tester Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 241 395 Artefakt Reaktion Unit Unit hat E Schnittstelle _ Umgebung Verhalten zu Reaktionsmessung Unit steuern und zu 85 Pfadabdeckung beobachten in 3 Stund implementiert In 5 Stunden Softwaretechnik Sommersemest
147. zur Sch tzung kommerzieller Anwendungssysteme angesehen Balzert 1997 Sommersemester 2006 Sinnvoll einsetzbar wenn Erfahrungswerte von vergleichbaren Projekten vorliegen Kemerer 1987 Bewertung der Systemmerkmale subjektiv Symons 1988 Studie mittlere FP Abweichung zwischen 2 Z hlern nur 12 Kemerer und Porter 1992 Z hlen der FPs relativ aufwendig Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 84 395 85 395 Object Points o F r 4GLs Query Languages Report Writers Haben nicht unbedingt mit OOP Objekten zu tun Gewichtete Sch tzung von o Anzahl verschiedener Screens o Anzahl erstellter Reports o Anzahl zu entwickelnder 3GL Module o Vorteil Einfacher und weniger zu sch tzen vergleichbare Pr zision wie Function Point Sch tzung Banker u a 1991 47 des Aufwands f r Function Point Sch tzung Kauffman und Kumar 1993 Rainer Koschke Uni Bremen Softwaretechnik Sommersemester 2006 86 395 Object Points Screens Reports views data tables sections data tables contained lt 4 lt 8 8 contained lt 4 lt 3B8 lt 3 1 1 2 0 1 2 3 7 1 3 2 3 2 3 A 5 Views Menge logisch zusammengehoriger Daten z B Kundenstammdaten Data Tables Server data tables Client data tables Tabellen die abgefragt werden m ssen um Daten zu bestimmen Jede 3GL Komponente 10

Softwaretechnik ¨Uberblick I - FB3 - Uni Bremen

Contents

Download Pdf Manuals

Related Search

Related Contents

Softwaretechnik &uml;Uberblick I - FB3 - Uni Bremen

Contents

Download Pdf Manuals

Related Search

Related Contents

Softwaretechnik ¨Uberblick I - FB3 - Uni Bremen