Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:softwaretechnologie

**Dies ist eine alte Version des Dokuments!**

Software-Technologie

Schwerpunkte der Klausur

  • Vorgabe: Einfaches technisches System mit
    • Kundenanforderungen,
    • technischen Anforderungen,
    • ersten Analyseergebnissen und einem
    • vorläufigen Architektur-Klassendiagramm.
  • Dazu sind folgende Aufgaben zu lösen:
    • Anforderungsmängel finden
    • das Klassendiagramm vervollständigen
    • fünf weitere UML-Diagramme erstellen
    • zwei Entwurfsmuster und eine sonstige Entwurfsmaßnahme einsetzen
  • Zuletzt folgen acht Wissensfragen, die nichts mit dem Projekt zu tun haben.

Einführung

Definitionen

Software Engineering befasst sich mit Techniken und Methoden

  • das Softwareprodukt möglichst fehlerfrei und möglichst nahe an den tatsächlichen Wünschen des Anwenders orientiert zu erstellen,
  • ständige Änderungen der Anforderungen zu bewältigen,
  • die zu jeder Zeit von jedem Entwickler zu bewältigende Komplexität klein zu halten,
  • eine geregelte und effiziente Zusammenarbeit aller Beteiligten zu ermöglichen und
  • dies alles in einem rationellen und planbaren Kosten- und Zeitrahmen zu realisieren.
Software Engineering ist die zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. (Prof. Helmut Balzert)

Software Engineering ist Programmierung unter mindestens einer der folgenden beiden Bedingungen (Parnas):

  • Mehr als eine Person ist befasst mit der Erstellung und/oder dem Gebrauch des Programms.
  • Mehr als eine Version des Programms wird erstellt werden.

Auf Software Engineering kann verzichten, wer alleine ein Programm für der einmaligen alleinigen Gebrauch entwickelt!

Objektorientierte Systementwicklung

Anforderungen / Aufwandsermittlung

Anforderungen

  • Anwender können ihre Anforderungen im Vorfeld nicht erkennen! (V-Modell XT: Auftraggeber muss alle Anforderungen im Vorfeld formulieren; V-Modell 97 und RUP: Anforderungserfassung ist Aufgabe des Auftragnehmers)
  • Durchschnittswerte: Anforderungen ändern sich monatlich um 2%, ausgelieferte Software erfüllt lediglich 61% der Anforderungen, 67% der Kosten eines Projekts beruhen auf falschen Anforderungen
  • Anforderungen basieren auf Wünschen → Wünsche basieren auf Anwendungsfällen
  • Möglichkeiten, Anforderungen/Anwendungsfälle zu finden, siehe Tabellen S. 70 und 71 (z.B. Brainstorming, Workshop, Interview, Reviews etc.)

Anwendungsfälle

Ein Anwendungsfall ist eine **vollständige Systemfunktion aus der Sicht des Anwenders**, vom auslösenden Ereignis bis zum Vorliegen des gewünschten Ergebnisses. Dabei muss das auslösende Ereignis keine Anwenderaktion sein; es kann auch von einem anderen System oder aus der Systemumgebung stammen. Entsprechend kann das erwünschte Ergebnis eine Ausgabe an den Anwender, an ein anderes System oder an die Systemumgebung sein. Interne Ereignisse des Systems werden nicht betrachtet. Für jeden Anwendungsfall wird eine Bezeichnung aus einem Objekt und einem Verb gewählt. Dabei ist es nicht festgelegt, ob der Name aus Sicht des Anwenders oder des Systems formuliert wird; meist ist eine Mischung für die Verständlichkeit sinnvoll, z.B. "Getränk wählen", "Getränk zubereiten".
  • Spezifikation von Use Cases (ab S. 74)
    • Ablaufskript
    • Entscheidungstabelle
      • n binäre Bedingungen erfordern 2^n Regeln; dabei muss eine Regel mit jeder enthaltenen Irrelevanz doppelt gezählt werden
    • Aktivitätsdiagramm (ab S. 76)

=

Formulieren von Anforderungen
Stakeholder ist jede Person, Gruppe oder Institution, die an dem zu entwickelnden Produkt oder dessen Herstellungsprozess in irgend einer Weise – positiv oder negativ – interessiert ist. (Liste möglicher Stakeholder S. 81)
  • Volere-Template und -Klassifizierung S. 81
  • nicht-funktionale Anforderungen können die Systemarchitektur stärker beeinflussen als funktionale
  • Anforderungen an Anforderungen (S. 83)
    • vollständig
    • eindeutig definiert / abgegrenzt
    • verständlich beschrieben
    • atomar
    • identifizierbar
    • einheitlich dokumentiert
    • notwendig
    • nachprüfbar
    • rück- und vorwärtsverfolgbar
  • Verfälschung von Anforderungen
    • Bei der Wahrnehmung der Realität durch den Autor der Anforderung.
    • Bei der Formulierung der wahrgenommenen Realität durch den Autor der Anforderung.
  • Mögliche Verfälschungen (S. 85)
    • Tilgung
    • unterspezifizierte Prozessworte
    • Verallgemeinerung
    • Verzerrung
  • Template
    • [when][under what conditions] the system (shall | should | will) [be capable of | provide <whom> the ability to] <process> what how
      • Requirements Management
        • Requirements Engineering (Erfassung, Qualitätssicherung und Definition)
        • Requirements Tracing (Sicherstellen, dass im Laufe des Entwicklungsprozesses keine Anforderung verloren geht, und dass alles, was realisiert wird, auf einer Anforderung basiert)
        • Change Management (Umgang mit Anforderungsänderungen, Versionierung)
        • Requirements Documentation (Strukturierte Verwaltung aller Anforderungen mit Abhängigkeiten, Beziehungen, Versionen und Zugriffsrechten).

      Aufwandsermittlung

  • Warum Aufwandsermittlung?
    • Angebot auf Ausschreibung. Auftrag wirtschaftlich sinnvoll (Auftraggeber/freier Markt)? Reichen die Ressourcen?
  • Einflussgrößen (S. 88): z.B. Programmtyp, Qualität des Programmierers, Programmiersprache, Organisation etc.
  • Methoden
    • Analogieschätzung
    • Delphi-Methode
    • Faktorenschätzung
    • COCOMO (S. 89)
    • Function Points (S. 90)
    • Use Case Points

=

Analyse und Architektur

Aufgabe jeder Softwareentwicklung ist es, die Lücke zwischen den Anforderungen einerseits und einem von einem Prozessor ausführbaren Code andererseits zu schließen. Die objektorientierte Analyse hat dabei die Teilaufgabe, aus den Erkenntnissen der Anforderungsanalyse ein objektorientiertes System zu modellieren, das in der Lage ist, die Anforderungen zu erfüllen.
  • Wesentliche Sichten auf ein System (S. 91)
    • Funktionale Sicht – was soll das System wie tun?
    • Statische Sicht – Bestandteile und Strukturen des Systems
    • Kommunikationsstruktur – wer kommuniziert mit wem mit welchem Inhalt?
    • Kommunikationsablauf – wer kommuniziert mit wem wie in welcher Reihenfolge, um eine Aufgabe zu lösen?
    • Zustandsautomaten – wie verhält sich jedes einzelne Objekt, um seinen Beitrag zur Aufgabenlösung zu leisten?
    • (Das Zeitverhalten eines Systems - wer macht wann was wie lange / bis wann?)
    • (Der physikalische Aufbau eines Systems - welche Komponente sitzt wo?)
    • (Ablaufstrukturen - wie hängen verschiedene Teilabläufe zusammen?)
  • Verantwortlichkeitsprinzip (ein Objekt übernimmt genau eine sinnvoll definierte Aufgabe im System)
    • CRC-Karten (Class-Responsibility-Collaboration, S. 92, Beispiel S. 110)
  • Klassen finden
    • Beobachtung der realen Welt, lesen von Spezifikationen etc.
    • Textanalyse
      • Substantive → Synonyme/Attribute streichen → Verantwortlichkeit suchen
    • Historische Analyse
    • Jacobson-Verfahren
      • Objekte der realen Welt (Entity Classes)
      • Use Cases (Control Classes)
      • Schnittstellenfunktionen im Use-Case-Diagramm (Boundary Classes)
      • Swimlanes im Aktivitätsdiagramm
    • Outside-In-Analyse (S. 97, Beispiel Tastatur S. 98)
      • Boundary- und Entity-Objekte finden → unterster Layer der Architektur und Presentation Tier
      • Verantwortlichkeitsobjekte aus Aktivitätsdiagramm
      • Teilverantwortungen delegieren → nur noch eine Aufgabe je Objekt
      • Delegation "nach oben"

=

Architektur
The organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts… Parts that interact through interfaces include classes, components and subsystems. (RUP)
  • Sichten der Architektur (S. 94)
    • Design
    • Implementation
    • Process
    • Deployment
    • Use Case
  • Architekturmuster (S. 95)

=

Strukturen
  • Assoziation, Aggregation, Komposition (S. 99)
    • beidseitig, einseitig, undefiniert navigierbar
  • Generalisierung / Spezialisierung (S. 100)
    • disjoint / non-disjoint, complete / incomplete (Default: incomplete/disjoint)

Interfaces

Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung
  • Information Hiding
  • Prinzip der einfachen Schnittstellen
  • provided / required interface

=

Zustandsautomaten
  • Mealy-Automat: Aktionen im Zustandsübergang, Moore-Automat: Aktionen beim Betreten eines Zustands
  • Aktionen (z.B. Setzen/Testen eines Flags, Ein-/Ausschalten eines Relais) sind atomar, d.h. sie benötigen theoretisch keine Zeit → Zustandsübergänge benötigen keine Zeit
  • Aktivitäten (z.B. Öffnen einer Türe, komplexe Berechnung) benötigen Zeit → finden nur in Zuständen statt
  • Erweiterter Endlicher Automat: kann außer seinem Zustand weitere Daten verwalten, in Aktionen ändern und seine Transitionen davon abhängig machen (diese Möglichkeit sollte aber nur für Zählvariable und Flags genutzt werden)
  • History (S. 120)
  • Entwicklung eines Zustandsautomaten (S. 120)
    • Suche alle Nachrichten, die dem Objekt gesendet werden können (am einfachsten in Sequenzdiagrammen), und alle zeitgesteurten Ereignisse.
    • Suche alle External Inputs, die das Objekt empfangen kann. External Inputs sind Ereignisse, die keine Nachrichten sind, z.B. Eingangsgrößen eines Sensors.
    • Suche alle unterscheidbaren Zustände des Objekts. Ein Zustand ist eine Situation, in der das Objekt in Ruhe ist oder eine Aktivität ausübt und dabei auf etwas wartet.
    • Überprüfe gleich erscheinende Zustände darauf, ob sie wirklich gleich sind; sie sind es nicht, wenn sie auf neue Ereignisse unterschiedlich reagieren. Häufig zeigt sich dabei, dass eine zusätzliche Nachricht erforderlich ist, um einen Zustandsübergang auszulösen.
    • Prüfe, ob sich mehrere Zustände nur durch den Wert einer Zählvariablen oder eines Flags unterscheiden; denn könnte ein Erweiterter Endlicher Automat sinnvoll sein.
    • Zeichne den ersten Zustands-Übergangs-Graphen.
    • Prüfe, ob ein Event in mehreren Zuständen einen Übergang in denselben Zielzustand bewirkt; dann könnte ein Composite State sinnvoll sein.
    • Ergänze die Aktionen. Prüfe bei jeder Aktion, ob sie den Richtlinien für entry- oder exit-Aktionen genügt, sonst ordne sie auf der Transition an.
    • Überprüfe Transitionen, die in den alten Zustand zurückführen, daraufhin, ob sie die entry- und exit-Aktionen durchlaufen sollen oder nicht.
    • Definiere den Startzustand und ergänze den Initial Pseudostate und evtl. erforderliche Aktionen zur Initialisierung.
  • SDL
  • State-Event-Matrix
    • Alle geplanten State-Event-Kombinationen eintragen. Dann Leerfelder füllen:
    • Die Kombination kann auftreten und wurde einfach vergessen. Sie wird nachgetragen.
    • Die Kombination kann auftreten, das Event kann aber nicht verarbeitet werden und muss aufbewahrt werden – Eintrag "defer".
    • Die Kombination kann auftreten, soll aber ignoriert werden; Feld wird mit "–" markiert.
    • Die Kombination kann in fehlerfreiem Betrieb nicht auftreten, ist also ein Hinweis auf einen Fehler; Feld wird zunächst mit "e" markiert.
  • Behavior State Machine (steuert das Verhalten eines Objekts)
  • Protocol State Machine (unterscheidet zulässige von unzulässigen Nachrichtensequenzen, mögliche Spezifizierung von Constraints)

Constraints

A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.
  • Preconditions
  • Postconditions
  • Invarianten
  • Object Constraint Language (Beispiel S. 126)
  • Programming by Contract
    • Auftragnehmer prüft Vorbedingungen, Nachbedingungen und Invarianten

=

Design

  • Aufgaben der Designphase → Wie wird die Aufgabe gelöst? <> Analyse: Was wird gelöst?
    • Modularisierung
    • Strukturierung
    • Spezifizierung als Grundlage für Codierung und Test
  • Vier-Komponenten-Modell
    • Human Interaction Component (→ Presentation Tier)
    • Problem Domain Component (Ergebnis der Analyse, → Business Logic Tier)
    • System Interaction Component (→ Distribution Tier)
    • Data Management Component (→ Persistence Tier)
  • Ziel: Wiederverwendbarkeit und Flexibilität
    • Hat "meine Klasse" mehr Kenntnisse über das System, in dem sie eingesetzt wird, als unbedingt erforderlich?
    • Besitzt das System mehr Kenntnisse über meine Klasse, um sie ansprechen zu können, als für den eigentlichen Zweck unbedingt erforderlich?
    • Ist meine Klasse sehr hoch spezialisiert?
    • Enthält meine Klasse mehrere änderungsanfällige Aspekte?
    • Enthalten die Methoden Fallunterscheidungen?

Designrichtlinien und -empfehlungen

  • Trennung von Schnittstelle und Implementierung
  • Komposition anstatt Vererbung
  • Einrichten nicht konkreter Klassen (Kapselung von Algorithmen)
  • Wiederverwendbare Klassen erzeugen
  • Wiederverwendbare Komponenten nutzen
  • Protokolle definieren, Protokollklassen einrichten
  • Root-Klassen definieren
  • Objektbeziehungen konkretisieren
  • Performance verbessern
  • Schnittstellen zu DMC und HIC vorbereiten
  • Gerätetreiber definieren
  • Virtuelle Maschinen konstruieren

Objektorientierte Metriken (S. 147)

  • Kopplung: Wissen der Objekte über ihre Umgebung
  • Kohäsion: Verantwortlichkeit der Objekte
  • Weighted methods per class (WMC)
  • Depth in inheritance tree (DIT)
  • Number of immediate children (NOC)
  • Coupling between objects (CBO)
  • Response for a class (RFC)
  • Lack of cohesion in methods (LCOM)
  • Weitere
    • Number of message sends (NOM)
    • Number of Instance Methods (NIM, = WMC mit Einheitsgewicht 1)
    • Number of Methods Added (NMA)
    • Number of Methods Overridden (NMO)
    • Number of Operators Overloaded
    • Number of Parametrized Classes
    • Number of Objects Composed

Human Interaction Component (S. 149)

  • Benutzer klassifizieren
    • Erfahrungsstand
    • Hierarchieebene
    • Gruppenzugehörigkeit
  • Szenarios erstellen
  • Kommandostruktur entwerfen
    • Beispiele und Richtlinien studieren
    • Entwurf erstellen und überprüfen
    • Views entwerfen
    • Prototyping
    • Klassenmodell erstellen
    • Verbindung zur PDC

Data Management Component

  • Kapselung der Speicherorganisation
  • Zugriffsverriegelung und Datenkonsistenz
  • Klassenmodell der DMC → Object Server

Systemschnittstelle

  • Tasks identifizieren (S. 155)
    • Ereignisgetrieben
    • Zeitgetrieben
    • Hochprior oder kritisch
  • Tasks definieren: Für jede identifizierte Task wird festgelegt

ƒ * wie sie heißt,

  • welche Aufgabe sie hat,
  • durch welche Ereignisse oder durch welchen Zeitablauf sie gestartet wird,
  • welche Priorität sie besitzt,
  • welche Services welcher Objekte sie aufruft,
  • auf welchem Weg sie Informationen erhält oder weitergibt (Nachrichtenparameter, Mailbox, Pipe, Buffer…).
Die UML unterscheidet aktive und nicht aktive Objekte: Ein aktives Objekt besitzt einen eigenen Thread of Control, ein nicht aktives Objekt liegt im Thread eines aktiven und kann von ihm aufgerufen werden. In einem objektorientierten System ist also ein aktives Objekt der Kern einer Task.
  • Aktives Objekt und no-wait-Semantik
  • Timer-Service
    • Scheduler einrichten
      • preemptives Scheduling
      • nicht-preemptives/kooperatives Scheduling
        • gut durch Zustandsautomaten umsetzbar (S. 157)
      • Scheduling sollte durch Narichtenpriorität gesteuert werden

    Hardware-Schnittstelle

  • Interrupts
  • Polling
  • Ausgabe

=

Implementierung

  • Konzept für automatisch generierbare technische Systeme (S. 168)
    • Jedes Objekt, das nicht ausschließlich Daten verwaltet, ist ein Aktives Objekt.
    • Jedes Aktive Objekt ist ein Zustandsautomat.
    • Jeder Zustandsautomat arbeitet nach dem "Run to Completion"-Prinzip.
    • Alle Aktiven Objekte kommunizieren durch Message Passing.
    • Das Scheduling ist durch Nachrichtenprioritäten gesteuert.
    • No-wait-Semantik und Scheduling nach Nachrichtenprioritäten werden durch einen zentralen Nachrichtenpuffer gewährleistet.
    • Scheduler, Timerdienst, Messagehandler, I/O-Services und wichtige Signalverarbeitungsalgorithmen werden von der Plattform zur Verfügung gestellt.
    • Alle Objekte und I/O-Ports werden von einem Erbauer erzeugt und installiert.
"Run to Completion" (RTC) ist das in der UML 2 definierte Verhalten eines nebenläufigen Zustandsautomaten: Ein Zustandsautomat befindet sich vom Start bis zum Ende einer Transition im "Run to Completion Step"; dieser darf durch eine neue Anforderung an dasselbe Objekt nicht unterbrochen werden, da der Zustand des Objekts während einer Transition undefiniert ist. Zum Run to Completion Step gehören auch Methoden nicht aktiver Objekte, die von der Transition aufgerufen werden.

> SDL ist eine formale Sprache mit dem Ziel der Spezifikation und Beschreibung des Verhaltens von Telekommunikationssystemen (insbesondere in den Funktionsbereichen Anrufbearbeitung, Wartung, Fehlerbehandlung, Systemkontrolle sowie beim Entwurf von Datenkommunikationsprotokollen). Aufgrund ihrer Eigenschaften ist SDL generell zur Verhaltensspezifikation von Echtzeitsystemen geeignet. Die Sprache ist in grafischer und textueller Notation definiert. SDL enthält eine Reihe von Konzepten wie Typen-, Instanzen-, Kommunikations- und Sichtbarkeitskonzept und dynamische Semantik. Aufgrund ihrer formal korrekten Syntax und Semantik sind SDL-Spezifikationen zur automatischen Konsistenzprüfung geeignet.

Tests

  • Statische Analyse
  • Korrektheitsbeweis
  • Test
    • Objektklassentest (S. 177)
      • Entwicklung eines Testrahmens, der die importierten Funktionen (required interface) simuliert, die exportierten Funktionen (provided interface) stimuliert (anregt) und die Arbeitsweise kontrolliert.
    • Integration
  • Auswahl der Testdaten
    • Black-box <––> White-box-Test
    • Äquivalenzklassen
      • Klassifikationsbaummethode
      • OO Äquivalenzklassen → Folgen von Änderungsoperationen
  • Testüberdeckung
    • C1-/C2-Überdeckung (S. 182)
  • OO-Test (S. 183)
    • Test abstrakter und abgeleiteter Klassen
    • Integrationstest
    • Test zyklischer Kommunikation
    • Test in der Multitasking-Plattform
  • Testwerkzeuge
    • Debugger
    • In das Programm eingebauter "Debugger"
  • Testlogbuch
    • Nachweis über durchgeführte/durchzuführende Tests
    • ermöglicht Regressionstests

Wartung

  • Wartungskosten ⇒ 1,5 * Herstellungskosten
  • Arten von Wartungsarbeiten
    • Anpassung an neue Anforderungen
    • Anpassung an andere Maschine
    • Innerbetriebliche Belange
    • Fehlerbeseitigung

Entwicklungsprozess

Ein Prozess(modell) besteht aus

  • Vorgehensmodell
    • wann und unter
    • welchen Voraussetzungen
    • welches Produkt durch
    • welche Aktivität mit
  • Methodenzuordnung
    • welcher Methode unter Verwendung von
    • welchem Werkzeug entsteht, und
  • Rollenzuordnung
    • wer wie daran beteiligt ist.

Wasserfallmodelle

  • Klassisch
    • Analyse
    • Definition
    • Entwurf
    • Implementierung
    • Wartung
  • 60 - 80% aller Fehler entstehen in der Analysephase! Analysefehler erzeugen 60 - 70 % der Gesamtkosten!
  • erweitert: mit Validierungsphasen
  • V-Modell von Boehm

Prototyping und iterative Modelle

  • Evolutionäres Prototyping
    • Spiralmodell
  • Rapid Prototyping
  • Exploratives Prototyping
    • Baseballmodell
  • Vorteile
    • Risiken werden früh erkannt
    • dem Kunden kann etwas vorgefüht werden
    • offene Fragen können am Beispiel ausprobiert/geklärt werden

Inkrementelle Entwicklung

  • Erstellen (und Ausliefern) des Produktes in mehreren zunehmend vollständigen Versionen

V-Modell 97

  • Internationaler Standard des Bundesinnenministeriums
  • Stellt die Anforderungen an das System (Hard- und Software) in den Vordergrund
  • Submodelle
    • Systemerstellung
    • Qualitätssicherung
    • Konfigurationsmanagement
    • (technisches) Projektmanagement
  • Dokumente werden von Aktivitäten erzeugt
  • Rollen und Rollenzuordnung (S. 21)
  • Jeder Aktivität werden Methoden (Elementarmethoden S. 24) und Werkzeuge zugeordnet
  • Szenarien
    • Inkrementelle Entwicklung (Regelfall)
    • Grand Design (Traditionelles Vorgehen)
    • Einsatz von Fertigprodukten
    • Objektorientierte Entwicklung
    • Entwicklung wissensbasierter Systeme
    • Software-Pflege und -Änderung
  • Durch Tailoring wird aus dem V-Modell das Projekthandbuch erstellt (S. 30)
  • Nachteile: schwerfällig, ausufernde Dokumentation, Tailoring/Erstellen des Projekthandbuchs ist Handarbeit (Fehlerquelle)

V-Modell XT

  • Seit 2004 verbindlich für Aufträge des Bundes
  • Vorgehensbausteine kapseln Rollen, Produkte und Aktivitäten (entsprechen etwa den Submodellen des V-Modells 97) → Weltkarte (S. 34)
  • Durchführungsstrategien (entsprechen Szenarien des V-Modells 97) (ggf. getrennte Strategien für AG und AN)
    • Agile Entwicklung
    • Komponentenbasierte Entwicklung
    • Auftraggeberprojekte
    • Grand Design
    • Objektorientierte Entwicklung
    • Entwicklung wissensbasierter Systeme
  • Entscheidungspunkte
  • Methoden und Werkzeuge
  • Rollen
  • Nachteile
    • Wust von unstrukturierten Texten
    • Wichtige Workflows/Rollen fehlen oder sind schwer auffindbar
    • Anforderungen werden als gegeben vorausgesetzt

Rational Unified Process

  • Ausschließlich für objektorientierte Softwareentwicklung mit der UML geeignet
  • iterativ (alle Aktivitäten werden mehrfach durchlaufen) und inkrementell (jede Iteration bring einen Mehrwert)
  • Use-Case-getrieben
  • Architekturzentriert
  • Phasen
    • Inception
    • Elaboration
    • Construction
    • Transition
  • Workflows (entsprechen insgesamt dem Submodell SE des V-Modells 97)
    • Business Modeling
    • Requirements
    • Analysis and Design
    • Implementation
    • Test
    • Deployment
  • 80% rule
  • Timeboxing
  • Nachteile
    • Kommerzielles Produkt mit Verweisen auf kommerzielle Tools von Rational
  • Spezialisierung des RUP für kommerzielle Client-/Server-Anwendungen: Object Engineering Process von Bernd Oesterreich
    • Timepacing

Agile Prozesse

  • Agile Manifesto (S. 52)
  • Extreme Programming
  • Crystal Methodenfamilie

Qualität des Entwicklungsprozesses

  • Process Maturity Levels
    • initial
    • repeatable
    • managed (defined)
    • measured (managed)
    • optimized (optimizing)
  • Capability Maturity Model
    • Key Process Areas → erreichen Ziele
    • Common Features → richten sich an Implementierung und Institutionalisierung
    • Key Practises → beschreiben Infrastruktur und Aktivitäten
  • Capability Maturity Model Integration
    • modulares Konzept → Integration neuer Entwicklungsdisziplinen
    • staged representation → CMM
    • continuous representation → Bewertung einzelner Prozessbereiche
    • Prozessbereiche (mit Zielen ab S. 60)
      • Process Management
      • Project Management
      • Engineering
      • Support
    • Standard CMMI Appraisal Method for Process Improvement
  • Software Process Improvement and Capability dEtermination
    • internationaler Standard (ISO 15504)
    • inhaltlich zu 90% mit CMMI deckungsgleich
  • Bootstrap
  • DIN EN ISO 9000 ff
    • "Schreib immer auf, wie du etwas machst, und tu alles so, wie es aufgeschrieben ist."
  • Six Sigma

Qualitätssicherung

  • Review
    • Schreibtischtest
    • Vier-Augen-Test
    • Structured Walkthrough (Yourdon)
    • Inspection (IBM)
    • Fagan-Inspection (IBM)
      • Vorgegeben Vorgehensmuster für verschiedene Dokumentklassen
      • Autor nicht (!) Vorleser des Dokuments
  • Statische Analyse
  • Konstruktive Maßnahmen
    • z.B. CodingStandards, CodingConventions, "sichere" Programmiersprachen
Total Quality Management (TQM) bezeichnet die durchgängige, fortwährende und alle Bereiche einer Organisation (Unternehmen, Institution, etc.) erfassende aufzeichnende, sichtende, organisierende und kontrollierende Tätigkeit, die dazu dient, Qualität als Systemziel einzuführen und dauerhaft zu garantieren. (S. 68)

ToDo

  • Eigene Aufzeichnungen zur Vorlesung durchgehen
  • Lernziele des Skripts anschauen
  • Praktikumsunterlagen anschauen
  • Aufgaben zum Übungsprojekt Handhabungsautomat lösen
  • UML-Diagrammtypen detaillierter anschauen
    • Use-Case-Diagramm
    • Aktivitätsdiagramm
      • Pins
      • Control / Object Flow
      • Beispiel von Robra (implizites Join oder so)
    • Komponentendiagramm
      • Ports (behavior port)
      • subsystem
    • Kompositions-Strukturdiagramm
    • Verteilungsdiagramm
      • Artefakte
    • Kommunikationsdiagramm
    • Sequenzdiagramm
      • Combined Fragments
    • Interaktions-Übersichtsdiagramm
    • Timing-Diagramm
      • Kompaktdarstellung ("Bonbon")
    • Zustandsautomaten
  • Nähere Informationen einholen
    • Extreme Programming
    • Zustandsautomaten
    • MVC. Welche Aufgabe hat der Controller?
    • SDL
    • OCL
    • Petri-Netze (?)
    • CORBA, CCM, COM, EJB, CAN(open) (?)
    • MDA
    • Was ist ein "aktives Objekt" genau?

Erledigt

Übungen

Seite 12

  • Bei der Nürnberger U3 werden unter den Türen vor dem Öffnen Trittbretter ausgefahren, um den Spalt zwischen Wagen und Bahnsteig zu überbrücken. Nach zwei Jahren Entwicklungszeit zeigte sich, dass alles vergeblich war, da der Spalt unterschiedliche Breite haben kann. Was ist hier falsch gemacht worden?
    • Die Entwickler haben sich nicht intensiv genug mit der Realität auseinandergesetzt. Sie sind offensichtlich nie vor Ort gewesen und haben sich die Gegebenheiten am Bahnsteig angeschaut.
  • Versuchen Sie, an einem Fahrkartenautomaten der VAG ein "Tagesticket Plus Preisstufe 4" zu lösen, und protokollieren Sie Ihren Arbeitsablauf.
  • Wieso hat auch der Hersteller einer Software Qualitätsanforderungen?
    • Der Hersteller sorgt nach der Auslieferung der Software auch für deren Support und Weiterentwicklung. Die Kosten hierfür übersteigen die Entwicklungskosten im Allgemeinen deutlich (Wert aus der Literatur: Faktor 1,5). Der Hersteller sollte also sicherstellen, dass seine Software wartungsfreundlich und leicht erweiterbar ist. Des Weiteren hat der Hersteller durchaus einen Ruf zu verlieren, wenn er qualitativ minderwertige Software herstellt.
  • Sie entwickeln für die "Ich-AG" eines Freundes ein einfaches Buchhaltungsprogramm. Was halten Sie dabei von Software Engineering?
    • Da das Programm evtl. von mehreren Personen genutzt wird und sicherlich auch mehr als einmal, ist Software-Engineering unumgänglich.
  • An einem großen Projekt arbeiten 150 Softwareentwickler. Wie ist das möglich?
    • Durch Berücksichtigung der Pronzipien des Software-Engineerings: Modularisierung, Tests, Arbeitsteilung, detailliertes Design etc.
  • Angenommen, Sie lesen in der Zeitung, dass ein neues Softwareprojekt in drei Jahren abgeschlossen sein und 15 Mio. € kosten soll. Mit welchen Ergebnissen müssen

Sie rechnen?

  • Die Entwicklungsdauer und -kosten werden die geplanten Werte sehr wahrscheinlich übersteigen. Aus den bekannten Durchschnittswerten aus der Literatur könnten die voraussichtlichen Werte ermittelt werden.

Seite 55

  • Was regelt ein Prozess?
    • Ein Prozess regelt die Rahmenbedingungen, unter denen eine Software entwickelt wird (z.B. die Teilnehmer, die Entwicklungsmethoden und die verwendeten Werkzeuge).
  • Was ist eine Rolle?
    • Eine Rolle fasst Aufgaben zusammen, die von Mitarbeitern in einem Prozess wahrgenommen werden müssen (z.B. System Engineer). Eine Rolle kann von mehreren Mitarbeitern wahrgenommen werden und ebenso kann ein Mitarbeiter mehrere Rollen innehaben.
  • Was macht ein Vorgehen nach dem Wasserfallmodell riskant und teuer?
    • Fehler werden spät entdeckt und ihre Behebung kostet dann entsprechend mehr.
  • Wodurch unterscheidet sich das ursprüngliche V-Modell nach Boehm von einem Wasserfallmodell?
    • Das V-Modell sieht für jede Phase des ursprünglichen Wasserfallmodells eine entsprechende Testphase vor und erlaubt ausdrücklich Sprünge in frühere Phasen, wenn Fehler auftreten.
  • Was bedeutet das "V" im V-Modell 97?
    • Vorgehensmodell
  • Versuchen Sie, in den V-Modellen 97 und XT etwas zu finden, was dem Requirements Workflow des RUP entspricht.
    • V-Modell 97: Unterpunkte von SE 1: z.B. Anforderungen an die Qualität definieren, Randbedingungen definieren etc. Das Ergebnis von SE 1 sind die Anwenderanforderungen.
    • V-Modell XT: Die Anforderungen müssen komplett vom AG geliefert werden.
  • Ist es nach der aktuellen Weltkarte der Vorgehensbausteine des V-Modell XT möglich, einen Prozess für ein sicherheitsrelevantes System zu definieren, das weder

HW noch SW enthält und keine Anforderungsfestlegung benötigt?

  • Nein. Systemsicherheit erfordert alle drei genannten Komponenten.
  • Wann soll im RUP die erste Version der Architektur vorliegen?
  • Am Ende der Elaboration-Phase.
  • Was unterscheidet den OEP vom RUP?
  • Ausrichtung auf kommerzielle Systeme
  • Timeboxing wird durch Timepacing (feste Abfolge von Terminen innerhalb einer Iteration) ersetzt
  • Wo findet sich das Deployment Diagram der UML in den V-Modellen 97 und XT wieder?
  • Führen Sie für Ihre Projektarbeit des Studiengangs ein "Standardisiertes Vortailoring" des V-Modells 97 durch.
  • Was ist ein "System Metaphor", zu welchem Vorgehensmodell gehört es, und zu welchem Ziel soll es beitragen?
  • Ein grober Überblick über das zu erstellende Gesamtsystem, das zu einem einheitlichen Verständnis bei den Beteiligten führen soll (Extreme Programming).
  • Um den Termin halten zu können, verordnet der Projektleiter seinen Programmierern für die nächsten vier Wochen 20% Überstunden. Welchen Erfolg kann er erwarten?
  • Überstunden wirken sich allerhöchstens kurzfristig aus. Auf längere Sicht führt die Mehrarbeit zu nachlassender Leistung bei den Mitarbeitern.
  • Sie erhalten als Auftragnehmer vom Auftraggeber eine vollständige Anforderungsspezifikation. Womit müssen Sie nach zwei Jahren Entwicklungsdauer rechnen?
  • Ca. 2% der Die Anforderungen ändern sich pro Monat, d.h. nach 2 Jahren sind nur noch knapp die Hälfte der Anforderungen gültig.
  • Was hat TestDrivenDevelopment mit Wiederverwendung zu tun?
  • Da die Testumgebung einen zusätzlichen Klienten für die zu testenden Komponenten darstellen, wird gleich sichergestellt, dass die Komponente mit mehreren (unterschiedlichen) Klienten kooperieren kann, was ein Nachweis für die Wiederverwendbarkeit ist.
  • Was ist erforderlich, damit wiederverwendbare Komponenten auch wiederverwendet werden?
  • Wiederverwendung muss durch einen Software-Reuse-Prozess unterstützt werden.
  • Arbeiten Sie sich anhand der gegebenen Links in Scrum ein und definieren Sie eine Variante, die zu den besonderen Randbedingungen Ihrer Projektarbeit passt.

Seite 63

  • Ein Bekannter erzählt Ihnen, seine Firma sei soeben nach CMM Level 1 zertifiziert worden. Was meinen Sie dazu?
    • CMM Level 1 bedeutet keinerlei Struktur im Entwicklungsprozess.
  • Ihre Firma beginnt plötzlich, Trainingsprogramme für ihre Mitarbeiter einzurichten. Was könnte der Grund sein?
    • Erreichen eines höheren CMM-/CMMI-Levels. Die Weiter- bzw. Ausbildung von Mitarbeitern zählt zu den zu erledigenden Auflagen z.B. bei CMMI Level 2.
  • Wieso ist CMMI für eine kontinuierliche Prozessverbesserung besser geeignet als CMM?
    • CMM bewertet lediglich die Gesamtperformance des Unternehmens, während CMMI auch Teilbereiche berücksichtigt. Dadurch sind Verbesserungen besser nachvollziehbar und Schwachstellen eindeutig identifizierbar.
  • Warum wurde Bootstrap entwickelt, und warum wurde die Entwicklung eingestellt?
 Bootstrap wurde für eruropäische Firmen quasi als Konkurrenzprodukt zu CMM entwickelt, ist aber inzwischen von SPICE abgelöst.

* Worin besteht die Verwandtschaft zwischen CMMI, SPICE und Bootstrap und der Unterschied zu CMM?

  • Die drei genannten Verfahren beinhalten auch die kontinuierliche Bewertung von Teilbereichen des Unternehmens, während CMM nur 5 allgemeine Stufen das Gesamtunternehmen betreffend anbietet.
  • Die Kosten eines Projekts wurden auf 5 Mio. € geschätzt; im Angebot stehen aber 6,2 Mio. €. Welche Berechnung könnte dahinter stehen?
  • Ein Softwarehaus, das auch Unteraufträge vergibt, möchte sich nach CMM zertifizieren lassen. Worauf muss es besonders achten?
  • Auf die Zertifizierung seiner Unterauftragnehmer.
  • Welche Reifegrade kennt ISO 9003?
  • Keine. Lediglich "bestanden" oder "nicht bestanden".
  • Woran denken Sie, wenn Sie SCAMPI hören?
  • An ein Bewertungsverfahren zu CMMI.
  • Wo ist von Stakeholdern die Rede?
  • Bei CMMI Level 2.

Seite 68

  • Hat es einen Sinn, auch für nicht-objektorientierte Programmierung C++ anstatt C einzusetzen?
    • Ja, denn C++ ist "sicherer" als C und trägt damit zur konstruktiven Qualitätssicherung bei.
  • Kann man ein Peer Review auch als konstruktive Maßnahme bezeichnen, und warum (nicht)?
    • Nein, da Reviews im Nachhinein Fehler finden sollen und diese nicht vorab verhindern.
  • Wie viele Teilnehmer erfordert ein Structured Walkthrough mindestens?
    • 6: Autor, Moderator, Schriftführer, 3 Reviewer (Wartungsprophet, Normenreiter, Benutzervertreter)
  • Ihr Abteilungsleiter will an Reviewsitzungen teilnehmen. Darf er das?
    • Nein, denn ein Review soll ungezwungen ablaufen und die (negativen) Ergebnisse dürfen nicht zur Bewertung von Mitarbeitern herangezogen werden.

Seite 86

  • Welche Techniken zur Spezifikation von Use Cases kennen Sie?
    • Aktivitätsdiagramm, Entscheidungstabelle, Ablaufskript
  • Wann ist eine Anforderung rechtlich irrelevant?
    • Wenn ihre Umsetzung im Produkt nicht zweifelsfrei nachgewiesen werden kann.
  • Welche Einflüsse könnten welche Stakeholder auf den Getränkeautomaten haben?
  • "Das Bezahlen kann durch Druck auf die Rückgabetaste abgebrochen werden; der Kunde erhält daraufhin sein eingeworfenes Geld zurück." Welche Fehler hat diese Anforderung? Formulieren Sie sie neu (dabei können es mehrere werden)!
    • Tilgung (Wann kann abgebrochen werden?), Verzerrung (Bekommt er tatsächlich sein Geld zurück?)

Seite 90

  • Für ein neuartiges Embedded System wurden 200 RFP gezählt. Es soll in C implementiert werden. Mit welchem Entwicklungsaufwand ist zu rechnen, und wie lange dauert die Entwicklung?
  • Was ergibt sich mit derselben Anzahl von RFP für eine einfache Datenbankapplikation in SQL?
  • Welcher Ihnen aus XP bekannte Begriff taucht oben in der Delphi-Methode auf?
    • System Metaphor (grundsätzlicher Überblick, grobes Verständnis des zu entwickelnden Produktes)

Seite 107

  • Was bedeutet MVC?
    • Model View Controller, ein Architekturmuster, das auf drei Schichten basiert
  • Welche Elementarmethode des V-Modells '97 hat mit Verantwortlichkeit zu tun?
    • CRC-Karten
  • Welche Objekte liefert eine Textanalyse des Satzes "Bei jedem Münzeinwurf wird der Wert der Münze vom Münzprüfer erkannt.", und warum?
    • Münze, Münzprüfer (Wert ist lediglich ein Attribut von Münze, Münzeinwurf ist eine Tätigkeit)
  • Was ist der Unterschied zwischen Assoziation, Aggregation und Komposition?
    • Aggregation → Teil-/Ganzes-Beziehung. Komposition → Aggregation mit Existenzabhängigkeit zwischen Teil und Ganzem.
  • Was stellt das nebenstehende Bild dar, und was fehlt hier eigentlich?
    • Generalization Sets
  • Die UML kennt zur Strukturierung von Modellelementen auch noch das Package. Warum ist es zur Architekturmodellierung nicht geeignet?
    • Packages definieren eher logische Einheiten auf Sourcecode-Ebene.
  • Was ist ein Persistence Tier?
    • Die Schicht der Architektur, die die Datenhaltung übernimmt.
  • Was kann ein Node enthalten?
    • Weitere Nodes und Artefakte.
  • Welche Arten von Interfaces unterscheidet die UML 2?
    • provided und required

Seite 124

  • Was ist ein Combined Fragment?
    • Mögliche Strukturierungselemente eines Aktvitätsdiagramms (z.B. opt, loop etc.)
  • Was ist eine Execution Specification?
    • Früher: Focus of Control. Veranschaulicht synchrone Aufrufe im Sequenzdiagramm.
  • Was bedeutet no-wait?
    • Das Standardverhalten in der UML 2: Asynchrone, nicht-blockierende Nachrichten
  • Warum wurde das Kollaborationsdiagramm der UML 1 in Kommunikationsdiagramm umbenannt?
  • Was ist in Abb. 5-83 fehlerhaft?
  • Was ist eine interne Transition?
    • Eine Transition in denselben State ohne entry- und exit-Aktionen auszuführen
  • Was bewirkt ein defer?
    • Eine Nachricht kann im aktuellen Zustand nicht verarbeitet werden und wird "aufbewahrt", bis ein Zustand sie behandelt, oder sie gelöscht wird.
  • Welchen Vorteil bringt die Verwendung einer State-Event-Matrix?
    • Mögliche Fehler werden gefunden, mögliche Kombinationen werden durchgespielt, unzulässige Nachrichten können identifiziert und behandelt werden

Seite 126

  • Wer ist schuld, wenn eine Precondition nicht erfüllt ist?
    • Der Auftraggeber.
  • Wer ist schuld, wenn eine Postcondition nicht erfüllt ist?
    • Der Auftragnehmer.

Seite 148

  • Wo lässt sich im Getränkeautomaten sinnvoll das Interpretermuster einsetzen?
    • Interpretieren von Schlüsseln für Getränke oder Rezepte.
  • Erstellen Sie ein Klassendiagramm des Entwurfsmusters "Zustand" für den Kassierer nach Abb. 5-86.
  • Erstellen Sie ein Sequenzdiagramm für die Systemgenerierung nach dem Klassenmodell aus Abb. 5-61. Ergänzen Sie evtl. erforderliche Set-Methoden.
  • Ermitteln Sie CBO und RFC für die Klassen Auftragsannahme, Kassierer und Zubereiter aus Abb. 5-60 und Abb. 5-61.

Seite 153

  • Nehmen Sie an, MS Word hat in einem großen Dokument mit automatischer Silbentrennung ein Wort falsch getrennt, und Sie wollen das in Ordnung bringen. Schreiben Sie dazu ein Szenario und versuchen Sie, dieses durchzuführen.
  • Erweitern Sie das Beobachtermuster (Abb. 5-102) zu einem MVC-Muster.
  • Überarbeiten Sie das Klassenmodell aus Abb. 5-61 so, dass die Grundsätze der MVC-Architektur eingehalten werden.

Seite 164

  • Entwerfen Sie ein Klassendiagramm für ein Aktives Objekt für Methodenaufruf mit no-wait-Semantik.
  • Ergänzen Sie das Diagramm aus Abb. 5-114 links um HW-Schnittstellen.
  • Wodurch unterscheiden sich CCM, COM und EJB?
    • Durch ihre Plattform- bzw. Sprachenabhängigkeit (COM: Windows/, EJB: */Java, CCM: */)

Seite 174

  • Ihr Klassendiagramm enthält eine Mehrfachvererbung. Für die Implementierung ist Java vorgesehen. Was können Sie tun?
  • Der Codegenerator von Enterprise Architect erzeugt seltsame Präprozessor-Direktiven. Was bedeuten diese?
  • Erzeugen Sie im Enterprise Architect ein einfaches Klassendiagramm mit fünf mal zwei Klassen und zwischen jeweils zwei Klassen
    • eine explizit einseitig navigierbare Assoziation
    • eine einseitig navigierbare, einseitig undefinierte Assoziation
    • eine beidseitig undefinierte Assoziation
    • eine explizit beidseitig navigierbare Assoziation
    • ein Interface für eine der Klassen und explizit einseitig navigierbare Assoziationen in einer Richtung auf die Klasse, in der anderen auf das Interface und vergleichen Sie den generierten Code bei verschiedenen Optionseinstellungen.
  • Der Enterprise Architect kann auch ein objektorientiertes Programm einlesen und daraus ein Klassendiagramm erzeugen. Testen Sie, wie gut das funktioniert, und

von welchen Einstellungen die Qualität abhängt.

  • Was bedeutet RTC?
  • Was bedeuten PIM und PSM?
  • Unter welchen Umständen kann man auf ein PSM verzichten?
  • Wandeln Sie den Zustandsautomaten aus Abb. 5-86 in SDL um.
  • Zeichnen Sie zu Abb. 5-129 unten ein Objektdiagramm (d.h. mit alle Exemplaren der Klassen) mit ausgefüllten Feldern der Pattern-Objekte.

Seite 189

  • Vergleichen Sie die Vor- und Nachteile von Statischer Analyse, Black-Box- und White-Box-Test.
  • Was hat Abschnitt 5.10.3 mit Abb. 5-140 zu tun?
  • Wozu dient ein Regressionstester?
  • Was haben der Elchtest und die letzten französischen Atomwaffentests miteinander zu tun?
  • In einem Softwareprodukt wurden am ersten Testtag 250, am zweiten 130, am dritten 65, am vierten 30 und am fünften 15 Fehler gefunden. Wie viele Fehler sind voraussichtlich noch enthalten?
  • Eine Rechteckklasse CRect ist gekennzeichnet durch ihre linke, obere, rechte und untere Begrenzung. Sie hat u.a. einen Konstruktor CRect(int links, int oben, int rechts, int unten) und eine Methode pointinme(int x, int y), die feststellt, ob sich eine Koordinate x/y innerhalb ihrer Grenzen befindet.
    • Erstellen Sie eine Äquivalenz- und Grenzwertklassenanalyse für pointinme.
    • Was kann beim Konstruktor schief gehen, und wie lässt sich das erkennen?
    • Eine abgeleitete Klasse CResRect hat eine neue Methode resize(int dx, int dy).
    • Was muss bei ihr getestet werden, und warum?
  • Planen Sie einen Überdeckungstest für den Zustandsautomaten des Kassierers aus Abb. 5-86.
    • Zu welchen Klassen müssen für den obigen Test Simulationsklassen entwickelt werden, wenn die echten Klassen noch nicht vorliegen?
    • Wie lässt sich dieser Aufwand vermeiden?
  • Die Nachrichten "entriegeln" und "schliessen" in Abb. 5-137 kommen vom Triebwagen. Warum ist das ein Testproblem, und was kann man dagegen tun?
  • Das Subsystem Kassierer nach Abb. 5-62 soll so implementiert werden, dass es bottom-up testbar ist. In welcher Reihenfolge müssen seine Klassen und eventuell erforderlichen Simulationsklassen erstellt werden, damit alles Erstellte möglichst bald testbar ist?
  • Die Funktionalität einer Klasse Stack (Stapelspeicher) ist wie folgt definiert:
    • void push(int wert) legt die Zahl wert "oben auf den Stapel".
    • int top() liefert den obersten Wert des Stapels
    • void pop() vernichtet den obersten Wert des Stapels
    • bool empty() liefert die Information, ob der Stapel leer ist
    • void clear() löscht den gesamten Inhalt.
    • Wie sieht eine Äquivalenzklassenanalyse für diese Klasse aus?
  • Die Funktion void sort(int &a, int &b, int &c), die die Werte a, b und c aufsteigend sortieren soll, wurde so implementiert:
    void sort(int &a, int &b, int &c) 
    { 
     int t; 
      if(a > b) 
      {  t = a; a = b; b = t; } 
      if(b > c) 
      {  t = a; a = c; c = t; } 
      if(a > b) 
      {  t = a; a = b; b = t; } 
    }
    • Planen Sie einen C2-Test für diese Funktion!
  • Welchem Umstand verdankt Microsoft einen wesentlichen Marktvorteil?
se/softwaretechnologie.1203419285.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)