20

Softwaretechnik SoSe 2016 (Fach) / Riebisch 4 - Wartung und Reengineering (Lektion)

Riebisch 4 - Wartung und Reengineering

Diese Lektion wurde von anduenacurri erstellt.

Lektion lernen

zurück  |  weiter 1 / 1

Anzeige
  • Staged Model (Grafik) Screenshot 2:46 Uhr
  • Begriff: Software-Wartung ● ANSI/IEEE Standard 729-1983:● “Modification of a software product after delivery to correctfaults, to improve performance or other attributes, or to adaptthe product to a changed environment.”● Üblicher Sprachgebrauch:● Änderungen am System nach dessen Auslieferung.● Schließt Anpassungen an neue Anforderungen ein
  • Begriff: Reverse Engineering ● Identifikation der Systemkomponenten und deren Beziehungen. Ziel ist dieBeschreibungen des Systems in einer anderen Form oder auf höheremAbstraktionsniveau.(Chikofsky und Cross II. 1990)● Aktivitäten zum Erhöhen des Verständnisses und Verbesserung vonWartbarkeit, Wiederverwendbarkeit, nach Inbetriebnahme einesProgrammes(Arnold 1993)(siehe auch Screenshot 2:47)
  • Begriff: Recovery, Redokumentation Architektur-Rekonstruktion:(Architectural Recovery,Design Recovery): ReverseEngineering mit dem Ziel, eineBeschreibung der Architekturdes Systems zu erstellen(Müller 1997, Koschke 2003)Redokumentation:Erzeugungeiner semantisch äquivalentenRepräsentation desbetrachteten Objekts(Programm oder Spezifikation)auf demselbenAbstraktionsniveau (Müller1997)ST 2:50
  • Begriff: Restrukturierung, Refactoring Transformation einer Repräsentation in eine andere aufderselben Abstraktionsebene, ohne Änderung derFunktionalität des Systems. (Chikofsky und Cross II.1990)2:51
  • Begriff: Reengineering (Renovation, Reclamation) ● Untersuchung (Reverse Engineering) und Änderung desSystems, um es in neuer Form zu implementieren.(Chikofsky und Cross II. 1990)● Keine Änderung der FunktionalitätErweitertes Reengineering: analysieren / restrukturieren, umdann Funktionalität zu ändern 2:55
  • Refactoring - Definition Refactoring - DefinitionA change made to the internalstructure of software to make iteasier to understand and cheaper tomodify without changing itsobservable behaviour
  • Beschreibe Refactoring näher („A poorly designed system is hard to change“) ● Wartung des Systems● Anpassen an neue technische und fachliche Anforderungen● Änderungen mit hohem Risiko verbunden● Fehler werden eingebaut, Änderungen unvollständig, Strukturzerfällt● Software ist nicht verständlich● Schlechte Codestruktur● Hohe Komplexität● Ziel: Schnelle und einfache Änderungen an der Software● Deshalb: Umstrukturierung des Code!
  • Zuordnung von Qualitätsmerkmalen zu Bewertungskriterien und Bad Smells 3:00
  • Bad Smells: The Bloaters Something that has grown so large that it cannot be effectively handled ● Long Method● Large Class● Primitive Obsession● Long Parameter List● Data ClumpsQualitätsmerkmale:- Wartbarkeit--- Lesbarkeit--- Einfachheit
  • Anzeige
  • Bad Smells: The Object- Orientation Abusers Solution does not fully exploit the possibilities of object-oriented design ● Switch Statements● Temporary Field--- Member variables used onlyoccasionaly● Refused Bequest--- Subclass does not use muchbehaviour of super class● Alternative Classes withDifferent InterfacesQualitätsmerkmale:- Wartbarkeit• Verständlichkeit• Einfachheit• Erweiterbarkeit• Konformität
  • Bad Smells: The Change Preventers Solution hinders changing or further developing the software by tangling and scattering ● Parallel InheritanceHierarchiesDivergent Change● a single class to be modified bymany different changesShotgun Surgery● need to modify many classeswhen making a single changeQualitätsmerkmale:- Wartbarkeit--- Erweiterbarkeit--- Einfachheit--- Verständlichkeit
  • Bad Smells: The Dispensables Something unnecessary that should be removed from the source code● Lazy Class● Data Class● Duplicated Code● Dead Code● Speculative GeneralityQualitätsmerkmale:Wartbarkeit• Einfachheit• Verständlichkeit• Erweiterbarkeit• Testbarkeit
  • Bad Smells: The Couplers Smells representing inapproriate coupling Feature Envy● a method is more heavilycoupled to other classes thanthe one that it is inInappropriate Intimacy● Message ChainsA.getB().getC().getD().getTheNeededData()Middle Man● trying to avoid high coupling withconstant delegation Qualitätsmerkmale:Wartbarkeit• Verständlichkeit• Einfachheit• Erweiterbarkeit• Testbarkeit
  • Ablauf von Refactoring (Grafik Dropbox) 3:06
  • Refactoring-Katalog (lange Liste von Elementen) (Grafik) 3:07
  • Smells im Kontext Beispiel Neid (Feature Envy) Kennzeichen Neid:● Einige (3) fremde Attribute● Verhältnis 0,25 à unterhalb einem Drittel● Daten gehören zu Einigen (1) Klassensiehe v.a.: 3:15
  • Strategy Pattern impliziert Neid 3:17
  • Embedded DSLs - (DSL = Domain Specific Language) Architekturstile:● Methodenketten● Geschachtelte Funktionen-> Ziel: LesbarkeitAber: charakteristische Eigenschaften von Smells:● Methoden-Ketten● Verletzung Law of Demeter● Evtl. Gestreute Kopplung● Evtl. Enge Kopplung
  • APIs weisen Smells auf (grafik) 3:19

zurück  |  weiter 1 / 1