SoED

Beudeutet dass ein object attribut oder methode während laufzeit verscheidene varianten haben kann

Von dieser Klassen kann keine Instanz (Konstruktor) erstellt werden. Dient als Oberklasse von der dann geerbt wird. Z.B. Pizza wäre die Oberklasse und Margherita, Procuitto die Unterklassen die von Pizza erben. Public abstract class BLABLA

1. analysis and design view (logical view)

   1. Zeigt die Grund Abstraktionen, als Objekte oder Klassen, auf.

   2. Für funktionale Anforderungen.
       

2. process view

   1. Zeigt auf wie das System sich währen der Laufzeit verhält
      shows how, at run-time, the system is composed of interacting processes

   2. Für nicht funktionale Anforderungen
       

3. implementation view (development view)

   1. Zeigt auf wie die Software aufgebaut und aufgeteilt ist für die Entwicklung

   2. Für das Projekt Management
       

4. deployment view (physical view)

   1. Zeigt auf wie die Komponenten auf die Hardware verteilt wird

   2. Für die Entwicklung und verteilung der Software
       

5. relation of all views to use cases or scenarios (+1)

   1. Für User und System Anforderungen

OOD modelliert das System als zusammengesetzte Objekte. Das Informationsmodell (Systemzustand) wird somit auf verschiedene Objekte verteilt

1) Use Cases zu System Inhalt

2) System Inhalt zu Architektur

3) Architektur zu Klassen model

4) Klassen zu Design Model

5) Design Model zu Implementation

• Generische Produke (Build to stock, BTS) vs. Kunden spezifische („angepasste“) Produkte (Build to order, BTO)
  • BTS: Produkt wird hergestellt unabhängig davon ob ein Kundenstamm besteht
    • Lizenzen werden verkauft
    • SW Hersteller besitzt alle Lizenzrechte
      • Analogie: Automobil
  • BTO: Produkt wird für, und in Absprache mit Kunden hergestellt
    • Arbeitszeit wird verkauft
    • Kunde besitzt alle Lizenzrechte
      • Analogie: Bauvorhaben

Verifikation: Zeigen dass das System den Spezifikationen entspricht

Validation: Zeigen/Sicherstellen dass das System den Anforderungen des Verwenders entspricht

• Change anticipation: Entwicklungsprozess beinhaltet Aktivitäten die eine Prognose zu den geplanten Änderungen erzeugt (e.g. Erstellung eines Prototyps mit Hauptfunktionen)
• Change tolerance: Die Prozesse sind so implementiert, dass Änderungen zu relativ geringen Kosten (= Zeit) umgesetzt werden können. Setzt einen inkrementellen Entwicklungsprozess voraus.

• Ein Prototyp ist eine initiale Version eines verwendeten Systems benutzt um bestimmte Konzepte und neue design Optionen zu demonstrieren. Meist werden eigene Sprachen und Tools fürs schnelle Prototyping verwendet. Ein Prototyp umfasst nicht alle Funktionalitäten des Endprodukts (Meist nur Prozesse die man besser verstehen möchte).
  • Vorteile: Kostengünstige Tests und Kundenfeedback für neue Konzepte, Denken „Out of the Box“ (e.g. starke Umstrukturierung, neue Libraries) möglich
  • Nachteile: Gefahr des Abschweifens vom Wesentlichen, (= unproduktive Zeit) Kundenfeedback kann unwesentlich sein („Dieser Button geht nicht“ etc.)
  • Anwendung: Prototypen werde in den folgenden Phasen eingesetzt:
    • Requirements engineering: Besseres Verständnis der Anforderungen
    • Design: Design Optionen und UI Designs ausprobieren
    • Test: Interface Integration Tests (?)

• Prototypen können meist nicht so verändert werden, dass alle non-funktionalen Anforderungen getroffen werden
• Prototypen sind in der Regel nicht dokumentiert
• Die Struktur des Prototyps ist meist schlecht, weil schnelle Resultate zählen