docEine Einführung - Universität Bonn
download 
Plainte Transcription
Eine Einführung - Universität Bonn
Vorlesung „Softwaretechnologie“ Wintersemester te se este 2008 008 ROOTS Kapitel 1 Software Engineering – Eine Einführung Ziele Erklärung der Bedeutung von Software Engineering Erläuterung der Hauptprobleme von SE Motivation der Verwendung objektorientierter Techniken Definition der grundlegenden Konzepte von SE Einführung von Software-Qualitäten Ei füh Einführung von SE SE-Prinzipien Pi i i © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-2 ROOTS Einführung in SE: Themenübersicht Überblick Bedeutung B d t Herausforderungen g mit andern Vergleich Ingenieurswissenschaften Software Engineering – Konzepte Definition der Grundbegriffe Software-Qualitäten Qualitäten V Verschiedene hi d Si Sichten ht W ist Was i t Software S ft Engineering? E i i ? Modellierung g Problemlösung Wissensakquisition Rationale Management Software Engineering g g Prinzipien p 7 Prinzipien Brügge & Dutoit, 2000: „Object-Oriented Software Engineering“, Kapitel 1 © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Ghezzi, 1996: „Software Engineering“ Kapitel 1 Engineering“, 1-3 ROOTS Bedeutung von Software Engineering Software ist allgegenwärtig I Immer mehr h S Systeme t werden d durch d hS Software ft kontrolliert k t lli t Software ist ein wirtschaftlicher Schlüsselfaktor Die Volkswirtschaft aller Industrieländer ist von Software abhängig Die Ausgaben für Software haben einen beträchtlichen Anteil am B tt Bruttosozialprodukt i l d kt aller ll Industrieländer I d t i lä d Software Engineering befasst sich mit Theorien Prozessen Methoden Werkzeugen zur professionellen Softwareentwicklung © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-4 ROOTS Ziele: Software-Kosten und Softwarequalität Softwarekosten übersteigen oft Systemkosten B i i l PC Beispiel: Der Softwarewartung kostet mehr als die Entwicklung Bis zu 80% der Gesamtkosten Schlechte Software schadet mehr als sie nutzt Unzufriedene Benutzer Direkte Schäden Software Engineering g g befasst sich mit kosteneffektiver Software-Entwicklung qualitativ hochwertiger Software © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-5 ROOTS Einige Beispiele: Qualität und Kosten Jahr 1900 - Bug Im Jahre 1992 erhielt Mary eine Einladung einen Kindergarten zu besuchen – im Alter von 104 Jahren! Fehlverhalten Automatisiertes Gepäcksystem am Flughafen von Denver beschädigte Koffer 3,2 Mio. $ über dem Budget, 16 Monate verspäteter Start mit zum größten Teil manuellem System Unnötig komplexe Lösung Das C-17 Transportflugzeug nutzt 19 Onboard-Computer, 80 Mikroprozessoren und 6 Programmiersprachen Es war 500 Mio $ über dem Budget Interface-Missbrauch Wissend, dass es ein System gab, das die Abfahrt des Zuges mit offenen Türen verhinderte, verhinderte fixierte ein Zugführer den Startknopf mit Klebeband in Er fand dies eine Startstellung. besonders clevere Art Als er den Zug verließ um eine klemmende Tür zu schließen, ... sicherzustellen, dass der Zug sofort losfuhr ... fuhr der Zug ohne ihn los als die Tür nicht mehr klemmte klemmte. sobald b ld di die lletzte t t Tü Tür geschlossen war. © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-6 ROOTS Hauptherausforderungen von SE: Komplexität und Änderung Komplexität von Softwaresystemen Viele Funktionen Viele, möglicherweise kollidierende Ziele Viele Komponenten Komplexität der Zusammenstellung Viele Teilnehmer Komplexität der Kommunikation Keine Einzelperson kann ein ganzes System verstehen Dauernde Änderung von Softwaresystemen Software modelliert einen Ausschnitt der „realen Welt“ Die reale Welt ändert sich ((Gesetzgebung, g g, Geschäftsabläufe,, ...)) Der Ausschnitt ändert sich (mehr Funktionalität hinzufügen, Systeme integrieren, ...) Die Implementierungstechnologie g g ändert sich ((neue Sprachen, Komponenten, ...) Das Team ändert sich (Personen gehen, neue kommen hinzu, ...) Das Management wechselt (neue Geschäftsausrichtung, ...) Alles kann sich jederzeit ändern! © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-7 ROOTS Charakteristiken von anderen Ingenieurswissenschaften Domäne Klar definierte Kl d fi i t Probleme P bl Ein Produkt muss gebaut werden Hohe Qualitätsanforderungen g Methoden Systematische Verfahren und ihre disziplinierte Anwendung Standardschnittstellen, komponenten und -prozesse Wissen um bereits verfügbare Teilkomponenten p und g gezielter Einsatz fertiger (Teil-) Lösungen Empirische Methoden zur Bewertung von Lösungen © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-8 ROOTS Software Engineering ist anders Andere Ingenieursbereiche Software Engineering Herstellung bestimmt die Endkosten Änderungen sind weniger häufig Herstellung ist eine einfache Duplizierung Änderungen geschehen dauernd 2000 Jahre von der Euklidischen zur nichtEuklidischen Geometrie Änderungen sind möglich, aber sehr teuer Manchmal innerhalb von Stunden (Kunde hat seine Meinung geändert) Änderungen sind einfach Redesign wird gründlich d hd ht durchdacht Auswirkungen werden genau analysiert Kein durchdachtes Redesign Auswirkungen werden nicht ausreichend bedacht Andauernde Änderungswünsche zusammen mit der Leichtigkeit, Änderungen durchzuführen, führen zu ungenügend überdachten, adhoc „Lösungen“. © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-9 ROOTS Kreatives Chaos versus diszipliniertes Engineering Programmieren ist ein kreativer Akt. Ich kann meine Kreativität nicht von Regeln begrenzen lassen. Ich bin ein Künstler. © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Wenn weniger Programmierer Kreativität mit chaotischer Vorgehensweise verwechseln würden, gäbe es mehr brauchbare Software! 1-10 ROOTS Einführung in SE: Themenübersicht Überblick Bedeutung B d t Herausforderungen g mit anderen Vergleich Ingenieurswissenschaften Software Engineering Konzepte Definition der Grundbegriffe Software Qualitäten Qualitäten V Verschiedene hi d Si Sichten ht W ist Was i t Software S ft Engineering? E i i ? Modellierung g Problemlösung Wissensakquisition Rationale Management Software Engineering g g Prinzipien p 7 Prinzipien Brügge & Dutoit, 2000: „Object-Oriented Software Engineering“, Kapitel 1 © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Ghezzi, 1996: „Software Engineering“ Kapitel 1 Engineering“, 1-11 ROOTS Was ist Software Engineering Modellierung M d lli Modellierung iistt d das wichtigste i hti t Mitt Mittell um mit it K Komplexität l ität umzugehen h Problemlösung g Suche nach akzeptablen Lösungen erfordert experimentellen Vergleich von Modellen Wissensakquisition Modellierung g erfordert das Sammeln von Daten, deren Organisation g und Formalisierung Rationale Management Dokumentation der Überlegungen / Gründe für Entscheidungen erleichtert Verständnis der Auswirkungen von späteren Änderungen © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-12 ROOTS Modellierung (1) Software Engineering ... hilft die Welt zu verstehen Modelle nicht mehr existenter Systeme: Modell der Dinosaurier, basierend auf Knochen, Zähnen und den Regeln der Anatomie Modelle von Systemen y die angeblich g existieren: Modell von Materie und Energie basierend auf Experimenten mit Teilchenbeschleunigern Modelle realer Systeme: Software basierend auf Betrachtung der Anwendungsdomäne und Benutzer “Participatory design” (Beteiligungsorientiertes Design) als Weg, die relevanten Aspekte der Anwendungsdomäne zu verstehen ... möglichst einfache aber ausreichend genaue Darstellung des Systems wichtigstes Mittel mit Komplexität umzugehen ☺ Abstraktion hilft den Blick auf die relevanten Aspekte zu richten ... ist i ein i H Hauptgrund d fü für Ä Änderungen d Je abstrakter desto mehr implizite Annahmen liegen dem System zugrunde. Je mehr Annahmen desto mehr Potential für Änderungen © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-13 ROOTS Was wir modellieren Objektorientierte Modellierung g „Problem domain object model“ Modellierung der Anwendungsdomäne Objekte Beziehungen Problemorientierte Sicht „Solution domain object model“ Objekte Beziehungen Interaktionen Modellierung des Systems Lösungsorientierte Lö i ti t Si Sicht ht Vergleich verschiedener Lösungen verlangt die Modellierung verschiedener alternativer Systeme © 2000-2008 Dr. G. Kniesel Vorteile der OO Modellierung Vorlesung „Softwaretechnologie“ Erstellung der beiden Modelle mit gleichen Mitteln möglich M d ll d Modell der Lö Lösung iistt eine i Erweiterung des ProblemModells Nachvollziehbarkeit (‚Traceability‘) 1-14 ROOTS „Modellierung“ in dieser Vorlesung Objektorientierte Konzepte Technische Grundlagen Die Unified Modelling Language (UML) Standardisierte graphische Notation für OO Modelle Objektorientierte j Modellierung g Anwendungs-Prinzipien Entwurfsmuster (Design Patterns) Typische „gute Entwurfs-Lösungen“ Refactoring Verletzung von Designprinzipien erkennen („Bad smells“) Entsprechende tsp ec e de verhaltenserhaltende e a te se a te de Restrukturierung est u tu e u g („ („Refactoring“) e acto g ) © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-15 ROOTS Problemlösung Software Engineering Begrenzte Ressourcen und unvollständiges Wissen erfordern ... den Vergleich verschiedener Lösungen/Modelle ... empirische Bestimmung von Alternativen Techniken um Angemessenheit von Modellen zu bewerten Benutzerzentrierter Entwurf (Participatory Design) Den Benutzer permanent in das Projekt einbinden und die Entwicklung leiten lassen Analyse-Überprüfung (Analysis Review) Vergleiche Modell des Anwendungsbereichs mit Realität aus Sicht des B Benutzers t Entwurfs-Überprüfung (Design Review) Vergleich des Lösungsmodells (solution domain model) mit Projektzielen I l Implementierungs-Überprüfung i Üb üf (C (Code d R Review) i ) und dT Testen System wird auf Basis des Lösungsmodells (solution domain model) validiert Projektmanagement Vergleiche Prozessmodell (Zeitplan, Budget, ...) mit der Realität des Projektes © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-16 ROOTS „Problemlösung“ in dieser Vorlesung Participatory design Den B D Benutzer t permanentt in i das d P Projekt j kt einbinden i bi d und d di die E Entwicklung t i kl leiten lassen Extreme Programming: Benutzer / Kunde als Teil des Teams Analysis-, Design-, Code-Review Extreme Programming: permanenter Review Review-Prozess Prozess durch „Pair Pair Programming“ Projektmanagement Vergleiche Prozessmodell (Zeitplan, Budget, ...) mit der Realität des Projektes j © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-17 ROOTS Wissensakquisition Software Engineering Wissensakquisition ist nicht linear Das Hi D Hinzukommen k einer i neuen IInformation f ti kkann alles ll vorher h erworbene Wissen unbrauchbar machen Hohes Fehlerrisiko Risk-based development (Risikoorientierte Softwareentwicklung) ... zielt darauf ab, mit hohem Risiko behaftete Komponenten und Aktivitäten zu erkennen. ... plant sie frühzeitig im Projekt ein Issue-based development (Problemorientierte Softwareentwicklung) ... erkennt an, dass jede Aktivität jede andere beeinflusst Analyse Systemdesign, Objektdesign p g Testen Implementierung, Auslieferung ... ersetzt lineare durch parallele Ausführung von Aktivitäten ... erleichtert es es, auf Änderungen zu reagieren ... ist leider schwieriger zu koordinieren „Wissensaquisition“ in dieser Vorlesung Prozessmodelle Risk-based Ri kb d development d l t Issue-based development Extreme Programming und „Agile Prozesse“ Verbindung beider Ansätze Es geht um den Umgang mit Änderungen! Das neue Wissen von heute kann die g gute Entscheidung g von g gestern hinfällig g werden lassen. die gestern verworfene Alternative neu ins Spiel bringen. © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-19 ROOTS ‚Rationale Management‘ Rationale (engl.) = Begründung, Erklärung, Motivation Rationale Management = Erfassung von Problemen Lösungsalternativen Argumenten für und Wider der Alternativen getroffene Entscheidung Begründung für die Entscheidung © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-20 ROOTS ‚Rationale Management‘: Sinn und Zweck Software Engineering Statische Problem- und Lösungs-Domänen Mathematikbücher M th tikbü h sind i d voller ll B Beweise. i Ni Nie aber b iistt ffestgehalten, t h lt warum ein Beweis gerade so und nicht anders geführt wurde. Das ist nicht weiter schlimm, da sich die zugrundeliegenden Modelle sehr selten ändern 2000 Jahre von euklidischer zu nicht-euklidischer Geometrie 1500 Jahre J h von geozentrischem ti h zu heliozentrischem h li ti h W Weltmodell lt d ll Dynamische y Problem- und Lösungs-Domänen g Rationale Management g Dokumentation der Gründe für Architektur und Entwurfsentscheidungen wichtig Sie ermöglicht die Auswirkung späterer Änderungen Ä dieser Entscheidungen nachzuvollziehen Sie reduziert den Änderungsaufwand und die Gefahr von Fehlentscheidungen © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-21 ROOTS Rationale Management: Problem Software Engineering Dokumentation von Alternativen Aktuelles Lösungsmodell beinhaltet nur die gewählte Alternative Betrachtet wurden aber evtl. N andere Möglichkeiten Rationale Management muss also N andere Alternativen mit erfassen Dokumentation der Gründe gegen jede verworfene Alternative Wichtigste Entscheidungshilfe bei Änderung: Ist etwa eine der vorherigen Annahmen ungültig geworden und somit auch die Schlussfolgerung die d damals l gezogen wurde? d ? Dokumentation der getroffenen Entscheidung Zusammen mit benutzten Bewertungskriterien g Dokumentation impliziter Entscheidungen Entscheidung aus Erfahrung oder Intuition, ohne explizit Alternativen zu betrachten Nachträgliches Explizitmachen sehr aufwendig Rationale Management erfordert enormen Zusatzaufwand © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-22 ROOTS Einführung in SE: Themenübersicht Überblick Bedeutung B d t Herausforderungen g mit andern Vergleich Ingenieurswissenschaften Software Engineering – Konzepte Definition der Grundbegriffe Software-Qualitäten Qualitäten V Verschiedene hi d Si Sichten ht W ist Was i t Software S ft Engineering? E i i ? Modellierung g Problemlösung Wissensakquisition Rationale Management Software Engineering g g Prinzipien p 7 Prinzipien Brügge & Dutoit, 2000: „Object-Oriented Software Engineering“, Kapitel 1 © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Ghezzi, 1996: „Software Engineering“ Kapitel 1 Engineering“, 1-23 ROOTS Software Engineering Konzepte Teilnehmer und Rollen S t Systeme und d Modelle M d ll Arbeitsprodukte Aktivitäten Ressourcen Aktivitäten, Ziele, Anforderungen, Randbedingungen In Anlehnung an IEEE St d d zu S Standards Software ft Engineering (s. [IEEE 1997] in Brügge/Dutoit) Notationen,, Methoden,, Methodologien g © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-24 ROOTS Teilnehmer und Rollen Teilnehmer (Participant) JJede d natürliche tü li h oder d jjuristische i ti h P Person di die am P Projekt j kt tteilnimmt il i t Beispiel: Alice, John, Marc, Theo, Lara, die Deutsche Bahn AG Interessensvertreter (Stakeholder) ( ) Repräsentant einer Personengruppe, die ein eigenes Interesse an dem Projekt oder Produkt hat Beispiel: Projektmanager Projektmanager, Entwickler Entwickler, zukünftige Nutzer Nutzer, durch das System zukünftig arbeitslos werdende Angestellte, ... Rolle (Role) Die Rolle die ein Teilnehmer im Projekt spielt Beispiel: Kunde, Endbenutzer, Entwickler, Projektmanager, Analyst, ... Oft abstrahieren wir Teilnehmer durch die Rollen die sie im Projekt oder beim U Umgang mit it d dem S System t einnehmen i h © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ Kunde Berater 1-25 Entwickler ROOTS System und Modelle System „reale l W Welt“ lt“ Beispiel 1: Fahrkartenautomat Beispiel p 2: Projekt j Modell Abstraktion des Systems Beispiele zu 1: Blaupausen, Schaltpläne, Programme, UML-Diagramme, ... Beispiele zu 2: Zeitpläne Zeitpläne, Kostenplan Kostenplan, ... © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-26 ROOTS Produkte (Products) Produkt Während Wäh d eines i P Projekts j kt entwickelte t i k lt A Artefakte t f kt Beispiele: Anforderungsdokumente, Programme, Testauswertungen, ... Interne Produkte Nur für das Projektteam bestimmt Beispiele: Demo-Prototypen, Testfälle, f Testergebnisse, ... Auszuliefernde Produkte (Deliverables) Für den Kunden bestimmt Üblicherweise vertraglich festgelegt, zusammen mit Zeitplan für Abgabe Beispiele: Fahrkartenautomat, seine Software, Handbücher © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-27 ROOTS Aktivitäten, Aufgaben und Ressourcen Aktivität (Activity) umfasst Menge von Aufgaben, Aufgaben die auf das gleiche Ziel gerichtet sind Beispiel: Anforderungs-Erhebung, Auslieferung, Management kann aus Teilaktivitäten bestehen Beispiel: Auslieferung f umfasst f Softwareinstallation S f und Benutzerschulung Aufgabe (Task) Atomare Aufgabe, g die zugeteilt g und erledigt g wird verwendet Ressourcen (Resources) erzeugt Produkte Ressourcen (Resources) Alles was zur Durchführung von Aufgaben benötigt wird Beispiele: Teilnehmer, Zeit, Material, ... P j kt l Projektplanung Planung von Aktivitäten und Aufgaben Zuordnung g von Ressourcen für Aufgaben g © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-29 ROOTS Ziele, Anforderungen, Randbedingungen Ziele (Goals) Leitprinzipien L it i i i b bzw. H Hauptziele t i l d des P Projektes j kt Definieren die wichtigen Attribute des Systems Beispiel p 1: Leitziel der Space-Shuttle p Entwicklung g ist hohe Sicherheit Beispiel 2: Leitziel der Entwicklung eines Fahrkartenautomaten ist hohe Verfügbarkeit Unklar definierte Ziele und Zielkonflikte machen einen großen Teil der Komplexität mancher Systeme aus Anforderungen (Requirements) Eigenschaften, die das System besitzen muss Funktionale Anforderungen (z.B. Ticket ausgeben) Nicht-Funktionale Nicht Funktionale Anforderungen (schnelle Reaktionszeit, Touchscreen) Randbedingungen (Constraints) Weitere Bedingungen, die für den Benutzer nicht sichtbar sind Z.B. Einbindung von Altsystemen © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-30 ROOTS Notation, Methode, Methodologie Notation Sprache S h zur graphischen hi h oder d ttextuellen t ll D Darstellung t ll eines i M Modells d ll Beispiel: UML Methode Reproduzierbares Verfahren zur Problemlösung Beispiel: Kochrezept, Sortieralgorithmus, S Rationale Management, Konfigurationsmanagement Methodologie Menge von sich ergänzenden Methoden zur Lösung einer bestimmten Problemklasse Beispiele: Unified Process, OMT, ... © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-31 ROOTS Vorlesung „Softwaretechnologie“ Wintersemester te se este 2008 008 Software-Qualitäten & EngineeringPrinzipien ROOTS Überblick Das Ziel: “qualitätsorientiertes Software Engineering" Softwarequalität und Prozessqualität Verschiedene Qualitätssichten durch verschiedene Interessensvertreter Verschiedene Qualitäten in verschiedenen Anwendungsbereichen wichtig Wie man “qualitätsorientiertes Software Engineering“ erreicht Engineering-Prinzipien „Rigor and formality“ T Trennung der d B Belange l Modularität Abstraktion E Erwartung t von Änderungen Ä d Allgemeingültigkeit Inkrementelle Vorgehensweise © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-33 ROOTS „Rigor and Formality“ Formality = engl. Förmlichkeit, Formalismus Formalisierung F li i hilft Di Dinge präzise ä i ausszudrücken dü k ... dadurch Widersprüche und Inkonsistenzen zu entdecken ... und g gegebenenfalls g sogar g beweisen zu können. Beispiele Typsysteme von Programmiersprachen Sicherheitskritisches Verhalten S Nebenläufigkeit / Parallelität Rigor = engl. Härte, Starre, Strenge gemeint ist konsequentes / diszipliniertes, systematisches Vorgehen Besonders wichtig für Formalisierungen aber nicht nur. Konsequentes, diszipliniertes Vorgehen im Laufe des Softwareentwicklung genauso wichtig. g Extreme Programming g g ist g © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-34 ROOTS Produktqualitäten Zuverlässigkeit Effizienz BenutzerBenutzerIn Externe S Sicht Software-Qualitäten: Verschiedene Sichten freundlichkeit Prozessqualitäten Wartbarkeit Portabilität EntwicklerIn © 2000-2008 Dr. G. Kniesel Erweiterbarkeit Interne Sicht V ifi i b k it Verifizierbarkeit Vorlesung „Softwaretechnologie“ Produktivität Pünktlichkeit Kontrollierbarkeit ManagerIn 1-35 ROOTS Qualitätsorientiertes Software Engineering Die gewünschten Qualitäten des Softwareproduktes S ft d kt Softwareprozesses ... müssen von Anfang an klar sein die treibende Kraft f für f den gesamten Prozess sein Das Erreichen der Qualitäten hängt ab vom Grad der Einhaltung guter Ingenieurs-Prinzipien nächster Abschnitt © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-36 ROOTS Ingenieurs-Prinzipien: “Separation of Concerns” (Trennung der Belange) Concerns Möglichkeiten der Trennung T Trennung nach hZ Zeit it z.B. Zeitplanung des täglichen Lebens Trennung nach Qualitäten z.B. anfängliche Konzentration auf bestimmte Qualitäten, später dann auf andere Trennung g nach Größe Entwicklung von Teilen des Systems geschieht getrennt Trennung ermöglicht ... ... die Kooperation verschiedenster Leute im selben Projekt ... die Bewältigung g g der Komplexität eines Projektes j Der einzige Weg Komplexität zu bewältigen ist die Trennung in verschiedene Belange. © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-37 ROOTS Ingenieurs-Prinzipien: “Separation of Concerns Concerns” Vergangenheit Prozedurale Dekomposition Funktionale Dekomposition Gegenwart objekt-orientierte Dekomposition Problem "tyrany tyrany of predominant decomposition decomposition" unabhängig von Dekompositionsart gibt es immer „überschneidende Belange" („crosscutting concerns“) Sicherheit,, Persistenz,, ... Aktuelle Weiterentwicklung / Zukunft (?) mehrdimensionale Trennung der Belange "aspekt aspekt-orientierte orientierte Softwareentwicklung" Softwareentwicklung http://aosd.net http://aosd.net/conference: AOSD.06, Universität Bonn, März 2006 © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-38 ROOTS Ingenieurs-Prinzipien: Modularität (2) Dekomposition Top-down T d M Methode th d Aufteilen des Ursprungsproblems Rekursive Dekomposition p von Unterproblemen p Divide-And-Conquer K Komposition iti Bottom-up Methode Elementare Komponenten p werden zuerst entworfen Projekt wird aus einzelnen Modulen zusammengesetzt Mö li hk it d Möglichkeit des V Verstehens t h Hilft beim modifizieren eines Systems © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-39 ROOTS Ingenieurs-Prinzipien: Modularität (3) Kohäsion (engl. „Cohesion“) Zusammenhalt Elemente El t eines i M Moduls d l werden d gruppiert i t Gruppen werden aus logischen Gründen gebildet Elemente kooperieren zum Erreichen eines Ziels Kohäsion ist ein Maß für die gegenseitigen Abhängigkeiten von Elementen einer Gruppe Hohe Kohäsion hoher Zusammenhalt der Gruppe Kopplung (engl. „Coupling“) Abhängigkeiten Kopplung ist ein Maß für die Abhängigkeiten zwischen den Modulen Starke Kopplung Viele unerwünschte Abhängigkeiten Modularität kann nur erreicht werden, wenn die Module einen hohen Zusammenhalt und d geringe i Abhä Abhängigkeiten i k it besitzen. b it © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-40 ROOTS Ingenieurs-Prinzipien: Abstraktion Definition Die wichtigen Aspekte herausfinden unter Vernachlässigung der Details Details. Generelle Idee Entwurf von Modellen als Abstraktion der Realität Gut für… … den erfolgreichen Umgang mit der Komplexität im Allgemeinen. … das Sichtbarmachen wesentlicher Aspekte einer Aufgabe. Gilt für… … Softwareprozesse z.B. Kostenabschätzung (nur über Schlüsselfaktoren) … Softwareprodukte z.B. Klassen sind Abstraktionen “realer” Objekte © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-41 ROOTS Ingenieurs-Prinzipien: Voraussehen von Änderungen Generelle Idee S ft Software muss einfach i f h erweiterbar it b und d änderbar ä d b sein i Änderungen g in den Softwareprodukten p Benutzerfeedback kann zu neuen Anforderungen führen Nicht alle Anforderungen waren im ersten Release erfüllt Änderungen im Softwareprozess Personalwechsel kann zu unvollständigem Wissen führen © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-42 ROOTS Ingenieurs-Prinzipien: Allgemeinheit Prinzip Probleme wenn möglich verallgemeinern Pro Mehr Wiederverwendungspotential Möglicherweise weniger komplexe Lösung Lösung g ist möglicherweise g durch bereits fertige g Komponenten p möglich g Kontra Könnte mehr Kosten verursachen er rsachen in Be Bezug ga auff Geschwindigkeit, Gesch indigkeit Speicherbedarf, Entwicklungszeit, Einarbeitungsaufwand, Wartungsaufwand, ... Übermäßige Allgemeinheit ist eher schädlich schädlich... Allgemeinheit ist ein fundamentales Prinzip in d E der Entwicklung t i kl von W Werkzeugen k und dP Paketen. k t © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-43 ROOTS Ingenieurs-Prinzipien: Inkrementelle Vorgehensweise Definition Ei Ziel Ein Zi l wird i d durch d h iimmer b bessere sukzessive k i Näh Näherungen erreicht. i ht Vorversionen der Software werden früh veröffentlicht Frühes Feedback der Kunden Vorher unbekannte Anforderungen stellen sich heraus Inkrementelle Vorgehensweise ist eine Grundvoraussetzung von Erweiterbarkeit © 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ 1-44 ROOTS
