Softwaretechnik

1. Vorstudie: In der Vorstudie wird die Entscheidung über Machbarkeit des Projekts geklärt

2. Anforderunganalyse: Was soll das System können ? (welche Benutzer in welchen

Anwendungsszenarien?)

3. Design: wie soll das System aufgebaut werden, wie sollte es aussehen, wie sollte es mit

seinen Nutzern interagieren?

4. Implementation: Realisierung des Systems

5. Integration & Einführung: Montage von Komponenten und Einführung des Systems beim Kunden vor Ort.

6 Wartung: Erhaltung / Änderungsaktivitäten

Charakteristika:

• Der Entwicklungsprozess wird mehrfach iteriert

• nach jeder Iteration wird ein Teilprojekt (Release) erstellt.

• nach jeder Iteration gibt es eine Absprache für die Anforderungen.

• nach dem ersten Release ist das Projekt benutzbar (Beta Version).

• jeder weitere Release ist ein Update

Vorteile dieser Methode sind:

• Die Iterationschritte sind relativ kurz

• Nach jedem Iterationschritt ist ein fertiges (teil-) Produkt verfügbar

• zyklisches Arbeiten

• ständiges Testen

• Kunde wird dauerhaft einbezogen

Die Iterationschritte werden zum neudefinieren von Ungenauen Anforderungsangaben (z.B. seitens des Kunden) genutzt.

Ablauf:

1. Der Prozess startet mit den (ungenauen) Kernangaben des Kunden

2. Auf diesen Angaben wird eine erste Version der Software entwickelt

3. Der Kunde benutzt dann diese Version um Erfahrungen an der Software zu sammeln und/oder seine Änderungvorschläge einzubringen

4. Anschließende Wartung wird als neuer Iterationschritt angesehen, der zu einer neuen Softwareversion führt

Dieses Modell wird vorallem dann benutzt wenn der Kunde seine eigenen Anforderungen nicht genau versteht oder Definieren kann. “I can’t tell you what I want, but I will know it when I see it.”

Vorteile:

• Bessere Überwachung des Projektes durch Zerlegung in kleine Iterationschritte

• Kunde bekommt früh und in kurzen Zeitabständen ein Produkt geliefert

• Der Kunde wird während des gesamten Projekts mit einbezogen

Nachteile:

• Eingeschränktes Wissen über die Anforderungen an das Projekt

• Risiko, dass Kernenforderungen übersehen werden

• Schwer zu Dokumentieren

• Anzahl der Iterationschritte unklar

Die Iterationschritte werden genutzt um (teil-) Pakete anhand der Angaben (des Kunden) so genau wie möglich zu implementieren.

Ablauf:

1. Der Prozess startet mit den Angaben des Kunden, die so genau wie möglich definiert wurden.

2. Die erste Version der Software deckt nur einen Teil seiner Anforderungen

3. Der Kunde sammelt anhand dieses Teilerfolges Erfahrungen und bringt diese in den nächsten Iterationschritt ein

4. Spätere Versionen schließen die Lücken in den Anforderungen des Kunden

Vorteile:

• Genaue Angaben über die Anforderungen des Systems

• Bessere Planung der Iterationschritte möglich

• außerdem ähnliche Vorteile wie die evolutionäre Methode

Nachteile:

• Iterationschritte enden in Produkten die nur einen kleinen Teil der Endsoftware erfüllen (gerade bei den ersten Schritten von Nachteil)

• Kunde muss genau wissen, was er will und dies erklären können

Agile Prozessmodelle verwenden die iterative evolutionäre Entwicklungsmethode. Die Anforderungen und Problemlösungen werden dynamisch festgelegt und können sich laufend ändern. Dabei kommt es zu frühen, funktionalen Prototypen einer Software. i.d.R. wird in kleinen Teams á 2-12 Mitarbeitern gearbeitet.

Zu den Agilen Prozessmodellen gehören unter anderem Scrum, Xp oder Kanban.

XP beschreibt eine Methode, die das Lösen einer Programmieraufgabe in den Vordergrund der Softwareentwicklung stellt und dem formalisierten Vorgehen wenig Bedeutung misst. XP geht davon aus, dass der Kunde noch nicht genau weiß oder einschätzen kann, was er braucht. Kommunikation und Kundenkontakt steht daher im Vordergrund. Oft ändern sich Prioritäten nachdem ein Iterationschritt durchlaufen wurde.

Der Kunde kann in der extrem Programmierung jederzeit Einfluss auf das Projekt nehmen.

• charakteristische Regeln / Praktiken, die das Vorgehen beim Prozessmodell XP beschreiben:

● On-Side-Customor: Ansprechpartner des Kunden betreut des Projekt uns ist vor Ort

immer ansprechbar

● Release Planning: Der Kunde legt die Priorität der Aufgaben, die Entwickler

entscheiden wie und in welchem Zeitraum sie die Aufgaben erledigen können

● Pair Programming: Zwei Entwickler arbeiten zusammen an einem Rechner: Einer

denkt operationell, der andere strategisch

● kurze Release-Zyklen: Erste laufende Software wird schnell fertiggestellt und dann alle

1-3 Wochen mit einem Update versehen

● einfaches Design: Aufgaben werden so einfach wie möglich umgesetzt. Es wird exakt

das realisiert, was der Kunde wünscht, ohne dabei groß an eventuelle zukünftige

Erweiterbarkeit zu denken

● Refactor: Code wird laufend so umstrukturiert, sodass dieser möglichst einfach aufgebaut ist,

ohne dass die Software ihr Verhalten ändert.

Scrum gehört zu den iterativen, agilen Prozessmodellen, da es ein Prozess ist, bei dem festgelegte “Sprints” ausgeführt werden. Bei jeder Iteration entsteht ein Teilprodukt und am Ende des Projektes ein vollständiges Produkt.

- Charakteristische Eigenschaften, die das Prozessmodell Scrum beschreiben:

• basiert oft auf Schätzungen (Zeit)

• hohes Maß an Selbstorganisation (kein Teamleiter vorhanden)

• Sprint-Ende wird niemals verlängert (Ende des Iterationschritts)

• Kundenzufriedenheit und Menschen stehen im Mittelpunkt (Vermeidung von Überlastungen)

• Anforderungen mit höchster Priorität werden zuerst angegangen.

Definition:

Ein Use Case umfasst alle Szenarien, die eintreten können, wenn ein Benutzer versucht mit einem System ein bestimmtes Ziel zu erreichen. Das Ergebnis einer Aktion mit dem System kann entweder ein Erfolg oder ein Fehler/Abbruch sein.

Es werden hierbei nur Kernfunktionen aufgezeigt, allerdings in keiner Weise implementiert.

include Beziehung:

Anwendungsfall A beinhandet (<<include>>) Anwendungsfall B. Das bedeutet, dass B immer ausgeführt wird, wenn der Benutzer A aufruft.

z.B. Morgenwäsche beinhaltet Zähnepunten (Morgenwäsche ---<<include>>---> Zähneputzen)

extend Beziehung:

Anwendungsfall A ist eine mögliche Erweiterung von Anwendungsfall B. Das bedeutet, dass A unter einer bestimmten Bedingung vom Benutzer ausgeführt werden kann, wenn B aufgerufen wird. z.B. Duschen ist eine mögliche Erweiterung der Morgenwäsche (Duschen---<<extends>>---> Morgenwäsche|Bedingung: nach Klogang)

„Assoziation“

Eine Assoziation beschreibt eine Beziehung zwischen zwei oder mehr Objekte (z.B. Klassen).

Unter binärer Assoziation versteht man eine Beziehung zwischen genau zwei Klassen. z.B. Kunde und Konto.

Unter reflexiver Assoziation versteht man eine Beziehung zu einer Klasse zu sich selbst. Z.b. Eine Beziehung von Person zu sich selbst. (Vater/Sohn Beziehung o.ä.)

„Aggregation“

Eine “ganzes-Teile”-Beziehung, bei der beide Objekte unabhängig voneinander existieren können.

z.B. Student ist ein Teil von Vorlesung; der Student ("lebt noch") ist auch noch Student, wenn es die Vorlesung nicht mehr gibt.

„Komposition“  

Strenge Form der Aggregation, bei der die Teile vom Ganzen existenzabhängig sind.

z.B. Raum ist ein Teil von Gebäude; wenn das Gebäude fehlt, kann auch kein Raum mehr existieren.

Die beiden folgenden Abbildungen zeigen zwei Möglichkeiten für die Darstellung ì angebotenen Schnittstellen:

Angebotene Schnittstelle, dargestellt mit Ball-Notation (auch Lollipop-Notation)

Angebotene Schnittstelle, dargestellt mit einer Schnittstellenrealisierungsbeziehung

“Required Interface”  

Die beiden folgenden Abbildungen zeigen zwei Möglichkeiten für die Darstellung von benötigten Schnittstellen:

Benötigte Schnittstelle, dargestellt mit Socket-Notation

Benötigte Schnittstelle, dargestellt mit einer Verwendungsbeziehung

Entwurfsmuster sind bewährte Lösungsschablonen für Probleme in der Softwaretechnik. Sie stellen damit eine Wiederverwendbare Schablone zur Lösung eines Problems dar.

charakteristische Eigenschaften:

ein gutes Muster sollte:

• ein oder mehrere Probleme lösen

• ein erprobtes Konzept bieten

• auf realen Designs basieren

• über das rein Offensichtliche hinausgehen

• den Benutzer in den Entwurfsprozess einbinden

• Beziehungen aufzeigen, die tiefgehend Strukturen und Mechanismen eines Systems umfassen

Ein Beispiel für ein Kompositum ist die grafische Benutzeroberfläche von Java. Alle Elemente und Schaltflächen sind Spezialisierungen der Klasse Component. Die Behälter dieser Elemente sind allerdings wiederum Spezialisierungen der selben Klasse.

Also werden im wesentlichen alle Standartelemente durch eine einzige Kompositum-Klasse definiert.

Das Strategy-Entwurfsmuster ist für Probleme geeignet bei denen viele verwandte Klassen sich nur in ihrem Verhalten unterscheiden, und unterschiedliche (austauschbare) Varianten eines Algorithmus benutzt werden sollen. Daten innerhalb eines Algorithmus können dabei vor dem Benutzer verborgen werden.

Das Observer-Entwurfsmuster ist für Probleme geeignet, bei denen ein Subjekt (Produkt, Software) seine internen Daten ändert und abspeichert. Diese Änderungen muss der Endnutzer (Observer) mitbekommen. Dazu benötigt der Observer mindestens eine update()-Methode.

Ein Model-View-Controller (MVC) ist ein Muster zur Strukturierung von Software-Entwicklungen. Das Muster besteht aus drei Einheiten, dem Datenmodell (engl. model), Der Präsentation (engl. view) und der Programmsteuerung (engl. controller).

Charakterisierung

• Implementation nicht sichtbar

• wiederverwendbar

• unfertiges System

• muss auf das Projekt abgestimmt werden

white-box frameworks are extended by inheritance

Extension of white-box frameworks is based on
inheritance and late binding:
1. inheritance from (abstract) classes of the framework
2. overriding selected methods
• Reminder: design pattern
“template method”
Define the skeleton of an
algorithm and override
individual steps of the
algorithm in sub classes

Characteristics of white-box extension:
- only implementation of selected methods necessary
- often knowledge of internal structure of framework required
(→ “white box”):
- when are which methods called with which expectations?
- which inherited attributes may be accessed by my extension?
- which inherited methods should my extension call?
→ important information for correct implementation of (abstract)
methods invoked by the framework
• Drawback: inheritance breaks encapsulation
State of framework objects can be inspected and
manipulated by extensions

black-box frameworks are extended by composition

Extension of black-box frameworks is based on
composition and delegation:
1. implementation of extending classes that realise an interface
defined by the framework
2. delegation of method calls from the framework to objects of
that class (e.g. by using the strategy pattern)

Characteristics of black-box extension:
- no inheritance of code, therefore implementation of all
methods defined by the interface necessary
- internal structure of framework remains hidden
(→ “black box”)
- no restriction to “object-oriented world”:
- more general entities can be composed (instead of objects)
- communication between entities is not confined to method calls
• Benefit: encapsulation preserved
Extensions have only access to information that they
are explicitly supplied with over the interface

“Don’t call us, we call you”. Wir schreiben z.B. einen Key-listener, der nicht permanent die Tastatur fragt, ob eine Taste gedrückt wurde, sondern die Taste sagt, gib uns bescheid wenn du gedrückt wurdest.

• Flow of control in applications using libraries:
- application (your code!) defines the control flow
- application calls the library (the reused code)
• Flow of control in applications based on frameworks:
- framework (the reused code!) defines the control flow
- framework calls the extensions (your code!)
- extension techniques permit customization of individual steps
of the control flow
• Inversion of control (invertierter Kontrollfluss):
A framework calls custom extensions, not vice versa!
• “Hollywood principle”: “Don’t call us, we call you!”

Zu der konstruktiven Qualitätssicherung zählen Maßnamen wie:

• systematische Projektdefinition und Projektzieldefinition

• Anforderunganalyse

• einigen auf Programmierstandarts

Zu der analytischen Qualitätssicherung zählen Maßnamen wie:

• statische Maßnamen wie Code-Analyse, Code Review (Stichwort Paar-Programmierung)

• dynamisches Testen (unterschiedliche Konstellationen werden tatsächlich ausgeführt und die erzeugten Ergebnisse werden überprüft)