Softwaretechnik 8.4.08
Softwaretechnik
8.4.08
Literatur: Ian Sommerville „Software Engineering“ 8th Edition München: Peason, 2007.
Teil I Grundlagen
Hinweis: Das Fachgebiet Softwaretechnik braucht eine präzise/formalisierbare Terminologie.
Hier: orientiert an : www.informatikbegriffsnetz.de
§ 1 Grundbegriffe
§1.1 Softwaretechnik
Definition: Softwaretechnik ist dasjenige Teilgebiet der Informatik, das sich mit der Erstellung,
Nutzung und Weiterentwicklung (insbesondere großer) Softwaresysteme beschäftigt.
Feststellung: Softwaretechnik befasst sich mit Software
● in größeren, industriellen Rahmen
und zwar
● programmiersprachenunabhängig
● anwendungsunabhängig
● plattformunabhängig
Definition: Ein Softwaresystem ist eine Menge von Programmen zusammen mit den sie
begleitenden Dokumenten, die für ihre Nutzung notwendig oder hilfreich sind.
Feststellung: Software-Erstellungsprojekte scheitern oft(31,1%) oder kosten ein Vielfaches (52,7%)
siehe Chaos-Studie (1995)
Feststellung: Softwaretechnik ist eine Ingenieurwissenschaften!
Vorgehen:
●
●
●
●
Anforderungen feststellen
Modell bauen
Lösung konstruieren
Ergebniss prüfen und beweisen
§1.2 Bertachtungsrahmen der Vorlesung
Feststellung: Man kann unterscheiden :
●
●
●
Erstellung ←!
Nutzung
Weiterentwicklung
Man kann unterscheiden :
●
●
Entwicklung für den Markt
Entwicklung für einen Auftraggeber ←!
Man kann unterscheiden nach Anwendungsgebiet :
● kommerziell (z.B.: Informationssysteme)←!
● technische (z.B.: Automotive)
● mobile (z.B.: Telekommunikationssysteme)
Feststellung: Die Erstellung geschieht im Rahmen eines Projekts.
Definition: Ein Projekt ist die zeitlich begrenzte, einmalige Verfolgung eines vorgegebenen Ziels,
die zu einem definierten Ergebnis führen soll.
Definition: Ein Produkt ist ein in sich abgeschlossenes (i.a. für einen Auftraggeber bestimmtes)
Ergebnis eines erfolgreich durchgeführten Projektes.
Definition: Szenario : Ein Hersteller erstellt für einen Auftraggeber ein kommerzielles
Softwaresystem im Rahmen eines Projekts.
Zusammenfassung: 2 Folien
Szenario dieser Vorlesung :
Ein Hersteller erstellt
für einen Auftraggeber
ein Softwaresystem
im Rahmen eines Projekts
Betrachtungsrahmen
Gegeben: „diffuse Vorstellung“
Gesucht: „Produkt das Vorstellung erfüllt“
§2 Eigenschaften
§2.1 Grundlagen
Feststellung: Die Erstellung hat vielfache Eigenschaften zu erfüllen bzgl.
● Kosten
● Umfang
● Zeit
● Qualität
Skizze (Sneed´s Teufelsdreieck)
Umfang +
+ Qualität
„Radar plot“
Kiviatgraph
Kosten
-
Zeit
Die vier Faktoren stehen zueinander in Widerstreit.
§2.2 Qualitätseigenschaften
Definition: Zuverlässigkeit ist der Umfang, in dem von einem System erwartet werden kann, dass es
die beabsichtigte Funktion mit der erforderlichen Genauigkeit ausführt. Sie umfasst Korrektheit,
Robustheit und Ausfallsicherheit
Zuverlässigkeit = Korrektheit + Robustheit + Ausfallsicherheit
Definition: Korrektheit (=funktionale Korrektheit) ist der Umfang, in dem die Systemausgaben die
Anforderungen für den gewünschten Gebrauch erfüllt.
Definition: Robustheit ist der Umfang, in dem ein System bei nicht vorgesehener Verwendung ein
sinnvolles und sicheres Verhalten zeigt.
Definition: Ausfallsicherheit ist der Umfang, in dem ein System gegen Störungen unempfindlich ist.
Definition: Wartbarkeit ist der Umfang, in dem das Lokalisieren und Beheben von Fehlern, sowie
das Anpassen an veränderte Anforderungen in einem System erleichtert wird. Sie umfasst
Validierbarkeit, Flexibilität und Verständlichkeit.
Wartbarkeit = Validierbarkeit + Flexibilität + Verständlichkeit
Definition: Validierbarkeit ist der Umfang, in dem ein System erlaubt festzustellen, ob es die
Anforderungen erfüllt.
Definition: Flexibilität ist der Umfang, in dem Veränderungen eines Systems erleichtert werden.
Definition: Verständlichkeit ist der Umfang, in dem es ein System anderen Personen als den
Entwicklern erlaubt, seine Struktur, Annahmen und Einschränkungen zu erfahren.
Softwaretechnik
15.04.08
Definition: Benutzungsfreundlichkeit ist der Umfang, in dem ein System den Anforderungen der
Benutzer nach einer einfachen, sicheren und leicht erlenbaren Handhabung nachkommt.
Definition: Effizienz ist der Umfang, in dem ein System mit Betriebsmitteln sparsam umgeht.
Definition: Portabilität ist der Umfang, in dem das Überführen eines Systems in eine andere
Hard-/Software-Umgebung erleichtert wird.
Fesstellung
Bei/Nach der Erstellung eines Systems sind diese Eigenschaften nachzuweisen (z.B.: Metriken)
Die Eigenschaften stehen oft im Widerspruch zueinander.
§3 Prinzipien, Methoden, Werkzeuge
§3.1 Grundlagen
Definition: Prinzipien sind Grundsätze, die man seinem Handeln zugrunde legt.
Definition: Methoden sind planmäßig angewandte begründete Vorgehensweisen zur Erreichung von
festgelegten Zielen
Definition: Werkzeuge sind Hilfmittel, die der Unterstützung konkreter Anwendungen von Methoden
dienen
Fesstellung: Man braucht Wissen auf drei Ebenen
● Man folgt wichtigen Prinzipien
● Man wendet hierzu konforme Methoden an
● Man benutzt dazu passende Werkzeuge
Man braucht hierzu passende Sprachen (Notationen, Diagramme, ...)
§3.2 Prinzipien
Fesstellung Mit den Prinzipien versucht man Erfahrungswissen auf den Punkt zu bringen. Sie
werden von allen „Kompetenten und Gutwilligen“ akzeptiert.
Übersicht
Grundlegende Prinzipien
1. Einfachheitsprinzip (Es sollte immer möglichst die einfachste Lösung gewählt werden.
KISS= Keep it Small and Simple)
2. Analogieprinzip (Dinge, die ähnlich sind, sind auch ähnlich zu behandeln)
3. Prinzip der Überraschungsminimierung (Das Verhalten des Produktes soll immer das
möglichst Nächstliegende sein!)
4. Vollständigkeitsprinzip (Es sind stets alle möglichen Fälle zu erfassen, selbst wenn nur
einige explizit benötigt werden)
5. Nachweisbarkeitprinzip (Es ist stets nachprüfbar zu machen, ob gestellte Ziele auch
erreicht wurden)
Strukturbezogene Prinzipien
1. Zerlegungsprinzip (Auf jeder Ebene soll das Produkt sinnvoll in Bausteine und deren
Beziehungen zerlegt sein)
2. Abkapselungsprinzip (Nur lokal benötigte Details sind nach außen hin unzugänglich zu
machen)
3. Lokalitätsprinzip (Zusammengehörende Dinge sind auch physisch zusammen zu bringen)
4. Trennung der Belange (Dinge, die nichts miteinander zu tun haben, sind auch getrennt
unterzubringen)
5. Abstraktionsprinzip (Dinge, die einheitliche Eigenschaften haben, sind miteinander zu
identifizieren, selbst wenn sie an verschiedenen Stellen verwendet werden)
§4 Lebenslauf und Aktivitäten
Fesstellung Man braucht ein mentales logisches Modell, wie man bei der Softwareentwicklung
vorgeht. Es dient hier nur als didaktischer Rahmen.
§4.1 Software-Lebenslauf
Problemstellung
Analysieren
Problemanalyse(Studie)
Definieren
Anforderungsdefintion(Pflichtenheft)
Entwerfen und Spezifizieren
Architektur und Bausteinspezifikationen (Klassen)
Implementieren und Integrieren
(fertiges) System
Installieren
System in Zielumgebung
Betreiben und Warten
Fesstellung
●
●
Der Software-Lebenslauf gibt einen allgemeinen Rahmen für die Entwicklung
Er besteht aus:
Aktivitäten und
Artefakten
Skizze
Person
Aktivität
Regeln
Werkzeuge
Fesstellung
1.
2.
3.
Zum Lebenslaufmodell gehören
Phasenstruktur
Phasenübergreifendes
Phasenfeinstrukturen
Phasenübergreifendes
● leiten (managen)
○ planen
○ steuern
○ überwachen
● Qualität sichern
● dokumentieren
Phasenspezifisches
● planen und entwerfen (im weiteren Sinne)
● realisieren
● Qualität sichern
● dokumentieren
§4.2 Aktivitäten
Definition: Analysieren ist die Tätigkeit, die auf das Verstehen und eine Erfassung
der in einer Aufgabenstellung angesprochenen Sachverhalte, sowie
auf eine Entscheidung über die Durchführbarkeit und die Erfolgsaussichten
eines künftigen Projektes abzielt.
Definition: Definieren ist die Tätigkeit, die darauf gerichtet ist, Anforderungen an ein zur Lösung
erforderliches Produkt zu stellen
Definition: Entwerfen (im engeren Sinne) ist das Konkretisieren eines Bausteins durch weitere
Bausteine und deren Beziehungen
Definition: Spezifizieren (im engeren Sinne) ist das Präzisieren von Anforderungen, die an
einen Baustein für dessen Benutzung gestellt werden.
Definition: Implementieren umfasst das Entwerfen (im weiteren Sinne), Programmieren und
Validieren eines (im allgemeinen nicht weiter zerlegten) Bausteins
Definition: Integrieren umfasst Montieren und gemeinsames Validieren von implementierten
und/oder bereits integrierten Bausteinen
Definition: Installieren ist das Einrichten eines Systems in dessen Zielumgebung zum Zwecke des
Betriebs
Definition: Betreiben (= Nutzen) ist das Verwenden eines Systems in seiner Zielumgebung.
Definition: Warten ist das Beheben von Fehlern in und das Anpassen,Weiterentwickeln
und Verbessern von Produkten nach der Auslieferung.
Definition: Qualitätssicherung ist die Zusammenfassung aller geplanten und systematisch
durchgeführten Tätigkeiten, die dazu geeignet sind, ein angemessenes Vertrauen zu erreichen, dass
etwas vorgegebenen Anforderungen genügt.
Definition: Dokumentieren ist das schriftliche Festhalten des Ergebnisses einer Tätigkeit.
Definition: Management umfasst das Planen, Führen und Überwachen von
Abläufen.
Softwaretechnik
22.04.08
Teil II Sprachen
§5 Sprachen und Modelle
§5.1 Grundlagen
Feststellung
Methoden gehen immer mit Sprachen einher, in denen die betreffenden Artefakte geschrieben sind.
Definition: Ein Artefakt ist ein Objekt (i.w.S.), das einen konkreten Sachverhalt beschreibt und
maschinenlesbar ist.
Artefakte haben einen Namen und sind versioniert.
Artefakte sind Dokumente einer Artefaktklasse, die durch eine Sprache definiert ist.
Beispiele: Anforderungslisten, Protokolle, Entwürfe, Sourcecode, .class-Files, xml-Files
Feststellung
Artefakte haben einen Namen und sie sind versioniert.
Artefakte, die von Mensch lesbar sind, heißen Dokument.
Artefakte sind in einer „Sprache“ geschrieben.
Feststellung
Sprachen können sein
● formal (Programmiersprachen, Spezifikationssprachen,....)
● informal (natürliche Sprache,...)
● halbformal (Klassendiagramme,...)
Definition
Eine Sprache ist formal, wenn sie eine mathematische Semantik hat
Feststellung
Sprachen können sein
● textuell (Programmiersprachen)
● visuell (Diagramme)
● hybrid (beinhalten beides)
§5.2 UML
Feststellung
Man kann verschiedene Sichten ( viewpoint, perspective) auf ein System haben z.B.:
● Datenstruktursicht (Klassendiagramme, ER-Diagramme, ...)
● Datenflusssicht (Aktivitätsprogramme, Workflowdiagramme,...)
● Kontrollflusssicht (Aktivitätsdiagramme, Programmablaufspläne,...)
● Zustandssicht (Zustandsautomaten, Petrinetze,...)
● .....
Feststellung
Zur Beschreibung dieser Sichten kann man UML verwenden
Unified Modelling Language
UML ist visuell und halbformal. Es ist von der OMG (Object Management Group), einem
Industriekonsortium, als Quasi-Standard akzeptiert.
Rumbaugh, Book, Jacobsen („die 3 Amigos“)
z.Zt. UML 2.1
hier UML 2.0
Literatur
Chris Rupp, et al.
Martin Hitz, et al.
Harald Störle
„UML 2 glasklar“
„UML @ Work“
„UML erfolgreich einsetzen“
http://www.holub.com/goodies/uml/
<Bilder von UML und anderen Diagrammen>
§5.3 Modellierung
Feststellung
In der Softwaretechnik gilt :
● Modelle beschreiben Realitätsausschnitte oder Softwaresysteme
● Sie vereinfachen (abstrahieren) von Details (Elision Prinzip : Alles Irrelevante kann
fortgelassen werden)
● Sie dienen einem Zweck
Definition: Ein Modell ist ein zielgerichtetes Abbild eines Systems (i.w.S.), das die Realität durch
Abstraktion auf die problemrelevanten Aspekte vereinfacht und hierzu ähnliche Beobachtungen und
Aussagen ermöglicht wie das Ausgangssystem.
Feststellung
Modelle können :
● Modelle von einem Vorbild sein (z.B.: um es besser zu verstehen)
● Modell für ein zu erstellendes System sein (z.B.: Programmentwurf)
Skizze
PSM
CIM
Realität
M0
M1
M2
.....
Mk
System
§6 Objekt-Beziehung-Beschreibung
§6.1 Grundlagen
Feststellung
Klassendiagramme kann man verwenden für
( A ) die Struktur der Anwendungsbereiche
( B ) die konzeptuelle, analytische Modellierung
( C ) die Struktur objekt-orientierter Software
( D ) die implementationsnahe, konstruktive Modellierung
Feststellung
Klassendiagramme gehen auf Entity-Relationship-Diagramme zurück
Definition: Ein Objekt (object, entity) ist eine von allen anderen unterscheidbare Einheit der
Realität oder unseres Denkens
Feststellung
Ein Objekt hat immer eine Identität (oid= object indentifier)
Definition: Eine Beziehung (relationship, link) ist eine ídentifizierbare Verknüpfung zwischen
mindestens zwei ( nicht notwendigerweise verschiedenen) Objekten
Feststellung
Objekte und Beziehungen haben Attribute
Defnition: Ein Attribut beschreibt eine Eigenschaft und besteht aus
● dem Eigenschaftsbezeichner und (Name)
● der Eigenschaftsausprägung (Wert)
Feststellung
Dimension der Beschreibung:
Entity – Relationship- Atribute (E-R-A)
Feststellung
Es ist zu unterscheiden zwischen
● Identität
„dasselbe“
● Gleichheit
„dasgleiche“
Softwaretechnik
29.04.08
§6.1 Grundlagen
Objekt-Identität vs. Gleichheit
Unterschiedliche Objekte
Hugo Meyer
Hugo Meyer
3000€
3000€
Sind gleich bzgl. der Attributwerte
UML notiert Objekte als Instanzen von Klassen:
E1 : Employee
name= Meyer
firstName= Hugo
salary= 3000
Gleichartige Objekte werden in Klassen zusammengefasst, die die Gemeinsamkeiten beschreiben.
Bsp:
Employee Klassen-Bezeichner
name:String Attributentyp
firstName: String
salary: Double
Ergebnistyp
getSalary():double
increaseSalary(double)
Parameter-Typ(en)
Auf der Klassen-Ebene werden Attribute durch den Bezeichner und den Typ beschrieben
§6.2 Klassendiagramme
Operationen (Methoden) werden durch die Signatur beschrieben, die aus
● Operationsbezeichner (increaseSalary(double))
● Parameter-Typen und Reihenfolge (increaseSalary(double))
● Ergebnistyp(getSalary():double)
besteht
Klassen- und Assoziationsbeschreibungen werden in (UML-) Klassendiagrammen notiert.
Assoziationen beschreiben die Beziehungen zwischen den zu den beteiligten Klassen gehörenden
Instanzen(Objekte).
Adorments(Ausschmückungen) beschreiben Assoziationen und Klassen näher (Leserichtung,
Sichtbarkeit, Kardinalitäten, Rollenbezeichnung, Operationsbezeichner („has“))
Design-orientierte Klassendiagramme sind sehr detailiert und werden als Grundlage von
Modelltransformationen in MDE-Kontext verwendet.
Daher sollte man beim Modellieren auf korrekte Diagramme achten, und zwar syntaktisch und
semantisch korrekt.
Die Bezeichner in UML-Diagrammen sollten nach bestimmten Konventionen gewählt werden
A) Klassen bezeichnen beliebige erfassbare Einheiten, wie Personen, Gruppen, Dinge....
--> Substantive im Singular beginnend mit Großbuchstaben im CamelCase
B) Assoziationen sind beliebige identifizierbare Zusammenhänge zwischen diesen
--> Verbalphrasen, klein geschrieben
C) Attribute bezeichnen beliebige erfassbare Eigenschaften
--> Substantiv mit Typ-Bezeichner klein geschrieben
D) Rollenbezeichner bezeichnen die Bedeutung eines Objekts in der Beziehungen
--> Substantive, klein geschrieben
E) Operationsbezeichner benennen die Methoden einer Klasse
--> Verben im Imperativ, klein geschrieben, evtl. mit Objekt in der Form : Verrichtung – Objekt
Assoziationen werden in Klassendiagrammen als Linien zwischen Klassen dargestellt
Class
Employee
Instanz
von
e1: Employee
name: Meyer
< comesFrom
< goesTo
Works At >
Instanz
von
Assoziation
Company
Instanz
von
e2: Company
Metaschema
Schema
Instanz
worksAt
Beschreibung von Zusammenhängen auf I-S-M-Dimensionen
UML unterscheidet 3 Arten von Assoziationen
1. Assoziation
2. Aggregation (Teil-Ganzes-Beziehung)
3. Komposition (Teil-Ganzes-Beziehung mit Existenzabhängigkeit)
Assoziationen können mit vielen Adorments näher beschrieben werden:
● Assoziationsbezeichner
● Leserichtung
● An jedem Assoziationsende Multiplizitäten
○ m..n
○ Rollenbezeichner
Klassen können spezielle Objekte enthalten:
Person
name
Employee
salary
Customer
customerId
Person
Customer
Employee
Die Teilmengeen sind disjunkt und die Vereinigung der Teilmengen kann kleiner sein, als die
Menge der instanzen der Superklasse.
Employee
Person (abstrakt)
Customer
Ist die Superklasse ohne eigene Instanzen, so nennt man sie abstrakt.
Abstrakte Klassen werden in UML mit Kursiv geschriebenen Bezeichnern gekennzeichnet.
Alternativ kann ein Constraint {abstract} verwendet werden:
{abstract}
Person
..
..
Generalisierungsbezeichnungen zwischen Klassen können in unterschiedlichen Sichten interpretiert
werden:
● Typsicht: Alle Objekte der Unterklasse(n) verhalten sich so, wie die Oberklasse
--> führt zu Substituierbarkeit und Polymorphie
Vererbung von Attributen und Operationen (Java Sicht)
● Schablonen- bzw. Makrosicht
Alle Objekte der Unterklasse sind so aufgebaut wie die Oberklasse (evtl. weitere Attribute)
--> Wiederverwendung durch Erweiterung
● Mengen-Sicht
Die Menge der Objekte einer Subklasse ist eine Teilmenge der Objekte der Superklasse
(Datenbank-Sicht)
Beziehung zwischen „Dingen“ in UML
Instanz- oder
Objektbezeichnung
KlassenBeziehung
Assoziation
Aggregation
Komposition
§ 6.3 Techniken
--> Übung
§ 6.4 Formalisierung
UML-Diagramme sind eine formale Sprache mit Syntax und Semantik.
A) Syntax wird über ein Metaschema (Meta-Modell) festgelegt
B) Semantik definiert man (in Mathematik) mit abstrakten Automaten
UML 2.0 ist syntaktisch durch ein großes Meta Modell beschrieben nämlich die so genannte
UML-Superstructure
Die UML Superstructure beschreibt die Struktur (Syntax) der UML-Diagrammsprachen.
Die grafische Notation ist nicht Bestandteil der Superstructure.
Softwaretechnik
06.05.08
Die UML Superstructur beschreibt alle 13 Diagrammsprachen der UML als UMLKlassendiagrammen auf der M-Ebene.
Meatmodelle dienen als :
– Konzeptuelle Beschreibungen von Sprachen (Nachschlagewerk, Illustration von Sprachen)
– Formalisierung der abstrakten Syntax sld Grundlage von semantischen Beschreibungen
– als Repository-Struktur innerhalb von Werkzeugen und Anwendungen
– Austauschformat zwischen Anwendungen
– ..........
Beispiel:
Durch die Metamodellierung wird eine Schichten-Sicht auf die Modelle ermöglicht
Metaschema für Klassendiagramme M
_____________________________
Klassendiagramme
S
_____________________________
Objektdiagramme
I
MOF Meta Object Facility (OMG)
______________________________
Metaschema für Klassendiagramme
______________________________
Klassendiagramme
UML Superstructur
Die UML-Welt nimmt eine 4-schichtige Sicht der Modelle an :
Trotz der Standardisierung und Formalisierung von UML gibt es viele syntaktische Freiheiten.
Daher braucht man Konventionen, um die Diagramme von unterschiedlichen Personen, Tools,
Transformationen, etc. verarbeiten zu können.
§ 7 Kontrollfluss-Beschreibungen
Das Verhalten von Systemen kann man unter verschiedenen Sichten betrachten:
– Kontroll-Fluss
Ablauf-Orientierung
– Zustandsänderung
Zustands-Orientierung
– Datenfluss
Daten-Orientierung
Kontrollfluss-Beschreibungen braucht man als schematische Darstellung für :
– Algortihmen
– Prozesse auf System-Ebenen
– Geschäftsprozesse
– Anwendungsfälle
Als Diagrammsprachen für Kontrollflüsse gibt es viele Varianten:
– PAP DIN 66001
– Struktogramme Nassi-Shneiderman-Diagramme
– Jackson-Bäume
– UML-Aktivitätsdiagramme
– Pseudocode
§ 7.1 UML-Aktivitätsdiagramme
Bestandteile:
– Aktionen
– Kontrollflüsse
– Bedingungen/Entscheidungen
– weitere Kontrollelemente
Eine Aktion ist eine imperative Beschreibung einer im allgemeinen zeitlich ausgedehnten Tätigkeit,
die von einerm Prozessor ausgeführt wird.
Bezeichner Objekt + Infinitiv
Symbol :
Eine Kontrollfluss-Kante beschreibt mögliche Aufeinanderfolgen von Aktionen
Symbol :
Aktionen sind atomare Aktivitäten, d.h. aus Sicht des Kontrollflusses können sie nur als Ganzes
ausgeführt werden.
Bedingungen kennzeichnen Entscheidungen, die der Prozessor aufgrund des Systemszustandes
fällen kann.
Bezeichner: Prädikats- bzw Verbalphrasen (isReady, notEmpty, ....)
Bsp:
[else]
[x>0]
[x<-10]
Kontroll-Elemente
Start-Knoten
End-Knoten
Beenden eines Teilablaufs
„Oder“ Knoten
„Und“ Knoten
„join“
„fork“
Bsp:
Anmerkung
UML-Aktivitätsdiagramme eignen sich für die Kontroll- und Datenfluss-Sicht.
Hier: Konzepte trennen !
Manche Aktivitäten bzw. Aktionensind do Komplex, dass sie auf einer detaillierten Ebene als
eigenes Aktivitätsdiagramm beschrieben werden können.
Dies wird in UML als verfeinerte Aktivität gezeichnet.
Die Semantik von Aktivitätsdiagrammen wird beschrieben durch Token-Flüssen
Regel: In jede Aktion geht genau ein Kontrollfluss hinein und genau ein Kontrollfluss heraus
Softwaretechnik
20.05.08
Rückblick Objekt-Beziehungssicht ; Klassendiagramme ; Objektdiagramme ;
Kontrollflusssicht beschreibt, welche Aktivitäten wie aufeinander folgen können
Datenflusssicht beschreibt, welche Daten Aktivitäten einander übergeben
Zustands-Übergangssicht beschreibt, wie sich die Zustände des Systems durch Aktivitäten ändern
Zustandsautomaten
§8 Datenfluss-Beschreibung
Feststellung In UML 2.0 werden Datenflüsse in Aktivitätsdiagrammen untergebracht
– Objectknoten
sind Platzhalter für Daten
– Datenflusskanten
beschreiben einen möglichen Informationsfluss
Feststellung Die Semantik von Aktivitätsdiagrammen wird durch ein „Tokenspiel“ definiert
Feststellung
Der Name von Objektknoten wird im Allgemeinen von dem Typ übernommen, der erwartet wird.
Bestellung
[geprüft]
A
B
Ein möglicher Zustand kann in Objektknoten zwischen“[„ „]“ annotiert werden
Feststellung Aktivitäten können Ausgabeobjektknoten haben
Prüfen
Zettel
Ware
Ware [geprüft]
wird eine solche Aktivität woanders verwendet, so werden die Objekte durch Pins notiert
Ware
Aktion die die
Aktivität
ausführt
Zettel
Ware prüfen
Wird durch Aktivität
verfeinert
Feststellung Verwendungen von Aktivitäten müssen „balanciert“ sein, d.h. die Pins der Anwendung
müssen zu den Objektknoten auf den Aktivitäten passen
Feststellung Historisch gibt es eine Reihe anderer Dialekte zur Datenflussbeschreibung
– Yourdon-De Marco
– Gare-Sasson
– SADT
– ....
§9 Zustands-Übergangs-Beschreibungen
§9.1 Grundlagen
Feststellung Für reaktive System/eingebettete Systeme braucht man eine klare zustandsabhängige
Beschreibung des Verhaltens
Definition : Reaktive Systeme sind Systeme, die auf externe und interen Ereignisse zustandsabhängige Reaktionen zeigt, wobei sich der Zustand ändern kann.
Skizze
Ereignis
A
Aktivität
Bedingung
a/f[b]
B
Zustand
Wenn Ereignis a eintritt und das System im Zustand A ist und die Bedingung b erfüllt ist, dann wird
f ausgeführt und das System geht dabei in den Zustand B
Feststellung
Zustandsautomaten ähneln endlichen Automaten, haben aber globale Variablen und sind daher nicht
mehr endlich
Beispiele für reaktive Systeme
– Autos
– Flugzeuge
– militärische Geräte
– Handys
– Waschmaschinen, etc.
– Benutzungsschnittstellen
– Webservices
§9.2 Einfache Zustandsautomaten
Feststellung Zustandsautomaten bestehen aus
– Zuständen
(States)
– Transitionen
– Ereignisse (Triggers)
– Bedingungen (Guards)
– Aktivitäten
– Kontrollelemente („PseudoStates“)
Feststellung
Zustände beschreiben Mengen von Konfigurationen, die das System im Allgemeinen eine längere
Zeit einnehmen kann. Man bezeichnet sie daher oft mir Partizipien Präsenz
Sie können Aktivitäten enthalten
Name
Müssen terminieren
entry / Aktivität
do/Aktivität
exit/aktivität
optional
a'/t[b']
a/t[b]
A
do
entry
exit
Softwaretechnik
27.05.08
Zustand-Übergangsbeschreibung
(reaktiven Systemen)
(eingebettete Systeme)
Kontrollfluss
Zustände und Übergänge
Vorzustand
A
Aktion
/S Zustände
Nachzustand
B
Dualität!
t[b]/s
entry, do, exit
Feststellung Transitionen werden annotiert mit
– Trigger t ist das auslösende Ereignis
– Bedingung b (guard) muss nach Verlassen des Zustandes erfüllt sein
– Verhalten s (action) wird beim Übergang ausgeführt (sollte keine spürbare Zeit in
Anspruch nehmen)
Feststellung
– Gibt es keine Transition, die „schalten“ kann, so wird der Trigger ignoriert
– Gibt es mehrere Transitionen, die schalten können, so wird irgendeine gewählt (don'tcare-Nichtdeterminismus)
Feststellung Es gibt noch weitere (knotenartige) Kontrollelemente (pseudo states) !keine Zustände!
Start (obligatorisch)
zeigt auf den Zustand, mit dem das System beginnt
Ende
markiert das Ende des Ablaufs
Kreuzung
erlaubt das übersichtliche
zusammenfassen von Transitionen
[b1]
[b2]
Entscheidung
wie Kreuzung, wobei die Bedingung dynamisch
ausgewertet werden
§9.3 Zusammengesetzte Zustände
Zustandsautomaten können (nach Harel) erweitert werden um
– Hierarchie (UML: Zusammengesetzter Zustand) StateCharts: xor-Superstates, xor-Blobs)
– Orthogonalität (UML: Regionen StateCharts: and-Superstates, and-Blobs)
Feststellung
Zur Strukturierung können Zustände selbst durch Zustandsautomaten verfeindert werden
A
H
Ein zusammengesetzter Zustand (composite state) entspricht einem Teilsystem, das sich nur in
genau einem(xor) seiner Unterzuständen befinden kann.
Transitionen können über die Grenze von zusammengesetzen Zuständen gehen.
Zusammengesetzte Zustände können abstrahiert werden, d.h. der Innere wird zugeblendet
A
Brille
Feststellung Durch Regionen in zusammengesetzten Zuständen ist es möglich, Teilsysteme in
parallel arbeitende unterteilsysteme zu zerlegen
A
B
a
b
C
c
D
c
F
a
E
b
Ein solches System befindet sich gleichzeitig in beiden Untersystemen
z.B (B,D) |-a (C,E) |-b (B,F) |-c (B,F) ..... (da es für B und Eingabe c keine Anweisung gibt, bleibt es auf B)
Feststellung
Es gibt noch weitere Sprachelemente (sh. Quick Reference), z.B. History-States
H
In einem zusammengesetzten Zustand wird dort weitergemacht, wo man ihn zuletzt verlassen hat.
Teil III Methoden
Feststellung
Für die Erstellung eines Softwaresystems braucht man
– Vorgehensweisen, -modelle (beschreiben, welche Aktivitäten durchzuführen sind)
– Methoden (sind begründete Vorgehensweisen, die es erlauben Teilaufgaben gezielt zu erfüllen)
– Techniken (sind „kleinere“ Methoden, die der Erstellung einzelner Dokumente dienen)
Die Übergänge sind fließend
§10 Analyse und Anforderungsdefintion
§10.1 Grundlagen
Feststellung
Die Grenze zwischen Analysieren und Definieren ist fließend:
Analysieren
– Verstehen
– Erfassen
– Abschätzung
•
Durchführbarkeit
•
Erfolgsaussichten
Definieren
– Anforderungen feststellen
Beides wird häufig unter „Requirement Engineering“ gefasst.
Feststellung
Die Erhebung der Anforderungen ist erforderlich für
– Abstimmung mit dem Kunden
– Erstellung des Pflichtenhefts
– Entwurf und Spezifikation
– Benutzerhandbuch
– Test
– ...
Fehler in den Anforderungen setzen sich lawinenartig in späteren Dokumenten fort und erzeugen
große Kosten.
Softwaretechnik
03.06.08
Literatur
Chris Rupp
„Requirements-Engineering und -Mangament“
Feststellung
In den „frühen Phasen“ ist das Wissen über das Produkt
– unscharf
– unsicher
– unpräzise
– unvollständig
– unformal
– ...
Deswegen spielen
– Kommunikation
– natürliche Sprachen
– Visualisierung
eine große Rolle
Feststellung
Auftraggeber und Hersteller sprechen im Allgemeinen verschiedene Sprachen!
Regeln
– Der Hersteller muss die Sprache des Anwenders lernen (nicht umgekehrt)
– Der Anwender muss seine Sprache möglichst diszipliniert verwenden.
§10.2 Anforderungslisten und Glossar
Feststellung
Ziel der Anforderungserhebung sind zwei Dokumente
– Anforderungslisten
– Glossar
Die Erhebung ist ein iterativer Prozess. Er muss geordnet und gezielt stattfinden.
Definition: Eine Anforderung (i.e.S.) ist ein kurzer, klarer,vollständiger, ganz natürlichsprachlicher
Satz.
Eine Anforderungsliste (i.e.S.) ist eine nummerierte Sammlung von Anforderungen.
Feststellung
– Durch Sammeln wird eine Abgrenzung des Systems vollzogen.
– Durch Gruppieren erhält man einen ersten Eindruck der Struktur.
– Durch Nummerierung wird einen Nachverfolgbarkeit (Traceability) ermöglicht
Anmerkung
Nummerierung und Gruppieren werden zusammen durch eine Nummerung (Dewey-Numbering)
gemacht, z.B.
1.1.1 1.1.2 1.1.3 1.2.1 1.2.1 ........
Feststellung
Anforderungen sollten
– eindeutig
– korrekt
– aktuell
– notwendig
– angemessen
– verständlich
– überprüfbar
– realisierbar
Feststellung
Man sollte die Anforderungen im Lichte einer „Vision“ erheben, damit später Erweiterungen
ermöglicht werden. Man schraubt darum die Anforderungen im zweiten Schritt zurück.
Feststellung
Anforderungen haben unterschiedliche Verbindlichkeit.
– Pflicht (muss, wird, ...)
– Wunsch (soll, sollte, ...)
– Vorschlag (kann, ...)
Feststellung
Die Anforderungsliste sollte
– vollständig
– redundanzfrei
– konsistent (widerspruchsfrei)
sein.
Feststellung
Man unterscheidet
– funktionale Anforderungen (beschreiben die gewünschte Funktionalität, Anwendungsfälle)
– nicht-funktionale Anforderungen (beschreiben weitere Erwartungen, z.B. Qualität)
Die Grenze ist unscharf
Beispiele für nicht-funktionale Anforderungen
– technische Anforderungen
– Anforderungen an Benutzerschnittstelle
– Anforderungen an die Qualität der Funktionen
– Anforderungen an die Qualität des Produkts
– rechtlich/vertragliche Anforderungen
– ...
Definition: Ein Glossar ist eine lexikonartige Beschreibung der wesentlichen Begriffe der
Anwendungstechnik.
Abschließende Feststellung
Häufig bietet die Anforderungsliste eine gute erste Basis für Architektur und das Glossar ist
Grundlage einer ersten Informationsmodells in Form eines Klassendiagramms.
§10.3 Erhebung von Anforderungen
Übersicht
(A) Stakeholder identifizieren
(B) Gespräche führen
(C) Dokumente analysieren
(D) Vorgänger erheben
(E) Kreative Techniken verwenden
(F) Szenarien und Anwendungsfälle feststellen
Diese Aktivitäten finden überlappend statt.
(A) Stakeholder identifizieren
Definition: Stakeholder (Betroffene, Beteiligte) sind Personen oder Personengruppen, die ein
System entwickeln, benutzen, in Betrieb halten oder sonst ein irgendein Interesse daran haben.
Beispiele
– Auftraggeber (Manager)
– Auftraggeber ( Betroffene)
– Hersteller (Manager)
– Hersteller (Betroffene)
– viele weitere Rollen
z.B.: Geschäftsleitung
z.B.: Fachabteilung, Sachbearbeiter, ...
z.B.: Geschäftsleitung
z.B.: Analytiker, Designer, Architekten, Programmierer
z.B.: Wartungspersonal, Schulungspersonal, Prüfer/Auditor,
Steuerberater, Justitiar, ... (möglichst viele)
(B) Gespräche führen
Feststellung
Gespräche mit den Stakeholdern müssen vorbereitet werden
– Fragenliste (für den Fragenden ; darunter auch offene Fragen)
Gespräche müssen protokolliert werden, z.B.
– Gesprächsnotiz
– Vermerk
– Ergebnisprotokoll
– Verlaufsprotokoll
Softwaretechnik
10.06.08
Rückblick
Anforderungslisten & Glossar
(A) Stakeholder identifizieren
(B) Gespräche führen
(C) Dokumente analysieren
(D) Vorgänge erheben
(E) Kreativitätstechniken einsetzen
zu (B)
Empfehlung
Man sollte von allen Gesprächen Ereignisprotokolle herstellen
Diese Protokolle enthalten nur konkrete Fakten über :
– Entscheidungen und Beschlüsse
– Gründe hierfür
– Aufgaben, Verantwortlichkeiten
– Referenzen (Literatur, URL's, Adressen)
– ...
zu (C) Dokumentenanalyse
Definition: Unter Dokumentenanalyse versteht man das Sammeln und Verarbeiten vorhandener
Dokumente zur Erhebung von Anforderungen.
Feststellung
Man sammelt :
– Formulare
– Laufzettel
– Checklisten
– Excel-Dateien
– Statistiken
–
–
Übersichten
...
Sie helfen :
– das Glossar zu füllen
– ein ersten Klassendiagramm (Domänenmodell) zu erstellen
– gute Fragen zu stellen
zu (D) Abläufe erheben
Definition: Unter Ablauferhebung versteht man das Erfassen und Darstellen der wesentlichen
vorhandenen Vorgänge (Abläufe, Geschäftsprozesse) mit dem Ziel der Anforderungserstellung
Feststellung
Man muss die Vorgänge beobachten.
Zu (E) Kreativitätstechniken einsetzen
Disclaimer
Diese Ansätze können nicht in einer Vorlesung gelehrt werden (Beispiel : Mindmapping)
Beispiel : Brainstorming
Beispiel : Metaplan-Techniken
zu (F) Anwendungsfälle feststellen
sh § 10.4
§ 10.4 Feststellung der Anwendungsfälle
Definition: Ein Anwendungsfall (use case) ist eine Klasse von Abläufen, die eine ( im Allgemeinen
etwas größere) Funktionalität realisieren.
Definition: Ein Szenario ist eine gedachte zusammenhängende Folge von Aktionen im Umgang mit
dem System
Feststellung
Szenarien sind Instanzen von Anwendungsfällen. Anwendungsfälle sind also Klassifizierer
(classifier)
Unterscheidung
Man beschreibt Anwendungsfälle mit Anwendungsfalldiagrammen.
Man beschreibt Szenarien durch :
– natürliche Sprache
– Aktivitätsdiagramme
– Zustandsautomaten
– Sequenzdiagramme
(A) Anwendungsfalldiagramme
Bestandteile
Assoziation
Systemgrenze
Spezialisierung
Anwendungsfall (Objekt-Infinitiv)
Akteur (Rolle von personen oder Systemen
<<include>>
<<extend>>
Benutzungsbeziehung
Ausnahmebehandlung
Skizze
A
Extension point
B
<<extend>>
C
Bed.
(B) Szenarien beschreiben
Beispiel : natürlichsprachliche Beschreibung
Beispiel : formatierte sprachliche Beschreibung
Feststellung
Weitere Möglichkeiten sind
– Aktivitätsdiagrammen
– Zustandsdiagramme
– (Entscheidungstabellen)
– Sequenzdiagramme
Bestandteile
Lebenslinie
Synchrone Nachricht
Asynchrone Nachricht
Feststellung
In UML kann man auch Kontrollstrukturen beschreiben
loop
auch :
alt
[Bed1]
Alternative
[Bed2]
per
Parallelausführung
Durch die Kontrollstrukturen kann man Mengen von Szenarien beschreiben.
Softwaretechnik
17.06.08
§ 10.5 Pflichtenheft
Feststellung
In der Anforderungsdefinition erhält man :
– Anforderungsliste
– Glossar
und
– Domänenmodell (erstes Klassendiagramm)
– Anwendungsfallmodell (erstes Anwendungsfalldiagramm)
und
– Protokolle
– Ablaufbeschreibungen
– Checklisten
– ...
Feststellung
Das Pflichtenheft ist ein natürlichsprachliches gut strukturiertes und anschaulich erklärtes
Dokument (i.e.S.), das :
– die Anforderungen an das Produkt erfasst
– die Grundlage für die Entwicklung darstellt
– als Vertragsgrundlage dient
Es sollte die o.g. Dokumente als Anlage enthalten.
§ 11 Architektur entwerfen
§ 11.1 Grundlagen
Feststellung
Aus dem Zerlegungsprinzip folgt, dass ein System (rekursiv) in Teilsysteme und Bausteine zerlegt
ist.
Man erhält dies
– top down oder
– bottom up oder
– gemischt
Ein System sollte im Allgemeinen nur etwa 7±2 Elemente enthalten (außer, falls er reinen
Katalogcharakter hat.)
Definition: Eine Zerlegung eines Systems in Bausteine(Components) und Beziehungen(Connectors)
heißt Architektur der Systeme
Beispiele für Bausteine (i.w.S.)
– Systeme, Subsysteme
– Paket
– Klasse
– Methode
– Variable
– (Programm)
–
–
–
Datenbank
Relation
...
Sie haben unterschiedliche Granularität.
Beispiele für Beziehungen (i.w.S.)
– A enthält B
– A liefert Daten B
– A benutzt B
– A ruft B auf
– A sendet Nachricht an B
– ...
Feststellung
Durch Festlegung der Bausteinarten und der Beziehungen, die man betrachtet, erhält man eine
Architektursicht (Sicht, Viewpoint).
Sichten werden mit Metamodellen definiert.
Skizze
reads
DataObject
Activity
produces
Feststellung
Die Begriffe Architektur, Baustein, Beziehungen sind konzeptionell gemeint, d.h. die können in
unterschiedlichen Entwicklungszuständen vorkommen :
– spezifiziert
– entworfen
– implementierten
– verifiziert
– getestet
– abgenommen
– ...
§ 11.2 Architekturstile
Feststellung
Es gibt eine Reihe von Architekturstilen (architecturell styles, patterns), die einen Namen haben.
Diese Stile legen fest
– Architektursicht
– Architekturstruktur
Beispiele
Pipe-Filter-Stil
unix
cat dictionary | sort | using | note
Client-Server-Stil (Grundform)
Client
Datenfluss
Server
n-ter-Stil
Interaktion
(n=3)
Applikation
Benutzung
Datenbank
Repository-Stil
Editor
Analyse
Codegenerator
Benutzung & Datenfluss
Empfehlung
Man soll drei Schichten mindestens betrachten
– Struktursicht
–
Benutzungssicht
im Wesentlichen : „ benutzen“ z.B.: Klassendiagramme, Komponentendiagramme
–
Datenflusssicht
im Wesentlichen : „Daten verarbeiten“ z.B. Aktivitätsdiagramme
Warnung
Die Sprache in der die Architektur notiert wird muss definiert sein:
– Standardnotation
– eigene Notation mit Legende
§ 11.3 Entwerfen
Feststellung
Es gibt viele Literatur über Entwurf, aber keine brauchbaren Regelwerke.
Grundsätze :
– strukturierte Analyse baut auf funktionale Zerlegung auf
– objekt-orientierte Analyse und Entwurf baut auf objekt-orientierung auf
Softwaretechnik
24.06.08
Feststellung
Historisch gibt es zwei Entwurfansätze
(A) Strukturierte Analyse, funktionale Zerlegung in Datenflusssicht
(B) Objektorientierte Analyse, Klassenzerlegung in Benutzungssicht
(A) SA
Skizze
Anforderungsanalyse
Identifizierung der Hauptaufgaben (Prozesse)
schrittweise Zerlegung in Teilprozesse
Datenflussdiagramme
Klassendiagramme
Spezifikation der atomaren
Prozesse
(B) OA
Skizze
Anforderungsanalyse
Erstellung der Domänenmodelle
Verfeinerung der Klassen mit ihren Verantwortlichkeiten, Attribute, Methoden
Abrundung der Klassenmodelle durch Entwurfsmuster
(C) Kombiniertes Vorgehen (Informationssysteme)
Anforderungen, Glossar, Anwendungsfalldiagramme
Architekturstil festlegen
Anwendungsfälle durchgehen und (hieraus) Subsysteme identifizieren und
die Domänenklassen festlegen
iterativ die Anforderungen durchgehen und damit die Klassenbeschreibung
weiterentwickeln
Entwurfsmuster berücksichtigen
Anmerkungen
Zur iterativen Erstellung von Klassen sind CRC-Knoten hilfreich
Class Responsibilities Collaboration
Klassenname
Verantwortlichkeiten
Oberklassen
Kollaborierende
Klassen
Rückpfeile für Notizen
§ 12 Bausteine spezifizieren
§ 12.1 Grundlagen
Feststellung
... Präzisieren von Anforderungen zu einem Baustein ...
Eine Spezifikation beschreibt was ein Baustein tun kann, nicht wie er das tut.
Sie muss
– einfach genug, um vom Menschen verstanden zu werden
– konkret genug, um als Grundlage der Implementierung zu dienen
– abstrakt genug, um nur das Wichtige zu enthalten
– vollständig genug, um alles zu erfassen.
Feststellung
Man kann Spezifikationen
– natürlichsprachlich
oder
– formal (Z, OCL, algebraische Spezifikation, ...)
anlegen.
§ 12.2 Schnittstellen
Feststellung
Aus dem Abkapselungsprinzip folgt die Unterscheidung in
– die Schnittstellen (interface)
– dem Rumpf (body) --> verborgen
eines Bausteins.
Definition: Die Schnittstelle eines Bausteins ist diejenige Menge an Informationen, die er selbst
und seine Umgebung benötigt, um miteinander in Beziehung zu treten. [Parnas]
Feststellung
Unterscheidungen
– Export-Schnittstelle
– Import-Schnittstelle
–
–
Syntax der Schnittstelle
Semantik der Schnittstelle
Signatur
benutzt
Spezifikation (i.e.S.)
(A) Operationssignatur
Skizze
Object retrieve (key k);
proc retrieve(in k:key) returns Object;
retrieve :: Key-> Object
Bestandteile
– Operationsbezeichner
– Eingabeparameterbezeichner (optional)
– Ausgabeparameterbezeichner (optional)
– Eingabetypbezeichner
– Ausgabetypbezeichner
(B) Klassensignaturen
Bestandteile
– Klassenbezeichner
– Operationssignaturen
Feststellung
Zur Beschreibung von Klassen muss auch der Zustand der Klasse berücksichtigt werden
Unterscheidung
– Oberflächensignatur
– Tiefensignatur
insert:Comparable x Object --> Void
insert:Comparable x Object --> Dict
Die Tiefensignatur berücksichtigt auch Vor- und Nachzustände. Sie wird als Basis für die
Spezifikation verwendet.
§ 12.3 Natürlichsprachliche Spezifikation
Skizze
Ausgabe
Eingabe
dict, key, data
Eingabeparameter
insert
dict'
Ausgabe, Nachzustandswerte
Vorzustand
Vorbedingung pre-insert
ist ein Prädikat auf Eingabedaten und Vorzustand (eine Menge).
Nachbedingung post-insert
ist ein Prädikat auf Eingabe- und Ausgabedaten sowie Vor- und Nachzustand.
Softwaretechnik
01.07.08
Spezifikation (Dokumentation)
Was? (nicht : WIE?)
Abkapselung
Schnittstelle
Signatur
Oberfläche
Tiefe
Vorbedingung
Rumpf
Spezifikation
natürlichsprachlich
formal
Nachbedingung
Vorzustand
Eingabeparameter
f
Nachzustand
Ausgabeparameter
Feststellung
Man kann Spezifikationen leichter formulieren, wenn man einen typischen Aufruf notiert
(Aufrufpattern)
Beispiel
Signatur: float static sqrt (float x);
Pattern: y = A.sqrt(x);
pre-sqrt: x>=0
post-sqrt: y² = x und es wird das Verfahren er Klasse A verwendet
Beispiel
Signatur: void sqrVal();
Pattern: float val;
sqrVal();
pre-sqrVal: true
post-sqrVal: Val' = val * val
Feststellung
Generell gibt es verschiedene Möglichkeiten mit Vorbedingung umzugehen:
– optimistisch (der Aufrufer muss die Vorbedingung sicherstellen)
– pessimistisch (der Aufgerufene muss die Bedingung prüfen)
Abbruch mit Ausnahme
ignorieren
Feststellung
Grundregel:
Alles was nicht spezifiziert ist, kann beliebig implementiert werden.
Framing-Bedingung
üblich
Alles was nicht erwähnt ist, bleibt unverändert
Feststellung
Zur Spezifikation einer Klasse gehören :
– die Bedeutung der Klasse
– die Verantwortlichkeiten
– die Invarianten der Klasse
§ 13 Qualitätssicherung
§ 13.1 Grundlagen
Definition: Qualitätssicherung ist die Zusammenfassung aller [..] Tätigkeiten, die dazu geeignet
sind, ein angemessenes Vertrauen zu erzeugen, dass etwas vorgegebenen Anforderungen genügt.
Unterscheidungen
konstruktiv
– durch adäquate Entwurfsverfahren
– durch Modell- und Programmtransformation
– Generatoren
analytisch
– durch Inspektion (Reviews)
– durch testen und Messen
– durch Beweisen (Verifikation)
Feststellung
Qualitätssicherung muss für alle Artefakte der Softwaretechnik durchgeführt werden.
§ 13.2 testen (i.e.S.)
Feststellung
Testen ist eine permanente Tätigkeit bei der Programmierung
Unterscheidung
– Unit Test lokaler Test eines Bausteins (Klasse) durch den Programmierer ist automatisierbar
(z.B. J-Unit)
– Functional Test
(Anwendungstest) Test des gesamten Systems durch ein QS-Team. i.Allg.
nicht automatisierbar
Feststellung
Das Testen setzt gute Testfälle voraus.
Definition: Ein Testfall einer Menge von Eingabedaten (und Vorzuständen) zusammen mit den
erwarteten Ausgabedaten (und Nachzuständen). Sie haben einen Namen oder Nummer. Sie werden
archiviert.
Feststellung
Die Ermittlung der Testfälle ist das Hauptproblem.
Skizze
if (x>y)
max=x;
else
max=x;
Blackbox
y>x
x
x
x
x>y
Whitebox
Programmüberdeckung ( => (4,2) (5,9))
Feststellung
Man unterscheidet
– Blackbox-Test
d.h. die Testfälle werden aus der Spezifikation erzeugt
– Strukturierter Test (Glassbox Test)
d.h. die Testfälle werden aus dem Programmtext erzeugt
Faustregel
Man testet :
– einige Normalfälle (aufgrund von Überdeckungen)
– viele Grenzfälle
– einige Fehlerfälle
Feststellung (Blackbox)
Man versucht Überdeckungen zu finden
– Funktionsüberdeckung (jeder UseCase, alle Anforderungen, jede Klasse, jede Methode)
– Eingabeüberdeckung
– Ausgabeüberdeckung
Feststellung (strukturierter Test)
Man versucht jede Bedingung jeweils erfüllt/ nicht-erfüllt auszuprobieren (C1-Test)
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement