Klausurvorbereitung Software Engineering TFH Berlin

Transkript

1 Teil 1 Einführung in Software Engineering Definition: Was ist Software Engineering? Unter Software Engineering (SE) versteht man den systematischen, disziplinierten und in seiner Größe abschätzbaren Ansatz, Software zu entwickeln, zu betreiben und zu warten (IEEE). Man versteht darunter aber auch die zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieursmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen. (H. Balzert, Lehrbuch der Software-Technik). Zielorientiert Berücksichtigung von z.b. Kosten, Zeit, Qualität. Zusammengefasst kann man sagen, dass SE Die Entwicklung komplexer Software erlaubt Den Einsatz von Werkzeugen und Methoden bedeutet Zeit und Kosten spart (sparen kann) Qualität und Produktivität erhöht (erhöhen kann) Hinweis: Die Definition des IEEE ist von mir frei aus dem Englischen übersetzt. Dort lautet sie: The systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. Ich gehe davon aus, dass man diesen englischen Satz zwar verstehen aber nur schwer übersetzen kann und rate zur Verwendung der deutschsprachigen Definition. Das Teufelsquadrat nach Sneed Das Teufelsquadrat nach Sneed zeigt die vier wichtigsten Faktoren bei der Entwicklung von Software-Projekten. Dabei hängen die einzelnen Faktoren voneinander ab, wodurch sich die beiden inneren Vierecke ergeben (eigentlich sind das rote, verzerrte Viereck und das Quadrat in der Mitte das gleiche, nur in unterschiedlichen Situationen). Im Beispiel ist zu sehen, dass eine Erhöhung der Qualität bei Verkürzung der Entwicklungsdauer zwangsweise mit einer Reduktion der Quantität und einer Erhöhung der Entwicklungskosten einhergeht. Das Viereck, welches aus den vier Faktoren gebildet wird, zeigt die Produktivität an, die mit den gegebenen Faktoren erreicht werden kann. Die Fläche des Vierecks bleibt immer gleich. Verschiebungen eines Faktors ergeben also weitere Verschiebungen, so dass sich Gebilde wie das hier rot eingezeichnete Viereck ergeben. Klar, ohne direkten Zusammenhang zum Teufelsquadrat: Erhöht man die Anforderungen an eine Software (z.b. die Quantität der implementierten Funktionen), so muss entweder die Qualität darunter leiden, oder aber Entwicklungsdauer und/oder kosten steigen an. Eben diesen Sachverhalt stellt das Teufelsquadrat dar. Anmerkung: In der heutigen Vorlesung ( ) hieß es, dass die senkrechten Seiten des Produktivitäts-Vierecks immer senkrecht sein müssen Das würde allerdings bedeuten, dass man ein Software-Projekt nur dann mit einer höheren Qualität ausstatten kann, wenn man die Entwicklungsdauer reduziert und das ergibt in meinen Augen wenig Sinn 1

2 Wissensgebiete des Software Engineering nach IEEE Software Requirements Was soll eine Software leisten? Software Design Wie wird die Software aufgebaut (Architektur)? Software Construction Realisierung der Software gemäß dem Design Software Testing Systematische Fehlerfindung und behebung Software Maintenance Wartung und Weiterentwicklung nach Auslieferung Software Configuration Management Verwaltung von Software-Versionen und Konfigurationen Software Engineering Management Projektmanagement von Personen, Organisationen, Zeit, etc. Software Engineering Process Definition und Verbesserung von Software-Entwicklungsprozessen Software Engineering Tools and Methods Werkzeuge und Methoden für die Software-Entwicklung Software Quality Messung und Verbesserung der Software-Qualität 2

3 Teil 2 Vorgehensmodelle Vorgehensmodell im Software Engineering werden auch als Software-Lebenszyklus bezeichnet und stellen verschiedene Vorgehensweisen zur Software-Entwicklung zur Verfügung. Sie sind in Phasen unterteilt, die entweder inhaltlich oder zeitlich voneinander abgegrenzt sind. Mit den Vorgehensmodellen ist die Steuerung komplexer Projekte möglich. Für jedes Projekt kann und muss das richtige bzw. passende Modell gefunden werden, da es unterschiedliche Detaillierungsgrade gibt. Vorgehensmodelle können sehr komplex sein, helfen aber dabei, komplexe Projekte zu bewältigen. Oft sind sie firmenintern oder vom jeweiligen Auftraggeber vorgegeben. Je mehr Erfahrung ein Entwickler oder ein Team von Entwicklern mit einem solchen Modell hat, desto effizienter können Zeit und Kosten gespart werden. Das Wasserfallmodell Dieses Modell stammt aus dem Jahre 1970 und ist auch als Phasenmodell bekannt. Es ist in die folgenden Phasen unterteilt: Anforderungsdefinition System- und Software-Design Implementierung (Programmierung) und Modultest Integration und Systemtest Installation und Wartung Diese Phasen bauen (mit Ausnahme der obersten natürlich), als Kaskade aufeinander auf. Man kann von einer Phase zu ihrem Vorgänger zurückgehen, aber keine Stufe überspringen. Wichtig ist, dass jede Phase erst komplett abgeschlossen sein muss, bevor die ihr nachfolgende Phase begonnen werden kann. abgeschlossene und genehmigte Dokumente. Jede Phase liefert ein oder mehrere Vorteile Dokumentation am Ende jeder Phase Kompatibel zu anderen Vorgehensmodellen Geeignet für den Einsatz bei Projekten mit klaren Anforderungen Nachteile Anforderungen werden früh eingefroren Unflexibel (nachträgliche Änderungen sind nicht eingeplant) Die Kosten- und Ressourceneinschätzung ist ungenau 3

4 Das Spiralmodell (Boehm, 1988) Beim Spiralmodell nach Boehm handelt es sich um eine Kombination vorhandener Modelle unter Berücksichtigung von Managementaspekten. Es enthält zwei Achsen: 1. Die Zeitachse 2. Die Kostenachse In den Windungen finden sich die Aktivitäten, in den Winkeln die Fortschritte der einzelnen Projektzyklen. Die einzelnen Windungen sind in vier Sektoren aufgeteilt: Festlegung von Zielen, Beurteilung von Alternativen Risikoanalyse Planung des nächsten Zyklus Entwicklung und Test Im Spiralmodell beginnt der Lebenszyklus eines Projekts im Zentrum der Spirale und verläuft auf ihr nach außen hin. Vorteile Frühzeitiges Erkennen von Risiken und Fehlern Lösungsalternativen Prototypbasiert Kontinuierliche Wartung und Erweiterung Iterativ und inkrementell Nachteile Nicht geeignet für kurzzeitige, kleine Projekte 4

5 Das V-Modell (1986) Beim V-Modell handelt es sich um eine Erweiterung des Wasserfallmodells, in dem aber keine strikten zeitlichen Abfolgen und keine Abnahmen am Ende der einzelnen Phasen vorhanden ist. Beim V-Modell XT handelt es sich um den Entwicklungsstandard für IT-Systeme des Bundes. Es wurde im Februar 2005 in der Version 1.2 vorgestellt. Aktivitäten und Produkte des Entwicklungs- und Planungsprozesses sind festgelegt. Eine Qualitätssicherung ist integriert. So werden die einzelnen Phasen verifiziert ( Wird ein korrektes Produkt entwickelt? ) und validiert ( Wird das richtige Produkt entwickelt? ). Vorteile Das V-Modell ist standardisiert und dennoch flexibel Die Softwarequalität wird gewährleistet Kosten werden reduziert Die Kommunikation zwischen den einzelnen Mitarbeitern/Teams wird erhöht Auftraggeber und nehmer haben eine gemeinsame Sprache Nachteile Anfangs sind Abstimmungsprozesse notwendig 5

6 Weitere Vorgehensmodelle (nicht im Detail relevant für die Klausur) RUP Rational Unified Process Beim RUP handelt es sich um ein Vorgehensmodell und Produkt von IBM Rational. Es bietet statische, dynamische und Praxis-Perspektiven. XP extreme Programming Bei XP findet die Entwicklung in kleinen Schritten statt. Dadurch werden Kommunikation und Tests besonders wichtig. MMD Model Driven Development Auf Grundlage von UML 2.0 wird zunächst ein Modell entwickelt, aus dem später der Code generiert wird (viele UML-Tools können dies automatisch durchführen). 6

7 Teil 2 UML 2.1 Phasen der objektorientierten Entwicklung Die objektorientierte Entwicklung teilt sich in drei Stufen bzw. Phasen ein: OOA, OOD und OOP. Am Anfang steht die OOA, die objektorientierte Analyse. Hier werden fachliche Anforderungen erfasst und beschrieben. Die zweite Phase, das OOD, das objektorientierte Design, befasst sich mit dem technischen Design und der Architektur des Projekts. Am Schluss wird in der OOP, der objektorientierten Programmierung, das Design in einer objektorientierten Sprache (z.b. Java, C#,...) umgesetzt Die Phasen der objektorientierten Analyse (OOA) Die einzelnen Phasen werden mit UML realisiert. 1. Beschreibung von Anwendungsfällen mit Use-Case-Diagrammen 2. Modellierung von Abläufen mit Aktivitätsdiagrammen 3. Darstellung von Zustandsänderungen mit Zustandsdiagrammen 4. Datenmodellierung mit Objekt- und Klassendiagrammen 5. Textuelle Beschreibung der Anforderungen Als Ergebnis erhält man ein detailliertes Pflichtenheft Unterschied zwischen Pflichten- und Lastenheft Unter einem Lastenheft versteht man die Anforderungen eines Kunden, die auch eine grobe Beschreibung des Konzepts enthalten sollen. Ein Pflichtenheft wird dagegen meistens vom Auftragnehmer erstellt. Es geht aus dem Lastenheft hervor und enthält detaillierte Anforderungen. 2.2 Was ist UML? Bei UML (Unified Modelling Language) handelt es sich um eine Modellierungssprache, die als Spezifikation von OMG (Object Management Group), einem Konsortium der Computerindustrie, die Integrationsstandards für Unternehmen entwickelt, herausgegeben wird und sich seit 2004 in der Version 2.0 befindet. UML wird als visuelle bzw. grafische Programmiersprache eingesetzt und hat wie alle anderen Programmiersprachen eine feste Syntax bzw. eine einheitliche Notation. Unter xuml versteht man die ausführbare Variante von UML. Diese ermöglicht es, ein erstelltes Analysemodell als Prototyp auszuführen (man spricht dann vom ausführbaren Pflichtenheft). 7

8 2.3 Die verschiedenen UML-Diagrammarten In UML 2.0 gibt es zunächst einmal zwei verschiedene Typen von Diagrammen: 1. Strukturdiagramme (statisch) 2. Verhaltensdiagramme (dynamisch) Strukturdiagramme Klassendiagramm Objektdiagramm Paketdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Einsatz- und Verteilungsdiagramm (Deployment) Verhaltensdiagramme Anwendungsfalldiagramm (Use Case) Aktivitätsdiagramm (Activity) Zustandsdiagramm (State Machines) Interaktionsdiagramm o Sequenzdiagramm o Kommunikationsdiagramm o Interaktionsübersichts-Diagramm o Zeitdiagramm 8

9 2.4 Das Anwendungsfalldiagramm (Use Case-Diagramm) Beim Anwendungsfalldiagramm in UML werden Geschäftsprozesse dargestellt. Ebenso wird das Verhalten des Systems aus der Sicht des Anwenders beschrieben Die Notation Geschäftsprozesse werden als Oval dargestellt und enthalten eine Beschreibung von sich selbst, die immer aus Substantiv und Verb bestehen muss. Akteure werden als Strichmännchen dargestellt. Bei ihnen handelt es sich um eine Person oder auch ein Teilsystem, welche(s) einen Geschäftsprozess auslöst. Assoziationen Anwendungsfalldiagramme unterscheiden sechs Arten von Assoziationen, die die Beziehungen zwischen den Geschäftsprozessen und Akteuren untereinander darstellen. Einfache Assoziation Beide sind beteiligt, bidirektionaler Informationsfluss Gerichtete Assoziation Quelle löst Ziel aus, Informationsfluss unidirektional Generalisierung Quelle ist Spezialisierung des Ziels Abhängigkeit Quelle ist vom Ziel abhängig, Ziel ist unabhängig Include-Beziehung Quelle enthält die Funktionalität des Ziels Extend-Beziehung Quelle erweitert die Funktionalität des Ziels Sonstige Assoziationen können durch Label beschriften werden. Notizen sind auch möglich und können mit Geschäftsprozessen und/oder Akteuren verlinkt werden. 9

10 Beispiel für ein Anwendungsfalldiagramm Erläuterungen Die gedachte Firma hat sowohl Privat- als auch Geschäftskunden. Diese werden unter dem Begriff Kunde zusammengefasst, haben aber unterschiedliche Eigenschaften. Die Generalisierungen unter den Akteuren auf der linken Seite zeigen diesen Umstand. Der Akteur Kunde kann den Geschäftsprozess Kfz reservieren auslösen, der auch über eine integrierte -Bestätigung verfügt (include). Natürlich sind sowohl Kunde als auch Mitarbeiter am Geschäftsprozess Kfz vermieten beteiligt, der durch den Geschäftsprozess Kfz-Zubehör vermieten in seiner Funktionalität erweitert wird. Der Kfz-Mitarbeiter ist am Geschäftsprozess Kfz reservieren beteiligt (klar). Unten rechts findet sich ein Beispiel für eine Notiz, die mit dem Akteur Kfz-Mitarbeiter verlinkt ist. Beschriftungen über Label wurden hier nicht vorgenommen. Diese erscheinen als Text an den Assoziationen. Findung der Anwendungsfälle Um die Anwendungsfälle zu finden, geht man wie folgt vor: Geschäftsprozesse werden von einem Ereignis ausgelöst und enden mit einem Ergebnis. Zum Beispiel wäre in diesem Fall der Wunsch eines Kunden nach einer Reservierung das auslösende Ereignis und die Reservierung das Ergebnis. Sowohl Auslöser als auch Ergebnis müssen eindeutig festgelegt sein! Anwendungsfälle sind abstrakt. Sie sind daher unabhängig von konkreten Möglichkeiten und technischer Umsetzung. In den Anwendungsfällen spielt es keine Rolle, ob der Kunde einen VW Golf oder einen Raumgleiter reservieren möchte diese Beschränkungen werden erst später berücksichtigt. 10

11 Textuelle Beschreibung Zu einem Anwendungsfalldiagramm gehört auch eine textuelle Beschreibung in Tabellenform. Diese ergänzt das Diagramm, ermöglicht eine detaillierte Beschreibung und bietet zusätzliche Möglichkeiten. Beispiel für eine textuelle Beschreibung Beschreibung des Anwendungsfalls Name (Use Case) Kurzbeschreibung Auslöser oder Motivation Ergebnis Akteure Eingehende Informationen Vorbedingungen Nachbedingungen Kfz reservieren Kunde reserviert ein Kfz Kunde wendet sich mit dem Wunsch nach einer Reservierung an die Firma Für den Kunden wird ein Kfz reserviert Kunde Kundennr., Kundendaten, Reservierungswunsch Keine Es wurde ein Kfz für den Kunden reserviert Ablaufschritte Kunde identifizieren Reservierungswunsch aufnehmen Reservierung prüfen Kfz reservieren Reservierung bestätigen 11