sweGL - Modelle

Requirements Elicitation
1. Use Case
  1. Diagramm
    1. Nicht vergessen:
      1. Systemgrenze
      2. Akteure
      3. Beziehungen
    2. Beziehungen
      1. <<extend>>
        Das Element am Pfeilanfang 'kann' das Elemnt an der Pfeilspitze 'erweitern'
      2. <<include>>
        Das Element am Pfeilanfang 'benutzt' das Element an der Pfeilspitze
  2. Szenario
    1. In natürlicher Sprache
    2. Stichwortartig
    4. 1. Name, 2. Ziel, 3. Akteure, 4. Vorbedingung, 5. Auslöser (Trigger), 6. Beschreibung der Durchführung (Aktivitäten), 7. Alternativen (Ausnahmefälle) 8. Nachbedingung (Resultate)
    5. Aktive Formulierung (Der Bankkunde macht..)
  3. Eindeutiger Name (Verb)
  4. Nicht Kunde sondern Bankkunde
2. Anforderungen der Kunden bzw. der künftigen Benutzer ermitteln
3. Sprache der Kundschaft und der User
4. Kommunikation mit den Kundinnen und Benutzer
Requirements Analysis
1. AnalyseObjektModel aka Domänenmodell
  1. Definierung von Objekten/Klassen in SW
    1. Nomen-Verb-Analyse
      1. Nomen
        Klasse
      2. Verben
        Methode
      3. Eigennamen
        Objekt
    2. Spezialisten einbeziehen
    3. Existierende Lsg analysieren
  2. Arten von Klassen
    1. Boundary
      1. Interface
    2. Control
      1. Ausführung / Steuerung
    3. Entity
      1. Speicherung
  3. Kardinalitäten
2. Anforderungen im Hinblick auf Ihre Umsetzung analysieren
3. Modell als Grundstruktur für einen technischen Entwurf
4. Kommunikation mit Softwareentwickler
5. Semi-formale Spezifikation
6. Sequenzdiagramm aka Verhaltensmodell
  1. - Boundary - Control (1!) - Entity
  2. Akteur
System Design
1. Subsysteme
  1. Ausgangslage ist das Analyseobjektmodell
  2. Aufteilen des Entwicklungsaufwandes
  3. Änderungen in einem Subsystem des Systems ohne andere Subsysteme zu beeinflussen
  4. Verständnis: Komplexität reduzieren, jedes Subsystem hat eine eindeutige Zuständigkeit
  6. 1. 'Das Routing Subsystem ist verantwortlich für...'
  7. Auch Komponenten oder Module genannt
  8. In UML: Packages oder Components
2. Modularität
  1. Modularisierung ist eine Hauptaufgabe der Konzeption von Software
  2. Ein Modul ist ein benannter, klar abgegrenzter Teil des Systems
  3. Gute Module
    1. bilden geschlossene Einheiten
    2. sind ohne Kenntnisse über den inneren Aufbau verwendbar
    3. funktionieren korrekt ohne Kenntnisse der Einbettung in Gesamtsystem
    4. ermöglichen Komposition und Dekomposition
      1. Dekomposition, ein System wird so in Teile zerlegt, dass
        jedes Modul mit möglichst wenig Kenntnissen der übrigen Module verstanden werden kann
        das Gesamtsystem ohne Detailkenntnisse über die Module verstanden werden kann
Detailed Design
1. Randbedingungen
  1. <<invariant>>
    1. Klassen-Invariante wird von jeder Instanz dieser Klasse (Objekt) immer erfüllt
  2. <<precondition>>
    1. Vorbedingung einer Methode spezifiziert die Anforderungen an Objekte welche diese verwenden.
  3. <<postcondition>>
    1. Nachbedingung einer Methode spezifiziert die Bedingungen welche nach der Ausführung erfüllt sind wenn die Vorbedingungen eingehalten werden.
  4. Form der Spez. von RB
    1. Natürliche Sprache
    2. Mathematische Notation
2. 1. Klasse
  2. Attribute
  3. Methoden
Software Testing
1. Model-Driven-Development
  1. Arbeite nur mit Design - Modellen
  2. Automatische Codegenerierung
  3. Vorteile
    1. Verschiedene Technologien, Programmiersprachen, Plattformen
    2. “sauberer” Code
    3. Modelle dienen nicht nur der Dokumentation
  4. Probleme
    1. Abstraktion
    2. Unvollständige Spez.
    3. Interessanter, anspruchsvoller Code wird noch immer manuell programmiert
2. Ziel:
  1. Ein Test ist dann erfolgreich, wenn er einen Fehler gefunden hat
3. Stellenwert
  1. Keine Software ist frei von Fehlern
  2. Testen ist Grundlage für erfolgreiches Projekt
  3. Softwaretests sind eine Qualitätssicherungstechnik
  4. Komplexität der Softwaresysteme wächst

Next up

sweGL - Modelle

Description

Resource summary

Media attachments

Similar

	Created by anna.vonflue about 11 years ago