Wissenschaftsdisziplin Softwaretechnik. Allgemeines Management. Führungsaufgaben. SW-Management SW-Entwicklung Prozess- & Q-Modelle Industrialisierung

Transkript

1 III Basiskonzepte Wissenschaftsdisziplin Softwaretechnik Allgemeines Management Charakteristika Prinzipien Führungsaufgaben Werkzeuge SW-Management SW-Entwicklung Prozess- & Q-Modelle Industrialisierung Strategie & Taktik Basiskonzepte: Statik Prozessmodelle Qualitätsmodelle Ökonomie Innovationen Basiskonzepte: Dynamik Q-Management Prüfmethoden Outsourcing Globale Entwicklung IT-Recht Risiken Basiskonzepte: Logik Requirements Engineering Basismodelle Rahmenmodelle Monumentale Modelle Agile Modelle Projekte Trends Maße Konfigurationen Prinzipien Basistechniken Methoden Werkzeuge Legende: = Übergabe von Teilprodukten = Einfluss = Unterstützung = Informationsaustausch In diesem Buchteil behandelt 99

2 In der Wissenschaftsdisziplin Softwaretechnik sind im Laufe der Jahrzehnte viele Konzepte entstanden und auch wieder verschwunden. Eine Reihe von Konzepten hat sich aber als stabil erwiesen. Diese Konzepte bezogen auf die Softwareentwicklung werden hier vorgestellt. Dabei wird sich auf Basiskonzepte konzentriert. Interessanterweise sind nicht alle Basiskonzepte neu. Einige Basiskonzepte entstanden bereits in den Anfangszeiten der Softwaretechnik oder wurden aus anderen Disziplinen übernommen. Dazu gehören Zustandsautomaten (1954), Petrinetze (1962) und Entscheidungstabellen (1957). Basiskonzepte Konzepte erlauben es, definierte Sachverhalte unter einem oder mehreren Gesichtspunkten zu modellieren. Ein Basiskonzept der Softwareentwicklung lässt sich durch folgende Eigenschaften charakterisieren: Atomares Konzept, konzeptionell langlebig, phasenübergreifend verwendbar, in unterschiedlichen Kontexten einsetzbar. Die erste Eigenschaft besagt, dass ein Konzept elementar und originär ist. Es ist nicht auf andere Basiskonzepte reduzierbar. Um von einem Basiskonzept zu sprechen, müssen die erste Eigenschaft und mindestens eine der anderen Eigenschaften erfüllt sein. Notationen Textuell Grafisch Formal Eine Notation stellt Informationen durch Symbole dar. Ein Konzept kann durch eine oder mehrere Notationen dargestellt werden. In Abhängigkeit von der Notation ist das betreffende Basiskonzept z. T. semantisch leicht modifiziert. Im Allgemeinen sind die Notationen aber gegenseitig substituierbar. Notationen lassen sich in die Kategorien textuell grafisch und informal formal klassifizieren. Die Abb zeigt die sich daraus ergebenden vier Quadranten. Texte beschreiben Informationen in Form von natürlichsprachlichen (z. B. deutschen) Texten oft auch als Prosa (von: Schrift in ungebundener Form) oder verbale Beschreibung (von: wörtlich, mit Worten) bezeichnet. Grafiken beschreiben Informationen durch grafische Symbole und Linien zwischen den Symbolen. Die Symbole und Linien werden fast immer durch Namen oder Texte annotiert. Unter formaler Beschreibung versteht man im Allgemeinen die Verwendung formaler, textueller Sprachen. Eine formale Sprache wird durch eine Grammatik definiert, die angibt, welche Zeichen- 100

3 grafisch Zustandsautomat UseCase- Struktogramm Timing- Entsch. bäume Aktivitäts- ER- Kommunikations- Petrinetze Syntax- Geschäftsprozess- Klassen- III Abb : Klassifizierung der Basiskonzepte nach der Darstellungsform ihrer Notationen. verbal Sequenz- Zustands- Matrix/Tabelle textuell referenzierbarer Text Text Entscheidungstabelle Pseudocode Gliederungsschablone UseCase- Schablone Textschablone Regeln Constraints XML, DTD & XML- Schemata OCL Formale Logik informal semiformal / formalisiert formal ketten erlaubte Sätze der Sprache sind. Die Verbindung»formale Beschreibung«und»textuelle Darstellung«muss aus heutiger Sicht erweitert werden auf»grafische Darstellung«. Der hier verwendete Begriff»formal«meint nur»syntaktisch formal«. Die Semantik ist damit noch nicht formal definiert. Die formale Definition der Semantik gelingt in der Informatik nur in Sonderfällen, selbst Programmiersprachen sind in ihrer Semantik nicht formal definiert. Auch für grafische Darstellungen kann eine Grammatik festgelegt werden. Eine grafische Syntax bestimmt, wie die Grafiken aufgebaut sind. Zwischen einer formalen und einer informalen, d. h. an keine Regeln gebundenen Beschreibung, liegt ein Bereich, den man als semiformale oder formalisierte Beschreibung bezeichnet. Diese Beschreibungen sind stärker formalisiert als die Umgangssprache, aber nicht streng mathematisch wie eine formale Sprache durch eine Grammatik. Viele Basiskonzepte erlauben mehr als eine Notation oder mischen mehrere Notationen, z. B. semiformalen Text und Grafiken. Als Standard für die Beschreibung vieler Basiskonzepte hat sich die UML ( Unified Modeling Language) durchgesetzt standardisiert als ISO/IEC 19501, siehe OMG UML-Website ( Die UML 2 unterscheidet 11 arten, wobei viele miteinander in Bezug stehen. Während die UML für die Modellierung von Softwaresystemen konzipiert wurde, gibt es für die Modellierung von Systemen SysML ( Systems Modeling Language), siehe OMG SysML Website Hinweis: Visuelles Programmieren Semiformal, formalisiert UML & SysML 101

4 ( Sie basiert auf der UML 2 und dient der ganzheitlichen Modellierung von Systemen unabhängig von Software oder Hardware (Abb ) (siehe auch [FMS08]). Abb : SysML umfasst eine Untermenge der UML 2 und wird durch zusätzliche Modellelemente erweitert. Von der SysML nicht benötigt UML 2 SysML Erweiterungen der SysML UML-Untermenge von der SysML verwendet Hinweis Die UML ist für die Modellierung von Echtzeit- und von Kommunikationssystemen nur bedingt geeignet. Es gibt aber eine Reihe von Büchern, in denen gezeigt wird, wie die UML auch für diese Gebiete eingesetzt werden kann, z. B. [Doug04] und [Dold03]. Sichten Ein Softwaresystem kann unter folgenden drei Gesichtspunkten, Sichten oder Perspektiven beschrieben, spezifiziert, modelliert, analysiert, entworfen und programmiert werden: Statik: Stabiler Aufbau des Systems untergliedert in: Funktionalität Daten Dynamik: Dynamisches Verhalten des Systems untergliedert in: Fachaspekte Kontrollstrukturen Geschäftsprozesse und Use Cases Zustandsautomaten Petrinetze Zeitaspekte Szenarien Logik: Logische Abhängigkeiten innerhalb des Systems untergliedert in: Formale Logik Constraints und die OCL in der UML Entscheidungstabellen Regeln Diese verschiedenen Sichten sind nicht unabhängig voneinander. In der Regel werden mehrere der Basiskonzepte in Bezug gesetzt. Die UML ermöglicht es, verschiedene Konzepte zu integrieren. 102

5 III In der UML wird zwischen Struktur (vergleichbar mit der hier verwendeten Bezeichnung»Statik«) und Verhalten (vergleichbar mit der hier verwendeten Bezeichnung»Dynamik«) unterschieden. Die Logik kann in der UML an verschiedenen Modellelementen annotiert oder es kann die OCL (ObjectConstraintLanguage)verwendet werden (siehe»constraints und die OCL in der UML«, S. 377). In der UML 2 werden sechs verschiedene Strukturdiagramme unterschieden 1 : Klassendiagramm Objektdiagramm Paketdiagramm Komponentendiagramm Verteilungsdiagramm Kompositionsstrukturdiagramm Sieben e erlauben es, das Verhalten zu modellieren: Aktivitätsdiagramm Use Case- (auch Anwendungsfalldiagramm genannt) Zustandsdiagramm Timing- (auch Zeitverlaufsdiagramm genannt) Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm Nicht alle diese e beschreiben Basiskonzepte. Daher werden hier nur die fett dargestellten arten im Rahmen der Basiskonzepte behandelt. In der UML können mehrere arten miteinander kombiniert werden, wenn es für die Modellierung nützlich ist. Viele e erlauben eine hierarchische Verfeinerung. UML-Profile Die UML ist als Beschreibungs- und Modellierungssprache nicht für alle Basiskonzepte geeignet. Es gibt in der UML jedoch die Möglichkeit, UML-Profile für spezielle Zwecke zu erstellen [OMG09a, S. 653 ff.]. Das Sprachkonzept Profil ( profile) ist ein leichtgewichtiger Erweiterungsmechanismus der UML leichtgewichtig, weil er das Metamodell der UML nicht verändert (siehe auch»prinzip der Abstraktion«, S. 26). EinProfilisteinPaket( package), das es erlaubt, Metaklassen des UML-Metamodells zu erweitern, um sie an spezielle Zwecke anzupassen. Ein Profil übernimmt die Notation und die Semantik eines Profil 1 Einen kompakten Überblick über alle wichtigen e der UML bietet die Quick Reference Map»UML 2«(2. Auflage ) von Heide Balzert auf 8 laminierten und faltbaren Seiten (W3L-Verlag, ISBN ). 103

6 Pakets (siehe auch»pakete«, S. 145). Vor den Paketnamen wird»profile«geschrieben (Abb ). Ein Profil-Paket kann andere Pakete importieren (»import«). Beispiel 1a Stereotyp Anwendung Beispiel In der Abb wird das Paket Types von dem Profil euronorm importiert. Der Datentyp Typpruefung wird als ein Typ in dem Stereotyp Euro5Diesel verwendet. Die Klasse JavaInteger wird ebenfalls als ein Atrributtyp eingesetzt. Die Erweiterungen erfolgen im Wesentlichen durch die Definition von Stereotypen. Ein Stereotyp legt fest, wie eine im Metamodell der UML vorgegebene Metaklasse für spezifische Zwecke angepasst werden kann. Um einen Stereotyp von anderen Klassen zu unterscheiden, wird ein Schlüsselwort in französischen Anführungszeichen (Guillemets) über der Klasse angegeben. Ein Stereotyp kann über Attribute verfügen, die auch als Eigenschaftsdefinitionen (tag definition) bezeichnet werden (Abb ). Außerdem können Constraints angegeben werden. Um die Elemente eines Profils nutzen zu können, muss das Profil angewendet werden (»applied«) (Abb ). Die Anwendungsbeziehung ist eine spezielle Importbeziehung. Das Paket importiert alle Elemente aus dem Profil. Die Erweiterung, die das Profil definiert, gilt für das entsprechende Paket. Für jede Eigenschaftsdefinition des Stereotypen kann bei der Anwendung ein Eigenschaftswert (tagged value) ergänzt werden. Die Eigenschaftswerte werden mit vorangestelltem Stereotypbezeichner als Attribute in das Element oder alternativ in ein Kommentarsymbol eingetragen und mit dem Element verbunden, auf den der Stereotyp angewendet wird. Die Abb zeigt, wie der Stereotyp Euro5Diesel in der Klasse PKW angewandt wird. Die Typen aus dem Paket Types sind ebenfalls in dem Paket fahrzeuge anwendbar. Klassifikationskriterien Basiskonzepte lassen sich nach folgenden Kriterien klassifizieren: Notation: textuell grafisch, informal formal (siehe Abb ) Zeitlicher Einsatz: In welchen Entwicklungsphasen einsetzbar Anwendungsbereiche: Software, softwareintensive Systeme Im Folgenden werden eine kaufmännisch/administrative Fallstudie und eine softwareintensive Fallstudie in Form verbal beschriebener Lasten- und Pflichtenhefte vorgestellt:»fallstudie: SemOrg Die Spezifikation«, S. 107»Fallstudie: Fensterheber Die Spezifikation«, S. 117 Anschließend werden die einzelnen Basiskonzepte vorgestellt und ihr Einsatz anhand der Fallstudien demonstriert:»statik«, S

7 III Schlüsselwort für ein Profil Types «enumeration» Typpruefung JavaInteger Abb : Beispiel für die Definition und die Anwendung eines UML-Profils. «profile» euronorm Profilname «import» Profil Metamodellelement, das erweitert wird Erweiterungsbeziehung Definition des Stereotyps «metaclass» Class metaproperties «stereotype» Euro5Diesel CO: JavaInteger HCplusNO: JavaInteger NO: JavaInteger PM: JavaInteger Pruefung: Typpruefung Name des Stereotyps Attribute des Stereotyps ( tag definition) fahrzeuge Importbeziehung Anwendung «apply» Anwendermodell ordinary properties «Euro5Diesel» PKW hersteller: String jahr: JavaInteger «Euro5Diesel» CO = 500 HCplusNO = 230 NO = 180 PM=5 Pruefung = 2009 Anwendung des Stereotyps «Euro5Diesel» «Euro5Diesel» CO = 500 HCplusNO = 230 NO = 180 PM=5 Pruefung = 2009 Wertzuweisung der Stereotypattribute ( tagged value) Alternative Notation für die Wertzuweisung der Stereotypattribute Stereotypisierte Klasse»Dynamik«, S. 227»Logik«, S. 357 Für ausgewählte Basiskonzepte werden methodische Schritte und Qualitätsüberprüfungen in Form von sogenannten Boxen angegeben, um eine schnelle Nachschlagemöglichkeit zu haben. Im Gegensatz zu den anderen Kapiteln, die didaktisch nacheinander angeordnet sind, beziehen sich die Boxen auf alle Basiskonzepte, auch wenn sie erst später behandelt werden. In der Regel werden je nach zu entwickelnder Software mehrere Basiskonzepte in Kombination eingesetzt. 105

8 Syntaxnotation Ausbildung Für die Beschreibung einer Syntax gibt es verschiedene Möglichkeiten. Hier wird folgender Beschreibungsformalismus für die Syntax verwendet 2 : Syntaxsymbole: Symbole, die zur Beschreibung der Syntax verwendet werden, sind kursiv dargestellt, z. B. { }, sonst handelt es sich um terminale Symbole. Schlüsselwörter: Schlüsselwörter sind fett dargestellt. = oder, z.b.+, d.h.+ oder muss gewählt werden. [ ] = optional, z.b. [ Klasse Datentyp Aufzählungstyp Primitiver Datentyp ], d. h. die Typangabe Klasse usw. ist optional und kann weggelassen werden. {} = Auswahl notwendig, z. B. [ { private public protected final static } ], d. h. in der Regel sind oder-alternativen in eine geschweifte Klammer eingeschlossen. Eine der Alternativen muss gewählt werden. + =kannwiederholt werden, z. B. [ { private public protected final static } ]+ Type, d. h. die Angaben in geschweiften Klammern können mehrfach angegeben werden.... = Liste (Elemente durch "," getrennt), z. B. [ readonly union subsets<attr> redefines<attr> ordered unique Einschränkung -Attr ]..., d. h. mehrere Angaben können aufgeführt werden, jeweils durch ein Komma getrennt. A ::= B (A wird definiert durch B), z. B. Sichtbarkeit ::= [ - # + ~ ]. Platzhalter, z.b. Type im Beispiel»wiederholt«, d. h. Type wird nicht hingeschrieben, sondern es wird an anderer Stelle definiert und steht hier nur als Platzhalter. Voreinstellungen sind unterstrichen, z. B. Generalisierungseigenschaften ::= [ {incomplete, disjoint} {complete, disjoint} {incomplete, overlapping} {complete, overlapping} ] Für jeden Softwareentwickler und insbesondere jeden Requirements Engineer bzw. Systemanalytiker gehört die Beherrschung der UML zum täglichen»handwerkszeug«. Die OMG als Entwickler der UML hat ein Ausbildungsprogramm unter der Bezeichnung»OMG Certified UML Professional TM «veröffentlicht, siehe Website UML Professional ( Es werden drei Kenntnisstufen unterschieden: Fundamental, Intermediate und Advanced. Die hier behandelten UML-Konzepte decken weitgehend die Kenntnisstufe Fundamental ab. 2 Es handelt sich um eine Pseudo-EBNF, angelehnt an die EBNF. Bei der EBNF (Extended Backus-Naur-Form) handelt es ich um eine Notation für die Beschreibung der Syntax von Programmiersprachen. 106