Also, jetzt stellt sich natürlich sofort die Frage, tritt hier ein
Überlauf auf.
Also diese Zahl hier, 1000 mal 60 mal 60 mal 24, das sind 10 hoch 3,
10 hoch 4, 10 hoch 5, 10 hoch 6 mal 2,4 mal 6 mal 6, 6 mal 6 ist 36,
mal 2 ist also etwas 70, 75, ist also noch eine 10er Potenz.
Also wir kommen 3, 4, 5, 6, 7 10er Potenzen.
Passt das in ein Long?
Wie hoch, wie groß das Max sind?
Ungefähr.
Weiß das jemand noch?
10 hoch 8, 10 hoch 9, das ist 2 mal 10 hoch 9, glaube ich, so
ungefähr.
Also das würde passen.
Aber außerdem haben wir gar kein Int, wir haben ja ein Long.
Das hat ja 64 Bit.
Das müsste locker passen.
Und hier kommen nochmal 3 10er Potenzen drauf auf ein Long, passt das
auch.
Das wären dann, sagen wir 10 hoch 7, das wären also 10 hoch 10, 10
hoch 11 wahrscheinlich, wenn man es genau ausrechnet.
Trotzdem funktioniert dieses Programm nicht richtig.
Und zwar, was wird ausgegeben?
505.000, eigentlich sollte das 1.000 heißen.
Nehmen Sie die Aufgabe B für 1.000.
5.000, eine 5, das tritt eine Ausnahme auf.
Wer ist für A?
Wer ist für B, die 1.000?
1.000 wäre das gewünschte Ergebnis.
5.000, ok.
Laufzeitfehler oder Ausnahme, irgend sowas?
Ist alles etwas schüchtern?
Die Antwort ist 5.
Die Frage ist jetzt, warum?
Warum kommt dann eine 5 raus?
Es müsste eigentlich eine 1.000 rauskommen.
Entschuldigung, was machen wir hier?
Wir dividieren durch Millis per Day, genau.
Warum?
Die Antwort ist ganz einfach.
Diese Zahl hier verursacht einen Überlauf im Integer-Bereich, aber
nicht im Long-Bereich.
Aber diese Multiplikation, das sind lauter Ganzzahlen, keine Long
-Zahlen, die werden als Ganzzahlen interpretiert.
Das Ergebnis ist größer als Integer.maxValue.
Also wird es irgendwo abgeschnitten.
Wieso da genau eine 5 rauskommt, das interessiert uns gar nicht.
Und damit kriege ich das falsche Ergebnis.
Die Frage ist, wie korrigiere ich es?
Die Antwort ist, ich muss die Dinger hier als Long markieren, damit
auch diese Multiplikation bei der Initialisierung mit Longs gerechnet
wird.
Also mit 64 Bit und dann klappt das.
Das sieht also so aus, das können Sie jetzt vielleicht schlecht sehen,
aber hier steht 24 L.
Ich kann es auch überall hinschreiben, aber 1 reicht.
Und links her, ich kann es auch erst hier hinten hinschreiben, dann
wird hier vorne noch mit Interest gerechnet und dann erweitert.
Okay, und dann funktioniert das.
Mindestens der erste.
Also Überläufe sind lautlose Killer, Sie merken gar nichts davon.
Stellen Sie sich vor, das wäre eine Zahl gewesen, die auf der Eingabe
kommt und nicht eine, die Sie wissen.
In unserem Fall wissen wir sie, aber wenn das auf der Eingabe kommt,
und Sie rechnen damit, dann kommt plötzlich völliger Unsinn heraus.
Also dass die Berechnung nicht überläuft, ist noch lange nicht
gegeben, selbst wenn die Zielvariable groß genug ist.
Und im Zweifel verwenden wir halt immer Long, dann ist man auf der
einigermaßen sicheren Seite.
So riesige Zahlen, wie man 2,64 oder 2,63 Bit braucht, kann man
natürlich auch haben, kann man auch da einen Überlauf erzeugen, aber
da braucht man schon sehr große Zahlen.
Das war also unser kleines Java-Rätsel für diesen Morgen.
Wir machen weiter mit der Vorlesung von letzter Woche.
Also wir waren stehen geblieben bei den Eigenschaften oder Problemen
bei der Entwicklung großer Software-Systeme.
Wir können da jetzt relativ rasch durchgehen.
Das eine ist, während der Entwicklung ändern sich die
Produktanforderungen.
Das heißt, Sie brauchen mehr neue oder geänderte Funktionen, geänderte
Benutzeroberfläche und neue Schnittstellen.
Zum Beispiel, Sie brauchen plötzlich eine Web-Schnittstelle für ein
Programm, das das nicht hatte.
Sie hätten gerne eine Sprachsteuerung oder Sie haben ein schönes
Programm, aber es müsste auf dem mobilen Gerät auch laufen, also
müssen Sie da irgendwas ändern und eine App-Version machen.
Die Anforderungen ändern sich.
Oder wenn Sie sich gerade etwas Aktuelles denken, Sie müssten
irgendwo, wie bei WhatsApp, plötzlich Verschlüsselung einführen, Ende
-zu -Ende-Verschlüsselung.
So eine Funktion, die ich nicht direkt aufrufe, aber die das System
leisten muss, ändern sich also die Anforderungen während der
Entwicklung oder auch während das System schon in Betrieb ist.
Das heißt, die Randbedingungen, die Anforderungen ändern sich.
Mein Klicker hier ändert sich nicht.
Was hilft da?
Da hilft gar nichts mehr.
Jetzt haben wir etwas Besseres.
Dann, während der Entwicklung ändern sich die Komponenten von Hardware
- und Software-Systemen, die Sie benutzen.
Sie kriegen neue Prozessoren.
Sie müssen plötzlich auf dem Raspberry Pi laufen.
Was machen Sie jetzt?
Sie haben eine andere Peripherie.
Es kommen neue Geräte hinzu, irgendwelche Sensoren, Sprachsteuerung,
Mikrofone.
Sie bekommen ein anderes Fabrikat.
Sie bekommen irgendwelche anderen technischen Innovationen.
Da gibt es irgendwo eine Verbesserung.
Plötzlich sagt man Ihnen, das mit der Rechnung geht viel zu langsam.
Das müssen Sie jetzt auf GPUs verpflanzen, die grafischen
Verarbeitungseinheiten.
Das wäre so eine technische Innovation.
Oder die Softwaremethoden und Werkzeuge, die Sie nutzen sollen, werden
geändert.
Plötzlich müssen Sie andere Programmierumgebungen nehmen.
Das ist alles, mit dem Sie rechnen müssen, wenn Sie über einen
längeren Zeitraum ein Projekt bearbeiten.
Gerne gibt es noch den Fall, dass sich die Portabilitätsanforderungen
ändern, dass die Softwareprodukte nämlich meist eine längere
Lebenszeit haben als die darunterliegenden Betriebssysteme und die
darunterliegende Hardware.
Die Hardware könnte man sagen, es gibt so eine Faustregel, die ist
allerdings wieder beschleunigt worden, die sagt, die
Hardwarezykluszeit ist ungefähr drei Jahre.
Es scheint mir, bei Mobiltelefonen scheint es nur noch ein halbes Jahr
zu sein, aber auf Dauer, glaube ich, ist das auch nicht durchzuhalten.
Wie Sie vielleicht gelesen haben, steigt die Verkaufszahlen für
Mobiltelefone letztlich nicht mehr.
Jetzt hat jeder eins.
Das heißt, die Hardwarezykluszeit wird auch bei Mobilgeräten sich
etwas verlangsamen, aber für einen neuen PC müssen wir etwa drei Jahre
warten.
Systemsoftwarezykluszeit, wenn wir bedenken, wie oft Sie ein neues
Betriebssystem bekommen, das ist auch etwa fünf bis sechs Jahre.
Wenn Sie aber jetzt eine andere Softwarezykluszeit haben, das Ding
läuft für zehn, 15 Jahre, dann können Sie leicht ausrechnen, da
wechsle ich das Betriebssystem zweimal.
Also ich fange mit einem an, wechsle es einmal mindestens und hier
nochmal und die Hardware kann mir drunter auch ausgetauscht werden.
Darum ist es wichtig, dass man auch portable Software hat, die auf
unterschiedlichen Geräten läuft.
Das hängt meistens schon mal an der Programmiersprache.
Wenn Sie eine Programmiersprache wie Java haben, die explizit für
Portabilität gebaut wurde, dann sind Sie da auf der sicheren Seite.
Aber diesen Luxus haben Sie nicht überall.
Also wenn Sie in C programmieren, der Geschwindigkeit halber, dann
kann es schon sein, dass die Portabilität eingeschränkt ist.
So, schauen wir mal, ob wir noch weiterkommen.
Also, das habe ich schon gesagt, Zielsystem entwickelt weltweit
vertriebene Softwareprodukte müssen übrigens noch eine andere
Eigenschaft haben, nämlich sie brauchen länderspezifische Varianten.
Und natürlich ist die Software, die in größeren Firmen bei uns
erstellt wird, international.
Sie wird international verkauft.
Das heißt, sie muss mit internationalen Versionen ausgestattet sein.
Das heißt, mit unterschiedlichen Sprachen für die Eingaben, für die
Ausgaben, für die Fehlermeldungen, für die Bedienungsanleitung,
vielleicht auch mit unterschiedlichen Währungen.
Sie muss ausgestattet sein für unterschiedliche Besteuerung.
Mehrwertsteuersätze sind unterschiedlich, die Besteuerung überhaupt
ist unterschiedlich.
Ich rede zu laut.
Danke.
Flüstern, wenn Sie wirklich müssen, flüstern.
Ich höre Sie einfach, das bringt mich total raus.
Es ist nicht, dass ich etwas dagegen habe, aber ich denke mir, es
lenkt ab.
Okay, so.
Wir gehen jetzt zu der längeren Definition von Softwaretechnik.
Wir hatten ja schon gesagt am Anfang, ganz einfach gesagt, das ist die
Konstruktionslehre für die Entwicklung und Pflege von
Softwaresystemen.
Jetzt erweitern wir sie aber nur ein bisschen.
Softwaretechnik, Softwareengineering, die technologische und
organisatorische Disziplin, diese beiden Begriffe erkläre ich gleich.
Disziplin zur systematischen Entwicklung und Pflege, das hatten wir
schon, von Softwaresystemen.
Softwaresysteme hatten wir auch schon definiert.
Und das neue ist, die spezifizierte, funktionale und nicht funktionale
Attribute erfüllt.
Jetzt gehe ich nochmal durch diese einzelnen Begriffe durch.
Es fragen manche Leute, ich bin so schlecht im Auswendiglernen.
So eine Definition muss man einfach wissen.
Was ist es?
Was ist die Softwaretechnik?
In jeder Klausur kommen auch so einfache Fragen dran, wo man sagt, was
ist, definieren sie oder vergleichen sie oder stimmt die Definition,
was ist falsch?
Das ist das Einfachste, was Sie lernen können.
Organisatorische und technologische Disziplin zur Entwicklung und
Pflege von Softwaresystemen, systematisch muss es auch noch sein und
ich brauche dazu Qualitätsattribute, nämlich funktionale Attribute und
nicht funktionale Attribute.
Das zeige ich Ihnen gleich noch.
Technologisch ist klar, wir arbeiten mit Techniken, nämlich mit
Software, aber was sind denn organisatorische Aspekte?
Das heißt leider, das gehört halt auch zur Softwaretechnik, nämlich
die organisatorischen Aspekte werde ich mich nicht sehr lange
aufhalten, bis an den Schluss der Vorlesung, wenn wir über die
Prozesse sprechen, aber da gehört zum einen die Planung dazu, was
mache ich, wann, wie, wo, mit wem, was ist von wem zu tun, was sind
die Kosten?
Das werden wir zum Teil behandeln heute, nicht so das wie und das wo,
sondern das was und die Kostenschätzung werden wir auch erst am Ende
der Vorlesung machen.
Dann das andere organisatorische, wenn Sie also Manager geworden sind,
brauchen Sie Personal und Ihre Stellen zu besetzen.
Sie müssen die Arbeit organisieren, die Regeln für die Zusammenarbeit,
natürlich auch die Arbeitsaufteilung, die einzelnen Aufgaben, die
verteilt werden müssen, wie macht man das, wer ist für was zuständig,
wer hat Verantwortung, wer berichtet an wen, also meistens berichtet
man natürlich an den Teamleiter oder Teamleiter, an den
Abteilungsleiter.
ja gut, dazu zur Arbeitsorganisation werden wir mehrere Prozessmodelle
besprechen.
Das allererste wird sein das sogenannte Wasserfallmodell, das
besprechen wir heute ganz kurz, aber es gibt natürlich modernere, die
wir gegen Ende der Vorlesung auch noch behandeln werden.
Dann Leitung, Motivieren und Kommunikation von Zielen, darüber werde
ich gar nicht sprechen.
Und die Kontrolle, prüfen, ob die Arbeit auch geleistet wird, ob alles
läuft, wie es soll, der Plan nach Plan fortschreitet, man sich an den
Plan hält und die Anforderungen erfüllt werden und entsprechende
Gegenmaßnahmen.
Also des organisatorischen Aspektes sind immer diese Fünfe hier.
Planung, Personal, Organisation, Leitung, Kontrolle.
Vertrauen ist gut, Kontrolle ist besser.
Dann kann man es sich vielleicht merken.
So, und dann kam jetzt dieses Wort systematisch drin vor, es wird
nicht herumprobiert, man weiß, wie man es machen muss, welche Methoden
und Werkzeuge man einsetzt, man ist jetzt nicht dabei und sagt, da
weiß ich jetzt gar nicht wie ich das machen soll, ich probiere mal
was.
Das ist eigentlich nicht systematisch.
Entwicklung und Pflege, das hatten wir schon besprochen.
Während der Entwicklung gibt es Änderungen, neue Anforderungen kommen
herein, die eingebaut werden müssen.
Es gibt natürlich auch Fehler, die korrigiert werden müssen und die
Gesamtkosten für ein System über die gesamte Lebenszeit kann durchaus
so sein, dass sie zwei Drittel oder vielleicht sogar drei Viertel der
Kosten schließlich nur in der Pflege der Software verschwindet.
Gut, und dann hatten wir noch die funktionalen Attribute und die nicht
-funktionalen Attribute.
Funktionale Attribute sind ganz einfach, das sind die Funktionen, die
Tätigkeiten, die das Software-System ausführt.
Sie schreiben also vor, was weiß ich, für ein Toll Collect ähnliches
System sagen Sie so etwas wie eine Funktion, das System muss
automatisch die Mautgebühren abrechnen und ohne anhaltendes Lasters
zum Beispiel.
Das wäre eine funktionale Anforderung.
Eine nicht-funktionale Anforderung sind meistens auch Anforderungen an
die Qualität.
Das sagt zum Beispiel, wie schnell die Software arbeitet.
Das könnte zum Beispiel heißen, jede Antwort an den Benutzer nach
Eingabe ist nach, was weiß ich, zwei Sekunden da.
Die Antwortzeit ist daher zwei Sekunden oder ich sage etwas wie in
meinem Webladen müsste ich 10.000 Anforderungen, also 10.000
Bestellungen pro Minute durchführen können.
Was übrigens gar nicht so viel ist.
Amazon kann viel mehr.
Oder das wäre eine Durchsatzfrage.
Also Antwortzeit ist das eine.
Wie schnell kommt die Antwort?
Durchsatz sagt, wie viele Aufträge, Berechnungen kann ich pro Sekunde
oder pro Stunde ausführen.
Das wäre der Durchsatz.
Das betrifft also die Geschwindigkeit.
Dann wie zuverlässig, da würde man sagen, wie oft darf das System
ausfallen.
Wenn Sie sich vorstellen, Sie wären Amazon, da wollen Sie eigentlich,
dass das System nie ausfällt, denn wenn es ausfällt, verlieren Sie
Geschäft.
Also haben Sie vielleicht eine Zuverlässigkeitsanfrage, die sagt, das
System darf, was weiß ich, pro Monat nicht mehr als eine Stunde nicht
verfügbar sein.
Oder strenger, pro Woche nicht mehr als fünf Minuten.
Je nachdem, das ist eine Anforderung.
Bei Bürosoftware ist das natürlich weniger kritisch.
Wenn da irgendwie eine Textverarbeitung mal abstürzt, ist zwar Zeit
verloren, aber ist nicht so kritisch wie woanders.
Das wäre Zuverlässigkeit, Benutzerfreundlichkeit.
Benutzerfreundlichkeit ist schwer zu messen.
Man kann natürlich sagen, ja, meins ist super benutzerfreundlich, dann
versucht es ein anderer und kommt nicht damit zurecht.
Benutzerfreundlichkeit misst man meistens so, dass man sagt, wie viele
Interaktionen mit dem System brauche ich, um eine Aufgabe zu erfüllen.
Muss ich 25 Mal klicken, durch 23 Menüs durch oder nur noch zwei.
Und wie sicher, auch das ist schwer zu quantifizieren, denn wir wissen
nicht, was die Hacker sich gerade ausdenken, um unsere Systeme
anzugreifen.
Aber gerade zu diesem Teilbereich, übrigens sehr wichtig in der
Informatik geworden, seit alles am Internet ist, gibt es eigene
Vorlesungen dafür.
Wir handeln hier auch nicht.
Und dann gibt es noch innere Qualitäten, die die Software intern hat,
von denen der Benutzer nichts merkt.
Das ist die sogenannte Änderbarkeit.
Wir sagten ja vorhin, dass während der Entwicklung, während dem
Lebenszyklus eines Softwaresystems sich das Betriebssystem ändern
kann, Portabilität sein kann oder ich neue Funktionen einfügen muss.
Dazu muss die Software auch so geschrieben sein, dass ich sie ändern
kann.
Das heißt, der Bearbeiter oder die Bearbeiterinnen müssen sie
verstehen können und ändern können.
Da ist also Spaghetti Code nicht das geeignete.
Dokumentationsgrad gehört auch dazu.
Noch ein kleiner Nebenbemerkung.
Wir leben nicht in einer idealen Welt.
Das heißt, die Aufgabe der Softwaretechniker ist nicht, die allerbeste
Software der Welt zu null Kosten übermorgen fertig zu haben.
Alles was wir brauchen, und das ist schon ziemlich viel, ist, dass wir
Software in ausreichender Menge für die Welt zur Verfügung stellen,
von zufriedenstellender Qualität, muss nicht perfekt sein, muss aber
zufriedenstellend sein und Qualitätsanforderungen können sich
unterscheiden.
Ein Kernkraftwerk hat sicher höhere Qualitätsanforderungen als eine
Textverarbeitungssoftware.
Aber wir brauchen sie von zufriedenstellender Qualität, sie muss
termingerecht da sein und sie muss zu wettbewerbsfähigen Kosten sein.
Sie muss nicht billig sein, sie darf aber nicht zu teuer sein.
Nehmen Sie dem Mann hinter Ihnen ein bisschen Kaffee.
Brauchen Sie Kaffee?
So, jetzt gibt es noch den Begriff der Softwareforschung.
Zur Abgrenzung der Softwareforschung oder Software Engineering
Research oder auch einfach nur Software Research ist die
Bereitstellung von Methoden und Werkzeugen und deren Bewertung.
Also sowas wie Eclipse oder einen Differenzgenerator oder Übersetzer
oder Programmchecker statische und dynamische Analyseverfahren,
unterschiedliche Fehlertypen finden.
Das sind die Werkzeuge, die Softwaretechnikforschung entwickelt und
nachdem es da sehr viele Anstrengungen gibt, ist es auch wichtig zu
bestimmen, ob diese Werkzeuge auch nützlich sind.
Ob sie wirkungsvoll sind und sagen wir, die Qualität von Software
verbessert oder die Herstellung beschleunigt.
Das sind eigentlich die Hauptkriterien, die man verbessern, einfacher
zu entwickeln lässt, mit weniger Fehlern oder Zeit spart.
Und da untersucht die Forschung auch die Bewertung von solchen
Verfahren.
Zum Beispiel, ich gebe Ihnen jetzt ein Beispiel.
Es gibt da das Feld aus der aktuellen Forschung, es gibt das Feld der
Softwaremetriken.
In der Softwaremetrik, da sagt man sich, wäre es nicht schön, wenn wir
Software gut vermessen könnten.
Physische Objekte können wir prima vermessen, wir können deren Größe
bestimmen, wir können das Gewicht bestimmen, wir wissen, wie man sie
beschleunigt, welche Energie man braucht, um sie herzustellen oder zu
beschleunigen, zu befördern, was immer es ist.
Temperatur können wir messen, Luftdruck können wir messen, wir können
alles mögliche messen.
Und wäre es nicht gut, wenn wir auch Software vermessen könnten und
insbesondere die Qualität vermessen könnten.
Bei physischen Objekten können sie sagen, wenn ich einen Kolben in den
Motor einsetzen muss, dann muss er eine bestimmte Durchmesser haben
und der Durchmesser darf nicht um 0,1 Millimeter abweichen.
Genauigkeit von plus, minus 0,1 Millimeter, sonst ist das Ding nicht
zu gebrauchen.
Gibt es denn nicht sowas für Software?
Ja.
So, dann gab es jetzt jahrelang Forschung darüber, ob es nicht gute
Softwaremetriken gäbe und es gibt natürlich welche und die sind
meistens von der Sorte, zählen wir mal.
Da werden gezählt, wie viel Zeilencode das ist.
Sagt man, je länger das Ding ist, desto schwieriger ist es.
Desto schwieriger ist es zu erstellen, desto mehr müssen wir testen.
Ist auch klar, dass ich natürlich eine Million Zeilencode nicht so
schnell erstellen kann wie 10.
Ja, okay.
Dann gibt es Verfeinerungen davon, die sagen, okay, wir zählen jetzt
nicht die Zeilencode.
Also als erstes zählen wir die Kommentare gar nicht, wir zählen nur
echten Code.
Und nachdem das vielleicht ein bisschen nicht viel Aussage gab,
könnten wir auch die Klassen zählen.
Oder wir könnten zählen, wie viele Funktionen oder Methoden jede
Klasse enthält und davon einen Mittelwert bilden.
Wenn wir ein System haben, wo der Mittelwert irgendwie größer ist als
10 oder so, dann sagen wir, das ist aber nicht gut.
Das ist qualitätsmäßig nicht so besonders.
Und wenn wir Klassen finden, die sehr, sehr groß sind, dann sagen wir
auch, da müssen wir aber genau hinschauen, ob das gerechtfertigt ist.
Vielleicht müssen wir die Klassen teilen.
Klingt alles vernünftig.
Also es gibt auch recht komplexe Dinge.
Die sagen auch, wenn ich eine Methode aufrufe, wie viele andere
Methoden werden da mit aufgerufen?
Auch das ist eine Maßzahl.
Das ist dann meistens dynamisch bestimmt.
Das kann ich nicht nur vom Code ablesen, sondern muss ich den Code
unter Umständen laufen lassen.
Ich würde sagen,
drei Dutzend unterschiedliche Metriken.
Jetzt gab es eine Untersuchung, bei Microsoft, die gesagt hat, welche
dieser Metriken eignet sich, um Fehleranfälligkeit vorherzusagen?
Also ist es jetzt die Anzahl der Methoden, die aufgerufen wird, die
Länge alleine, oder ist es die Anzahl der Klassen, oder ist es die
Anzahl der Methoden pro Klasse im Schnitt, oder was da alles gab?
Die hatten, ich würde sagen, zwei Dutzend dieser Metriken
durchprobiert.
An fünf großen Systemen von Microsoft ist egal, wie die heißen.
Die wurden dann sowieso anonymisiert.
Das hieß dann nur noch ABCDE.
Die wollten sich auch nicht losstellen, welche Systeme schlecht sind.
Was sie jetzt gemacht haben, ist, sie sagen, wir wissen, die Software
ist fertig.
Sie ist ausgeliefert worden und wir wissen, wie viele Fehler
zurückgemeldet wurden an den Hersteller.
Der Hersteller ist dann hergegangen und hat gesagt, gut, jede
Fehlermeldung, die wir dann bekommen haben nach der ersten Lieferung,
die verknüpfen wir jetzt mit den Modulen oder Modulen, Klassen, die
bei der Korrektur geändert werden mussten.
Dass wir wissen, wo die Fehler lagen.
Das ist auch ziemlich schwierig, aber diese Arbeit haben sie sich
gemacht.
Es geht natürlich über GIT und was immer die benutzen für
Versionskontrolle und die Fehlerverfolgungssoftware, die sie hatten,
konnten sie also zurückprojizieren die Fehlermeldungen auf die
defekten Module.
Und dann konnten sie sagen, okay, jetzt rechnen wir für jedes Modul,
sprechen wir mal nur von einer dieser Metrik, sagen wir Anzahl Zeilen
Code.
Für jedes der Module rechnen wir aus den Anzahl der Zeilen Code und
setzen das in Bezug zu der Anzahl der Fehler.
Sie können sich das vorstellen, Sie haben zwei Achsen und das ist
Anzahl der Fehler nach Auslieferung, Entschuldigung, andersherum,
Anzahl der Fehler nach Auslieferung an der vertikalen Achse und auf
der horizontalen Achse die Metrik.
Sagen wir Zeilen Code.
Und dann tragen wir die einzelnen Punkte ein.
Jedes Modul wird ein Punkt.
Also ich hatte 10.000 Zeilen und 23 Fehler, das ist ein Punkt.
Oder ich hatte 100 Zeilen, keinen Fehler.
Das ist auch ein Punkt in diesem Koordinatensystem.
Dann bekommen sie so eine Punktwolke.
Aus dieser Punktwolke rechnen sie jetzt aus eine Korrelation.
Die sagt, gibt es einen Zusammenhang zwischen diesen beiden Zahlen,
nämlich der Metrik Zahl, der Anzahl Zeilen Code und Anzahl der Fehler.
Wenn es nämlich so einen Zusammenhang, so eine Korrelation gibt, dann
könnte ich das benutzen für eine Vorhersage.
Dann könnte ich später hergehen und sagen, ich habe hier ein Modul,
das hat 256 Zeilen.
Auf meiner Korrelation kann ich jetzt auf diese X-Achse gehen und 256
Zeilen nehmen und danach schauen, wie viele Fehler es möglicherweise
haben wird.
Und wenn ich dann im Bereich bin, wo sehr viele auftreten, dann sage
ich, okay, da muss ich besonders häufig testen.
Okay?
Klingt vernünftig.
Was kam raus?
Raus kam, es gibt keine Korrelation.
Es gibt keine.
Und das haben sie für alle Metriken gemacht.
Sie haben dann begonnen, Metriken zu kombinieren.
Vielleicht muss man mehrere dieser Metriken linear kombinieren.
Das kann man auch machen.
Erklärt man, wie das geht, kann man in der Vorlesung von mir hören,
empirische Softwaretechnik.
Und sie haben also Folgendes, ich muss das genauer sagen, es gibt eine
Korrelation, aber nur innerhalb eines bestimmten Systems, eines festen
Systems.
Nehmen sie also, sage ich, Internet Explorer her.
Für den können wir, wenn wir schon alle Fehler wissen, dann können wir
eine Korrelation bilden, die dann auch ziemlich gut ist in der
Vorhersage der Fehler.
Aber die mussten wir schon haben, um die Korrelation überhaupt zu
bilden.
Das heißt also, was sie gerne machen würden, ist, diese Korrelation,
die sie da für Internet Explorer ausgerechnet haben, auf ein anderes
Produkt übertragen.
Und das geht nicht.
Das heißt also, was sie gelernt haben, über diesen Zusammenhang
zwischen Metriken und Fehleranfälligkeit an einem System, können sie
nicht auf ein anderes System übertragen, wodurch sie natürlich nutzlos
werden.
Und tatsächlich, es gibt keine solche, jedenfalls noch nicht, eine
solche Metrik.
Das ist eine extrem wichtige Erkenntnis, weil das ging voraus Dekaden
von Forschung in Softwaremetriken.
Und das war das erste richtig große Studio, die gesagt hat, Leute,
vergesst es.
Es klappt so nicht.
Wie kann ich denn Maßstäbe setzen?
Ich glaube, das ist ziemlich einfach.
Sie sagen, was die wirklich machen wollten, ist, dass sie sagen
konnten, können wir fehlerträchtige Module identifizieren.
Und da lege ich halt irgendeinen Schwellwert fest.
Dann sage ich, okay, wenn ich ein Modul habe oder ein Subsystem, das
idealerweise eine bestimmte Größe überschreitet, dann weiß ich, dass
die Anzahl der Fehlerträchtigkeit stark nach oben geht.
Und dann verwende ich extra viel Zeit auf das Testen dieser wenigen
Module.
Und damit ist der Kunden zufriedener, weil die nun jetzt häufig
auftretenden Fehler eliminiert sind.
Das war die Idee.
Dann können Sie irgendwo einen Schwellenwert festsetzen, wie Sie den
festlegen, ist egal.
Was halt geeignet ist.
Das hängt auch mit dem, was Sie leisten können, zusammen.
Sie können nicht jedes Modul extra festtesten.
Sie müssen ja immer sagen, bei 10 Prozent der Module können wir uns
extra Zeit nehmen.
Und dann legen Sie diese Schwelle fest.
Also, Metrik hilft nichts.
Jedenfalls nicht für Fehlervorhersage.
Und das ist eben, was Forschung ist.
Wir sind ja immer gehalten, wir heißen Forschungsuniversität, wollen
ja immer Sie auf aktuelle Forschung verweisen.
Jetzt habe ich das gerade mal getan.
Ich hoffe, ich kann das noch ein paar Mal mehr machen.
So, Methoden.
Es geht darum, den Unterschied zwischen Methoden und Verfahren
herauszuarbeiten.
Ich hatte vorhin gesagt, die Festlegung von Methoden und
Bereitstellung von Methoden und Verfahren und Werkzeugen.
Das sind Vorgehensweisen, zu erreichen von Zielen, halten den Weg zu
etwas hin und dabei wird nicht herumprobiert und geben an, welche
Konzepte verwendet werden.
Das kann durch ein oder mehrere Verfahren unterstützt werden.
Verfahren sind expliziter, detaillierter.
Sie geben direkte Vorschriften an und beschreiben einen konkreten Weg
zur Lösung.
Also mehr einsatzbezogen und enthalten formale Vorschriften.
Ich zeige Ihnen das zum Beispiel.
Angenommen, wir machen die sogenannte objektorientierte Analyse, die
wir noch lernen werden, aber die Sie zum Teil ja schon kennen.
Die Methode oder die Vorgehensweise ist, wir orientieren uns an den
Daten des Systems, das ist das statische Modell und an der
Funktionalität des Systems, das ist das dynamische Modell.
Das heißt, wir sagen lediglich, wir brauchen irgendwie eine
Modellierung des Systems, das die Daten berücksichtigt.
Ein Verfahren wiederum sagt Ihnen genauer, wie Sie dieses Prinzip oder
diese Methode umsetzen.
Und auch das werden wir besprechen, nämlich wenn Sie sich vor der
Frage stellen, ich müsste jetzt ein objektorientiertes Modell
erstellen, dann würde ein Verfahren Ihnen sagen, wie geht das?
Wie finde ich die Klassen?
Wie finde ich die Methoden?
Wie finde ich die Assoziationen zwischen den Klassen, Attribute der
Klassen?
Wie entferne ich Redundanzen?
Wie finde ich Vererbungshierarchien?
Wie stelle ich die auf?
Da gibt es Verfahren dazu.
Zum Beispiel, um in einem Verfahren, in einem UML, dieser Unified
Modelling Language, zu bleiben, um die Klassen zu identifizieren, geht
man her und sucht sich die Nomen in einem Text, im Anforderungstext,
der die Software beschreibt.
Sagt dann, okay, die Nomen sind Kandidaten für Klassen.
Die beschreiben einzelne Objekte, die wir in der Software brauchen und
Namen von Personen oder auch von Dingen, die drin vorkommen, die
beschreiben Instanzen.
Und damit kann ich anfangen, ein Modell zu bilden.
Das werden wir noch genauer besprechen, aber wie gesagt, die Methode
sagt allgemein, wir orientieren uns an den Daten und den Funktionen,
ohne genau zu sagen, wie das geht.
Wir haben das Verfahren dann gesagt, gehen Sie so vor, Schritt für
Schritt für Schritt.
Werkzeuge automatisieren Teile davon, von den Verfahren oder
unterstützen und ersparen uns damit Arbeit oder überprüfen.
Zum Beispiel, das Verfahren könnte sein, wir legen die
Kontrollstrukturen einer Programmiersprache fest, die wir benutzen
dürfen, also zum Beispiel wenn wir eine C programmieren dürfen, sagen
wir, wir wollen kein Goto verwenden, keine Sprünge, denn das führt zu
Spaghetti -Code und der ist schwer lesbar und schwer wartbar, wollen
wir vermeiden.
Das kann ich also im Verfahren festhalten, aber ein Werkzeug könnte
dann überprüfen, ob es tatsächlich geschieht.
Das könnte also ganz einfach durchforsten, ein Programm auf Gotos.
Oder auch sonstige Textile kennen Sie auch, auf unerwünschte
Konstrukte oder Formulierungen.
Hier kommt ein aktuelles Beispiel, das ist von 2014.
Das ist der sogenannte Apple-SSL-Fehler, der eine große
Sicherheitslücke war.
Weiß das noch jemand?
Hat das jemand noch auf dem Radar?
Kennt das jemand?
Ja, ein, zwei.
Ja, sehr schön.
Ja, da haben Sie vielleicht 2014, haben Sie vielleicht noch nicht
hingeschaut, aber es ging durch die Presse und alles.
Hier ist der Code.
Wo ist der Fehler?
Den sehen Sie, aber Sie müssen hinschauen.
Natürlich verstehen Sie von dem Zeug nichts, aber Sie können raten, wo
der Fehler ist.
Hier.
Genau.
Exakt.
Ja.
Hier ist der Fehler.
Ja.
Sagen Sie, wie?
Das hier bedeutet, dass...
Ja, Sie haben es gesagt, der ist nicht ausgerückt, eigentlich müsste
das Code hier ausgerückt sein, damit man es gleich sieht, aber ist
halt auch ein Fehler.
Was immer das Ding verursacht, dann springe ich zu fail und wenn es
keinen Fehler verursacht, dann springe ich auch zu fail.
Was heißt das?
Der Code, der hier steht, wird nie ausgeführt.
Der wird nie ausgeführt, wir springen immer von hier nach hier.
Und das war es.
Hier war noch eine wichtige Überprüfung dabei, die dann einfach nicht
ausgeführt war.
Eine automatische, ich gebe zu, das ist vielleicht nicht auf den
ersten Blick erkennbar, erst wenn man gewissermaßen sensibilisiert ist
dafür, aber ein Werkzeug hätte das ohne weiteres erkannt.
Das hätte ich gesagt, zumindest schon.
Benutzen Sie hier GoTools, ist auch nicht nett, aber wenn schon, dann
hast du hier einen Fehler, weil alle Sprünge führen über diesen Teil
hinweg.
Können wir das löschen?
Ist das Kunst oder kann das weg?
Und damit wüssten Sie, da ist was falsch.
Natürlich habe ich das hingeschrieben, weil ich es brauchte.
Eine automatische Prüfung hätte das gefunden.
Also, wir können mit Werkzeugen das Einhalten von Verfahren und
Vorgehensweisen, Methoden, Standards oder auch Notationen erzwingen
oder ermutigen und die Produktivität durch Automatisierung erhöhen.
Werkzeuge benutze ich immer dann, wenn ich hohe Präzision erfordere,
große Mengen zu untersuchen habe, also oft wiederholt werden müssen,
jedes Mal, wenn das Programm wieder verändert, müsste ich wieder eine
Prüfung durchmachen.
Das mache ich händisch nicht, weil da fehlt mir die Aufmerksamkeit,
habe vielleicht auch nicht die Zeit und die Überprüfungen, die
automatisch geschehen sollen, machen wir natürlich automatisch.
Das ist also eine Klasse von Werkzeugen.
Natürlich gehören MAVEN und GIT auch zu diesen Werkzeugen dazu.
Die automatisieren einfach Prozessschritte für ein Buch während der
Softwareentwicklung.
Es ist natürlich klar, dass sie wichtig sind.
Es gibt einen Bereich in der Softwareforschung wiederum, der heißt
CASE, das heißt Computer Aided Software Engineering.
Das ist
eine Abwandlung von CAD, Computer Aided Design, wo Sie am Rechner
Maschinen oder Gebäude entwickeln.
So hat man auch dieses CASE Computer Aided Software Engineering sich
ausgedacht und da geht es auch um die Sofortentwicklung oder
Entwicklung von Softwarewerkzeugen.
Zum Beispiel Werkzeuge zum Gestalten grafischer Oberflächen.
Wir werden sehen, wie man das macht im Laufe der Vorlesung.
Wir werden über grafische Oberflächen sprechen.
Wir werden es auf die primitive Art und Weise tun, nämlich einzelne
Knöpfe durch Aufrufe platzieren.
Initialisiere einen Knopf und platziere ihn an einem bestimmten Punkt
in dem Konstrukt, da gibt man die Werte der Koordinaten an.
Damit kann man kleinere Benutzeroberflächen durchaus gestalten, aber
es gibt natürlich sehr schlaue Werkzeuge, mit denen Sie die
Benutzeroberfläche gewissermaßen malen können und der entsprechende
Code erzeugt wird.
Das ist auch ein Werkzeug, aber das werden wir leider nicht sehen,
aber Sie werden sehen, wie eine grafische Benutzeroberfläche intern
funktioniert.
Was mir in dieser Vorlesung wichtiger ist, als die allertollsten
Benutzeroberflächen zu gestalten.
Und jetzt.
Überblick über den Aufbau der Vorlesung.
Wir sind also jetzt mit der Einführung fast fertig.
Noch diese Folie und dann noch eine lustige Folie.
Dieses Vorgehensmodell heißt der Wasserfall oder Waterfall im
Englischen aus dem einfachen Grunde, weil wir mehrere Phasen haben, in
diesem Fall sechs Stück.
In diesen Phasen entstehen Dokumente oder Arbeitsprodukte oder
Programme oder Enthörfe.
Die werden in der nächsten Phase übergeben, dort wieder bearbeitet und
noch mehr daraus gemacht.
Zum Beispiel haben wir erstmal mit einer Planungsphase zu sprechen.
In der Planung legen wir fest, was wir herstellen wollen, was es
kosten wird, ob wir es überhaupt können.
Das wird in der Planungsphase gemacht und das machen wir als nächstes.
In der Definitionsphase gehen wir her und nehmen diese Beschreibung
des Systems, das übrigens in den Worten des Kunden beschrieben ist,
und wandeln das um in eine exakte Beschreibung, indem wir Modelle
bilden.
Klassenmodelle.
Und wenn wir diese Klassenmodelle haben, dann gehen wir in die
Enthorfsphase.
In der Enthorfsphase sagen wir, wie wir das Gesamtsystem
strukturieren.
Welche Subsysteme es gibt, welche auf das Internet verteilt sind,
welche auf dem einen und dem anderen Rechner laufen und so fort.
Das ist der Enthorf, da werden wir uns sehr, sehr lange damit abmühen
müssen, denn das ist ein ganz wichtiger Anteil, der die Zukunft des
Gesamtsystems bestimmt, nämlich seine Änderbarkeit.
Wir werden sehr lange darüber sprechen.
Und dann kommt die eigentliche Implementierung.
Die eigentliche Implementierung besteht dann nur noch im Auscodieren
der Klassen, die Sie in der Enthorf angelegt haben.
Im Enthorf legen Sie sogar schon die Schnittstellen der einzelnen
Methoden fest und lassen die Rümpfe leer.
Und das geschieht in der Implementierung.
In der Implementierung geschieht außerdem der Modultest.
Das heißt, Sie nehmen die einzelnen Klassenpakete her und testen sie
für sich.
Anschließend an diese Phase kommt der Systemtest.
Da gibt es unterschiedliche Ausprägungen, die werden wir später noch
genauer sehen.
Unterschiedliche Testverfahren.
Beim Testverfahren ist eine Frage besonders wichtig.
Und die ist, wann darf ich denn aufhören zu testen?
Sie wissen, die Eingaben sind ja nahezu unbeschränkt.
Und wir können unmöglich den gesamten Eintrageberaum in jedem
Einzelfall durchtesten.
Das geht schon bei den einfachsten Programmen, die nur eine Schleife
haben, nicht mehr.
Wenn die Anzahl der Schleifen-Iterationen abhängt von der Eingabe,
dann haben Sie schon Trillionen von Möglichkeiten.
Also das werden wir nie schaffen, dass wir ein Programm, ein System
komplett testen.
Das heißt, wir können nur Stichproben nehmen und da ist die Frage
jetzt, wann haben wir genügend Stichproben gezogen?
Wann haben wir genügend Zuversicht, dass das System keine Fehler mehr
enthält oder wir in absehbarer Zeit keine finden werden.
Da gibt es sogenannte Testvollständigkeitskriterien, die wir hier
behandeln werden für unterschiedliche Testverhandlungsweisen.
Die garantieren wir keine Fehlerfreiheit, aber die geben wir ein
Kriterium, wenn ich sagen kann, ich habe jetzt ausreichend getestet.
Und schließlich kommt Abnahme, Einsatz und Wartung.
Das heißt, wenn das ein Auftragssystem war, dann wird der Auftraggeber
Ihnen verlangen, dass er eine Abnahme durchführt.
Der Abnahme ist im Wesentlichen eine Vorführung des Systems, unter
unterschiedlichen Bedingungen wahrscheinlich.
Dann geht es über in den Einsatz.
Das heißt, das System geht in den Produktivitätsmodus und dann tritt
ein die sogenannte Wartung.
Das heißt, jetzt beginnt die Zeit, wo die Pflege trifft.
Das heißt, Sie müssen Fehlermeldungen behandeln, beseitigen und
Erweiterungen vornehmen, Anpassungen vornehmen.
Okay.
Was jetzt dieses Wasserfallmodell betrifft, ist, wir werden jede
dieser Phasen einzeln vornehmen.
Die moderneren Vorgehensweisen gehen her und vermischen diese Phasen
mehr oder weniger oder behandeln sie iterativ.
Um die Vorlesung aber nicht alles zu vermischen, gehe ich also her und
behandle diese Phasen alle für sich, wohl wissend, dass in der Praxis
das nicht so gemacht wird.
Es ist selten so, dass Sie eine Planungsphase haben, die komplett
abgeschlossen ist und keine Änderungen mehr ergibt und Sie erst dann
weitergehen dürfen in die Definition.
Und Sie müssen nicht warten mit der Definition, bis jedes Subsystem
ausdefiniert ist, um mit dem Entwurf eines definierten Subsystems zu
beginnen.
Aber ich mache das aus pädagogischen Gründen, diese strenge Trennung,
damit Sie sehen, was die eigentlichen Aufgaben in der Planung, in der
Entwurf, in der Implementierung, im Testen ist in gewissen Maßen in
Isolation, in Reinform.
Und später, wenn wir das alles verstanden haben, dann zeige ich Ihnen,
was Extreme Programming tut und wie Scrum funktioniert und wie
Microsoft es macht und wie die iterativen Modelle es tun.
Sie brauchen mir also nicht sagen, das ist aber ganz veraltet,
überholt, der Wasserfall, wieso erzählt er mir das?
Ich mache das aus einem guten Grund, nämlich aus didaktischem Grund.
Warum heißt es Wasserfall?
Er hat fast die richtige Anzahl von Phasen.
Er hat nur 5.
Er ist der sechste wahrscheinlich.
Abnahme.
So,
jetzt also die Planungsphase.
Dazu dürfen Sie gleich Literatur lesen, nämlich aus dem Buch, das ich
Ihnen genannt hatte, von Brügge und Dittoy, Object-Oriented Software
Engineering Using OML Patterns in Java.
Und wir lesen drüber die Use Case Diagrams and Requirements
Elicitation in diesen Abschnitten.
Es kann sein, dass es in neueren Ausgaben sich ein bisschen verschoben
hat, also nagen Sie mich nicht fest, aber Kapitel 4 wäre ganz was
anderes.
Dann blättern Sie halt ein paar Seiten weiter und dann finden Sie
bestimmt die Requirements Elicitation und die Use Case Diagrams finden
Sie auch.
Also jetzt geht es darum, also lesen, es geht es darum, die
Planungsphase zu machen, diese anderen Phasen kommen später, da kommt
jetzt ein Bildchen, das werde ich aber nicht erklären, weil ich das
schon mündlich gemacht habe.
Was passiert in der Planungsphase?
Planungsphase sagt, eigentlich hätte ich es andersrum in Reihenfolge
nehmen sollen, wir stellen ein sogenanntes Lastenheft her.
Das Lastenheft beschreibt die Eigenschaften des Systems, funktional
und nicht funktional, in Worten des Kunden, nicht in Worten des
Informatikers.
Warum in Worten des Kunden?
Weil der Kunde eben mit mir diskutieren möchte, mit Ihnen diskutieren
möchte, was das System tun soll und denen ist es egal, ob das Client
-Server ist oder mit dem Besuchermuster oder als Fließband
implementiert ist oder als Schichtenmodell, das ist völlig egal.
Das kommt viel später erst, wir müssen erstmal wissen, welche
Funktionen der Benutzer haben möchte.
Dieses Wort Lastenheft ist übrigens keine Erfindung der Informatik,
das gibt es auch in anderen Bereichen, sagen wir zum Beispiel im
Maschinenbau, da hatte ich gerade das Vergnügen, das zu beobachten.
Mein Sohn ist Maschinenbauer und er musste eine neue Presse entwickeln
und der Pressehersteller ist, ja, da gibt es sehr viele und der hat ja
tatsächlich ein Lastenheft aufgestellt.
Das kenne ich doch.
Also, das Lastenheft beschreibt die Eigenschaften unseres zukünftigen
Systems aus der Sicht des Benutzers oder auch des Auftraggebers.
Dann gibt es dazu eine Durchwirkbarkeitsstudie, wir müssen uns sicher
sein, wenn wir als Unternehmen das aufnehmen wollen, ein Angebot
machen wollen, ob wir das auch können.
Wir brauchen eine Projektkalkulation, wir müssen sagen, okay, für wie
viel können wir das anbieten.
Das bestimmt dann natürlich auch, ob wir wettbewerbsfähig sind, aber
wir wollen wahrscheinlich keinen Verlust machen und außerdem brauchen
wir einen Projektplan, der sagt, wann machen wir was?
In welchen Schritten führen wir das aus?
So, und das, wo wir uns am meisten befassen werden, ist das
Lastenheft.
Also, in Worten des Kunden zu beschreiben im Lastenheft, das haben wir
jetzt gesagt, die Phase wird auch übrigens im Englischen Requirements
Elicitation Phase genannt oder auch einfach nur Requirements.
Requirements sind Anforderungen und auf Deutsch kann man dazu auch
sagen, Anforderungserhebung oder Ermittlung.
Aber meistens sagen wir einfach Lastenheft machen oder Anforderungen
erstellen oder planen.
Eine Anforderung, ein Requirement ist wie folgt definiert, a condition
or capability that must be met or possessed by a system or system
component to satisfy a contract, a standard, a specification or other
formally imposed document.
Wir haben jetzt hauptsächlich über die Eigenschaften, das heißt die
Spezifikation, gesprochen, aber selbstverständlich muss ich mich auch
an Standards halten, möglicherweise an
vertraglich vereinbarte Eigenschaften.
Deswegen diese ausführliche Definition or other formally imposed
document.
The set of all requirements forms the basis for subsequent development
of the system or system component.
Das ist eine schöne Definition für eine Anforderung.
So, jetzt Planungsphase.
Erste Schritte, wo fange ich an?
Wo kommt das Zeug eigentlich her?
Es könnte ein Auftrag eines Kunden vorliegen.
Der Kunde droht mit Auftrag.
Das ist wunderbar, dann wissen wir, was zu tun ist.
Möglicherweise wollen Sie aber eine Firma gründen, gerade nach Ihrem
Studium vielleicht.
Haben Sie noch keinen Kunden.
Also was machen Sie stattdessen?
Sie haben vielleicht ein Forschungsergebnis.
Sie haben vielleicht im Master etwas Interessantes gemacht, dass Sie
jetzt ein Produkt umwandeln können.
Oder während des Studiums ist Ihnen überhaupt etwas Interessantes
aufgefallen.
Oder Sie machen so wie Bill Gates und brechen das Studium ab und
machen gleich Ihr Microsoft Number Two.
Was übrigens Bill Gates sagt, das ist ganz lustig, wenn er sagt, also
ich habe mein Studium abgebrochen, but I don't recommend it.
Vorentwicklungen, es gab bereits Entwicklungen in Ihrer Firma, es gibt
Trendstudien, wir müssen aber auch jetzt das machen oder vielleicht
könnten wir das auf ein Mobilgerät bringen.
Es gibt eine Marktanalyse, die Sie machen können oder Sie haben
einfach eine Idee.
Die Idee ist immer das Beste.
Also im PSE, das bei Ihnen ja im nächsten Semester oder übernächsten
Semester ansteht, versuchen wir das gerade zu machen, dass wir auch
die Studenten, wir haben Vorstellungen, Beispiele, dass wir machen
können, aber wir haben auch Gruppen, die sagen, wir haben eine Idee,
wir wollen das und das verwirklichen.
Zum Beispiel hatten wir jetzt letztes Jahr hatten wir die Idee, dass
Sie einen Panikknopf für das Mobiltelefon machen, der so funktioniert,
wenn Sie sich bedroht fühlen, sagen wir in der Dunkelheit oder am
Bahnhof oder so.
Dann drücken Sie auf diesen Panikknopf.
Der Panikknopf sendet eine Panikmeldung an andere Mobiltelefone in der
Umgebung.
Es ist aber nichts, wenn Sie Ihren Bruder anrufen oder so etwas, der
200 Kilometer weg ist, sondern Sie wollen eigentlich Leute sagen, hier
ist jemand, der macht sich Sorgen um seine Sicherheit.
Natürlich gehen wir dann an, wo und in welche Richtung das ist, sodass
die Leute jetzt nicht die Pistole zücken und Verteidigungshaltern
gehen müssen, wie im Film, sondern einfach nur erscheinen, hingehen
und sagen, durch ihre Präsenz die Situation entschärfen.
Es geht nicht darum, jetzt martialisch irgendwie aufzufallen, sondern
einfach nur da zu sein.
Das war eine gute Idee, weil Sie sehen, dass das gar nicht so einfach
ist.
Denn das Mobiltelefon muss sich melden.
Bei wem?
Bei einem Dienstgeber natürlich.
Der Dienstgeber muss sagen, okay, wo bist du?
Ich brauche die Koordinaten.
Welche anderen Mobiltelefone haben sich denn bei mir gemeldet, die
nicht mehr als, sagen wir, 500 Meter weg sind und denen sende ich die
Botschaft.
Das verzögert natürlich auch ein bisschen, aber
das System funktioniert.
Ich weiß nicht mehr, wie es heißt.
Das hätte ich mir vorher überlegen sollen.
Aber man muss da mitmachen, man muss also die Software installieren
und das ist vielleicht ein Handicap.
Das ist nicht vorinstalliert.
Das heißt, die Wahrscheinlichkeit, dass jemand das System auch
wirklich in der Tasche hat, ist leider etwas gering.
Aber als Beispiel für eine Idee, das ist gut.
So, jetzt müssen die Hauptanforderungen an das Produkt ermittelt
werden.
Sie haben sich etwas ausgedacht.
Und jetzt sagen sie, okay, wie finde ich jetzt diese Anforderungen an
das System?
Naja, es gibt Fragebögen.
Sie könnten an zukünftige Benutzer Fragebögen austeilen.
Fragen, welche Funktionen brauchen sie?
Welche Geschwindigkeit brauchen sie?
Welche Daten werden benötigt?
Sie können Interviews führen, die funktionieren meist besser, weil sie
dann die Leute vor sich haben und tiefer gehende Fragen stellen
können, wenn dieser Fragebögen ist so leicht, einfach irgendeinen
Haken zu setzen und zu vergessen, anstelle zu denken.
Sie können eine Aufgabenanalyse oder Dokumentanalyse machen.
Das muss ich ein bisschen genau erklären.
Oft ist es so, dass man ein Automatisierungsproblem hat.
Aber es bereits eine Lösung gibt, aber die Lösung ist auf Papier.
Das heißt, es gibt Formulare, Dokumente, die ausgefüllt werden müssen.
Dann gibt es einen Prozess.
Zum Beispiel denken Sie an Versicherungsabschluss.
Versicherungsabschluss heißt, es kommt ein Versicherungsvertreter zu
Ihnen, der legt Ihnen ein Formular für eine Lebensversicherung vor
oder irgendeine andere Versicherung, Reiserücktrittsversicherung oder
was es da so alles gibt.
Da werden natürlich die Daten erfasst, Ihre Adresse und Namen und so
weiter.
Ihr Alter ist wahrscheinlich ganz wichtig, Ihr Beruf, wo Sie wohnen,
wie viele Kilometer Sie pro Tag fahren und so weiter.
Diese Daten werden alle erfasst und dann kommt irgendjemand, wird das
irgendwie eingereicht und dann gibt es jemand, der schaut sich das an
und sagt, okay, das ist schadensgleich so und so, der ist noch jung
und der ist gefährlich für seine Autoversicherung, die ist teuer und
so.
Das wird also alles händisch gemacht und dann gibt es noch jemand, der
sich nochmal anschaut und so weiter.
Also haben Sie einen papierenden Prozess.
Und jetzt gehen Sie her und sagen, okay, wenn ich den in den Rechner
bringen will, habe ich ja schon die ganzen Formulare.
Das heißt, ich weiß schon, welche Daten zu erfassen sind, welche zu
pflegen sind, dass sie zu aktualisieren sind unter Umständen, kann ich
sogar die Entscheidungsprozesse vereinfachen oder automatisieren.
Das sagt, okay, über 200 Kilometer pro Tag fahren ist klasse so und
so, Autotyp sowieso und so weiter.
Kann ich vielleicht automatisieren.
Aber mein Punkt ist, dass Sie hier mit einer Analyse beginnen können,
da können Sie ganz genau sagen, was gemacht werden muss.
Das ist eigentlich schön.
Oder Sie nehmen sogenannte Szenarien her, Szenarien beschreiben Sie,
mögliche Anwendungsszenarien des Systems.
Ich gebe Ihnen gleich ein Beispiel dafür, das kommt aus dem Buch von
Dittoy.
Dann gibt es diese Anwendungsfälle, die sind Teilmengen von Szenarien,
da nehmen Sie einen bestimmten Vorfall, der gelöst werden muss mit dem
System und dazu gibt es ein bestimmtes Diagramm, das aber leicht
billig ist.
So, ein Szenario.
Schauen wir uns das also an.
Ist die Beschreibung eines Ereignisses oder eine Folge von Aktionen
und Ereignissen aus der Sicht eines Benutzers.
Die Verwendung des Forms in Textform.
Kann aber auch Texte und Bilder und Videos enthalten, Ablaufpläne
enthalten, sowie Details über den Arbeitsplatz.
Ist es im Büro, ist es im Auto, ist es im Logistikunternehmen, ist es
bei Amazon, wo ist es?
Also, wir haben hier ein Szenario aus wie gesagt, Dittoy, Brücke und
Dittoy, die brennende Lagerhalle.
Das ist also eine textuelle Beschreibung eines Vorgangs.
Während Bob mit seinem Einsatzwagen die Hauptstraße entlang fährt,
bemerkt er, dass Rauch aus einem Lagerhaus aufsteigt.
Sein Kollege Alice meldet den Notfall vom Fahrzeug aus.
Alice gibt die Adresse der Lagerhalle in ihren mobilen Rechner ein,
eine kurze Beschreibung der Lage, zum Beispiel nordwestliche Ecke und
eine Priorität.
Sie bestätigt ihre Eingabe, wartet auf Bestätigung zurück von der
Einsatzzentrale.
Der Disponent auf der Leitstelle oder der Einsatzzentrale wird durch
ein Piepen seines Rechners auf den Notfall aufmerksam gemacht.
Er analysiert die Information, die Alice ihm geschickt hat und
bestätigt die Meldung.
Ich habe sie gekriegt, alarmiert die Feuerwehr und gibt die erwartete
Ankunftszeit an Alice weiter.
Ich habe die Feuerwehr alarmiert und sie ist da in 10 Minuten.
Alice empfängt die Bestätigung und die erwartete Ankunftszeit.
Das ist ein Szenario.
Das ist ein System, das Brücke und Freunde tatsächlich mit Studenten
entwickelt haben zur Meldung von Notfällen aus Polizeiautos heraus.
In Pittsburgh übrigens.
Wie gesagt, es kommt im Buch vor, beschreibt also eine einzelne
Instanz von Melden eines Feuers, beschreibt nicht alle möglichen
Situationen, in denen ein Feuer gemeldet werden kann oder ein
sonstiger Notfall.
Das ist nämlich für die Polizei.
Da gibt es alles mögliche von Notfällen.
Karambolage mit oder ohne verletzte Überfälle.
Ich weiß gar nicht, was die Polizei alles machen muss.
Alle diese Notfälle werden irgendwie an eine Zentrale gemeldet, wenn
zusätzlich Hilfe gebraucht wird.
Wir haben auch die Akteure hier genannt.
Polizisten, Disponenten.
Szenarien können auch in der Testphase benutzt werden, in der
Auslieferung eingesetzt werden.
Das heißt also, ich habe dieses Szenario.
Das hilft mir, die Funktion des Systems festzulegen, aber später kann
ich dieses Szenario gewissermaßen als Abnahmetestfall benutzen.
Ich spiele das einfach jetzt dann in der Realität durch.
Ohne das Feuer natürlich zu entfachen müssen.
Man kann es ja auch im Entwurf benutzen, aber das werden wir nicht
weitermachen.
Es ist meist so, dass man die Szenarien, mehrere dieser Szenarien
aufschreibt und die Entwicklung iterativ ist und mit dem Kunden
natürlich durchbesprochen werden muss.
Überarbeitet, sobald sich die Anforderungen ändern.
Wir haben also konkrete Beschreibungen konkreter Vorfälle und Aktionen
und nicht abstrakte Ideen.
Diese Art der Entwicklung ist auch ohne festgesetztes Ende.
Ich kann nicht von vornherein sagen, hier hören Sie auf.
Irgendwann muss ich sagen, es muss es genügend Leuten, in diesem Fall
Polizisten und Disponenten, vorgelegt haben, sind das alle Fälle, die
wir brauchen?
Gibt es noch mehr?
Gibt es noch Variationen, die wichtig sind?
Irgendwann ist man dann erschöpft und durch.
Aber man kann nicht sagen, ich habe das jetzt nach zwei Szenarien
erledigt.
Wie finden wir Szenarien?
Solange das System nicht existiert, fällt es Kunden meistens sehr
schwer, zu verbalisieren, was sie brauchen.
Sie sollten es also nicht erwarten, dass sie schon sagen können, was
genau die Funktionen des Systems sind.
Der Kunde versteht zwar die Probleme, nicht jedoch die Lösungsdomäne,
nämlich Computer.
Man versuche, mit den Kunden zu kommunizieren, indem man hilft,
Anforderungen zu formulieren.
Dem Kunden hilft, die Anforderungen zu verstehen.
Die Änderungen sind normal.
Tipps zum Finden, stellen Sie dem Kunden folgende Fragen.
Was sind die Hauptaufgaben, welche das System erledigen soll?
Was sind die wichtigsten Aufgaben?
Welche Daten werden benötigt?
Werden eingegeben, von einer Datenbank abgeholt, Datenbanksystem
abgeholt, müssen sie geändert werden, gelöscht werden?
Über welche Änderungen muss das System Bescheid wissen, die außerhalb
des Systems liegen?
Das könnte eben in unserem Fall das Feuer sein, aber es kann auch ein
anderer Vorgang sein, dass sich irgendjemand anmeldet, irgendein
digitaler Vorfall sich ereignet, irgendwelche Datenstände sich
anstellen, irgendwelche Alarme kommen und so weiter.
Über welche Änderungen muss der Benutzer des Systems eigentlich
informiert werden?
Beispielsweise nicht.
Aber Sie müssen vorsichtig sein, bei den Fragen kriegen Sie nicht
immer alle oder die korrekten Antworten.
Das liegt zum Teil am Unvermögen der Betroffenen.
Es ist schwer etwas zu sagen, was man permanent... Wie würden Sie
jemandem erklären, wie man Fahrrad fährt?
Setz dich aufs Fahrrad, halt irgendwie das Gleichgewicht, aber wie das
Gleichgewicht halten geht, können Sie nicht sagen.
So geht es vielen.
Und wie gesagt, Beobachtungen von existierenden Systemen, wie sie
schon immer laufen, hilft auch sehr.
Im Fall des Feuermeldens ist es sicher so, dass es ein existierendes
System gibt, das läuft wahrscheinlich über das Funkgerät.
Das über das Funkgerät eine Brandmeldung absetzt.
Formulare hatten wir ja besprochen.
Okay, wir beschreiben also das System von außen.
Wir beschreiben nicht seine Innereien.
Wir haben dabei Akteure, der mit dem System interagiert.
Ein Anwendungsfall stellt eine Klasse von Funktionen dar, welche das
System anbietet.
Und ein Anwendungsfall-Diagramm, das werden wir jetzt noch sehen, oder
Use -Case-Model ist die Menge aller Anwendungsfälle.
Diese Anwendungsfälle sind ja von der Syntax und Semantik her etwas
billig.
Es gibt nämlich Kästchen und Strichmännchen und Ovale.
Das ist so ziemlich alles, was man für die Beschreibung eines
Anwendungsfalls braucht.
Man braucht also einen Akteur, das könnte ein Student sein.
Das ist das Strichmännchen.
Könnte aber auch ein anderer sein.
Ein Zufallsgenerator zum Beispiel, der von außen auf das System
einwirkt.
Er braucht einen Namen und eine Beschreibung.
Für jeden Akteur brauchen wir einen Namen.
Entschuldigung, für jedes Anwendungsfall braucht man einen Namen, die
Akteure, die Eingangsaktionen, Ausgangsaktionen, Ereignisfluss und
spezielle Anforderungen.
Zum Beispiel erstelle Hausarbeiten.
Da könnte ich mir sagen, was ich dazu brauche.
Wir machen etwas anderes.
Wir haben einen Kurs oder eine Vorlesung.
Da gibt es die Akteure, den Professor, den Übungsleiter und den
Student oder die Studentinnen.
Und es gibt den Anwendungsfall halte Vorlesung, halte Übung, erstelle
Hausarbeiten.
Das Anwendungsfalldiagramm auf dieser Ebene zeigt uns eben einfach nur
die verschiedenen Anwendungsfälle an.
Wer damit interagiert, ganz grob gewissermaßen den Informationsfluss,
also der Übungsleiter hält auch mal die Vorlesung.
Er hält die Übung.
Der Student nimmt an den Vorlesungen teil und macht seine
Hausarbeiten.
Da haben wir den Systemnamen.
Kurs ist vielleicht nicht gerade geeignet, aber so ist es mal.
Und wir haben klar, was die Systemgrenzen sind.
Das ist erstmal das eine Diagramm.
Es ist, wie gesagt, technisch nicht sehr komplex.
Aber zu finden, was hier reinkört, ist dabei die Herausforderung.
Was in das Diagramm reinkört.
Das war der Anwendungsfall.
Es können untereinander Beziehungen stehen.
Das kommt jetzt auch noch.
Ein bisschen mehr können wir sagen.
Wir können erweiterte Beziehungen angeben.
Ich zeige Ihnen das zum Beispiel.
Und wir können einschließende Beziehungen einnehmen, wenn wir einen
Anwendungsfall haben, der in mehreren anderen vorkommt.
Gewissermaßen die Methode, die von mehreren aufgerufen wird.
Ich zeige Ihnen, was damit gemeint ist.
So.
Also, was wir hier machen, also wieder mehr humoristisch als wie
ernst.
Angenommen, wir haben einen Anwendungsfall Kaffee trinken und wir
haben einen Anwendungsfall Schlafen.
Und wir haben einen Anwendungsfall erstelle Hausarbeiten.
Wenn das hier auch vorkommt, Kaffee trinken und schlafen, dann könnte
ich das sagen.
Das erstelle Hausarbeiten ist eine Erweiterung dieser Dinger.
Wir können auch noch eine Einbeziehungs diese Include Relation
bestimmen.
Das spart uns Schreibarbeit.
Wenn zum Beispiel der Anwendung stelle Fragen sowohl beim Üben oder
bei der Vorlesung vorkommt, dann kann ich das mit diesem Include-Pfeil
andeuten.
Also, das hier ist ein Unterklassen-Pfeil.
Ja, der hier.
Das hier ist eine Unterklasse von dem hier.
Es gibt also hier gewissermaßen Mehrfachvererbung, die wir in Java
nicht haben.
Und das hier ist eine einschließende Beziehung.
Also, hier stimmt noch was nicht.
Das dürfen Sie selbst herausfinden, indem Sie du Tour lesen.
Wie schreibe ich das jetzt in Textform?
Ich brauche erst das Bildchen und dann die Textform.
Die Textform sagt mir, ich brauche den Namen, teilnehmende Akteure,
Student, Eingangsbedingungen, erhält Übungsblatt, das kam jetzt am
Bild nicht vor, Student ist gesund, wenn er nicht gesund ist, kann er
wohl kaum ein Übungsblatt machen, der Student gibt die Lösung ab, das
ist der Ergebnis, Ereignisfluss steht auch da, das ist offensichtlich
spezielle Anforderungen, hier haben wir keine.
Das wäre eine textuelle Beschreibung eines Anwendungsfalles.
Hier kommt Anwendungsfall, Vorfallverwaltung, Polizist, Disponent,
melde Vorfall, ist der Anwendungsfall, der Disponent selbst hat eine
Aufgabe, den Vorfall zu öffnen und Ressourcen anzufordern.
Er braucht wohl auch noch einen weiteren Anwendungsfall, der heißt
Vorfall schließen, ist erledigt.
Szenarien, wahr oder falsch?
Szenarien können nach Abschluss der Prüfphase gelöscht werden, da es
in Anwendungsfällen Diagrammen enthalten sind.
Können Sie sie wegwerfen?
Genau, genau.
Ich würde ja Szenarien auf alle Fälle auch behalten, um sie dann
testen zu benutzen.
Okay, gut.
Szenario basiert Entwurf kann nur eingesetzt werden, wenn man einen
Kunden hat.
Nee, oder?
Ja?
Genau.
Man kann sich selbstverständlich auf selbst die Szenarien ausdenken,
wenn man sie analysiert.
Oder ein Papier existierendes System oder teilautomatisches System
umsetzt in einem Szenario.
Wie findet man Anwendungsfälle?
Wie findet man die jetzt?
Sie stehen also vor dem Problem, irgendeinen Anwendungsfall zu
identifizieren, naja, Sie können sich jetzt einen sogenannten
vertikalen Ausschnitt nehmen, das heißt nicht das Gesamtsystem
betrachten, sondern alles, was zu einer bestimmten Situation gehört
und die mit dem Benutzer besprechen, zukünftigen Benutzer besprechen.
Sie können auch andersrum vorgehen, Sie können einen horizontalen
Ausschnitt nehmen und sagen, was gehört hier alles dazu?
Das heißt, Sie erfassen viele Szenarien, um einen größeren Bereich des
Systems zu definieren.
Auch das, diesen Bereich diskutieren Sie wieder mit dem Benutzer.
Also nehmen wir zum Beispiel her der horizontale Ausschnitt aus dem
wäre das gesamte Meldesystem in einem Einsatzfahrzeug.
Für Polizei oder Lebensretter oder Notfallrettern oder keine Ahnung,
Feuerwehr.
Alle gleichzeitig betrachten.
Man kann auch hergehen und Prototypen machen.
Der Prototyp für den Polizisten könnte also so vorsehen, das habe ich
mal sehr schön gelernt.
Man nehme sich einfach ein Blatt Papier, schreibe eine, male eine
Benutzerschnittstelle drauf, mit was weiß ich, Eingabefeldern und OK
-Buttons und Cancel-Buttons und was da alles dazugehört.
Halte Sie den Benutzer hin und sage, okay, angenommen, Sie haben
diesen Vorfall, was würden Sie jetzt machen?
Dann schaut er auf dieses Ding und sagt, dann wissen Sie schon, es ist
was falsch.
Ich würde da drücken oder das eingeben oder so und dann sagen, aha,
gut.
Und als nächstes erscheint dieses Bild.
Habe ich noch nicht programmiert, oder ich male es mir rasch, zeige
eben, führe dem Kunden gewissermaßen durch das System, in dem ich die
Benutzerschnittstelle als Prototyp bedienen lasse.
Das ist der billigste Prototyp, den Sie sich denken können, nämlich
ihn zu malen.
Ist sehr, sehr nützlich für Benutzerschnittstellen.
Man kann natürlich auch den Benutzer beobachten.
Ich kann dem Polizeifahrzeug mitfahren.
Wie ist denn so ein Tag in einem Police Cruiser in einer
amerikanischen Stadt?
Befragen kann man, es gibt manchmal ungenaue Antworten.
Im Police Cruiser zu fahren, ist mir in San Francisco passiert.
Ich war mit einem Freund in San Francisco.
Wir wurden überfallen.
Mein Freund war dann am Auge verletzt, er bekam einen Schlag aufs
Auge.
Sein Glas ist gesplittert und hat ihn hier oben und unten verletzt.
Er hat geblutet wie wahnsinnig.
Und dann hat jemand den
Notfall, also ein Krankenwagen kam an und wir konnten dann im
Krankenwagen mit Tatütata, durch San Francisco düsen, war schön, mir
hat ja nichts gefehlt.
Die Hügel rauf und runter, war toll.
Als wir fertig waren, es war Gott sei Dank nicht schlimmer, er war
keine Verletzung am Auge, hat schon die Polizei auf uns gewartet.
Hat gesagt, jetzt schauen wir mal, ob sie den Täter sehen, auf der
Straße.
Und schon ging es wieder los.
War lustig, mit Karacho durch San Francisco zu düsen.
Und dann, es war eigentlich da drüben.
Da war es, schauen wir mal hin.
Oh, das ist eine Einbahnstraße.
Schaltet einfach alle Lichter an und fährt gegen die Einbahn, kommt
Gegenverkehr, auf und gehst da raus, wie im Film.
Ich sage es Ihnen, es war sehr lustig.
Haben wir natürlich nicht gefunden, aber der fährt mit dem Auto
einfach die Stufen hoch, wissen Sie?
Was diese Autos aushalten, ist schon erstaunlich.
Das sind speziell angefertigte Polizeiautos, der kann die Treppe
hochfahren damit.
Okay, gut, das nebenher.
Aber so können Sie mit beobachten, das ist der Punkt dabei.
Was macht der eigentlich und wo kann man hier automatisierend
eingreifen?
Melde Notfall, ich glaube, das brauchen wir jetzt nicht mehr so
beschreiben, so genau wie möglich.
Wir wissen ja, was reingehört, das überspringe ich jetzt mal.
Es sind noch mal, wie gesagt, diese Beispiele, die sollten Sie aber
selbst durchlesen, es ist wirklich langweilig, das in der Vorlesung
durchzubearbeiten.
Was gibt es da drüben?
Weiter geht es.
Können Sie, wie gesagt, selbst durchlesen, finde ich nicht so gut, das
in der Vorlesung einzeln zu besprechen.
Öffne Vorfall, wählt Reaktion, bestätigt die Meldung, empfängt die
Bestätigung und wählt die Reaktion.
Das ist das, was herauskommen sollte, wenn Sie so einen Anwendungsfall
beschreiben.
Das ist die Methodik, wie Sie vorgehen.
Akteure, Disponenten und so weiter, brauchen wir alles.
Kommt noch ein Beispiel, will ich jetzt nicht mehr durchgehen.
Finden die Akteure, finden die Ereignisse los.
Ist eigentlich jetzt alles klar geworden, aber ich will noch mal auf
die Probleme bei der Anforderungsbeschreibung hinweisen.
Zum einen ist, dass es eventuell seichtes Bereichswissen ist.
Man weiß nicht genau, was passiert.
Jeder einzelne Akteur weiß nur seinen Ausschnitt des Systems und sagt,
ich muss immer nur das hier machen, den Rest machen die Kollegen und
das geht mich nichts an, weiß ich auch nicht.
Verteilt über viele Quellen, manchmal schwer explizit festzustellen.
Die verschiedenen Quellen können sich jetzt widersprechen.
Entweder, weil sie ein Missverständnis haben oder unterschiedliche
Ziele haben oder unterschiedliches Problemverständnis.
Dann müssen Sie aber auch herausfinden, was die Sache ist.
Es gibt stillschweigendes Wissen, es wird nicht gesagt, nicht
ausgebrochen, weil man das einfach implizit mit annimmt, da gibt es
jede Menge an Wissen, das man regelmäßig braucht.
Es gibt eine beschränkte Beobachtbarkeit, es gibt zum Beispiel von den
Benutzern Betriebsblindheit und wenn jemand da ist und sie beobachtet,
ändern sie ihr Verhalten, auch das kann vorkommen und schließlich kann
es verzerrt sein.
Das heißt, der Betroffene kann, wenn sie fragen wollen, dürfen oder
wollen nicht sagen, was benötigt ist.
Sie dürfen die Probleme nicht so richtig benennen, weil sie dafür eins
auf den Deckel kriegen oder weil vielleicht die Firma das nicht will,
dass man drüber redet.
Sie wollen vielleicht auch nicht sagen, wie es geht, was notwendig
ist.
Sie geben ihnen unvorstellbare Informationen, vielleicht auch sogar
führen sie einen falschen Pfad entlang, weil sie Angst haben davor,
dass sie wegrationalisiert werden.
Das ist auch ein vernünftiger, also ein glaubhafter Grund.
Oder sie haben ein verdecktes Ziel, sie wollen irgendetwas abschießen
oder sonst irgendetwas, irgendein verdecktes Ziel und geben ihnen
entsprechende Antworten oder auch keine.
Da müssen sie sich gewahr sein, dass nicht jeder, wenn sie über ein
gewünschtes System löchern, dass der ihnen auch die richtige oder die
vollständige Antworten gibt.
Da müssen sie noch ein bisschen selbst nachdenken.
Und natürlich können die Spezifikationen ungedau sein, das ist wieder
ein Beispiel.
Als Laserexperten wurde ein Laserstrahl von der Erde zu einem Spiegel
auf der Raumfährediscovery geschickt.
Echter Vorfall.
Ein Laserstrahl hochschicken und dann projizieren lassen auf einen
Berg in Höhe von 10.000 Fuß.
Gab die Höhe 10.023 ein, laserstrahl nie die Spitze des Berges.
Warum nicht?
Es war nicht Fuß, sondern es waren Meilen erwartet.
Das heißt, 10.000 Meilen, das ist ziemlich weit weg von der Erde.
Hier noch ein Beispiel für eine unbeabsichtigte Funktion.
Auch ein echter Vorfall.
Londoner U-Bahn ist in der Station, der Zug fährt ohne den Zugführer
weg.
Was ist passiert?
Eine Fahrgasttür hing fest, ließ sich also nicht schließen.
Der Zugführer steigt also aus, um die Tür zu schließen, lässt seine
Fahrertür offen, weil er weiß, dass dann der Zug nicht wegfährt.
Lässt die Fahrertür offen, dann geht er zu der Tür und gibt ihr einen
Tritt.
Schon fährt der Zug los.
Ohne Fahrer, mit offener Tür.
Was war?
Das Steuerprogramm hatte die Fahrertür nicht mit berücksichtigt, das
war nicht vorgesehen.
Nur Fahrgasttüren.
Aber stellen Sie sich mal die Situation vor.
Hallo, mein Zug ist weg.
Okay, Anforderungsspezifikation, beide haben das Anforderungen,
Anforderungsspezifikation, immer natürliche Sprache, Analysemodell,
formale und semiformale Notationen, die werden wir später noch
kennenlernen.
Das handelt sich hauptsächlich um Abläufe, die beschrieben werden in
formalen Notationen und Klassendiagrammen, die wir beschreiben werden,
aber das können wir leider noch nicht.
So, jetzt kommen wir zurück zu den Funktionalen und Nichtfunktionalen
oder Qualitätsanforderungen.
Funktionale Anforderungen sind also Beschreibung der Interaktion
zwischen dem System und der Systemumgebung, unabhängig von der
Implementierung.
Ein Polizist muss also in der Lage sein, zum Beispiel Ressourcen
anzufordern.
Nichtfunktionale Anforderungen, Aspekte, die nicht direkt mit dem
funktionalen Verhalten in Verbindung stehen, aber Qualitäten angeben,
zum Beispiel Antwortzeit, Durchsatz, Zuverlässigkeit, und so weiter.
Und dann gibt es noch Einschränkungen, die sagen, aber in so einem
Fall gibt es noch eine spezielle Situation oder es muss Java benutzt
werden oder es muss auf Windows laufen oder irgend so etwas.
Irgendwelche Einschränkungen, die noch zu berücksichtigen sind, was
weiß ich, gesetzlicher Art, Steuereigenschaften.
Hier kommen die Vergleiche.
Beschreibt Benutzerausgaben, die das System unterstützen muss.
Zum Beispiel erstelle eine Tabelle, benachrichtige Interessenten.
Nichtfunktional beschreiben Eigenschaften des Systems oder Domäne.
Werden zum Beispiel als Einschränkungen formuliert, als Zusicherungen,
jede Benutzereingabe in weniger als einer Sekunde erkannt werden.
Systemanschluss darf nicht zu Datenverlust führen.
Benutzbarkeit, Zuverlässigkeit, Geschwindigkeit, Robustheit zum
Beispiel bedeutet, dass das System auch bei Fehleingaben und
Fehlbenutzung nicht abschmiert und wieder vernünftig weiterarbeitet.
Sicherheit, Systemprobleme, Antwortzeit, Skalierbarkeit, Durchsatz
hatten wir schon, Verfügbarkeit.
Skalierbarkeit heißt, was passiert, wenn ich mehr und mehr Benutzer in
das System bekomme.
Ich habe am Anfang 100, was ist, wenn ich 1000, 10.000, eine Million
habe, wie weit muss das System das verkraften.
Dann die Wartbarkeit, da wäre die Anpassbarkeit und die
Erweiterbarkeit wichtig zu nennen.
Das sind also qualitative Anforderungen.
Einschränkungen sind Implementierungseinschränkungen, muss in Java
oder C oder sonst was geschrieben werden, die Schnittstellen, die es
bieten muss oder Schnittstellen, die es benutzen kann.
Die Einsatzumgebung, Büroumgebung oder im Panzer oder im Laster oder
im Kran oder in der Hosentasche.
Lieferumfang, was alles dazu gehört.
Rechtliches Lizenzen, Zertifikate, Datenschutz, Dinge, die
berücksichtigt werden müssen.
Das sind also Arten qualitativer Anforderungen und Einschränkungen zur
rechten Seite.
Jetzt müssen wir uns die noch ein bisschen genauer ansehen.
Also, hatte ich eigentlich schon mündlich vorher schon erwähnt.
Hier geht es um die Leichtigkeit, mit denen die Benutzer, Akteure das
System benutzen können.
Zum Beispiel die Anzahl der Schritte, die man braucht, um eine Aktion
durchzuführen.
Internetbestellung, ist das jetzt 23 Menüs oder kann ich das mit einem
Klick machen?
Kennen Sie wahrscheinlich die Einführung von Amazon, mit einem Klick
seine Bestellung aufzugeben.
Robustheit.
Robustheit heißt die Fähigkeit, bei falschen Eingaben zu richtig zu
reagieren oder jedenfalls nichts kaputt zu machen, auch nicht
abzustürzen.
Oder was passiert eigentlich, wenn die Betriebsbedingungen nicht
eingehalten werden?
Betriebstemperatur ist 10 bis 25 Grad Celsius.
Was passiert, wenn ich außerhalb bin?
Schalte das System ab.
Was passiert, wenn ich die maximale Anzahl von Anfragen ist 2000 pro
Sekunde, wenn ich das überschreite?
Was passiert dann?
Das ist die Robustheit.
Verfügbarkeit störungsfreier Betrieb zur Gesamtzeit, also
störungsfreie Betriebszeit zur Gesamtzeit.
Zum Beispiel eine Stunde pro Woche nicht verfügbar, weniger als 5
Minuten nicht verfügbar.
Immer da, wenn auch reduziert, das mache ich dann durch Replikation.
Wir haben gesehen, bei dem Ariane-Absturz zum Beispiel, dass auch
Replikation nicht immer hilft, wenn man sich dumm anstellt.
Nichtfunktionale Anforderungen, das klingt jetzt ein bisschen komisch.
Wettkämpfe zu registrieren und ohne Vorwissen zu sehen, das bezieht
sich auf ein anderes System, das die Tor- und Brücke beschreiben, das
Arena -System.
Da kann man sich für Wettkämpfe Tickets bestellen.
Oder zusehen auf dem Rechner.
10 gleichzeitige Wettkämpfe unterstützen, das betrifft
Geschwindigkeit, Benutzbarkeit.
Verwalter muss in der Lage sein, Wettkämpfe hinzuzufügen, ohne bereits
existierend zu ändern zu müssen.
Ein digitales System, in dem man unterschiedliche Wettkämpfe
organisieren und beobachten kann.
Aber sollten Sie selbst nachlesen.
Funktionale Anforderungen kommen immer vom Kunden.
Stimmt das?
Nein?
Nein, warum nicht?
Genau, man muss selbst analysieren, selbst nachdenken.
Der Kunde darf keine nicht-funktionalen Anforderungen stellen.
Keine nicht-funktionalen, also nur funktionale, auch Quatsch.
Natürlich stellt der Kunde auch die nicht-funktionalen Anforderungen.
Er darf die Entwicklungsumgebungen und Methoden vorschreiben.
Was sagen Sie dazu?
Ja,
eigentlich nein.
Eigentlich nein, denn die Internen haben jetzt nichts mit der
Funktionalität des Systems zu tun.
Und das sollte der Entwicklungsmannschaft oder dem Softwarehaus
freigestellt sein, was sie jetzt benutzen, wo sie sich vertraut
fühlen.
Wenn sie sagen, sie dürfen aber Microsoft Visual Studio nicht
benutzen, sondern sie müssen Eclipse benutzen, dann kostet es extra
gewissermaßen.
Aber wenn der Kunde es natürlich so will, dann müssen sie auch sagen,
ja gut, dann machen wir es so.
Aber eigentlich müsste er das nicht vorschreiben.
Was gehört nicht zu den Anforderungen?
Naja, die Systemstruktur selbst.
Haben Sie ja gesehen bei dem Anforderungsproblem, das wir hatten für
die Polizei.
Ich habe nichts gesagt von einem Klienten-Server, obwohl das nahe
liegt.
Wir sprachen nur über die Funktionen.
Entwicklungsmethoden hatten wir gerade.
Entwicklungsumgebung muss man eigentlich auch nicht zu den
Anforderungen nehmen.
Meistens auch nicht vorgeschrieben.
Die Programmiersprache, die Wiederverwendbarkeit.
Die Programmiersprache, weil es den Kunden natürlich erstmal nicht
interessiert.
Wiederverwendbarkeit, weil der Kunde meist nicht so lange so weit
denkt, dass das System überarbeitet werden muss.
Der Kunde nimmt an, das ist perfekt, wenn es kommt.
Die Wirklichkeit ist, dass ihm später einfällt, naja, wir sollten aber
noch das haben und auch noch diese Funktion.
Und dann ist es eine interne Eigenschaft, die sie als Hersteller eher
interessiert.
So, und wie in allen großen Projekten ist es jetzt auch notwendig zu
sagen, und haben wir das jetzt alles richtig gemacht?
Steht jetzt alles da, was wir haben wollen?
Was der Kunde haben will?
Wir haben also ein elendlanges Lastenheft geschrieben.
Ich sagte Ihnen schon, Toll Collect, 10.000 Seiten.
Woher weiß ich, dass es jetzt fertig ist?
Nun, da gibt es eine...
Es bleibt einem nichts anderes übrig, als in gewisser Maße eine
Inspektion durchzuführen.
Das heißt, ich suche mir Inspektoren und bitte sie, die Anforderungen
durchzulesen und zu prüfen, ob sie korrekt sind, ob sie sich an keiner
Stelle widersprechen.
Ich lasse sie überprüfen, ob sie vollständig sind.
Habe ich was vergessen?
Das kommt öfter vor, als man denkt.
Und ich prüfe auf Konsistenz, also auf Widerspruchsfreiheit.
Könnte sein, dass sich funktionale Anforderungen widersprechen oder
auch die nicht-funktionalen Anforderungen widersprechen.
An einer Stelle steht das, an einer Stelle steht etwas anderes.
Das heißt, die Validierung macht man auch, ist auch ein wichtiger
Schritt, zu sehen, ob das fertig ist.
Ferner wollen wir wissen, ob es eindeutig ist, die Beschreibung klar
ist, ob es wirklich weiß, was gemacht werden soll.
Ob es auch noch realisierbar ist, erfüllt und geliefert werden können,
wenn zum Beispiel jemand sagt, ich brauche aber eine Sprachsteuerung
für dieses System, ich will nicht mehr tippen müssen.
Der Polizist soll das einfach sagen können, ich habe hier ein Beispiel
vor, wie ein Funkgerät und das soll alles digitalisiert werden, dann
müssen sie sagen, ich weiß nicht, ob wir das können.
Ob wir eine Sprachsteuerung hinkriegen.
Verfolgbarkeit,
jede Systemfunktion soll einer Menge von Anforderungen zugeordnet
werden können, das heißt, wenn Sie das System implementiert haben,
haben Sie eine bestimmte Funktionen implementiert, dann sagen Sie,
okay, die entspricht der folgenden Anforderung.
Das heißt, das müsste ich auch irgendwie festhalten können.
Aber natürlich haben Sie die Probleme, es gibt Änderungen, schon
während Sie arbeiten, gibt es schon Änderungen, Inkonsistenzen können
bei jeder Änderung auftreten und Werkzeugunterstützung ist auch da
erforderlich und die gibt es.
Die Werkzeugunterstützung, da gibt es ein System, das heißt, zunächst
mal, dass ich die funktionalen Anforderungen natürlich in GIT oder SVN
-Versionshaltungssystem einspeise, nicht einfach nur ein Dokument
habe, damit kann ich auch wieder zurückfallen auf vorherige Stände der
Dokumentation, brauche ich mehr Benutzerunterstützung, auch das muss
möglich sein, einfach nur ein Wortdokument herumzuschicken, das tut es
nicht.
Dann ist es so, dass dieses Spezifikationsdokument irgendwann mal in
mehrere Stücke zerfällt, dass der Anwendungsbereich und der
Anwendungsbereich von unterschiedlichen Leuten bearbeitet wird, aber
irgendwann möchte ich das zusammenführen, das heißt, ich brauche sowas
wie Maven, um alles zusammenzustellen, das
Gesamtspezifikationsdokument, die Verfolgbarkeit der Anforderungen
zurückverfolgen können, gewährleisten.
Und da gibt es jetzt, ich will jetzt keine Werbung machen, aber das
sind ja ältere Werkzeuge, das heißt, eins von Telelogic heißt DOORS
für Anwendungsverwaltung oder von Rational Requisite Pro.
Das sind, sage ich mal, Verwaltungswerkzeuge für Anforderungen, die
aber die Anforderungen an sich nicht verstehen.
Die verstehen da gar nichts davon.
Die sagen nur, hier fehlt was, das ist dann und dann aktualisiert
worden, das ist dann und dann überprüft worden oder wir haben jetzt
alles oder so.
Wieder ein Verweis auf aktuelle Forschung.
Was könnte man hier noch automatisieren?
Was man hier noch automatisieren könnte, ist folgendes.
Die Texte nach inhaltlichen Schwächen zu durchsuchen.
Zum Beispiel bei sogenannten Phrasen, die Nominalisierungen enthalten.
Eine Nominalisierung ist, wenn ein Verb in einen Nomen verwandelt
wird.
Hier haben wir zum Beispiel einen Fall, das steht also, nach der
Anmeldung wird der Kunde auf die Startseite weitergeleitet.
Das ist eine Nominalisierung, denn das eigentliche Verb, das uns hier
interessiert, ist sich anmelden.
Und die Frage ist jetzt, wer meldet den Kunden an?
Der Kunde selbst, jemand anderer?
Wie geht das?
Ist es am Internet?
Ist es eine Einwahlseite?
Mache ich das per Telefon?
Was denn eigentlich?
Wenn ich gesagt hätte, wir haben jetzt tatsächlich ein System gebaut,
das so etwas kann, das untersucht den Text nach unvollständigen
Nominalisierungen.
Das geht so, dass Sie hier dieses Nomen identifizieren, dann in einem
ja, das kennen Sie jetzt auch nicht, einer sogenannten Ontologie
nachschauen, was ein zugehöriges Verb wäre.
Das wäre in diesem Falle anmelden.
Dann schaue ich in dieser Ontologie nach, welche Bestandteile zu dem
Verb anmelden gehören, nämlich der Anmelder, das Subjekt, der, der
angemeldet wird und auch noch die Methode des Anmeldens.
Und mit dieser Information geben wir eine Rückversicherung an den
Nutzer, sagt, hier kommt eine Nominalisierung vor, die ist
unvollständig.
Wir brauchen noch die folgenden Bestandteile und mit dieser
Nominalisierung zu starten ist immer gut, weil man meistens so
Nominalisierung benutzt, wenn man nicht alles sagt.
Transport der Paletten ist ähnlich, wer transportiert wie, von wo nach
wo, können wir alles rauskriegen, indem wir Informationen über das
Wort Transport haben.
So, dieses Werkzeug, übrigens gibt es im Prototyp, heißt DINOM.
Denominalisierer, wie auch Debugger, entkäfern, entnominalisieren,
egal, das ist auch wieder ein Bereich der Forschung.
Ich bin jetzt genau fertig.