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