Home

Entwicklung eingebetteter Software mit UML

1. ABBILDUNG 84 Ausschnitt aus der K Fehlertabelle f r das Teilsystem LichtregelungFlur K Fehlerbehebungsstrategien Die Behebung der Fehler aus der K Fehlertabelle wird in den Tabellen zur Doku mentation der Fehlerbehebungsstrategie in den Verifikationskapiteln dokumentiert Beispielsweise wird die Behebung des Fehlers K LF FNr 3 in den Verifikationska piteln der System Anforderungen des Entwurfs und des Kodes dokumentiert In der Tabelle zur Dokumentation der Fehlerbehebungsstrategien wird verdeutlicht welche Fehler aus der Fehlerliste behoben wurden und wie dies geschehen ist Die Tabelle gibt damit Aufschluss ber den Stand der Rework Aktivit ten Anhand der Tabelle kann au erdem entschieden werden ob eine erneute Verifikation des ge n derten Komponenten Kodes notwendig ist Abbildung 85 zeigt einen Ausschnitt aus einer Tabelle zur Dokumentation der Feh lerbehebungsstrategie f r das Teilsystem LichtregelungFlur K Fehlerbehebungsstrategien In der Tabelle werden alle Fehler aus der Fehlertabelle aufgef hrt Die Beschrei bung der Strategien zur Behebung der Fehler erlaubt es nachzuvollziehen was sich im Komponenten Kode ge ndert hat Entwicklung eingebetteter Software mit UML 161 System Komponenten bearbeiten Referenz auf Behebung des Fehlers Strategie zur Behebung des Fehlers durchgef hrt FNr IJN K LF FNr1 Methode requestLightStatus implementiert J
2. San ee EEN SectionNr int Kc Q 1 S HallwaySection sectionNr ini roomNr int CDefaultHallwayRoomNr E ch 1 LightControlUnit EE changedLightStatus void imeRunOut void occupancyMessage occupancy zOccupancyType void PresencoController abstract entryTime Time exitTime Time sectionNr int roomNr int FgetStatus Occupancy Time Type getValuef int LichtStatus nderung weiterleiten Anwesenheit weiterleiten LichtStalus ndern ES 1 1 roomNr int lightControl zLightStatusType LightStatus void setLightControlUnit ighiControlUnitPrr LightControlUnit 1 Anwesenheit E pr fen PrfalwayDightControfer 1 TimelntervalExit durationType 10 E Aktuelle Systemzeit abfragen PresenceOontrollerHallway a getStatus zOccupancyTimeType D 1 1 Klassendiagramm LichtregelungFlur Dieses Diagramm zeigt alle Klassen die an der Erbringung der Funktionalit t der Lichtregelung in den Flurabschnitten beteiligt sind ABBILDUNG 53 Ausschnitt aus dem E Klassendiagramm f r das Teilsystem LichtRegelungFlur Klassenbeschreibungen Class Tables Die Klassenbeschreibungen Class Tables erl utern die Attribute und ffentlichen Methoden jeder Klasse im Software System informell Im Gegensatz zu den Klas sendiagrammen beschreibe
3. Entwicklung eingebetteter Software mit UML 105 System Entwurf bearbeiten H ightStatus cLightOn Controller zLighttStatus eLightOft Controller zLightStatus cLightOn ABBILDUNG 55 Sequenzdiagramm zu Szenario1 Flurlichtregelung durch Anwesenheit E Kollaborationsdiagramme Die E Kollaborationsdiagramme des UML Entwurfs beschreiben das Verhalten des Software Systems durch die Interaktion zwischen zu implementierenden Objekten Die E Kollaborationsdiagramme verfeinern die A Kollaborationsdia gramme aus den E Anforderungen Sie sind an die Entwurfsentscheidungen ange passt und hinsichtlich der Entwurfsaspekte berarbeitet worden Unter Verwendung eines CASE Werkzeusgs z B StP UML lassen sich die E Kol laborationsdiagramme automatisch aus den E Sequenzdiagrammen generieren Abbildung 56 zeigt ein Kollaborationsdiagramm zu Szenariol des Use Cases Flurlichtregelung_durch_Anwesenheit PANJA E Kollaborationsdiagramm Das E Kollaborationsdiagramm verfeinert das A Kollaborationsdiagramm Abbildung 27 Kollaborationsdiagramm zu Szenariol Flurlichtregelung durch Anwesenheit auf Seite 53 und wurde aus dem E Sequenzdiagramm generiert Bei der Generierung mit StP UML werden allerdings Parameter und Datentypen nicht bernommen 106 Entwicklung eingebetteter Software mit UML Produkte Actor PresenceControllerHallway 1 getState imd1 Contact
4. Entwicklung eingebetteter Software mit UML 187 System Integration e Software System Dokumentation Dieses Dokument umfasst den UML Ent wurf f r das zu implementierende Software System Au erdem beinhaltet es Anforderungen an die zu implementierenden Komponenten e Software Komponenten Dokumentation Dieses Dokument umfasst den Quell kode der implementierten Komponenten e Ausf hrbare Komponente Dieses Produkt beinhaltet den bersetzten Kode der Komponenten Probleml sungs A dokumentation Ausf hrbare D Komponente Ausf hrbares System Software System Dokumentation System Integration o Software Komponenten Dokumentation ABBILDUNG 96 Verwendete Produkte des Prozesses System Integration 6 1 Prozessverfeinerung Der Prozess System Integration unterteilt sich in zwei Teilprozesse siehe Abbil dung 97 Ausgehend von dem ausf hrbaren Komponenten Kode werden Ausf hr bare Teilsysteme erstellt Der UML Entwurf gibt Anleitung welche Teilsysteme gebildet werden im Entwurf als Packages gekennzeichnet Au erdem kann dem UML Entwurf entnommen werden von welchen Komponenten die Teilsysteme abh ngig sind d h welche Test Rahmen zum Ausf hren der Teilsysteme ben tigt werden Die Funktionalit t der Test Rahmen wird anhand der Testpl ne zum Test des Systems aus dem Dokument A Validation bestimmt In Makefiles werden die Komponenten festgehalten die zum Zusammenbinden
5. O L Entwurfsentscheidungen Entwurfs erstellen ingenieur Entwurfs Anforderungs ingenieur ingenieur UML Entwurf a bearbeiten a _ O Komponenten Verfolgbarkeitsmatrix Anforderungen erstellen Entwurf bearbeiten Entwurfs ingenieur a z z Verifizierer Entwurfs Anforderungs ingenieur ingenieur System Entwurf verifizieren O Komponenten Testf lle T bearbeiten Validierer ABBILDUNG 71 Kontrollfluss f r den Prozess System Entwurf bearbeiten 128 Entwicklung eingebetteter Software mit UML Prozess Entwurfsentscheidungen erstellen 4 5 Prozess Entwurfsentscheidungen erstellen Im Prozess Entwurfsentscheidungen erstellen werden aus den informellen nicht funktionalen B Anforderungen und dem Wissen ber die Systemumgebung Ent wurfsentscheidungen abgeleitet Die informellen nicht funktionalen B Anforderungen geben Richtlinien f r die Strukturierung des Systems vor Beispielweise f hrt die nicht funktionale Anforderung der nderbarkeit eines Systems zu einer bestimmten Systemstruktur Daf r muss im Vorfeld gekl rt werden welche Bereiche des Systems z B welche Anforderungen welche Schnittstellen zu anderen Systemen oder welche Strukturelemente aus der Umgebung stabil sind und welche h ufigen nderungen unterworfen sind Bereiche deren nderung abzusehen ist sollten in Komponenten d h Teilsystemen oder Klassen gekapselt und nicht auf das gesamte
6. Prozess Ausf hrbare Komponente erstellen Im Prozess Ausf hrbare Komponente erstellen wird f r jeden Test der bersetzte Komponenten Kode mit den zum Test geh renden Test Stubs und dem Test Trei ber zusammengebunden Es entstehen lauff hige Binaries f r jede Komponente Folgendes Produkt wird im Prozess Ausf hrbare Komponente erstellen modifiziert e Ausf hrbarer Komponenten Kode Prozess Komponententest durchf hren Im Prozess Komponententest durchf hren werden die lauff higen Binaries ausge f hrt W hrend der Ausf hrung werden Testausgaben produziert und im Dokument E Validation im Abschnitt Dokumentation der Testergebnisse beschrieben Nach der Durchf hrung eines Tests werden die produzierten Testausgaben mit dem Entwicklung eingebetteter Software mit UML 183 System Komponenten bearbeiten erwarteten Verhalten der Komponente verglichen Das erwartete Verhalten kann den Testpl nen zum Komponententest entnommen werden Gibt es Unterschiede zwischen dem tats chlichem und dem erwarteten Verhalten einer Komponente wird dies als Fehlverhalten in der Tabelle zur Bewertung der Testergebnisse im Dokument E Validation dokumentiert Anschlie end werden die beschriebenen Fehlverhalten auf Fehler in der System Dokumentation zur ckgef hrt Die Fehler werden in der Fehlertabelle im Dokument K Verifikation festgehalten Die Tabelle zur Bewertung der Testergebnisse wird um Verweise auf die Fehlernumm
7. e Komponenten Anforderungen 206 Entwicklung eingebetteter Software mit UML Weiterf hrende Literatur Verfolgbarkeitsmatrix Entwurf E Verifikation E Validation A Use Cases Szenarien E Anforderungen Verfolgbarkeitsmatrix Anforderungen A Verifikation A Validation 6 7 Weiterf hrende Literatur 1 Peter Liggesmeyer Modultest und Modulverifikation state of the art BI Wiss Verlag Mannheim Wien Z rich 1990 Glenford J Meyers Methodisches Testen von Programmen Oldenbourg Ver lag M nchen Wien 1982 Entwicklung eingebetteter Software mit UML 207 System Integration 208 Entwicklung eingebetteter Software mit UML KAPITEL 7 System Validation Ziel des Prozesses System Validation ist das ausf hrbare System in der Entwick lungs und anschlie end in der Anwendungsumgebung gegen die Anforderungen zu testen Der Test in der Entwicklungsumgebung wird als Systemtest bezeichnet Dabei wird die Zuverl ssigkeit des Systems hinsichtlich funktionaler Funktions test und nicht funktionaler Anforderungen wie z B Performanz berpr ft Der Test in der Anwendungsumgebung wird Akzeptanz oder Abnahmetest genamnt Besteht das System diesen Test nimmt der Kunde das System ab und es wird beim Kunden eingef hrt Treten w hrend der Tests Fehlverhalten des Systems auf wer den diese auf Fehler in der Dokumentation zur ckgef hrt und behoben Abbildung 107 gibt einen berbli
8. 9 Martin Verlage J rgen M nch Formalizing Software Engineering Standards Proceedings of the Third International Symposium and Forum on Software Engineering Standards ISESS 97 California USA June 1 6 1997 10 Wolfgang Wagenbichler Erstellung einer SW Systemdokumentation mit StP Projektarbeit Fachbereich Informatik Universit t Kaiserslautern 67653 Kai serslautern 1999 URL http wwwagse informatik uni kl de access system publications html 8 Entwicklung eingebetteter Software mit UML 19 Einf hrung 20 Entwicklung eingebetteter Software mit UML KAPITEL 2 Projekt initialisieren Ziel des Prozesses Projekt initialisieren ist ein Entwicklungsprojekt f r ein einge bettetes Software System aufzusetzen sowie die wichtigsten Anforderungen an das zu entwickelnde System und Ziele f r das durchzuf hrende Projekt aufzustellen Es gibt verschiedene Gr nde warum ein Entwicklungsprojekt f r ein eingebettetes Software System aufgesetzt wird Beispielsweise identifiziert ein Kunde Probleme in seiner Umgebung die durch die Einf hrung eines Software Systems behoben werden k nnen z B berh hter Energiebedarf in einem Universit tsgeb ude Probleme die ein eingebettetes Software System l sen kann lassen sich z B durch Marktforschung und analyse ermitteln Neben konkreten Problemen k nnen auch strategische Ziele zum Aufsetzen eines Software Entwicklungsprojekts f hren Wurde der Beda
9. A Zustandsdiagramme Prozess A Aktivit tsdiagramme bearbeiten Jede komplexe Operation einer Klasse wird mit Hilfe eines Aktivit tsdiagramms verfeinert Anstelle von Aktivit tsdiagrammen k nnen die Operationen auch mit Hilfe von Pseudo Code oder informellen Beschreibungen erl utert werden Das Aktivit tsdiagramm erlaubt die Verfeinerung einer Aktivit t in Teilaktivit ten Die Namenskonventionen geben Richtlinien f r Benennungen von Bezeichnern z B Bezeichner werden der engl Sprache entnommen Die Konsistenz der anderen UML Diagramme mit den Aktivit tsdiagrammen muss sichergestellt sein Daf r muss u a gepr ft werden ob f r komplexe Operationen im Klassendiagramm ein Aktivit tsdiagramm exis tiert f r komplexe Operationen im Zustandsdiagramm ein Aktivit tsdiagramm exis tiert Beziehungen zwischen Klassen im Klassendiagramm im Aktivit tsdiagramm genutzt werden Folgende Produkte werden im Prozess A Aktivit tsdiagramme bearbeiten konsu miert Systemumgebung 80 Entwicklung eingebetteter Software mit UML Prozess Verfolgbarkeitsmatrix Anforderungen bearbeiten e Referenz Dokumente e Namenskonventionen e A Use Cases e Szenarien e A Packagediagramme e A Klassendiagramme e A Zustandsdiagramme e A Sequenzdiagramme Folgendes Produkt wird produziert e A Aktivit tsdiagramme 3 7 Prozess Verfolgbarkeitsmatrix Anforderungen bearbeiten Im Prozess Verfolg
10. Anwesen ktImd3 1 0 Wert offen A Kein Licht an im Flurabschnitt LichtStatusFlur 1 0 Minuten 0 LichtStatusFlur 1 0 Wert off A Startzustand erreicht A Beginn des Tests A Anwesenheit gemeldet durch AnwesenheitskontaktImd1Doorl AnwesenheitskontaktImd1Doorl 1 1 Minuten 11 AnwesenheitskontaktImd1Doorl 1 1 Wert geschlossen A Ende des Tests bei 60 min A Ende des Testfalls mit Werten belegen damit Zeitdifferenz A auch am Ende richtig berechnet werden kann AnwesenheitskontaktImd1Doorl1 1 2 Minuten 60 Anwesen Anwesen Anwesen eitskonta eitskonta eitskonta ktImd1Doorl ktImd2Doorl ktImd2Doorl 1 1 Minuten 1 1 Wert zo 1 2 Wert geschlossen 60 en Anwesen Anwesen Anwesen Anwesen Anwesen eitskonta eitskonta eitskonta eitskonta eitskonta eitskonta ktImd1Door2 1 1 Minuten ktImd1Door2 1 1 Wert zo ktImd2Door2 1 1 Minuten ktImd2Door2 1 1 Wert zo ktImd3 1 1 Minuten 60 60 en 60 en Anwesen ktImd3 1 1 Wert offen A Kein Licht an im Flurabschnitt LichtStatusFlur 1 1 Minuten 60 LichtStatusFlur 1 1 Wert off ABBILDUNG 101 Ausschnitt aus einem Teilsystemtest Stub 196 Entwicklung eingebetteter Software mit UML Produkte Teilsystem Makefile Die Teilsystem Makefiles beschreiben Abh ngigkeiten zwischen Komponenten innerhalb eines Teilsystems und vom Teilsystem zu anderen Komponenten Make files e
11. E Aktivit tsdiagramme A Aktivit ts bearbeiten diagramme Eder Namens konventionen Software System Dokumentation Entwurfs entscheidungen UML Entwurf Unterschiede zur Analyse TN E Package UL S diagramme L 1 E Klassendiagramme BE S Class Tables E Kollaborations diagramme E Zustands diagramme E Aktivit ts diagramme eege i ABBILDUNG 73 Verwendete Produkte des Prozesses UML Entwurf bearbeiten 132 Entwicklung eingebetteter Software mit UML Prozess UML Entwurf bearbeiten Folgende Produkte werden im Prozess UML Entwurf bearbeiten konsumiert A Use Cases Das Dokument beschreibt die m glichen Verwendungsweisen des zu entwickelnden Systems A Packagediagramme Das Dokument beschreibt eine Zerlegung des Systems in Teilsysteme A Klassendiagramme Das Dokument beschreibt Klassen des Systems mit ihren Attributen Methoden und Beziehungen Data Dictionary Das Dokument erl utert die verschiedenen Elemente des A Klassendiagramms informell A Sequenzdiagramme Das Dokument beschreibt das Verhalten des Systems als Interaktion von Objekten der Klassen aus dem Klassendiagramm A Zustandsdiagramme Das Dokument beschreibt das Verhalten einzelner Klassen A Aktivit tsdiagramme Das Dokument verfeinert einzelne komplexe Operati onen Entwurfsentscheidungen Das Dokument beschreibt Implementierungsent scheidungen die aus der Systemumgebung oder Qualit t
12. Folgende Produkte werden modifiziert Entwicklung eingebetteter Software mit UML 217 System Validation e Probleml sungsdokumentation e Software Systemdokumentation e Software Komponenten Dokumentation e Ausf hrbare Komponente e Ausf hrbares System O O Probleml sungdokumentation E J Validierer Anforderungs System ingenieur integrations O O Ingenieur 2 Entwurfs Kodierer ingenieur A Validation Systemtest Software Komponenten Dokumentation Systemtest durchf hren Software System o dokumentation K Verifikation Rework Systemtest Ausf hrbares System Ausf hrbare Komponente Ausf hrbarer System Kode ABBILDUNG 113 Verwendete Produkte des Prozesses Systemtest 218 Entwicklung eingebetteter Software mit UML Prozess Systemtest Prozess Systemtest durchf hren Im Prozess Systemtest durchf hren wird das System unter Verwendung des Simula tors ausgef hrt Durch den Einsatz des Simulators lassen sich die in den Testpl nen beschriebenen Vorbedingungen k nstlich herstellen Durch die Manipulation der Sensorwerte im Simulator werden die in den Testpl nen beschriebenen Ausgangs bedingungen geschaffen Das Verhalten des Systems wird beobachtet und im Dokument A Validation im Abschnitt Dokumentation der Testergebnisse proto kolliert Nach der Durchf hrung eines Tests wird das protokollierte Systemverh
13. Integriere Teilsystem Ausf hrbares 1 n 1 Iteration Teilsystem erstellen Teilsystemtest durchf hren Rework Teilsystemtest Integriationstest Systemtest System Validation Systemtest durchf hren REEL Rework Systemtest Akzeptanztest Installiere System Akzeptanztest durchf hren Rework Akzeptanztest Test im Betrieb Test im Betrieb durchf hren Rework Test im Betrieb 238 Entwicklung eingebetteter Software mit UML Index A A Aktivit tsdiagramme 56 A Aktivit tsdiagramme bearbeiten 80 A Checkliste 59 A Ergebnisbewertung 66 A Fehlerbehebungsstrategien 61 A Fehlertabellen 60 A Klassendiagramme 48 A Klassendiagramme bearbeiten 76 A Kollaborationsdiagramme 53 A Kollaborationsdiagramme bearbeiten 79 Akzeptanztest 220 Akzeptanztest durchf hren 222 Anforderungsingenieur 31 68 127 169 199 215 A Packagediagramme 46 A Sequenzdiagramme 51 A Sequenzdiagramme bearbeiten 78 A Testergebnisse 65 A Testpl ne 64 A Testverfahren 63 A Use Cases 42 A Use Cases bearbeiten 72 Ausf hrbare Komponente 152 166 188 210 Ausf hrbare Komponente bearbeiten 179 Ausf hrbarer Komponenten Kode 169 Ausf hrbarer System Kode 198 Ausf hrbarer Teilsystem Kode 198 Ausf hrbares System 187 192 210 Ausf hrbares Teilsystem 193 Ausf hrbares Teilsystem erstellen 204 A Validation 62 A Verifikation 58 A Zustandsdiagramme 54 A Zustandsdiagramme
14. Produkte Probleml sungsdokumentation Problembeschreibung Verfolgbarkeitsmatrix Anforderungen B Anforderungen A Verifikation Informelle B Anforderungen A Checkliste siehe Abbildung 10 auf Seite 24 Penlgklassitikation A Fehlertabellen A Fehlerbehebungsstrategien A Use Cases Szenarien A Validation A Testverfahren A Testpl ne A Testergebnisse A Ergebnisbewertung E Anforderungen A Packagediagramme A Klassendiagramme Data Dictionary A Sequenzdiagramme A Kollaborationsdiagramme A Zustandsdiagramme A Aktivit tsdiagramme Dom nenwissen Systemumgebung Referenz Dokumente Namenskonventionen ABBILDUNG 20 Produkt bersicht f r den Prozess System Anforderungen bearbeiten B Anforderungen Die B Anforderungen beschreiben die Anforderungen an das zu entwickelnde Sys tem aus Sicht des Benutzers Kunden Sie gliedern sich in drei Kapitel 1 die infor mellen tabellarischen B Anforderungen 2 das Use Case Diagramm mit einer 1 Da Use Cases auch auf Entwurfsebene auftreten k nnen werden die Use Cases auf Anforderungsebene im Folgenden auch als A Use Cases bezeichnet Dies gilt analog auch f r weitere Bezeichner mit dem Pr fix A Entwicklung eingebetteter Software mit UML 4 System Anforderungen bearbeiten kurzen Beschreibung der einzelnen Use Cases A Use Cases und 3 eine Reihe von Szenarien die die A Use Case
15. Aufbau der Code Datei s Im Kopf der Datei steht wie bei der Header Datei als Kommentar der Autor das Erzeugungsdatum und die Dateihistorie Danach wird die Datei lt Klasse hh gt inkludiert include lt Klasse hh gt Dabei ist Klasse durch den jeweiligen Klassennamen zu ersetzen e Daran schlie t sich der Quellcode f r die einzelnen Methoden an e Alle anderen Methoden und alle Attribute sind private e Globale Variablen sind nicht erlaubt e Auf das Konstrukt extern ist zu verzichten e Variablen sollen nur am Anfang eines Blocks deklariert und initialisiert werden e In jeder Zeile steht nur eine Anweisung Es sollen keine type casts verwendet werden ABBILDUNG 87 Ausschnitt aus Programmierrichtlinien f r C Entwicklung eingebetteter Software mit UML 165 System Komponenten bearbeiten Ausf hrbare Komponente Die Ausf hrbare Komponente besteht aus dem Komponententest Rahmen und dem Ausf hrbaren Komponenten Kode Komponententest Rahmen Der Komponententest Rahmen beinhaltet den Quellkode der Treiber und Stubs die zum Test der Komponenten ben tigt werden Die Funktionalit t der Test Treiber und Test Stubs ist in den Testpl nen f r den Komponententest im Kapitel E Valida tion beschrieben Komponententest Treiber Der Komponententest Treiber ist ein Modul z B Testfall cc mit der Funktion main in der Methoden der zu testenden Klasse aufgerufen werden Welche Objekte im Komponenten
16. beiten mit den Rollen verbunden e Kodierer Der Kodierer implementiert die System Komponenten nimmt an der Verifikation des Komponenten Kodes teil und ist f r die Fehlerbehebung in den ihm zugeordneten Dokumenten verantwortlich e Verifizierer Die Aufgaben des Verifizierers sind die Inspektion des Quellkodes zu organisieren diese in Kooperation mit dem Kodierer durchzuf hren und die Ergebnisse zu dokumentieren e Validierer Die Aufgaben des Validierers im Prozess System Komponenten bearbeiten sind Komponententest Rahmen zu erstellen den Komponententest durchzuf hren und die Ergebnisse zu dokumentieren e Anforderungsingenieur Die Aufgabe des Anforderungsingenieurs ist bei der Verifikation gefundene Fehler in den ihm zugeordneten Dokumenten zu behe ben Hierf r kann er den Kunden kontaktieren sofern die Problembeschreibung oder die Informellen B Anforderungen betroffen sind es Entwurfsingenieur Die Aufgabe des Entwurfsingenieurs ist bei der Verifika tion gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben e Qualit tsmanager Die Aufgabe des Qualit tsmanagers ist entsprechend den l ngerfristigen Bed rfnissen und Erwartungen einer Software Entwicklungsor ganisation Wissen Erfahrung in geeigneter Form zu verwalten einzelnen Pro jekten auf Anfrage zur Wiederverwendung zur Verf gung zu stellen und kontinuierlich aufgrund gemachter Projekterfahrungen zu verbessern Wissen Erfahrungen kann vom Qualit tsman
17. nen abstrakt beschrieben Eine informelle Beschreibung reicht meist aus Die Akti vit tsdiagramme k nnen auch vollst ndig durch Pseudo Code oder informelle Beschreibungen ersetzt werden Abbildung 29 zeigt einen Ausschnitt aus einem A Aktivit tsdiagramm f r das Teil system Systemmodusermittlung des Geb udeautomationssystems 56 Entwicklung eingebetteter Software mit UML Produkte A Aktivit tsdiagramm UserData changeValue Bei einem Aufruf von changeValue wird je nachdem von welcher Klasse die Instanz gebildet wurde der Wert auf verschiedene Eigenschaften gepr ft und anschlie end ein updateValues an die DefinitionOfTempOpModus geschickt UserData changeValue Pr fe Eingabewert updateValues updateValues wird an die gt DefinitionOfTempOpModus geschickt ABBILDUNG 29 Ausschnitt aus einem Aktivit tsdiagramm Verfolgbarkeitsmatrix Anforderungen Die Verfolgbarkeitsmatrix Anforderungen zeigt Beziehungen zwischen den B Anforderungen und den E Anforderungen tabellarisch auf Gegen bergestellt wer den die informellen tabellarischen B Anforderungen und die Klassen aus den E Anforderungen Ein Kreuz in der Tabelle zeigt dass eine Klasse an der Realisie rung einer informellen B Anforderung beteiligt ist Die Verfolgbarkeitsmatrix unterst tzt eine berpr fung der Konsistenz zwischen B und E Anforderungen und die Durchf hrung sp ter evtl auftretender nderungen Abb
18. Action LightController SwitchLightOn Event fmSwitchOff Action LightController SwitchLightOff Zustandsdiagramm der Klasse LightControlUnit Die Klasse kennt vier Zust nde FM Betrieb Automatik Betrieb manueller Betrieb und Zeitverz gerung W hrend des FM Betriebs ist es dem Hausmeister erlaubt niemand ist im Flur anwesend das Flurlicht ber das ControlPa nelFM einzuschalten Wenn ein Benutzer im Flurabschnitt anwesend ist wird unterschieden ob er den Flurlicht schalter bet tigt hat manueller Betrieb oder nicht Automatik Betrieb Der manuelle Betrieb wird wieder aufgehoben wenn alle Benutzer den Flurabschnitt verlassen haben ABBILDUNG 28 Zustandsdiagramm der Klasse LightControlUnit mit einem Ausschnitt aus den vorhandenen Entry Do und Exit Aktionen Entwicklung eingebetteter Software mit UML 55 System Anforderungen bearbeiten A Aktivit tsdiagramme Mit Hilfe der Aktivit tsdiagramme lassen sich Methoden detaillierter beschreiben die komplexe Operationen ausf hren Die Funktionalit t der Methoden wird mit tels der Aktivit tsdiagramme in Teilfunktionen zerlegt und beschrieben Aktivit ts diagramme sollten nicht verwendet werden um die Systemfunktionalit t zu beschreiben Dies f hrt leicht zu einer funktionalen Sichtweise die sich nur sehr schwer mit einer objektorientierten Strukturierung des Systems verbinden l sst Auf Ebene der E Anforderungen werden die identifizierten komplexen Operatio
19. In jedem Raum soll ein Control Panel bereitgestellt werden ber das der Benutzer seine individuellen Klimaeinstellungen z B Solltemperatur Arbeitszeiten Aufheizzeiten siehe genaue Auflistung weiter unten eingeben kann Dem Hausmeister steht ein eigenes Control Panel zur Verf gung ber das er verschiedene Werte f r das gesamte Geb ude z B Heizperioden Defaultwerte Akzeptanzintervalle siehe genaue Auflistung weiter unten setzen kann ABBILDUNG 11 Ausschnitt aus einer Problembeschreibung Entwicklung eingebetteter Software mit UML 25 Projekt initialisieren B Anforderungen Die B enutzer Anforderungen beschreiben die Anforderungen an das zu entwi ckelnde System aus Sicht des Benutzers Kunden Sie gliedern sich in drei Kapitel 1 die informellen tabellarischen B Anforderungen 2 das Use Case Diagramm mit einer Beschreibung der einzelnen Use Cases A Use Cases und 3 eine Reihe von Szenarien die die A Use Cases verfeinern Im Folgenden werden nur die f r diesen Prozess relevanten informellen tabellarischen B Anforderungen erl utert Eine Beschreibung der A Use Cases und der Szenarien erfolgt in Kapitel System Anforderungen bearbeiten Informelle B Anforderungen Die informellen B Anforderungen beschreiben die funktionalen nicht funktiona len und inversen B Anforderungen an das zu entwickelnde System in tabellarischer Form und in nat rlicher Sprache Die funktionalen Anforderungen beschreiben d
20. Komponenten Kode Review vorbereiten Software Komponenten Dokumentation Review Sitzung Komponenten Kode Komponenten Kode Komponenten Anforderungen Ausf hrbare Komponente Komponententest Rahmen Probleml sungs dokumentation Ausf hrbarer Komponenten Kode ABBILDUNG 93 Verwendete Produkte des Prozesses Komponenten Kode verifizieren 176 Entwicklung eingebetteter Software mit UML Prozess Quellkode bearbeiten Prozess Komponenten Kode Review vorbereiten Im Prozess Komponenten Kode Review vorbereiten wird der Komponenten Kode mit Hilfe der K Checkliste die im Dokument K Verifikation dokumentiert ist berpr ft Gelesen wird von den Verifizierern Werden Fragen in der Checkliste mit Nein beantwortet dann k nnte es sich um einen Fehler handeln Probleme im Dokument werden in der Fehlertabelle dokumentiert Ergebnis dieses Prozesses ist eine Liste mit m glichen Fehlern die in sogenannten K Fehlertabellen beschrieben wird Jeder Fehler ist dabei einer Fehlerklasse zuzu ordnen Die potentielle Fehlerliste wird im Dokument K Verifikation dokumen tiert Im Prozess Komponenten Kode Review vorbereiten werden folgende Produkte konsumiert e E Klassendiagramme e Class Tables e E Zustandsdiagramme e E Aktivit tsdiagramme e Komponenten Anforderungen e Entwicklungsrichtlinien e Komponenten Kode Im Prozess w
21. PRHallwayLightController O getValue 2 occupancyMessage 6 1sOn 5 SwitchOn 3 lightControl LightController LightControlUnit ABBILDUNG 56 E Kollaborationsdiagramm zu Szenariol Flurlichtregelung durch Anwesenheit E Zustandsdiagramme Das dynamische Verhalten einer Klasse wird mit Hilfe eines Zustandsdiagramms beschrieben Die E Zustandsdiagramme aus dem UML Entwurf verfeinern die A Zustandsdiagramme Sie sind an die Entwurfsentscheidungen angepasst und hin sichtlich der Entwurfsaspekte berarbeitet worden Jedes Zustandsdiagramm wird informell beschrieben Dabei sollten insbesondere die verschiedenen Zust nde erl utert werden Abbildung 57 zeigt ein E Zustandsdiagramm f r die Klasse LightControlUnit des Teilsystems LichtRegelungFlur eines Geb udeautomationssystems PANJA E Zustandsdiagramme Das E Zustandsdiagramm verfeinert das A Zustandsdiagramm f r die Klasse LightControlUnit Abbildung 28 Zustandsdiagramm der Klasse Entwicklung eingebetteter Software mit UML 107 System Entwurf bearbeiten LightControlUnit mit einem Ausschnitt aus den vorhandenen Entry Do und Exit Aktionen auf Seite 55 Die Nachrichten die ein Objekt der Klasse verschickt oder geschickt bekommt sind erweitert um Parameter und R ckgabewerte Au erdem wurden Entscheidungen hinsichtlich der Klassenstruktur ber cksichtigt wie das Zusammenfassen
22. Referenzdokument A Use Cases und Szenarien Die Namenskonventionen geben Richtlinien f r Benennun gen von Bezeichnern z B Bezeichner werden der engl Sprache entnommen Die Konsistenz der anderen UML Diagramme mit den Klassendiagrammen muss sichergestellt sein Daf r muss u a gepr ft werden ob e die Attribute und Methoden im Zustandsdiagramm im Klassendiagramm defi niert sind e Klassen deren Objekte im Sequenzdiagramm miteinander kommunizieren eine Beziehung im Klassendiagramm haben e jedes Objekt im Sequenzdiagramm einer Klasse im Klassendiagramm zugeord net werden kann Folgende Produkte werden im Prozess A Klassendiagramme bearbeiten konsu miert e Systemumgebung e Referenz Dokumente e Namenskonventionen e A Use Cases e Szenarien e A Sequenzdiagramme e A Zustandsdiagramme e A Aktivit tsdiagramme Folgende Produkte werden produziert e A Packagediagramme e A Klassendiagramme Entwicklung eingebetteter Software mit UML 77 System Anforderungen bearbeiten Prozess Data Dictionary bearbeiten Die Klassen sowie deren Attribute Methoden und Assoziationen Aggregationen werden informell beschrieben Das CASE Werkzeug StP UML erlaubt aus den Klassendiagrammen und aus ange legten Beschreibungen ein Data Dictionary automatisch zu generieren Folgendes Produkt wird im Prozess Data Dictionary bearbeiten konsumiert e A Klassendiagramme Folgendes Produkt wird produziert
23. Zusammenarbeit mit dem Anforderungsingenieur erstellt Es sollte zwischen funktionalen nicht funktionalen und inversen Anforderungen unterschieden werden Die funktionalen Anforderungen verfeinern die in der Pro blembeschreibung festgehaltene erwartete Systemfunktionalit t Sie lassen sich beispielsweise nach verschiedenen Systemfunktionen strukturieren z B Tempera tur und Lichtregelung Es gilt abzugleichen ob die beschriebene Systemfunktio nalit t mit den zur Verf gung stehenden Sensoren und Aktuatoren erreicht werden kann Evtl hat der Kunde nicht funktionale Anforderungen an das zu entwickelnde Sys tem Beispielsweise w nscht er sich bestimmte Reaktionszeiten des Systems Die Dokumentation der nicht funktionalen Anforderungen kann informell geschehen Sp ter sollte darauf geachtet werden dass alle nicht funktionalen Anforderungen quantifizierbar dokumentiert sind Auf diese Weise kann ihre Einhaltung berpr ft werden Sollen bestimmte Verhaltensweisen des Systems ausgeschlossen werden dann k nnen diese Anforderungen als inverse Anforderungen festgehalten werden Folgende Produkte werden im Prozess Informelle B Anforderungen bearbeiten konsumiert e Dom nenwissen e Problembeschreibung Folgendes Produkt wird produziert e Informelle B Anforderungen 34 Entwicklung eingebetteter Software mit UML Weiterf hrende Literatur 2 8 Weiterf hrende Literatur 1 Merlin Dorfman Richard H Thayler
24. der Kunde mit dem sp teren Benutzer Anwender des Systems gleichgesetzt Dies ist in der Praxis nicht immer gegeben In einem solchen Fall kann es durchaus sinnvoll sein potentielle Benutzer Anwender bei der Erstellung der System Anforderungen einzubeziehen 68 Entwicklung eingebetteter Software mit UML Kontrollfluss e Dom nenexperte Die Aufgaben des Dom nenexperten sind das Produkt Dom nenwissen bereitzustellen und zu warten sowie f r Ausk nfte ber die Dom ne bereitzustehen e Verifizierer Die Aufgaben des Verifizierers sind die Inspektion der System Anforderungen zu organisieren diese in Kooperation mit dem Anforderungsin genieur durchzuf hren und die Ergebnisse zu dokumentieren e Validierer Die Aufgabe des Validierers im Prozess System Anforderungen bearbeiten ist Testf lle zu entwickeln und zu dokumentieren e Qualit tsmanager Die Aufgabe des Qualit tsmanagers ist entsprechend den l ngerfristigen Bed rfnissen und Erwartungen einer Software Entwicklungsor ganisation Wissen Erfahrung in geeigneter Form zu verwalten einzelnen Pro jekten auf Anfrage zur Wiederverwendung zur Verf gung zu stellen und kontinuierlich aufgrund gemachter Projekterfahrungen zu verbessern Wissen Erfahrung werden vom Qualit tsmanager im Prozess System Anforde rungen bearbeiten in Form von Checklisten Namenskonventionen Fehlerklas sifikationen etc zur Verf gung gestellt Diese sind zum Teil Bestandteil von Produkten
25. die Regelung der Temperatur erfolgt in den R umen eines Geb udes manuell dies f hrt zu berh h tem Energiebedarf oder der Bedarf ergibt sich aus strategischen Zielen des Unter nehmens Basierend auf dem identifizierten Bedarf werden die wichtigsten Anforderungen an das zu entwickelnde eingebettete System gestellt z B durch eine automatische Regelung der Temperatur soll der berh hte Energiebedarf gesenkt werden Die identifizierten Probleme oder strategischen Ziele und die wichtigsten Anforde rungen an ein System sind in der Problembeschreibung dokumentiert Vom Kunden h ngt ab wie detailliert die erwartete Sytemfunktionalit t an dieser Stelle beschrieben wird Folgendes Produkt wird im Prozess Problembeschreibung bearbeiten konsumiert e Dom nenwissen Folgendes Produkt wird produziert e Problembeschreibung 2 6 Prozess Dom nenwissen bearbeiten Im Prozess Dom nenwissen bearbeiten werden Eigenschaften und Charakteristika der Anwendungsdom ne vom Dom nenexperten dokumentiert Zur Beschreibung der Dom ne geh rt eine Dokumentation der sp teren Umgebung des zu entwi ckelnden Software Systems In der Beschreibung sollten folgende Fragen gekl rt sein e Wie sieht die Struktur der Dom ne des Systems aus Die Strukturierung des Anwendungsbereichs gibt Aufschluss dar ber wie das sp tere System konstruiert werden muss und welche Funktionalit t abgedeckt werden soll Insbesondere sollte beschrieben
26. leicht miteinander verglichen werden Die Testergebnisse beschreiben das Verhalten der Komponente beim Testdurch lauf Abbildung 67 zeigt eine m gliche Dokumentation der Ergebnisse eines durchge f hrten Tests anhand des oben aufgef hrten Testplans Entwicklung eingebetteter Software mit UML 123 System Entwurf bearbeiten PANJA Dokumentation der Testergebnisse Ergebnis zu KompTest1 Korrekter Testlauf Verwendete Stubs LightController gt lightControl zLightStatusType void LightController 1 0 Schritt 1 Aufruf des LightControlUnit Konstruktors 1 Aufruf Methode LightController gt lightContro gt gt Status auf Licht aus gesetzt Schritt 2 Aufruf der Methode fmLightControl cLightOn 2 Aufruf Methode LightController gt lightContro gt gt Status auf Licht an gesetzt Schritt 3 Aufruf der Methode fmLightControl cLightoff 3 Aufruf Methode LightController gt lightContro gt gt Status auf Licht aus gesetzt Schritt 4 Aufruf der Methode occupancyMessage cPersonIn 4 Aufruf Methode LightController gt lightContro gt gt Status auf Licht an gesetzt Schritt 5 Aufruf der Methode changedLightStatus Schritt 6 Aufruf der Methode occupancyMessage cPersonOut 5 Aufruf Methode LightController gt lightControl gt gt Status auf Licht aus gesetzt ABBILDUNG 67 Ausschnitt aus der Dokumentation zum Test der Komponente Li
27. nderungen Die Qualit tsorientierung des Prozesses spiegelt sich beispielsweise in der Bereitstel lung von Dokumentationsvorlagen und dom nenspezifischen Checklisten wider Der Prozess unterst tzt die Entwicklung einer verst ndlichen und leicht nderbaren System Dokumentation Kontrolliert iterativ Bei eingebetteten Systemen steht die grobe Funktionalit t relativ fr h im Entwick lungsprozess fest z B Licht und Temperaturregelung bei Geb udeautomations systemen Somit kann in der Regel eine fr hzeitige Aufteilung des Systems in Teilsysteme erfolgen Dies kommt der Anforderung nach einem planbaren und kontrollierbaren Entwicklungsprozess entgegen Der hier vorgestellte Prozess erlaubt Iterationen nur zu fest definierten Zeitpunkten Die Iterativit t des Prozes ses zeigt sich beispielsweise in der Anbindung von Rework Aktivit ten im Anschluss an Verifikations und Validationsschritte Der Entwicklungsprozess erlaubt dar ber hinaus eine inkrementelle Entwicklung der Software mit einer anschlie enden gemeinsamen Integration der Inkremente Entwicklung eingebetteter Software mit UML 7 Einf hrung 1 3 Herkunft des Prozesses Der hier vorgestellte Entwicklungsprozess wurde aufbauend auf folgenden Quellen entwickelt e einem im Sonderforschungsbereich 501 entwickelten Referenzprozess zur Ent wicklung gro er Systeme e Erfahrungen aus Software Entwicklungsprojekten zur Erstellung von Geb u deautomationssysteme
28. r die Pro grammierung Es umfasst einerseits Vorschriften f r die Wahl von Bezeichnern f r das Aussehen des Quellkodes und f r dessen Kommentierung Andererseits umfasst es Vorschriften wie der Komponenten Kode aus dem UML Entwurf und den Komponenten Anforderungen abzuleiten ist Entwicklung eingebetteter Software mit UML 151 System Komponenten bearbeiten Folgende Produkte werden im Prozess System Komponenten bearbeiten modifi ziert e Software Komponenten Dokumentation Dieses Dokument umfasst den Quell kode der implementierten Komponenten Dar ber hinaus beinhaltet die Doku mentation Dokumente zu Verifikationsaktivit ten auf Implementierungsebene z B eine Klassifikation f r Fehler eine Checkliste zur Inspektion des Kodes und Fehlertabellen zur Dokumentation gefundener Fehler und Fehlerursachen e Ausf hrbare Komponente Das Produkt ausf hrbare Komponente enth lt den Quellkode der Testrahmen Komponententest Rahmen die zum Test der Kom ponenten ben tigt werden Dar ber hinaus umfasst die ausf hrbare Kompo nente den ausf hrbaren Komponenten Kode Dieser enth lt den bersetzten Kode der Komponenten und der Testrahmen sowie eine Menge ausf hrbarer Binaries d h bersetzte und mit einem Testrahmen zusammengebundene Komponenten e Probleml sungsdokumentation Dieses Dokument beinhaltet die Anforderun gen an das zu entwickelnde Software System aus Sicht der Benutzer Kunden und der Entwickler e So
29. 1 eine Beschreibung des durchgef hrten Testverfahrens 2 die aufgestellten Testpl ne 3 die Ergebnisse der durchgef hrten Tests sowie 4 eine Bewertung der Testergebnisse und Dokumenta tion von Fehlverhalten Es ist wichtig Testpl ne aufzustellen und durchgef hrte Tests und Testergebnisse zu dokumentieren um gegebenenfalls Tests wiederholen zu k nnen Regressions test Beim Komponententest wird jede Komponente d h Klasse im System getestet Zum Test wird ein Testrahmen ben tigt Ein Treiber aktiviert die zu testende Klasse Stubs simulieren Klassen die von der zu testenden Klasse aufgerufen wer den Dokumentation des Testverfahrens E Testverfahren Dieses Dokument beschreibt das Testverfahren mit dessen Hilfe Testpl ne ausge w hlt wurden Es gibt wie zum Test des Systems verschiedene Black box Testver fahren f r den Komponententest z B kann ebenfalls ein quivalenzklassen oder Grenzfallbasierter Test durchgef hrt werden Die Wahl eines Black box Testverfah rens erlaubt das Ableiten von Testpl nen aus den Komponenten Anforderungen Die ausf hrbare Komponente wird erst zur Durchf hrung der Tests ben tigt Das Entwicklung eingebetteter Software mit UML 119 System Entwurf bearbeiten spezielle Testverfahren sollte entsprechend des Projekt und Systemkontexts ausge w hlt werden Abbildung 65 zeigt einen Ausschnitt aus der Dokumentation des Testverfahrens das in dem Geb udeautomationsprojek
30. A stp operation 337 340 void LightController lightControl zLightStatusType LightStatus switch zLCState case cStatusLicht Aus if LightStatus cLightOn A Zustandwechsel zLCState cStatusLichtAn A Licht einschalten lightPtr gt SwitchOn break A Ende des case Block cStatusLicht Aus case cStatusLichtAn if LightStatus cLightOff A Zustandwechsel zLCState cStatusLichtAus A Licht ausschalten lightPtr gt SwitchOffO break A Ende von case Block cStatusLichtAn default break HI lightControl zLightStatusType LightStatus A end stp operation ABBILDUNG 82 Ausschnitt aus der Implementationsdatei der Klasse LightController K Verifikation Das Dokument K Verifikation enth lt Hinweise zu und Ergebnisse von durchge f hrten Verifikationsaktivit ten auf Implementierungsebene Im Folgenden wird sich auf eine Inspektion mit Checklisten als Verifikationsaktivi t t eingeschr nkt Das Dokument K Verifikation umfasst dann 1 eine Checkliste 2 eine Fehlerklassifikation 3 eine Liste der gefundenen Fehler und 4 eine Beschreibung der Fehlerbehebungsstrategien 158 Entwicklung eingebetteter Software mit UML Produkte K Checkliste Die Checkliste unterst tzt das Lesen des zu verifizierenden Komponenten Kodes und erleichtert das Finden von Problemen im Dokument Bei der berpr fung des Komponenten Kode m ssen wie bei der Verifikation der Syst
31. Akzeptanztest modifiziert e Komponenten Kode e K Verifikation e Ausf hrbare Komponente e Ausf hrbares System e UML Entwurf e Komponenten Anforderungen e Verfolgbarkeitsmatrix Entwurf e E Verifikation e E Validation e A Use Cases e Szenarien e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation e A Validation 7 7 Prozess Test im Betrieb Im Prozess Test im Betrieb wird das beim Kunden installierte System durch die regelm ige Verwendung getestet Auftretende Fehlverhalten meldet der Kunde Entwicklung eingebetteter Software mit UML 223 System Validation dem Entwicklungsunternehmen Dort werden sie im Dokument A Validation doku mentiert auf Fehler in der Dokumentation zur ckgef hrt und behoben Mit einem sp teren Release des Systems k nnen die Korrekturen herausgegeben werden In eingebetteten Systemen sind gravierende Fehlverhalten die erst im Prozess Test im Betrieb aufgedeckt werden h ufig sehr teuer Beispielsweise k nnen solche Fehlverhalten mit teuren R ckrufaktionen verbunden sein Abbildung 113 zeigt den Prozess Test im Betrieb mit konsumierenden produzie renden und modifizierenden Produkten O O O Entwurfs Anford rungs 3 ingenieur O O SO EL A AE Valderer Kodierer Kunde Software System u Dokumentation Reale Systemumgebung Software Komponenten Ausf hrbares System Dokumentation Test im
32. Ansteuerung der Aktuatoren zu Sch den in der Systemumgebung f hren z B am Geb ude und am Inventar eines Raumes Zum anderen m ssen die herrschenden Umweltbedingungen in der realen Systemumgebung akzeptiert wer den Umweltbedingungen lassen sich in der Regel nicht vollst ndig beeinflussen Dies erschwert eine berpr fung des Systems gegen die Anforderungen Ein bestimmtes Verhalten des Systems kann nur getestet werden wenn bestimmte Umweltbedingungen gelten beschrieben als Vorbedingung zur Ausf hrung eines Szenario Das Verhalten l sst sich in der realen Umgebung also nur dann pr fen wenn die realen Umweltbedingungen zuf llig mit den im Test geforderten Umweltbedingungen bereinstimmen Der Einsatz eines Simulators der das Verhalten der real existierenden Sensoren und Aktuatoren und der Systemumgebung simuliert beseitigt die Probleme Eine falsche Ansteuerung von Aktuatoren bleibt ohne Folge und bestimmte Umweltbe dingungen lassen sich k nstlich herstellen Au erdem lassen sich Reaktionszeiten in der Umgebung z B das Aufheizen eines Raums k nstlich beschleunigen Entwicklung eingebetteter Software mit UML 213 System Validation Beim Einsatz eines Simulators muss gew hrleistet sein dass die Schnittstelle die dem entwickelten Software Systems angeboten wird mit der Schnittstelle der real existierenden Sensoren und Aktuatoren bereinstimmt Abbildung 110 zeigt einen Ausschnitt aus der Beschreibung des im G
33. Betrieb Ausf hrbarer K Verifikation System Kode Test im Betrieb durchf hren Installiertes System Rework Test im Betrieb Probleml sungs dokumentation Ausf hrbare Komponente ABBILDUNG 115 Verwendete Produkte des Prozesses Test im Betrieb 224 Entwicklung eingebetteter Software mit UML Prozess Test im Betrieb Prozess Test im Betrieb durchf hren Im Prozess Test im Betrieb durchf hren wird das beim Kunden installierte System durch die laufende Verwendung getestet Der Test im Betrieb ist kein Test im her k mmlichen Sinne F r die Durchf hrung werden keine Testbedingungen geschaf fen und es werden keine Tests anhand von Testpl nen durchgef hrt Das System wird beim Kunden laufend verwendet und dadurch getestet W hrend der Verwen dung k nnen Fehlverhalten auftreten die der Kunde dem Entwicklungsunterneh men meldet Das vom System gezeigte und vom Kunden gemeldete Fehlverhalten wird in der Tabelle zur Bewertung der Testergebnisse im Dokument A Validation dokumen tiert Anschlie end werden die beschriebenen Fehlverhalten auf Fehler in der Sys tem Dokumentation zur ckgef hrt Die Fehler werden in der Fehlertabelle im Dokument K Verifikation festgehalten Die Tabelle zur Bewertung der Testergeb nisse wird um Verweise auf die Fehlernummern erweitert Folgende Produkte werden im Prozess Test im Betrieb durchf hren konsumiert e Reale Systemumgeb
34. Case eine informelle Beschreibung Interne Konsistenz der Modelle T Wenn ein Use Case zu einem anderen in Beziehung steht Findet sich die Beziehung auch in den Szena rien die zu dem Use Case geh ren 2 Sind die Szenarien die zum Use Case geh ren in der informellen Beschreibung dokumentiert Konsistenz mit den informellen B Anforderungen Referenzdokumenten 1 Wenn im Use Case ein Aktuator benutzt wird Ist der Aktuator in der Geb udearchitektur beschrieben 2 Let der Akteur des Use Cases in der Geb udearchitektur den informellen B Anforderungen beschrieben 3 Gibt der Use Case das in den B Anforderungen beschriebene Verhalten wider ABBILDUNG 31 Ausschnitt aus der A Checkliste B Anforderungen E Anforderungen Fehlerklassifikation Die aufgedeckten Probleme Fehler werden in Fehlertabellen aufgelistet Dabei wird jedes Problem Fehler einer Fehlerklasse zugeordnet Die Fehlerklassifikation umfasst spezifische Fehlerklassen z B Unvollst ndigkeit oder falsche Informa Entwicklung eingebetteter Software mit UML 59 System Anforderungen bearbeiten tion und unspezifische Fehlerklassen z B Inkonsistenz oder Sonstige Nur wenn ein Fehler keiner spezifischen Fehlerklasse zugeordnet werden kann wird er einer unspezifischen zugeordnet Die Erl uterung der Fehlerklassen mit Beispielen hilft einen existierenden Fehler in eine der vorgegebenen Klassen einzuordnen Abbil dung 32 zeigt zwei m gliche Fehlerklas
35. Entwicklung eines eingebet teten Systems Sie enth lt eine erste abstrakte Beschreibung der erwarteten Sys temfunktionalit t Sie wird vom Kunden erstellt und dient als Basisdokument f r die Entwicklung der informellen B Anforderungen BANJA Problembeschreibung Problem Gefordert ist ein Temperatur und Lichtregelungssystem f r ein Universit tsgeb ude da bei der Regelung der Temperatur nicht automatisch auf einen unterschiedlichen W rmebedarf zu unterschiedli chen Zeiten R cksicht genommen wird Die Folge ist dass R ume auch Nachts bei Nichtbelegung geheizt wer den bei der Regelung des Lichts nicht automatisch auf eine Personenanwesenheit geachtet wird Die Folge ist dass h ufig das Licht in R umen brennt obwohl niemand anwesend ist Die bisherige Klimaregelung ist wegen berh hten Energiebedarfs und aufgrund eines Mangels an Komfort nicht zufriedenstellend Erwartete Systemfunktionalit t Das zu entwickelnde Kontrollsystem soll die Temperatur und Lichtregelung f r eine section innerhalb des Universi t tsgeb udes Geb ude 32 Flur 4 der Universit t Kaiserslautern bernehmen Daf r verf gt diese section ber eine Reihe von Installationen Sensoren und Aktoren Das Kontrollsystem soll f r verschiedene Benutzergruppen ausge legt sein Es wird zwischen einem Hausmeister und Benutzern von Zimmern unterschieden Diese sollen unterschiedli che Funktionalit ten des Systems nutzen k nnen
36. Im angegebenen Testplan soll das System beispielsweise das Licht im Flur anschalten quivalenzklasse LichtStatusFlur on Die quivalenzklassen f r die Eingangs und Ausgangsvariablen entsprechen den konkreten Werten f r den Test weil der Wertebereich jeder Variable nur aus zwei Elementen besteht e Test SS qui J z E Eingangsvariable Ausgangsvariable Aquivalenz konkreter Nummer SS klasse Wert a SysTestl AnwesenheitskontaktImdl offen offen Doorl AnwesenheitskontaktImdl r offen offen 1 Door2 AnwesenheitskontaktImd2 e offen offen Doorl LichtstatusFlur off off AnwesenheitskontaktImdl 2 geschlossen geschlossen Doorl 3 LichtstatusFlur on on ABBILDUNG 36 Ausschnitt aus der Beschreibung eines Testplans zu Szenariol Flurlichtregelung durch Anwesenheit Dokumentation der Testergebnisse A Testergebnisse Das Dokument A Validation erlaubt die Dokumentation der Testergebnisse an der gleichen Stelle an der auch die Testpl ne dokumentiert sind Auf diese Weise k n nen die Testergebnisse mit dem erwartetes Verhalten des Teilsystems oder Systems abgeleitet aus den B Anforderungen leicht miteinander verglichen werden Entwicklung eingebetteter Software mit UML 65 System Anforderungen bearbeiten Die Testergebnisse beschreiben das Verhalten des Teil Systems beim Testdurch lauf Abbildung 37 zeigt eine m gliche Dokumentation der Ergebnisse eines durchge f hrten Tes
37. K LF FNr2 Abfrage der aktuellen Zeit wurde integriert J Aufruf beim Zustands bergang wurde von KERN SwitchOff in SwitchOn ge ndert J ABBILDUNG 85 Ausschnitt aus der Tabelle zur Dokumentation der Fehlerbehebungsstrategien Teilsystem Lichtregelung Flur Entwicklungsrichtlinien Die Entwicklungsrichtlinien bestehen aus den Kode Ableitungsrichtlinien und den Programmierrichtlinien Kode Ableitungsrichtlinien Die Kode Ableitungsrichtlinien leiten den Kodierer an die Information der Zustandsdiagramme aus dem UML Entwurf zu implementieren Der Kodierer wird dabei Schritt f r Schritt bei der Umsetzung aller Teile eines Zustandsdiagramms angeleitet Zum besseren Verst ndnis der Richtlinien werden Beispiele gegeben Bei der Implementierung unter Verwendung der Richtlinien erfolgt eine Schachte lung von Methoden analog zum Aufbau der Zustandsdiagramme Jeder Superstate sowie die parallelen Substates werden durch eine eigene Methode realisiert Die Hierarchie der Zustandsdiagramme und die Trennung von parallelen Substates als voneinander unabh ngige Teile bleiben in der Implementierung sichtbar Durch die Vorgaben und Empfehlungen soll insbesondere die Verfolgbarkeit vom Entwurf zum Kode gew hrleistet werden Andere Ziele wie beispielsweise eine effiziente Implementierung der Komponenten haben niedrigere Priorit t Wenn derartige Kode Ableitungsrichtlinien an die konkreten Charakteristika eines Software Systems angepa
38. Klasse Schedu ledFct abgeleitet 3 Wenn es sich bei der Klasse um eine Sensor oder Aktuatorklasse handelt Wurde die Klasse von der Klasse Portbaustein abgeleitet 4 Wenn ein Attribut einer Klasse vom Benutzer gesetzt werden kann Kann der Wert vom Control Panel an die Klasse weitergeleitet werden durch Assoziationen und oder Durchreichmethoden Existiert f r jede Klasse mindestens ein Konstruktor 6 Wenn durch ein Objekt Speicherplatz allokiert wird z B ein Objekt legt ein anderes an Gibt es einen Destruktor f r das Objekt der den Speicherplatz beim L schen des Objekts wieder freigibt Ka Interne Konsistenz der Modelle 1 Wenn die Klasse dynamisches Verhalten besitzt Existiert ein Zustandsdiagramm f r die Klasse 2 Werden die Assoziationen der Klasse zu anderen Klassen im Zustandsdiagramm verwendet Konsistenz zum Klassendiagramm der E Anforderungen 1 Existiert zu jeder Klasse jeder Methode und jedem Attribut aus der Analyse eine Repr sentation im Ent wurf 2 L sst sich jede Klasse im Entwurf aus den E Anforderungen oder aus Entwurfsentscheidungen heraus ableiten ABBILDUNG 62 Ausschnitt aus der E Checkliste UML Entwurf Komponenten Anforderungen Fehlerklassifikation Die aufgedeckten Fehler werden in einer Fehlertabelle aufgelistet Dabei wird jeder Fehler einer Fehlerklasse zugeordnet Die Fehlerklassifikation ist identisch zur Fehlerklassifikation bei der Inspektion der E Anforderungen siehe Abbi
39. Objektorientiert Der Entwicklungsprozess verwendet zur Modellierung objektorientierte Konzepte Dies sind Datenabstraktion und Kapselung Das Konzept basiert auf dem des abstrakten Datentyps Zusammengeh rige Daten Attribute und Funktionen Methoden wer den in Objekten gekapselt Die Methoden operieren auf den Attributen die den Zustand eines Objekts bilden Anderen Objekten ist nur die Dienstschnittstelle die von den ffentlichen Methoden eines Objekts gebildet wird bekannt Klassen Eine Menge von Objekten gleichen Verhaltens und gleicher Struktur wird durch die Abstraktion Klasse beschrieben In einem objektorientierten Pro gramm existieren Klassen nur im Programmtext und Objekte als Instanzen dieser Klassen nur zur Laufzeit Vererbung Attribute und Methoden werden von der bergeordneten Klasse an die entsprechenden Unterklassen vererbt Die Unterklassen k nnen um weitere Funkti onalit t erg nzt werden Kunde Lieferant Beziehung Zu Erf llung einer Methode ist ein Objekt h ufig auf andere angewiesen Das Kunden Objekt benutzt dann die ben tigten Methoden der Lieferanten Objekte Durch die Verwendung objektorientierter Konzepte soll die Einhaltung von Modu larisierungsprinzipien wie dem Kopplungs und Geheimnisprinzip erleichtert werden Eine angemessene Modularisierung unterst tzt wiederrum die Verst nd lichkeit nderbarkeit und Wiederverwendbarkeit eines Systems Die objektorien tierten Konzepte werden
40. Packagediagrammen kann es im Entwurf weitere Teilsysteme geben die aus den Entwurfsentscheidungen resultieren und sich bei spielsweise mit Implementierungsdetails besch ftigen z B mit der Realisierung der Zeit Entwicklung eingebetteter Software mit UML 99 System Entwurf bearbeiten Jedes Package wird mit einer kurzen Beschreibung erl utert Abbildung 38 zeigt ein E Packagediagramm f r das Geb udeautomationssystem E Packagediagramm Zu den sechs Teilsystemen aus den E Anforderungen siehe Abbildung 23 Teil systeme eines Geb udeautomationssystems und Erl uterung des Package Lichtre gelungFlur auf Seite 48 kommen zwei weitere Teilsysteme Zeit und Scheduling hinzu Das Teilsystem Zeit umfasst alle Klassen die an der Realisie rung der Zeitfunktionalit t beteiligt sind Das Teilsystem Scheduling umfasst alle Klassen die an der Realisierung des Schedulingmechanismusses beteiligt sind 100 Entwicklung eingebetteter Software mit UML Produkte Benutzungsschnittstelle Hardware Wrappe Package LichtregelungFlur Dieses Package enth lt Klassen die die Regelung des Lichts in den Flurabschnitten bernehmen Werte die daf r ben tigt werden werden mit Hilfe der Klassen des Packages Benutzungsschnittstelle gesetzt ABBILDUNG 52 E Packagediagramm f r ein Geb udeautomationssystem E Klassendiagramme Pro Teilsystem existiert im UML Entwurf ein Klassendiagramm welch
41. Quellkode bearbeiten wird aus den E Klassendiagrammen den Class Tables und den E Zustands und Aktivit tsdiagrammen des UML Entwurfs sowie aus den Komponenten Anforderungen der Komponenten Kode entwickelt Die Implementierung kann f r jede Komponente unabh ngig durchgef hrt werden Die Entwicklungsrichtlinien leiten den Implementierungsprozess an und f hren zu einer einheitlichen Gestaltung des Komponenten Kodes Nach der fertiggestellten Implementierung wird der Komponenten Kode bersetzt Der Komponenten Kode wird gegen den UML Entwurf die Komponenten Anforderungen und gegen die Entwicklungsrichtlinien verifiziert Die Ergebnisse der Verifikation werden im Dokument K Verifikation dokumentiert Abbildung 92 zeigt den Prozess Quellkode bearbeiten mit konsumierenden produ zierenden und modifizierenden Produkten Folgende Produkte werden im Prozess Quellkode bearbeiten konsumiert e Entwicklungsrichtlinien Das Dokument beschreibt Richtlinien f r die Imple mentierung von Komponenten Folgende Produkte werden modifiziert e Komponenten Kode Das Dokument beschreibt den Quellkode der einzelnen Komponenten e Ausf hrbarer Komponenten Kode Dieses Produkt beinhaltet den bersetzten Komponenten Kode e K Verifikation Das Dokument beschreibt Anleitungen f r und Ergebnisse von Verifikationsaktivit ten auf Implementierungsebene e UML Entwurf e Verfolgbarkeitsmatrix Entwurf e Komponenten Anforderungen e E Verifikation e E
42. Standards Guidelines and Examples on System and Software Requirements Engineering IEEE Computer Society Press 1990 2 IEEE Std 1076 1993 IEEE 1994 3 Richard H Thayer Merlin Dorfman Software Requirements Engineering Second Edition Institute of Electrical amp Electronic Engineering 1999 Entwicklung eingebetteter Software mit UML 35 Projekt initialisieren 36 Entwicklung eingebetteter Software mit UML KAPITEL 3 System Anforderungen bearbeiten Ziel des Prozesses System Anforderungen bearbeiten ist die Ermittlung und umfas sende Beschreibung von Anforderungen und Beschr nkungen denen das zu entwi ckelnde eingebettete System gen gen soll Diese werden in der Probleml sungsdokumentation fixiert Im Laufe des Prozesses sollen die Benutzer Kunden und die Entwickler ein gemeinsames und m glichst genaues Verst ndnis des gew nschten Systems bekommen Daf r m ssen sich die Entwickler in das Anwendungsgebiet und die Benutzer in M glichkeiten der Informationstechnik ein arbeiten Abbildung 18 gibt einen berblick ber die verwendeten Produkte im Prozess Sys tem Anforderungen bearbeiten Folgende Produkte werden konsumiert e Dom nenwissen Dieses Dokument beschreibt typische Eigenschaften und Cha rakteristika der Anwendungsdom ne Es umfasst insbesondere eine Beschrei bung der Systemumgebung e Namenskonventionen Dieses Dokument beinhaltet Konventionen f r die Wahl von Bezeichnern
43. Stub Objekts LightControlUnit lightControlUnitPtr new LightControlUnit lightControllerPtr cout lt lt endl cout lt lt Schritt 2 Aufruf der Methode setLightControlUnit lt lt endl lt lt LightControlUnit lt lt endl lightControllerPtr gt setLightControlUnit lightControlUnitPtr cout lt lt endl cout lt lt Schritt 3 Aufruf der Methode callBack lt lt endl lightControllerPtr gt callBack cout lt lt endl ABBILDUNG 88 Ausschnitt aus einem Test Treiber zum Test der Komponente LightController Komponententest Stubs Die Komponententest Stubs sind Dummies von Klassen die durch die zu testende Klasse aufgerufen werden Die Funktionalit t Methoden R ckgabewerte und Ausgaben die die Komponententest Stubs bieten m ssen sind in den Testpl nen zum Komponententest siehe Kapitel E Validation dokumentiert Relevante Test ergebnisse werden von den Komponententest Stubs nach cout geschrieben Entwicklung eingebetteter Software mit UML 167 System Komponenten bearbeiten Abbildung 89 zeigt einen Ausschnitt aus einem Test Stub f r die Klasse Light Controller des Teilsystems LichtRegelungFlur aus dem Geb udeautomations system NNUA Komponententest Stub class Light public Actuator stp class members public A Operation SwitchOn A Description A Diese Methode schaltet das Licht an void SwitchOn void counterSwitchOn cout
44. System Anforderungen verifizieren System umgebung System Anforderungen Referenz Dokumente E Anforderungen Review vorbereiten Reviewsitzung System Anforderungen Verfolgbarkeitsmatrix Anforderungen Rework A Verifikation System Anforderungen ABBILDUNG 45 Verwendete Produkte des Prozesses System Anforderungen verifizieren 84 Entwicklung eingebetteter Software mit UML Prozess System Anforderungen verifizieren Folgende Produkte werden im Prozess System Anforderungen verifizieren konsu miert e Problembeschreibung e Systemumgebung e Referenz Dokumente e Informelle B Anforderungen Teilprodukt der B Anforderungen Folgende Produkte werden modifiziert e A Use Cases e Szenarien e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation Prozess System Anforderungen Review vorbereiten Im Prozess System Anforderungen Review vorbereiten sollen Probleme in den A Use Cases den Szenarien den E Anforderungen und in der Verfolgbarkeitsmatrix Anforderungen aufgedeckt und in einer Fehlertabelle dokumentiert werden Hierzu werden die Dokumente mit Hilfe einer Checkliste berpr ft die im Dokument A Verifikation dokumentiert ist Werden Fragen in der Checkliste mit Nein beant wortet dann k nnte es sich um einen Fehler handeln Gelesen wird von den Verifi zierern Ergebnis dieses Prozesses
45. System Entwurf bearbeiten 4 1 Prozessverfeinerung 42 Produkte Entwurfsentscheidungen UML Entwurf Verfolgbarkeitsmatrix Entwurf Komponenten Anforderungen E Verifikation E Validation 30 31 32 32 34 35 37 38 40 41 46 57 58 62 67 68 69 70 74 81 83 87 89 91 93 95 96 98 110 111 114 119 iv Entwicklung eingebetteter Software mit UML Inhalt KAPITEL 5 KAPITEL 6 4 3 4 4 4 5 4 6 4 7 4 8 4 9 4 10 4 11 Namenskonventionen Rollen Kontrollfluss Prozess Entwurfsentscheidungen erstellen Prozess UML Entwurf bearbeiten Prozess Komponenten Anforderungen erstellen Prozess Verfolgbarkeitsmatrix Entwurf bearbeiten Prozess System Entwurf verifizieren Prozess Komponenten Testf lle bearbeiten Weiterf hrende Literatur System Komponenten bearbeiten 5 1 5 2 3 3 5 4 5 5 5 6 3 4 Prozessverfeinerung Produkte Komponenten Kode K Verifikation Entwicklungsrichtlinien Ausf hrbare Komponente Rollen Kontrollfluss Prozess Quellkode bearbeiten Prozess Ausf hrbare Komponente bearbeiten Weiterf hrende Literatur System Integration 6 1 6 2 6 3 6 4 6 5 6 6 Prozessverfeinerung Produkte Ausf hrbares System Rollen Kontrollfluss Prozess Integriere Teilsystem Prozess Integrationstest 126 126 128 129 130 139 141 142 146 148 151 153 154 155 158 162 166 169 170 171
46. System verteilt werden So minimiert man die Auswirkung von nderungen auf das System Neben den informellen nicht funktionalen B Anforderungen liefert die Systemum gebung Einschr nkungen f r die Implementierung Zum Beispiel macht der ver wendete Zielrechner Einschr nkungen hinsichtlich der Parallelit t z B wenn das Betriebssystem keine Parallelit t erlaubt und Effizienz z B das System muss mit einem bestimmten Speicher auskommen Eventuell stellt der Qualit tsmanager Komponenten bereit die wiederverwendet werden k nnen Durch die Wiederverwendung von Komponenten wird die Imple mentierung ebenfalls eingeschr nkt Die gesammelten Entwurfsentscheidungen werden dokumentiert Abbildung 72 zeigt die verwendeten Produkte im Prozess Entwurfsentscheidungen erstellen Entwicklung eingebetteter Software mit UML 129 System Entwurf bearbeiten Dom nenwissen System O umgebung Software System Entwurfs Dokumentation ingenieur H U Entwurfsentscheidungen erstellen Entwurfs entscheidungen B Anforderungen Informelle B Anforderungen ABBILDUNG 72 Verwendete Produkte des Prozesses Entwurfsentscheidungen erstellen Folgende Produkte werden im Prozess Entwurfsentscheidungen erstellen konsu miert e Systemumgebung e Informelle B Anforderungen Folgendes Produkt wird produziert e Entwurfsentscheidungen 4 6 Prozess UML Entwurf bearbeiten Im Prozess UM
47. Testergebnisse Die beim Test entdeckten Fehlverhalten lassen sich auf Fehler im Kode zur ckf h ren und werden in der K Fehlertabelle im Dokument K Verifikation dokumentiert In die Tabelle zur Bewertung der Testergebnisse wird ein Verweis auf die Fehler nummern erg nzt Entwicklung eingebetteter Software mit UML 125 System Entwurf bearbeiten Namenskonventionen Die Namenskonventionen im Prozess System Entwurf bearbeiten erweitern die Namenskonventionen aus dem Prozess System Anforderungen bearbeiten Sie gew hrleisten die Namensgleichheit zu sp teren Entwicklungsprodukten und erleichtern eine Abstimmung im Team Abbildung 69 zeigt m gliche Namenskonventionen f r den Prozess System Ent wurf bearbeiten OT Namenskonventionen e Konventionen aus Prozess System Anforderungen bearbeiten e Konstanten beginnen mit einem c Verwendete Typen werden als solche gekennzeichnet Sie erhalten als Endung Type e Zust nde beginnen mit einem z ABBILDUNG 69 Namenskonventionen f r den Prozess System Entwurf bearbeiten 4 3 Rollen Im Prozess System Entwurf bearbeiten sind die Rollen Entwurfsingenieur Verifi zierer Validierer Anforderungsingenieur und Qualit tsmanager involviert Ihre Verantwortlichkeiten f r die Produkte ergeben sich aus Abbildung 70 Folgende wesentliche T tigkeiten sind im Prozess System Entwurf erstellen mit den Rollen verbunden es Entwurfsingenieur
48. UML Entwurf umfasst folgende UML Diagramme 1 Packagediagramme 2 Klassendiagramme 3 Klassenbeschreibungen Class Tables 4 ein Use Case Diagramm E Use Cases 5 Sequenzdiagramme 6 Kollaborationsdiagramme 7 Zustandsdiagramme und 8 Aktivit tsdiagramme Unterschiede zur Analyse Im Dokument Unterschiede zur Analyse werden Unterschiede zwischen den A Klassendiagrammen aus den E Anforderungen und den E Klassendiagrammen aus dem UML Entwurf dokumentiert Dabei werden nderungen f r jede Klasse aus dem UML Entwurf aufgelistet Mit Hilfe des Dokuments ist es m glich die Auswirkungen der Entwurfsentschei dungen auf die A Klassendiagramme f r jede Klasse nachzuvollziehen Die Struk tur der E Klassendiagramme Klassen und deren Beziehungen wird mit diesem 1 Da Use Cases auch auf Anforderungsebene auftreten k nnen werden die Use Cases auf Entwurfsebene im Folgenden auch als E Use Cases bezeichnet Dies gilt analog auch f r weitere Bezeichner mit dem Pr fix E 98 Entwicklung eingebetteter Software mit UML Produkte Dokument begr ndet Das Dokument erleichtert einerseits eine berpr fung der Konsistenz zwischen den E und den A Klassendiagrammen da Unterschiede begr ndet werden m ssen Andererseits unterst tzt es eine Propagierung von nderungen an den A Klassendiagrammen zu den E Klassendiagrammen Das Beispiel siehe Abbildung 51 zeigt dokumentierte nderungen an den Klas sen LightCont
49. Validation e A Use Cases e Szenarien e E Anforderungen Entwicklung eingebetteter Software mit UML 171 System Komponenten bearbeiten e Verfolgbarkeitsmatrix Anforderungen e A Verifikation e A Validation 172 Entwicklung eingebetteter Software mit UML Prozess Quellkode bearbeiten Verifizierer Kodierer Software System O O Dokumentation E 7 U HU Entwurfs Anforderungs UML Entwurf ingenieur ingenieur U HU U Class Tables Quellkode bearbeiten Komponenten Kode E Klassendiagramme bearbeiten HU Komponenten Kode E Zustands verifizieren diagramme E Aktivit ts diagramme Komponenten Anforderungen Probleml sungs a dokumentation Entwicklungsrichtlinien Kode Ableitungs richtlinien Programmier richtlinien Software Komponenten Dokumentation Komponenten Kode K Verifikation Ausf hrbare Komponente Komponententest Rahmen Ausf hrbarer Komponenten Kode ABBILDUNG 92 Verwendete Produkte des Prozesses Quellkode bearbeiten Entwicklung eingebetteter Software mit UML 173 System Komponenten bearbeiten Prozess Komponenten Kode bearbeiten Im Prozess Komponenten Kode bearbeiten werden die Komponenten aus dem UML Entwurf und den Komponenten Anforderungen implementiert Die Information aus den Klassendiagrammen und den Class Tables l sst sich mit Hilfe von CASE Werkzeugen meist automatisch in den K
50. Verfeinerungshierarchie angegeben und beschrieben welche Inhalte in den Produkten enthalten sind Abbildung 1 zeigt die grafische Darstellung von Produkten anhand eines Beispiels Hier ist das Produkt Probleml sungsdokumentation in drei Teilprodukte Problembeschreibung Anfor Entwicklung eingebetteter Software mit UML Prozessbeschreibung derungen und Validationsdokument verfeinert Das kleine Quadrat im Produkt Anforderungen deutet an dass dieses Produkt wiederum aus einer Menge von Teil produkten besteht Im Anhang ist eine bersicht ber die gesamte Produkthierar chie enthalten Produkte lassen sich noch weiter strukturieren hinsichtlich ihrer inhaltlichen Gliederung Eine solche inhaltliche Strukturierung ist oftmals feingra nularer als die Produktverfeinerungshierarchie Sowohl die Produkthierarchie als auch die inhaltliche Strukturierung einzelner Teilprodukte werden in diesem Bericht bersichtlich mit UML Packagediagrammen dargestellt In diesem Bericht gibt es f r die Inhalte der einzelnen Produkte ausf hrliche textuelle Erl uterungen mit Beispielen Verfeinerungshierarchie Probleml sungs dokumentation Inhaltliche Strukturierung Problem beschreibung Pa Anforderungen 5 _ Testverfahren 2 E Testpl ne Testergebnisse Validations dokument ABBILDUNG 1 Repr sentation von Produkten Ergebnisbewertung Einige Produkte z B Kodekomponente Teilsystem etc k nnen in m
51. bearbeiten 79 B B Anforderungen 26 41 B Anforderungen bearbeiten 70 Baseline 2 Entwicklung eingebetteter Software mit UML 239 240 C Class Tables 103 Class Tables bearbeiten 135 D Data Dictionary 50 Data Dictionary bearbeiten 78 Dom nenexperte 30 69 Dom nenwissen 28 Dom nenwissen bearbeiten 32 E E Aktivit tsdiagramme 108 E Aktivit tsdiagramme bearbeiten 138 E Anforderungen 46 E Anforderungen bearbeiten 74 E Checkliste 115 E Ergebnisbewertung 125 E Fehlerbehebungsstrategien 118 E Fehlertabellen 116 E Klassendiagramme 101 E Klassendiagramme bearbeiten 134 E Kollaborationsdiagramme 106 E Kollaborationsdiagramme bearbeiten 137 Entwicklungsrichtlinien 162 Entwurfsentscheidungen 96 Entwurfsentscheidungen erstellen 129 Entwurfsingenieur 169 199 215 E Packagediagramme 99 E Sequenzdiagramme 105 E Sequenzdiagramme bearbeiten 136 E Testergebnisse 123 E Testpl ne 120 E Testverfahren 119 E Use Cases 104 E Use Cases bearbeiten 134 E Validation 119 E Verifikation 114 E Zustandsdiagramme 107 E Zustandsdiagramme bearbeiten 137 F Fehlerklassifikation 59 116 159 I Informelle B Anforderungen 26 Informelle B Anforderungen bearbeiten 34 Installiere System 221 Installiertes System 198 Integrationstest 204 Integriere Teilsystem 201 K K Checkliste 159 K Fehlerbehebungsstrategien 161 K Fehlertabellen 160 Kode Ableitungsrichtlinien 162 Kodierer 169 199 215 Komponente 91 92 93 Komponenten Anfo
52. der Ausf hrbaren Teilsys teme ben tigt werden Die Makefiles erleichtern das Zusammenbinden der Kompo nenten zu Ausf hrbaren Teilsystemen Im Prozess System Integration werden die Ausf hrbaren Teilsysteme au erdem getestet Entdeckte Fehlverhalten werden auf Fehler in der Dokumentation zur ckgef hrt und behoben 188 Entwicklung eingebetteter Software mit UML Prozessverfeinerung Die System Integration erfolgt iterativ siehe Abbildung 98 Im ersten Iterations schritt werden die Ausf hrbaren Komponenten zu Ausf hrbaren Teilsystemen inte griertt und die Teilsysteme werden getestet In den darauffolgenden Iterationsschritten werden diese Teilsysteme zu umfassenderen Ausf hrbaren Teil systemen integriert die wiederum getestet werden In einem letztem Iterations schritt werden die verbleibenden Teilsysteme zu einem ausf hrbaren Gesamtsystem integriert Letzteres wird nicht mehr im Rahmen des Prozesses Sys tem Integration getestet sondern in einem sp teren Prozess System Validation Mit den verschiedenen Iterationsschritten variieren die Produktfl sse in Abbildung 97 Daher ist an den Produktflussbeziehungen die variieren k nnen jeweils gekennzeichnet in welchen Iterationen sie g ltig sind Beispielsweise produziert der Teilprozess Ausf hrbares Teilsystem erstellen den Ausf hrbaren Teilsystem Kode in der 1 bis zur n 1 Iteration In der n Iteration d h der letzten Iteration wird dann der Ausf hrbare Syste
53. der Umge bung in der das Software System eingesetzt werden soll z B durch das verwendete Betriebssystem oder aus Qualit tsanforderungen an das zu entwi ckelnde Software System z B Effizienz oder Portabilit t Die Wiederverwen dung von Komponenten kann ebenfalls zu Entwurfsentscheidungen f hren Die Abbildung 50 zeigt Entwurfsentscheidungen f r das Geb udeautomationssys tem die aus der Umgebung und aus der Wiederverwendung von Komponenten resultieren Entwurfsentscheidungen Die Entwurfsentscheidungen sind zur leichteren Referenzierung durchnummeriert Die Entscheidungen EE1 und EE2 lassen sich auf Eigenschaften der Systemumge bung zur ckf hren EE3 ergibt sich aus der Wiederverwendung einer Komponente EE Beschreibung der Entwurfsentscheidung Das Zielsystem ist ein zentraler Steuerungsrechner mit einem Portbaustein ber den EEI e alle Sensoren abgefragt e alle Aktuatoren angesteuert werden k nnen EE2 Parallelit t wird durch Verwendung eines einfachen Schedulers simuliert EE3 Die Zeit wird durch eine wiederverwendbare Komponente Timer realisiert ABBILDUNG 50 Ausschnitt aus den Entwurfsentscheidungen f r ein Geb udeautomationssystem Neben diesen Entwurfsentscheidungen gibt es noch eine Reihe allgemeiner Ent wurfskriterien die bei der berarbeitung und Verfeinerung des UML Entwurfs 96 Entwicklung eingebetteter Software mit UML Produkte eine Rolle spiele
54. die Ver st ndlichkeit des Systems Zum Entwurf hin kann ber ein Streichen dieser Klassen aus Gr nden der Effizienz des Systems nachgedacht werden Hauptauf gabe der A Klassendiagramme ist das Verst ndnis des zu entwickelnden Systems 48 Entwicklung eingebetteter Software mit UML Produkte zu erleichtern Sensoren und Aktuatoren werden durch kontrollierende Klassen gekapselt Bei Sensoren bernimmt die kontrollierende Klasse st ndige Abfragen Bei Aktuatoren l st die kontrollierende Klasse Konflikte zwischen verschiedenen Funktionalit ten z B die Temperaturregelung will die Jalousien schlie en und die Lichtregelung will sie ffnen Komplexe Regelungsaufgaben lassen sich durch Hierarchien von Regelungsklassen vereinfachen Das Klassendiagramm wird mit einer kurzen Beschreibung versehen Abbildung 24 zeigt einen Ausschnitt aus dem Klassendiagramm des Teilsystems LichtregelungFlur des Geb udeautomationssystems OO A Klassendiagramm Die Klassen spiegeln zum Teil die statische Geb udearchitektur wieder z B besteht eine Section aus HallwaySections F r Sensoren und Aktuatoren wurden Klassen gebildet z B Contact oder Light Die Sensoren und Aktuatoren werden durch kontrollierende Klassen gekapselt z B PresenceController oder LightCont roller Au erdem wurde im Beispiel eine Hierarchie von Kontrolleinheiten gebil det Beispielsweise ist der PRHallwayLightController der LightControlUnit unt
55. einer Vielzahl von Komponenten besteht ist eine Integration aller Komponenten in einem Schritt meist nicht sinnvoll Bei einer Inte gration in einem Schritt lassen sich beispielsweise Ursachen von Fehlverhalten des Systems nur sehr schwer lokalisieren Aus diesem Grund sollte ein komplexes Software System schrittweise integriert und getestet werden Daf r werden Aus f hrbare Teilsysteme gebildet und deren Verhalten getestet Teilsysteme sind nur ausf hrbar wenn Abh ngigkeiten zu Komponenten aus anderen Teilsystemen als Treiber und Stubs realisiert werden Die Funktionalit t der Test Rahmen d h der Teilsystemtest Stubs und Treiber wird aus den Testpl nen zum Test des Systems abgeleitet Die Teilsystem Makefiles unterst tzen das Zusammenbinden des ber setzten Komponenten Kodes Ausf hrbarer Komponenten Kode zu ausf hrbaren zusammengesetzten Produkten 192 Entwicklung eingebetteter Software mit UML Produkte Ausf hrbares Teilsystem Das Ausf hrbare Teilsystem umfasst Produkte die zur Ausf hrung von Teilsyste men notwendig sind Dies sind Teilsystemtest Rahmen Teilsystem Makefiles und der ausf hrbare Teilsystem Kode Teilsystemtest Rahmen Der Teilsystemtest Rahmen beinhaltet den Quellkode der Treiber und Stubs die zum Test des Verhaltens der Teilsysteme ben tigt werden Die Abh ngigkeiten eines Teilsystems nach au en sind im UML Entwurf beschrieben Diese Abh n gigkeiten werden durch Treiber und Stubs
56. enterFMLightControl das erste Mal aufgerufen wird oder nicht bool first_try true Starten der Simulation durch Starten des Schedulers S start SystemTime getActualTime amp CurrentTime while CurrentTime toDuration 60 lt timeDuration_TestCase TestCase Aktuelle Zeit ermitteln SystemTime getActualTime amp CurrentTime switch TestCase case 6 if Time toDuration 60 gt testCase6_pointInTime_fMLightControl amp amp first_try true A Der Hausmeister gibt ueber das ControlPanelFM das Kommando das WFlurlicht fuer den Flurabschnitt 1 einzuschalten cout lt lt Der Hausmeister versucht ueber lt lt das ControlPanelFm das Licht einzuschalten n HousePtr gt enterFMLightControl cLightOn 1 A Der HousePtr gt enterFmLightControl Aufruf soll nur einmal aufgerufen werden first_try false break ABBILDUNG 100 Ausschnitt aus einem Teilsystemtest Treiber 194 Entwicklung eingebetteter Software mit UML Produkte Teilsystemtest Stub Die Test Stubs sind Dummies f r Klassen die durch das zu testende Teilsystem aufgerufen werden Die Methoden die die Test Stubs zur Verf gung stellen m s sen k nnen dem UML Entwurf entnommen werden Alle Methoden die durch das zu testende Teilsystem aufgerufen werden m ssen durch Stubs simuliert werden Die Funktionalit t der Teilsystemtest Stubs d h R ckgabewerte und Ausgaben werden durch die Testpl ne zum Systemtest
57. f r die andere Rollen verantwortlich sind Eigenverantwortlich ist der Qualit tsmanager hier f r das Produkt Namenskonventionen D O O O O o Kunde EE II U O UO Anforderungs Verifizierer Validierer Dom nen Qualit ts Ingenieur experte manager verantwortlich f r i i verantwortlich f r verantwortlich verantwortlich verantwortlich verantwortlich Z f r f r f r f r Son B S Verfolgbarkeitsmatrix Zen hi d EE Anforderungen Validation 2 konventionen S A Verifikation nen Informelle E o pemanan a B Anforderungen H Anforderungen wisse ABBILDUNG 40 Ressourcen und Produkte des Prozesses System Anforderungen bearbeiten D I 3 4 Kontrollfluss Die Reihenfolge der Bearbeitung der Teilprozesse ist in Form eines Pr zedenzgra phen in Abbildung 41 dargestellt Entwicklung eingebetteter Software mit UML 69 System Anforderungen bearbeiten B Anforderungen E Anforderungen bearbeiten bearbeiten Verfolgbarkeitsmatrix Anforderungen bearbeiten O O Anforderungs Kunde ingenieur C O O System Anforderungen verifizieren VerifiziererAnforderungs Kunde ingenieur O Testf lle EJ bearbeiten Validierer ABBILDUNG 41 Kontrollfluss f r den Prozess System Anforderungen bearbeiten 3 5 Prozess B Anforderungen bearbeiten Im Prozess B Anforderungen bearbeiten werden aus der Problembeschreibung den informellen tabellarischen B Anforderungen und
58. in der Probleml sungsdokumentation Entwicklung eingebetteter Software mit UML 37 System Anforderungen bearbeiten Folgendes Produkt wird im Prozess System Anforderungen bearbeiten modifiziert e Probleml sungsdokumentation Dieses Dokument umfasst neben einer Pro blembeschreibung eine Beschreibung der Anforderungen aus Sicht des Benut zers Kunden und eine Beschreibung der Anforderungen aus Sicht der Entwickler Au erdem umfasst das Dokument eine Verfolgbarkeitsmatrix mit deren Hilfe Zusammenh nge innerhalb der System Anforderungen explizit gemacht werden Des Weiteren enth lt die Probleml sungsdokumentation Dokumente zu Verifikationsaktivit ten auf System Anforderungsebene z B eine Fehlerklassifikation eine Checkliste zur Inspektion der System Anforde rungen Fehlertabellen zur Dokumentation gefundener Fehler und Fehlerursa chen und Dokumente zu Validationsaktivit ten z B Testpl ne Fehlertabellen zur Dokumentation gefundener Fehlverhalten Fehler und Fehlerursachen System Anforderungen H Probleml sungs bearbeiten dokumentation Namens konventionen ABBILDUNG 18 Verwendete Produkte des Prozesses System Anforderungen bearbeiten 3 1 Prozessverfeinerung Der Prozess System Anforderungen bearbeiten unterteilt sich in f nf verschiedene Teilprozesse siehe Abbildung 19 Im Prozess B Anforderungen bearbeiten wer den die Anforderungen aus Benutzersicht die sog B enutzer Anforderung
59. ist Let ein Zustand vom Typ OR so wird f r ihn ein Attribut definiert Dieses stellt einen Aufz hlungstyp enum dar dessen Werte durch die m glichen Substates gegeben sind Ist der Zustand vom Typ AND so erh lt er kein eigenes Attribut F r jeden seiner parallelen Substates wird ein Attribut definiert Zust nde vom Typ BASIC finden sich als Attributwerte ihres Superstates wieder Bemerkung Da eine geschachtelte Definition von Aufz hlungstypen nicht m glich ist wurde hier auf die Darstellung der zusam mengesetzten Zustandskonfiguration durch mehrere Attribute ausgewichen Da C f r die Werte einer Aufz hlung Konstanten definiert ist auf die Eindeutigkeit der Attributwerte zu achten Empfehlungen Attributbezeichnern sollte state vorangestellt werden Um Attributwerte eindeutig zu machen sollten sinnvolle Erg nzungen der Bezeichner durch Teile des Namens des Superstates gemacht werden Beispiel Im Ampelbeispiel ergeben sich folgende Attribute A Root Zustand Ampel ist vom Typ OR gt 1 Attribut enum cBlinkend cNormalBetrieb stateAmpel A Normalbetrieb ist vom Typ OR gt 1 Attribut enum cOwGruen cNsGruen stateNormalbetrieb A OWGruen ist vom Typ AND gt 2 Attribute f r die 2 Substates enum cNsBereit cNsSchuss stateKameraNS enum cNsKeinAuto cNsEinAuto cNsZweiAutos stateZaehlerNS NSGruen ist vom Typ AND gt 2 Attribute f r die 2 Substates enum cOwBereit cOwSchuss sta
60. ist eine Liste mit Problemen im Dokument d h m gli chen Fehlern Jeder potentielle Fehler ist dabei einer Fehlerklasse zuzuordnen Die potentielle Fehlerliste wird im Dokument A Verifikation dokumentiert Im Prozess System Anforderungen Review vorbereiten werden folgende Produkte konsumiert e Problembeschreibung e Systemumgebung e Referenz Dokumente e B Anforderungen e E Anforderungen Entwicklung eingebetteter Software mit UML 85 System Anforderungen bearbeiten e Verfolgbarkeitsmatrix Anforderungen Folgendes Produkt wird modifiziert e A Verifikation Prozess Reviewsitzung System Anforderungen Im Prozess Reviewsitzung System Anforderungen werden die beim Lesen gefunde nen Fehler besprochen An der Inspektionssitzung nehmen Anforderungsingeni eure und Verifizierer teil Die Aufgabe der Verifizierer ist es nicht die erkannten Fehler zu l sen sondern lediglich diese w hrend der Sitzung aufzuzeigen Die Verifizierer f hren durch die Liste der potentiellen Fehler Ergebnis der Inspekti onssitzung ist eine berarbeitete Fehlerliste die im Dokument A Verifikation fest gehalten wird Im Prozess System Anforderungen Review vorbereiten werden folgende Produkte konsumiert e Problembeschreibung e Systemumgebung e Referenz Dokumente e B Anforderungen e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen Folgendes Produkt wird modifiziert e A Verifikation Prozess Rework Syst
61. k nnen z B das Aufheizen des Raumes dauert eine Zeitspanne t die sich nicht verk rzen l sst Diese Beschr nkungen m ssen beim Test in der realen Umgebung akzeptiert werden und f hren dazu dass bestimmte Systemverhalten nicht getestet werden k nnen weil sich bestimmte Umweltbedingungen nicht herstellen lassen z B l sst sich im Sommer die Sys temreaktion auf eine Raumtemperatur unter 4 Grad nur selten testen 214 Entwicklung eingebetteter Software mit UML Rollen 7 3 Rollen Im Prozess System Validation sind im wesentlichen die Rollen Validierer Kunde Anforderungsingenieur Entwurfsingenieur Kodierer und Systemintegrationsinge nieur involviert Die Verantwortlichkeiten f r die Produkte ergeben sich aus Abbil dung 111 Folgende wesentliche T tigkeiten sind im Prozess System Validation mit den Rollen verbunden Validierer Die Aufgabe des Validierers ist es den System und Akzeptanztest durchzuf hren und die Ergebnisse zu dokumentieren Beim Test im Betrieb sind die vom Kunden entdeckten Fehlverhalten zu dokumentieren Des Weiteren sind jeweils Ma nahmen zur Fehlerbehebung einzuleiten Dar ber hinaus ist der Validierer verantwortlich f r die Bereitstellung eines Simulators Kunde Die Aufgabe des Kunden beim Akzeptanztest ist das System abzuneh men Beim Test im Betrieb ist es Aufgabe des Kunden im Betrieb auftretende Fehlermeldungen der Software Entwicklungsorganisation zu melden Anforderungsingen
62. lauff hige Binary f r das Gesamtsys tem Installiertes System Das installierte System ist das beim Kunden eingesetzte System Es interagiert mit den real existierenden Sensoren und Aktuatoren in der Systemumgebung 198 Entwicklung eingebetteter Software mit UML Rollen 6 3 Rollen Im Prozess System Integration sind im wesentlichen die Rollen Systemintegrati onsingenieur Validierer Anforderungsingenieur Entwurfsingenieur Kodierer und Qualit tsmanager involviert Die Verantwortlichkeiten f r die Produkte ergeben sich aus Abbildung 103 Folgende wesentliche T tigkeiten sind im Prozess System Integration mit der Rollen verbunden Systemintegrationsingenieur Der Systemintegrationsingenieur integriert itera tiv bersetzten Komponenten Kode zu Ausf hrbaren Teilsystemen und schlie lich zum Gesamtsystem Validierer Die Aufgaben des Validierers im Prozess System Integration sind Teilsystemtest Rahmen zu erstellen den Teilsystemtest durchzuf hren und die Ergebnisse zu dokumentieren Kodierer Die Aufgabe des Kodierers ist beim Teilsystemtest gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben Anforderungsingenieur Die Aufgabe des Anforderungsingenieurs ist beim Teilsystemtest gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben Hierf r kann er den Kunden kontaktieren sofern die Problembe schreibung oder die Informellen B Anforderungen betroffen sind Entwurfsingenieur Die Aufga
63. light nitlightControl z EEN Control eLightOf lt Entry Aktion lerPtr rol cLightOff ee auf FM Betrieb 2 FERN gt LightControl ae Methode fmLightCont mLightCont ler lishtCont ontrol lt Ausgabe rol zLightStatusType void rol cLightOn kdi htOn Status auf Licht an i g gesetzt FM Betrieb 3 ER r LightControl SE Methode fmLightCont mLightCont ler lightCont ontrol lt Ausgabe ol zLightStatusType void rol cLightOff roei Om Status auf Licht aus g gesetzt FM Betrieb 4 d 2 _ LightController light occupancyMes BR LightControl Control lt Ausgabe FM Betrieb gt Automatik ler lightCont Be S i sage cPersonIn x Status auf Licht an Betrieb rol cLightOn gesetzt 5 changedLightSta Automatik Betrieb tus manueller Betrieb 6 D G gt LightControl nn a A manueller Betrieb gt FM Saee PERONU ler lightCont SCH auf Licht aus Bee sas rol cLightOff gesetzt g Entry Aktion ABBILDUNG 66 Ausschnitt aus einem Testplan zum Test der Komponente LightControlUnit 122 Entwicklung eingebetteter Software mit UML Produkte Dokumentation der Testergebnisse E Testergebnisse Das Dokument E Validation erlaubt die Dokumentation der Testergebnisse an der gleichen Stelle an der auch die Testpl ne dokumentiert sind Auf diese Weise k n nen die Testergebnisse mit dem erwartetes Verhalten der Komponente abgeleitet aus dem Entwurf und dokumentiert im Testplan
64. nicht eingesetzt e _ Klassennamen beginnen mit einem Gro buchstaben e Alle anderen Namen beginnen mit einem Kleinbuchstaben e Au er zur optischen Trennung enthalten Bezeichner keine weiteren Gro buchstaben Methoden die zum Lesen bzw Setzen von Attributen benutzt werden werden als solche gekennzeichnet Sie erhalten einen entsprechenden Pr fix set get e Methoden die einen boolschen Wert zur ckliefern erhalten is oder has als Pr fix ABBILDUNG 39 Namenskonventionen auf Ebene der System Anforderungen 3 3 Rollen Im Prozess System Anforderungen bearbeiten sind die Rollen Anforderungsingeni eur Kunde Dom nenexperte Verifizierer Validierer und Oualit tsmanager invol viert Ihre Verantwortlichkeiten f r die Produkte ergeben sich aus Abbildung 40 Folgende wesentliche T tigkeiten sind im Prozess System Anforderungen erstellen mit den Rollen verbunden e Anforderungsingenieur Die Aufgaben des Anforderungsingenieurs sind die B und E Anforderungen sowie die Verfolgbarkeitsmatrix zu erstellen Dies sollte in enger Abstimmung mit dem Kunden Benutzer erfolgen Nach einer Verifikation bzw Validation ist der Anforderungsingenieur f r erforderliche Korrekturen nderungen und Erweiterungen entsprechend der Verifikations bzw Validationsergebnisse verantwortlich e Kunde Die Aufgabe des Kunden Auftraggebers ist bei der Erstellung der Sys tem Anforderungen mitzuwirken Aus Gr nden der Vereinfachung wird hier
65. nnen aus den Sequenzdiagrammen Kollaborationsdiagramme automatisch generiert werden Die Generierung sollte geschehen wenn sich die Sequenzdiagramme in einem stabilen Zustand befinden Folgendes Produkt wird in dem Prozess A Kollaborationsdiagramme bearbeiten konsumiert e A Sequenzdiagramme Folgendes Produkt wird produziert e A Kollaborationsdiagramme Prozess A Zustandsdiagramme bearbeiten F r jede Klasse mit dynamischen Verhalten wird ein Zustandsdiagramm angelegt Das Diagramm zeigt die verschiedenen Zust nde und Bedingungen f r Zustands transitionen Die Namenskonventionen geben Richtlinien f r Benennungen von Bezeichnern z B Bezeichner werden der engl Sprache entnommen Die Konsis tenz der anderen UML Diagramme mit den Zustandsdiagrammen muss sicherge stellt sein Daf r muss u a gepr ft werden ob e alle Methoden die im Sequenzdiagramm von einem Objekt einer Klasse ver schickt werden im Zustandsdiagramm der Klasse als Aktionen auftreten e Beziehungen zwischen Klassen im Klassendiagramm im Zustandsdiagramm genutzt werden Entwicklung eingebetteter Software mit UML 79 System Anforderungen bearbeiten Folgende Produkte werden im Prozess A Zustandsdiagramme bearbeiten konsu miert Systemumgebung Referenz Dokumente Namenskonventionen A Use Cases Szenarien A Packagediagramme A Klassendiagramme A Sequenzdiagramme A Aktivit tsdiagramme Folgendes Produkt wird produziert
66. siehe Kapitel A Validation bestimmt In einem Testplan wird ein bestimmter Startzustand vorausgesetzt Dies kann z B bedeuten dass die Anwesenheit einer Person im Raum gefordert wird Initialisiert man ein Software System so stellt sich dieses auf einen Initialzustand ein der fest kodiert ist Initialzust nde der State Diagramme Es ist wahrscheinlich dass es Unterschiede zwischen dem geforderten Startzustand f r den Test und dem Initial zustand des Software Systems gibt F r die Stubs hei t dies dass es n tig sein kann das Software System zuerst in diesen Startzustand zu bringen Erst dann fol gen die Sensorwerte entsprechend des Testplans Abbildung 101 zeigt einen Ausschnitt aus einem Teilsystemtest Stub f r das Teil system LichtRegelungFlur aus dem Geb udeautomationssystem Teilsystemtest Stub Dem UML Entwurf kann entnommen werden dass das Teilsystem Lichtrege lungFlur nur Klassen aus dem Teilsystem HardwareWrapper aufruft Die ent sprechenden Klassen d h Sensoren und Aktuatoren werden durch Teilsystemtest Stubs simuliert Als zentrale Anbindung an die konkrete Hardware wurde im UML Entwurf des Geb udeautomationssystems die Klasse Portbaustein eingef hrt Von dieser Klasse sind alle Sensor und Aktuatorklassen abgeleitet Beim Teilsystemtest dient diese Klasse zur Realisierung der Stubs Die Methoden des Portbausteins werden so modifiziert dass ein bestimmtes Verhalten der Sensoren erreicht
67. sse g l tig sind sind wiederum an den Pfeilen angegeben 200 Entwicklung eingebetteter Software mit UML Prozess Integriere Teilsystem O O Integriere GI g Teilsystem System integrations ingenieur Validierer 1 n 1 Iteration E T LI g Integrationstest Validierer Anforderungs Entwurfs Kodierer ingenieur ingenieur n Iteration ABBILDUNG 104 Kontrollfluss f r den Prozess System Integration 6 5 Prozess Integriere Teilsystem Im Prozess Integriere Teilsystem werden aus dem bersetzten Komponenten Kode Ausf hrbare Teilsysteme konstruiert Im UML Entwurf ist beschrieben welche Teilsysteme gebildet werden Basierend auf dem UML Entwurf und den Testpl nen zum Systemtest werden Test Rahmen f r die Teilsysteme entwickelt Die Defi nition von Makefiles erleichtert ein Zusammenbinden der Komponenten zu Ausf hrbaren Teilsystemen Abbildung 105 zeigt den Prozess Integriere Teilsystem mit konsumierenden produ zierenden und modifizierenden Produkten Entwicklung eingebetteter Software mit UML 201 System Integration Software System Dokumentation O o LU System integrations Validierer C UML Enwu gt ingenieur Ausf hrbares System Integriere Teilsystem Ausf hrbares Teilsystem Ausf hrbare Komponente Teilsystemtest Rahmen erstellen Com Teilsystemtest Rahmen Ausf hrbarer Komponenten Kode eilsystem Makefile erstelle
68. um 0 00 Uhr des Tages datum g ltig und verlieren ihre G ltigkeit um 24 00 des Tages domm Das kleinste Intervall ist somit f r genau 24h g ltig es wird angegeben mit datum datum wobei datum datum ist Gilt f r ein Intervall J datum datum datum lt datum so gilt J J U Ja mit J datum 31 12 und J3 1 1 datum ABBILDUNG 15 Ausschnitt aus dem Zeitreferenz Modell 2 3 Rollen Im Prozess Projekt initialisieren sind die Rollen Kunde Dom nenexperte und Anforderungsingenieur involviert Ihre Verantwortlichkeiten f r die Produkte erge ben sich aus Abbildung 16 Folgende wesentliche T tigkeiten sind im Prozess Pro Jekt initialisieren mit den Rollen verbunden e Kunde Der Kunde ist in Zusammenarbeit mit dem Anforderungsingenieur f r die Erstellung der Problembeschreibung und der Informellen B Anforderungen verantwortlich Diese Dokumente k nnen weitgehend in nat rlicher Sprache formuliert werden wobei es bez glich der Problembeschreibung keinerlei for melle Vorgaben gibt und f r die Informellen B Anforderungen ein tabellari sches Schema vorgegeben wird e Dom nenexperte Die Aufgaben des Dom nenexperten sind das Produkt Dom nenwissen bereitzustellen und zu warten sowie f r Ausk nfte ber die Dom ne bereitzustehen 30 Entwicklung eingebetteter Software mit UML Kontrollfluss e Anforderungsingenieur Der Anforderungsingenieur unterst tzt den Kunden bei der Erstel
69. werden welche Elemente es im 32 Entwicklung eingebetteter Software mit UML Prozess Dom nenwissen bearbeiten Anwendungsbereich gibt welche Beziehungen zwischen den Elementen beste hen und welche Eigenschaften die Elemente haben Bei der Entwicklung eines Geb udeautomationssystem sollten z B die R ume des Geb udes die Anzahl der Fenster und T ren in den verschiedenen R umen und die Information ob ein Raum geregelt werden soll beschrieben werden e Welche physikalischen Gesetzm igkeiten gelten in der Dom ne und welche Beschr nkungen ergeben sich daraus Die physikalischen Gesetzm igkeiten werden bei der Entwicklung genutzt um das vom System gew nschte Verhalten zu realisieren Im Anwendungsbe reich Geb udeautomation gibt es z B Gesetzm igkeiten ber den W rmever lust in einem Raum ber Fenster und W nde Teilweise basieren auf den physikalischen Gesetzm igkeiten Beschr nkungen die bei der Entwicklung des Systems ber cksichtigt werden m ssen Die Ber cksichtigung bei der Auf stellung der Anforderungen verhindert dass Anforderungen gestellt werden die in der Systemumgebung unm glich eingehalten werden k nnen F r ein Geb udeautomationssystems sind solche Beschr nkungen z B die maximale Raumtemperatur die erreicht werden kann oder die minimale Aufheizzeit von Ist auf Solltemperatur e Welche Sensoren und Aktuatoren sollen im Anwendungsbereich installiert wer den Sensoren m
70. wiederverwendet oder neu definiert sein Abbildung 60 zeigt einen Ausschnitt aus den definierten Datentypen des UML Entwurfs f r das Geb udeautomationssystem Allgemeine Datentypen Bei jedem Datentyp wird angegeben ob er wiederverwendet oder neu implemen tiert wird Die angegebene Definition nimmt bereits Bezug auf die konkrete Imple mentierungssprache C C Typdefinition Art Beschreibung typedef unsigned int timeCompType Wiederverw ee T der Zeit Stunden durationType timeCompType Wiederverw Beschreibt eine Zeitdauer in Minuten typedef enum cPersonIn cPersonOut Neu M gliche Werte f r den Anwesenheitstatus zOccupancyType typedef enum cLightOff cLightOn Neu M gliche Werte f r die Flurlichtanlage zLightStatusType ABBILDUNG 60 Ausschnitt aus den definierten Datentypen eines Geb udeautomationssystem Klassendefinitionen Die Klassendefinitionen beschreiben jeweils f r eine Klasse wie Assoziationen und Aggregationen zu anderen Klassen realisiert werden Dar ber hinaus werden Konstruktoren Destruktoren private Methoden sowie importierte Datentypen und Methoden anderer Klassen beschrieben Zusammen mit den Klassenbeschreibun 112 Entwicklung eingebetteter Software mit UML Produkte gen und den Zustands und Aktivit tsdiagrammen des UML Entwurfs erlauben die Klassendefinitionen eine unabh ngige Implementierung einzelner Klassen Die Liste der importierten Meth
71. 179 185 187 188 191 192 199 200 201 204 Entwicklung eingebetteter Software mit UML Inhalt 6 7 Weiterf hrende Literatur KAPITEL 7 System Validation 7 1 Prozessverfeinerung 7 2 Produkte Simulator Reale Systemumgebung 7 3 Rollen 7 4 Kontrollfluss 15 Prozess Systemtest 1 6 Prozess Akzeptanztest 7 7 Prozess Test im Betrieb 7 8 Weiterf hrende Literatur ANHANG A Produkthierarchie ANHANG B Prozesshierarchie ANHANG C Kontrollfluss Index 207 209 211 212 213 214 215 216 217 220 223 226 227 231 235 239 vi Entwicklung eingebetteter Software mit UML KAPITEL 1 Einf hrung In immer mehr technischen Produkten werden Steuerfunktionen von eingebauten Computersystemen sog eingebetteten Systemen bernommen Eingebettete Sys teme sind heute in vielen Bereichen zu finden z B in der Automobilindustrie ABS Motorsteuerung etc im Konsumg tersektor Digitalkameras Mikrowel lenherd etc im medizinischen Bereich Herzschrittmacher k nstliche Organe etc in der Geb udeautomation Feuermeldesystem Klimaanlage Lichtsteuerung etc in der Telekommunikation Handy Vermittlungsanlage etc in der industri ellen Produktion Fertigungssteuerungen Roboter etc oder in der Flugzeugindus trie Autopilot Radarkontrolle etc Die Bedeutung und Komplexit t eingebetteter Systeme nimmt mit der zunehmenden Verbreitung und der bernahme einer Viel z
72. 2818 5 2 35 sleae45 31823 Prozess 2 aae S Z ZE Projekt initialiseren XIX Informelle B Anforderungen bearbeiten Dom nenwissen bearbeiten System Anforderungen bearbeiten B Anforderungen bearbeiten A Use Cases bearbeiten Szenarien bearbeiten E Anforderungen bearbeiten A Sequenzdiagramme bearbeiten X X X Gei Entwicklung eingebetteter Software mit UML 231 Prozesshierarchie g E ls EE JE GE 2 p las 5 E D 5 oje s 53 2 5 33 o 5 22 32 S 2 E2 8 F S H s amp 2 2 2 8 5 FAHER EHEHE Prozess z 2 2233 gt 2 8 2 336 A Klassendiagramme bearbeiten I IX A Zustandsdiagramme bearbeiten X A Aktivit tsdiagramme bearbeiten X A Kollaborationsdiagramme bearbeiten X Data Dictionary bearbeiten Verfolgbarkeitsmatrix Anforderungen bearbeiten System Anforderungen verifizieren System Anforderungen Review vorbereiten Reviewsitzung System Anforderungen Rework System Anforderungen Testf lle bearbeiten System Entwurf bearbeiten X Entwurfentscheidungen erstellen UML Entwurf bearbeiten E Use Cases bearbeiten E Klassendiagramme bearbeiten Class Tables bearbeiten E Zustandsdiagramme bearbeiten E Aktivit tsdiagramme bearbeiten E Sequenzdiagramme bearbeiten E Kollaborationsdiagramme bearbeiten Komponenten Anforderungen erstellen Verfolgbarkeitsmatrix Entwurf bearbeiten System Entwurf verifizieren Sy
73. 7 Systemintegrationsingenieur 199 215 System Komponenten bearbeiten 151 Systemtest 217 Systemtest durchf hren 219 Systemumgebung 28 System Validation 209 Szenarien 45 Szenarien bearbeiten 73 T Teilsystem 99 Teilsystem Makefile 197 Teilsystem Makefile erstellen 203 Teilsystemtest durchf hren 206 Teilsystemtest Rahmen 193 Teilsystemtest Rahmen erstellen 203 Test im Betrieb 223 Test im Betrieb durchf hren 225 Testf lle bearbeiten 87 U UML Entwurf 98 UML Entwurf bearbeiten 130 Unterschiede zur Analyse 98 V Validation 3 Validierer 69 127 169 199 215 Verfolgbarkeitsmatrix Anforderungen 57 Verfolgbarkeitsmatrix Anforderungen bearbeiten 81 Verfolgbarkeitsmatrix Entwurf 110 Verfolgbarkeitsmatrix Entwurf bearbeiten 141 Verifikation 3 Verifizierer 69 126 169 Entwicklung eingebetteter Software mit UML 241
74. Au erdem umfasst es eine Verfolg barkeitsmatrix mit deren Hilfe Zusammenh nge innerhalb der System Anfor derungen explizit gemacht werden Des Weiteren enth lt die Probleml sungsdokumentation Dokumente zu Verifikations und Validations 2 Probleml sungs o dokumentation aktivit ten ABBILDUNG 8 Verwendete Produkte des Prozesses Projekt initialisieren Projekt initialisieren 2 1 Prozessverfeinerung Der Prozess Projekt initialisieren unterteilt sich in drei Teilprozesse siehe Abbil dung 9 Der Bedarf f r ein eingebettetes System wird ermittelt Dies kann bei spielsweise durch einen Kunden geschehen der seine Umgebung beobachtet und 1 Verifikationsaktivit ten sind T tigkeiten die der berpr fung der Korrektheit eines Soft waredokuments z B UML Entwurf oder Komponenten Kode dienen 2 Validationsaktivit ten sind T tigkeiten die der berpr fung der Zuverl ssigkeit von aus f hrbaren Produkten z B ausf hrbares Teilsystem oder System dienen 22 Entwicklung eingebetteter Software mit UML Prozessverfeinerung Dom nenwissen System umgebung Referenz Dokumente die existierende Situation analysiert Es werden Probleme identifiziert die durch ein eingebettetes System gel st werden k nnen oder es werden strategische Ziele definiert die durch ein eingebettetes System erreicht werden k nnen Aus dem Bedarf heraus werden die wichtigsten An
75. Die Aufgabe des Entwurfsingenieurs sind die Entwurfs entscheidungen zu erstellen in Interaktion mit dem Anforderungsingenieur den UML Entwurf zu erstellen die Komponenten Anforderungen zu erstellen sowie die Verfolgbarkeitsmatrix Entwurf zu erstellen Des Weiteren nimmt er an der Verifikation des Entwurfs teil und ist f r die Fehleridentifikation und behebung in den ihm zugeordneten Dokumenten verantwortlich e Verifizierer Die Aufgaben des Verifizierers sind die Inspektion des System Entwurfs zu organisieren diese in Kooperation mit dem Entwurfsingenieur durchzuf hren und die Ergebnisse zu dokumentieren 126 Entwicklung eingebetteter Software mit UML Rollen Validierer Die Aufgabe des Validierers im Prozess System Entwurf bearbeiten ist Komponenten Testf lle zu entwickeln und zu dokumentieren Anforderungsingenieur Die Aufgaben des Anforderungsingenieurs sind den Entwurfsingenieur bei der Erstellung des UML Entwurfs zu unterst tzen sowie bei der Verifikation gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben F r letzteres kann er den Kunden kontaktieren sofern die Problembe schreibung oder die Informellen B Anforderungen betroffen sind Qualit tsmanager Die Aufgabe des Qualit tsmanagers ist entsprechend den l ngerfristigen Bed rfnissen und Erwartungen einer Software Entwicklungsor ganisation Wissen Erfahrung in geeigneter Form zu verwalten einzelnen Pro jekten auf Anfrage zur Wiederverwendu
76. E Aktivit tsdiagramme Methoden von Klassen f hren teilweise komplexe Operationen aus Die E Aktivi t tsdiagramme erlauben deren Zerlegung Einige komplexe Operationen wurden bereits in den E Anforderungen identifiziert Die existierenden A Aktivit tsdia 108 Entwicklung eingebetteter Software mit UML Produkte gramme aus den E Anforderungen werden zu E Aktivit tsdiagrammen verfeinert Au erdem werden Aktivit tsdiagramme f r weitere komplexe Operationen aus dem UML Entwurf erg nzt Wenn die Operationen in den E Anforderungen nur informell beschrieben wurden dann ist es sinnvoll diese nun mit Hilfe von Pseudo Code oder Aktivit tsdiagrammen zu pr zisieren Auf diese Weise werden Fragen fr hzeitig gekl rt Abbildung 58 zeigt ein E Aktivit tsdiagramm f r die Methode check der Klasse TimelntervalsExit des Teilsystems Systemmodusermittlung f r das Geb udeautomationssystem E Aktivit tsdiagramm Die Methode check der Klasse TimelntervalsExit berpr ft ob ein vom Benutzer eingegebener Wert innerhalb eines Akzeptanzintervalls liegt Wenn dies der Fall ist dann wird der eingegebene Wert als aktueller Wert verwendet Wenn der Wert des Benutzers nicht innerhalb des Akzeptanzintervalls liegt wird berpr ft ob der Wert ber der oberen Grenze oder unter der unteren Grenze des Intervalls liegt Je nachdem wird die obere oder untere Grenze als neuer Wert verwendet Entwicklung eingebetteter Software mit
77. Element sowie eine Fehlerbeschrei bung charakterisiert Abbildung 63 zeigt einen Ausschnitt aus einer Fehlertabelle f r das Teilsystem LichtregelungFlur E Fehlertabellen Die Fehlertabelle dokumentiert zwei Fehler im Teilsystem LichtregelungFlur im UML Entwurf Beide Fehler befinden sich in der Beschreibung der statischen Struktur des Systems Klassendiagramme Sie wurden beim Inspizieren des UML Entwurfs und der Komponenten Anforderungen gefunden Entwicklung eingebetteter Software mit UML 117 System Entwurf bearbeiten Prozess g w hrend betroffenes betroffenes allgemeine S dessen der FNr i g Fehler Diagramm Element Fehlerbeschreibung 2 3 gefunden E wurde Abk rzung Klassendia requestLightStatus E LF FNrl SEN LightController R ckgabetyp nicht U sysentrevvorb gramme festgelegt E LE FNr Klassendia PresenceController R ckgabetypen nicht U sysentrevvorb gramme Hallway festgelegt ABBILDUNG 63 Ausschnitt aus der Fehlertabelle Lichtregelung Flur E Fehlerbehebungsstrategien In der Tabelle zur Dokumentation der Fehlerbehebungsstrategien wird verdeut licht welche Fehler aus der Fehlerliste behoben wurden und wie dies geschehen ist Au erdem wird in den Tabellen die Behebung von Entwurfsfehlern dokumen tiert die die Ursache f r Fehler in folgenden Entwicklungsprodukten waren und erst dort entdeckt wurden Diese Fehler sind in den K Fehlertabellen doku
78. Entwicklung eingebetteter Software mit UML Der Do it Prozess V 1 0 ANTJE VON KNETHEN J RGEN M NCH Entwicklung eingebetteter Software mit UML Der Do it Prozess V 1 0 von Antje von Knethen und J rgen M nch 1999 Interner Bericht Nr 05 00 Sonderforschungsbereich 501 vknethen muench informatik uni kl de Die Autoren m chten sich bei Prof H Dieter Rombach f r die wissenschaftli che Unterst tzung sowie die Bereitstellung des Umfeldes in dem die vorlie gende Arbeit entstanden ist herzlich bedanken Der weitere Dank gilt den Kollegen der AG Software Engineering sowie des Sonderforschungsbereichs 501 an der Universit t Kaiserslautern Dies sind insbesondere Raimund L Feld mann und Stefan Vorwieger die bei der Entwicklung des Beispielsystems als Betreuer mitgewirkt haben Thomas Schneider der die Systemadministration unterst tzt hat sowie Lothar Baum Martin Becker Lars Geyer Martin Kronen burg und Georg Molter die beratend zur Seite standen Der Dank schlie t Wolf gang Wagenbichler ein der das Dokumentenmanagement in diesem Projekt bernommen und hierf r unterst tzende Werkzeuge entwickelt hat sowie die Studenten der Software Engineering Praktika die das Beispielsystem entwi ckelt haben Dar ber hinaus gilt Dr Barbara Paech und Christian Bunse vom Fraunhofer Institut f r Experimentelles Software Engineering Dank f r wert volle Kommentare zur Prozessbeschreibung Sonderforschungsbereich 501 Arbeitsg
79. Fehlers dokumentiert um nderungen an den Dokumenten zu verdeutlichen Dies geschieht mit Hilfe der Tabelle zur Dokumentation der Fehlerbehebungsstrategie im Dokument E Verifikation L sst sich ein Fehler auf einen Fehler in den System Anforderungen zur ckf hren wird der Fehler auch in den System Anforderungen behoben Die Behebung wird im Dokument A Verifikation beschrieben Im Prozess Rework System Entwurf werden folgende Produkte konsumiert e Entwurfsentscheidungen Entwicklung eingebetteter Software mit UML 145 System Entwurf bearbeiten Folgende Produkte werden modifiziert e A Use Cases e Szenarien e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation e A Validation e UML Entwurf e Komponenten Anforderungen e Verfolgbarkeitsmatrix Entwurf e E Verifikation 4 10 Prozess Komponenten Testf lle bearbeiten Im Prozess Komponenten Testf lle bearbeiten werden entsprechend des ausge w hlten Black box Testverfahrens Testpl ne entwickelt Ein m gliches Testkri terum besteht in der berdeckung der Kanten der Zustands und Aktivit tsdiagramme der Klassen sowie ihrer ffentlichen Methoden Der Test der ausf hrbaren Komponente soll basierend auf den Testpl nen m glich sein F r den Test einer Komponente wird ein Testrahmen Stubs und Treiber ben tigt Der Testrahmen muss als Teil des Testplans beschrieben sein Er beschreibt welche Stubs mit welchen Methoden f r de
80. Flur einschalten m chte Durch diese Methode erfolgt die Benachrichtigung vom personIn PRHallwayLightController dass jemand in den Flur eingetre LightControlUnit ten ist Durch diese Methode erfolgt die Benachrichtigung vom personOut PRHallwayLightController dass alle Benutzer aus dem Flur abschnitt ausgetreten sind Diese Methode wird vom LightController aufgerufen falls der changedLightStatus Zustand der Lichtanlage im Flur sich ge ndert hat d h der Benutzer von Hand das Licht an oder ausgeschaltet hat ber diese Methode meldet die Klasse PRHallwayLightCont timeRunOut roller dass der Flur seit l nger als ZeitspanneVerlassen LT2 Minuten leer ist ABBILDUNG 25 Auszug aus der Beschreibung der Klasse LightControlUnit A Sequenzdiagramme Die A Sequenzdiagramme verfeinern die Szenarien aus den B Anforderungen Sie bilden das in den Szenarien beschriebene Verhalten des Systems auf die Interaktion zwischen Objekten innerhalb des Systems ab Die Anzahl der Sequenzdiagramme entspricht der Anzahl der Szenarien F r Szenarien die beschreiben dass das Sys Entwicklung eingebetteter Software mit UML 51 System Anforderungen bearbeiten tem nicht reagiert m ssen keine Sequenzdiagramme entwickelt werden Sequenz diagramme betonen den zeitlichen Ablauf des Nachrichtenaustauschs zwischen Objekten im System Abbildung 26 zeigt ein Sequenzdiagramm zu Szenario1 des Use Cases Flurlicht
81. Komponenten Kode und ein bersetzter Test Rahmen werden zusammengebunden Das ausf hr bare Binary als Teil des ausf hrbaren Komponenten Kodes wird ausgef hrt und Testausgaben werden im Dokument E Validation protokolliert Bei auftretenden Fehlverhalten werden die Fehler in der gesamten System Dokumentation d h Probleml sungsdokumentation Software System Dokumentation und Software Komponenten Dokumentation gesucht und behoben Entwicklung eingebetteter Software mit UML 153 System Komponenten bearbeiten Software System Entwicklungsrichtlinien Dokumentation Kode Ableitungs richtlinien Programmier System richtlinien Komponenten Komponenten bearbeiten Anforderungen Software Komponenten Quellkode a Dokumentation bearbeiten Komponenten Kode E Validation Ausf hrbare Komponente H K Verifikation bearbeiten Probleml sungs dokumentation Ausf hrbare Komponente Komponententest Rahmen Ausf hrbarer Komponenten Kode ABBILDUNG 79 Verfeinerung des Prozesses System Komponenten bearbeiten 5 2 Produkte Im folgenden wird eine bersicht ber die im Prozess System Komponenten bear beiten verwendeten Produkte gegeben Die bersicht beschreibt die interne Struk turierung der Dokumente Anschlie end erfolgt eine Beschreibung der Inhalte der Dokumente 154 Entwicklung eingebetteter Software mit UML Produkte Software Komponenten Dokumen
82. L Entwurf bearbeiten werden die Diagramme aus den E Anforde rungen hinsichtlich der Entwurfsentscheidungen und anderer Entwurfsaspekte berarbeitet und verfeinert Die Realisierbarkeit des Software Systemmodells wird gew hrleistet und die endg ltige Struktur des Software Systems festgelegt Insbe sondere bei der Verfeinerung helfen die Namenskonventionen Bezeichner z B von Konstanten oder Datentypen zu benennen 130 Entwicklung eingebetteter Software mit UML Prozess UML Entwurf bearbeiten Der Prozess UML Entwurf bearbeiten geschieht in Interaktion mit dem Anforde rungsingenieur der die Anforderungen erarbeitet hat Hauptziel ist es eine L sungsstruktur f r die Anforderungen festzulegen Abbildung 73 zeigt die verwendeten Produkte im Prozess UML Entwurf bearbei ten Entwicklung eingebetteter Software mit UML 131 System Entwurf bearbeiten Probleml sungsdokumentation O E B Anforderungen Entwurfs ingenieur 7 Anforderungs ingenieur Informelle B Anforderungen UML Entwurf bearbeiten A Use Cases E Use Cases bearbeiten E Klassendiagramme ET bearbeiten TR E Anforderungen IT A Package Class Tables diagramme bearbeiten Est ii A Klassendiagramme NT E Sequenzdiagramme wu bearbeiten B E Kollaborations diagramme Data Dictionary A Sequenzdiagramme bearbeiten A Kollaborations diagramme E Zustandsdiagramme bearbeiten A Zustands diagramme
83. ML Entwurf Reviewsitzung System Entwurf Komponenten Anforderungen E Anforderungen Verfolgbarkeitsmatrix Anforderungen A Verifikation U HU Verfolgbarkeits matrix Entwurf Rework System Entwurf E Verifikation ABBILDUNG 76 Verwendete Produkte des Prozesses System Entwurf verifizieren Folgende Produkte werden im Prozess System Entwurf verifizieren konsumiert e Entwurfsentscheidungen Folgende Produkte werden modifiziert Entwicklung eingebetteter Software mit UML 143 System Entwurf bearbeiten UML Entwurf Komponenten Anforderungen Verfolgbarkeitsmatrix Entwurf E Verifikation A Use Cases Szenarien E Anforderungen Verfolgbarkeitsmatrix Anforderungen A Verifikation A Validation Prozess System Entwurf Review vorbereiten Im Prozess System Entwurf Review vorbereiten werden der UML Entwurf die Komponenten Anforderungen und die Verfolgbarkeitsmatrix Entwurf mit Hilfe der E Checkliste die im Dokument E Verifikation dokumentiert ist berpr ft Gelesen wird von den Verifizierern Werden Fragen in der Checkliste mit Nein beantwortet dann k nnte es sich bei einem Aspekt um einen Fehler handeln Pro bleme in den Dokumenten werden in der Fehlertabelle dokumentiert Ergebnis dieses Prozesses ist eine Liste mit m glichen Fehlern Jeder Fehler ist dabei einer Fehlerklasse zuzuordnen Die potentielle Fehlerliste wird im Dokument E Verifikati
84. Matthias Jarke Peter Haumer Scenarios in System Development Current Practice IEFE Software Vol 15 Nr 2 S 34 45 M rz 1998 Entwicklung eingebetteter Software mit UML 89 System Anforderungen bearbeiten 15 Tsuneo Yamaura How To Design Practical Test Cases IEEE Software Vol 15 Nr 6 S 30 36 November 1998 9 Entwicklung eingebetteter Software mit UML KAPITEL 4 System Entwurf bearbeiten Ziel des Prozesses System Entwurf bearbeiten ist ein realisierbares Software Sys tem zu entwerfen welches die System Anforderungen aus der Probleml sungsdo kumentation erf llt Dar ber hinaus soll der Entwurf eine unabh ngige Implementierung einzelner Komponenten d h Klassen erlauben Um diese Ziele zu erreichen werden die UML Diagramme aus dem Prozess System Anforderungen bearbeiten verfeinert und hinsichtlich ihrer Realisierbarkeit berarbeitet Abbildung 47 gibt einen berblick ber die verwendeten Produkte im Prozess System Entwurf bearbeiten Folgende Produkte werden konsumiert e Namenskonventionen Dieses Dokument beinhaltet Konventionen f r die Wahl von Bezeichnern in der Software System Dokumentation Diese Konventionen erweitern die auch in diesem Dokument enthaltenen Konventionen f r die Wahl von Bezeichnern in der Probleml sungsdokumentation e Dom nenwissen Dieses Dokument beschreibt typische Eigenschaften und Cha rakteristika der Anwendungsdom ne Es umfasst insbesondere ein
85. Tables im Kode enthalten ABBILDUNG 83 Ausschnitt aus der K Checkliste Komponenten Kode Fehlerklassifikation Die aufgedeckten Fehler werden in einer Fehlertabelle aufgelistet Dabei wird jeder Fehler einer Fehlerklasse zugeordnet Die Fehlerklassifikation ist identisch zur Fehlerklassifikation im Dokument A Verifikation der System Anforderungen Entwicklung eingebetteter Software mit UML 159 System Komponenten bearbeiten siehe Abbildung 32 Ausschnitt aus einer Fehlerklassifikation Spezifische Feh lerklassen auf Seite 60 K Fehlertabellen In den K Fehlertabellen werden alle Fehler die im Produkt Software Komponen ten Dokumentation gefunden wurden aufgelistet Die Tabelle umfasst einerseits Fehler die w hrend der Inspektion des Komponenten Kodes gefunden wurden Andererseits enth lt sie Fehler die Ursachen von Fehlverhalten sind Die Fehlver halten wurden beim Test ausf hrbarer Produkte entdeckt und in der K Fehlerta belle dokumentiert Der Prozess w hrend dessen ein Fehler gefunden wurde istin der Fehlertabelle vermerkt z B komkodrevvorb f r Komponenten Kode Review vorbereiten oder systestdur f r Systemtest durchf hren Die Fehler werden dabei mit Hilfe des Produkts und des Teilsystems in dem sie aufgetreten sind gekennzeichnet Produkt Teilsystem FNr Nummer Zu jedem Fehler wird die vom Fehler betroffene Datei angegeben Abbildung 84 zeigt eine Tabelle zur Dokumentati
86. Teilsystemen gegen die B Anforderungen ist m glich wenn die gebildeten Teilsysteme unterschiedliche Ver wendungsweisen z B Lichtregelung und Temperaturregelung des Systems reali sieren Dann entsprechen die B Anforderungen an das System den Anforderungen an die Teilsysteme Beim Systemtest wird das ausf hrbare Gesamtsystem in der Entwicklungsumgebung gegen die B Anforderungen getestet Dabei wird sowohl die bereinstimmung des Systems mit den funktionalen Anforderungen Funkti onstest als auch die bereinstimmung mit den nicht funktionalen Anforderungen berpr ft Beim Akzeptanztest wird das installierte System in der tats chlichen Systemumgebung durch den Kunden gegen die B Anforderungen getestet Dokumentation der Testverfahren A Testverfahren Dieses Dokument beschreibt die Testverfahren mit deren Hilfe Testpl ne f r den Integrations den System und den Akzeptanztest erstellt werden Es gibt verschie dene Testverfahren die angewendet werden k nnen z B die Black box Testver fahren quivalenzklassen oder Grenzfallbasiertes Testen Die Wahl eines Black box Testverfahrens erlaubt das Ableiten von Testpl nen aus den System Anforde rungen Das ausf hrbare Produkt Teilsystem oder System wird erst zur Durchf h rung der Tests ben tigt Ein bestimmtes Testverfahren sollte entsprechend des Projekt und Systemkontexts ausgew hlt werden Abbildung 35 zeigt einen Aus schnitt aus einer Dokumentation eines Testverfahrens d
87. UML 109 System Entwurf bearbeiten TimelntervalsExit check min nterval acceptancelnterval lt input lt maxlnterval acceptancelnterval minInterval acceptancelnterval lt input lt maxlnterval acceptancelnterval value input en valkse maxlnterval acceptancelnt vpteet mininterval acceptanceln 1 input lt mininterval cceptancelnterval ABBILDUNG 58 E Aktivit tsdiagramm zur Methode check der Klasse TimelntervalExit Verfolgbarkeitsmatrix Entwurf Die Verfolgbarkeitsmatrix Entwurf zeigt Beziehungen zwischen den E Anforde rungen und dem UML Entwurf auf Attribute und Methoden aus den E Anforde rungen und Attribute und Methoden aus dem UML Entwurf werden f r jede Klasse des Entwurfs gegen bergestellt Ein Kreuz in der Tabelle zeigt dass ein Attribut Methode des UML Entwurfs an der Realisierung eines Attributs Methode der E Anforderungen beteiligt ist Die Verfolgbarkeitsmatrix unterst tzt eine ber pr fung der Konsistenz zwischen den E Anforderungen und dem UML Entwurf und die Durchf hrung sp ter evtl auftretender nderungen Abbildung 59 zeigt einen Ausschnitt aus einer Verfolgbarkeitsmatrix Entwurf f r die Klasse LightController des Teilsystems LichtRegelungFlur 110 Entwicklung eingebetteter Software mit UML Produkte Verfolgbarkeitsmatrix Entwurf Die Zeilen geben die Attribute und Methoden der Klasse LightController aus den E Anforderungen wie
88. UML 211 System Validation O O g Validierer Kunde O O O J Anforderungs Entwurfs Kodierer ingenieur ingenieur Probleml sungs dokumentation Software System o System Validation dokumentation Systemtest y Software Komponenten Dokumentaion Akzeptanztest Ausf hrbare Komponente Reale Systemumgebung Test im Betrieb o Ausf hrbares System ABBILDUNG 108 Verfeinerung des Prozesses System Validation 7 2 Produkte Im folgenden wird eine bersicht ber die im Prozess System Validation verwen deten Produkte gegeben Die bersicht beschreibt die interne Strukturierung der Dokumente Anschlie end erfolgt eine Beschreibung der Inhalte der Dokumente soweit dies nicht bereits in vorangegangenen Kapiteln erfolgt ist 212 Entwicklung eingebetteter Software mit UML Produkte Software Komponenten Dokumentation Simulator Siehe Abbildung 80 auf Seite 155 Ausf hrbare Komponente Reale Systemumgebung Siehe Abbildung 80 auf Seite 155 f Probleml sungsdokumentation 2 Ausf hrbares System S iehe Abbildung 20 auf Seite 41 Siehe Abbildung 99 auf Seite 192 Software System Dokumentation Siehe Abbildung 49 auf Seite 95 ABBILDUNG 109 Produkt bersicht f r den Prozess System Validation Simulator Der Test eines Systems in der realen Systemumgebung ist oft schwierig Zum einen kann eine falsche
89. UNG 27 Kollaborationsdiagramm zu Szenariol Flurlichtregelung durch Anwesenheit Entwicklung eingebetteter Software mit UML 53 System Anforderungen bearbeiten A Zustandsdiagramme Die Komplexit t eingebetteter Systeme liegt in ihrem dynamischen Verhalten Aus diesem Grund ist die Modellierung des Verhaltens sehr wichtig Die Sequenz und Kollaborationsdiagramme beschreiben die Interaktion der verschiedenen Objekte Zustandsdiagramme beschreiben das dynamische Verhalten einzelner Klassen Ein Zustandsdiagramm beschreibt verschiedene Zust nde und Transitionen zwi schen den Zust nden f r die Objekte einer Klasse Nicht ber cksichtigt werden im Zustandsdiagramm die Aufrufe von Methoden dieser Klasse die lediglich zum Setzen oder Abfragen von Werten dienen und keine Zustands nderung ausl sen Innerhalb eines Zustands sind verschiedene Aktionen erlaubt 1 Entry Aktionen die beim Eintritt in den Zustand ausgef hrt werden 2 Do Aktivit ten die ausge f hrt werden solange ein Zustand aktiv ist 3 Exit Aktionen die beim Verlassen eines Zustands ausgef hrt werden und 4 Event Aktionen die beim Auftreten eines Events ausgef hrt werden Die Do Aktivit ten beschreiben teilweise komplexe Methoden f r die eine weitere Modellierung notwendig sein kann Die Modellie rung kann mit Hilfe von Aktivit tsdiagrammen Pseudo Code oder informellen Beschreibungen geschehen In eingebetteten Systemen m ssen Sensorwerte regelm ig
90. Validation E EEEEEEEEEEEEENE EREEEEEIEE KII K K Bel es K re st Br es Er a o 5 Gel Gel od Leg Software Komponenten Dokumentation Komponenten Kode K Verifikation X 228 Entwicklung eingebetteter Software mit UML Produkt Dom nenexperte Anforderungs ingenieur ingenieur Verifizierer Systemintegrations ingenieur Qualit tsmanager Validierer Kodierer Ausf hrbare Komponente Komponententest Rahmen Komponententest Stubs Komponententest Treiber Ausf hrbarer Komponenten Kode Ausf hrbares System Ausf hrbares Teilsystem Teilsystem Makefile Ausf hrbarer System Kode Installiertes System Ausf hrbarer Teilsystem Kode Teilsystemtest Rahmen Entwicklungsrichtlinien Kode Ableitungsrichtlinien K x Programmierrichtlinien Dom nenwissen Systemumgebung Referenz Dokumente Namenskonventionen Simulator Reale Systemumgebung Gel Gel zi Sl zg Gel Gel Entwicklung eingebetteter Software mit UML 229 Produkthierarchie 230 Entwicklung eingebetteter Software mit UML ANHANG B Prozesshierarchie Im Folgenden werden die Prozesse tabellarisch aufgelistet zessen werden die beteiligten Rollen angegeben Zu den einzelnen Pro Problembeschreibung bearbeiten A g S bi 1 2 amp E SIS h Sp elZEulaerl2 s EES aja sig s a 21 5 33 S Pel 52 5 22 2 s s2l
91. abei das gew nschte Verhalten des Systems Die nicht funktionalen Anforderun gen beschreiben Qualit tseigenschaften durch die sich das System auszeichnen soll Die Qualit tseigenschaften lassen sich teilweise bestimmten Verhalten des Systems zuordnen z B geforderte Reaktionszeiten des Systems bei bestimmten Verwendungen Teilweise beeinflussen sie aber auch die Struktur des Gesamtsys tems z B geforderte nderbarkeit des Systems Die inversen Anforderungen schlie en bestimmte Verhaltensweisen des Systems aus d h sie beschreiben Ver haltensweisen die das System unter keinen Umst nden zeigen darf Die Einhal tung inverser Anforderungen muss ausf hrlich getestet werden Um die informellen tabellarischen B Anforderungen in sp teren Entwicklungs dokumenten referenzieren zu K nnen werden sie durchnummeriert Eine tabellarische Auflistung der Anforderungen wird vom Benutzer Kunden zusammen mit dem Anforderungsingenieur erarbeitet Abbildung 12 zeigt einen Ausschnitt aus den informellen B Anforderungen f r ein Geb udeautomationssys tem 1 Der Produktname Informelle B Anforderungen bezieht sich ausschlie lich auf die hier beschriebene tabellarische Darstellung und wird auch im Folgenden so verwendet Zur Verdeutlichung wird manchmal auch von Informellen tabellarischen B Anforderun gen gesprochen 26 Entwicklung eingebetteter Software mit UML Produkte Beispiel Informelle B Anforderung
92. ager im Prozess System Komponenten bearbeiten z B in Form von Checklisten oder Fehlerklassifikationen zur Verf Entwicklung eingebetteter Software mit UML 169 System Komponenten bearbeiten gung gestellt werden Diese sind zum Teil Bestandteil von Produkten f r die andere Rollen verantwortlich sind Eigenverantwortlich ist der Qualit tsmana ger hier f r das Produkt Entwicklungsrichtlinien O O O O O O Kodierer Qualit ts Anforderungs Validierer Entwurfs Verifizierer N SE ingenieur ingenieur verahtwortlic verantwortlich a verantwortlich Ee verantwortlich f r f r f r f r CET v A CFTR CEF Ce 5 Verifikation Ce Ce 5 g Se Probleml sungs GC dokumentation H ooftware System Dokumentation I Ausf hrbarer Komponenten Kode ABBILDUNG 90 Ressourcen und Produkte des Prozesses System Komponenten bearbeiten 5 4 Kontrollfluss Die Reihenfolge der Bearbeitung der Teilprozesse ist in Form eines Pr zedenzgra phen in Abbildung 91 dargestellt Quellkode o bearbeiten O O O O Kodierer Verifizierer Anforderungs Entwurfs ingenieur Ingenieur O O O O Ausf hrbare o E e E Komponente bearbeiten Kodierer Validierer Anforderungs Entwurfs ingenieur ingenieur ABBILDUNG 91 Kontrollfluss f r den Prozess System Komponenten bearbeiten 170 Entwicklung eingebetteter Software mit UML Prozess Quellkode bearbeiten 5 5 Prozess Quellkode bearbeiten Im Prozess
93. agramme bearbeiten Data Dictionary bearbeiten A Kollaborations diagramme mer Data Dictionary ABBILDUNG 43 Verwendete Produkte des Prozesses E Anforderungen bearbeiten Entwicklung eingebetteter Software mit UML 75 System Anforderungen bearbeiten Folgende Produkte werden im Prozess E Anforderungen bearbeiten konsumiert e Systemumgebung e Referenz Dokumente e A Use Cases e Szenarien e Namenskonventionen Folgendes Produkt wird produziert e E Anforderungen Die E Anforderungen beschreiben das Verhalten des zu ent wickelnden Systems aus Sicht der Entwickler Es umfasst verschiedene UML Diagramme Die A Klassen und Packagediagramme beschreiben die Struktur des zu entwickelnden Systems Das Data Dictionary beschreibt die Klassen Attribute Methoden und Beziehungen aus den Klassendiagrammen Die A Sequenz und A Kollaborationsdiagramme beschreiben das Verhalten des Sys tems durch die Interaktion von Objekten Die A Zustandsdiagramme beschrei ben das Verhalten einzelner Klassen Die A Aktivit tsdiagramme verfeinern einzelne Operationen Die verschiedenen Teilprozesse des Prozesses E Anforderungen bearbeiten beein flussen sich gegenseitig und lassen sich nicht unabh ngig voneinander durchf h ren Wird z B eine Nachricht an ein Objekt einer Klasse in einem Sequenzdiagramm geschickt A Sequenzdiagramme bearbeiten so muss diese Nachricht auch als Methode dieser Klasse in d
94. ahl oftmals sicherheitskritischer Funktionen signifikant zu Die Funktionalit t ein gebetteter Systeme wird immer weniger allein durch Hardware sondern zunehmend durch Software sog eingebettete Software realisiert Dies erfordert geeignete Techniken Methoden und Werkzeuge zur Entwicklung qualitativ hoch wertiger Software f r eingebettete Systeme In diesem Bericht wird ein Entwick lungsprozess f r die objektorientierte Entwicklung eingebetteter Software vorgestellt Entwicklung eingebetteter Software mit UML 1 Einf hrung 1 1 Zielsetzung Ziel dieses Berichts ist die Dokumentation eines vollst ndigen Anwendungsent wicklungsprozesses f r die Entwicklung von Software in eingebetteten Systemen Dies beinhaltet alle Schritte von der Projektinitialisierung und Anforderungsfestle gung bis hin zur System Validation Dem Entwicklungsprozess liegen eine objektorientierte Vorgehensweise unter Ver wendung der Unified Modeling Language UML sowie bliche Inspektions und Testverfahren zugrunde Der Prozess basiert auf Erfahrungen aus Projekten in denen Software f r eingebettete Systeme entwickelt wurde Im Einzelnen enth lt dieser Bericht eine vollst ndige Beschreibung der Software Entwicklungsaktivit ten mit allen eingesetzten Entwicklungstechniken und methoden eine vollst ndige Beschreibung der zugeh rigen Entwicklungsprodukte Doku mente und sonstige Artefakte wie z B ausf hrbare Systemkomponenten mit
95. aktualisiert werden Dies geschieht durch eine laufende Abfrage der Sensorklassen durch die kontrol lierenden Klassen Diese laufenden Abfragen k nnen beispielsweise mit Hilfe von Do Aktivit ten Do each 5 sec getValue oder Event Aktionen SsecMessage getValue modelliert werden Jedes Zustandsdiagramm wird mit einer informellen Beschreibung erl utert Abbildung 28 zeigt ein Zustandsdiagramm f r die Klasse LightControlUnit A Zustandsdiagramm Da das verwendete CASE Werkzeug StP UML Entry Do und Exit Aktionen in separaten State Tabellen speichert werden die Aktionen im Anschluss an das Zustandsdiagramm aufgef hrt Eine Tabellensymbol an der linken oberen Ecke eines Zustands weist darauf hin dass es Entry Do und oder Exit Aktionen zu diesem Zustand gibt 54 Entwicklung eingebetteter Software mit UML Produkte Im Zustandsdiagramm werden drei Zust nde unterschieden keine Anwesenheit Anwesenheit und Zeitverz gerung Die Zust nde keine Anwesenheit und Anwesenheit werden jeweils in zwei Unterzust nde verfeinert Eine Abfrage von Sensorwerten ist in dieser Klasse nicht notwendig manueller Betrieb changedLightStatus personOut Zeitverz gerung Entry Aktion f r State Automatik Betrieb LightController SwitchLightOn Entry Aktion f r State FM Betrieb LightController SwitchLightOff Internal Aktion f r State FM Betrieb Event fmSwitchOn
96. al ten mit dem erwarteten Verhalten des Systems verglichen Das erwartete Verhalten kann den Testpl nen entnommen werden Gibt es Unterschiede zwischen dem tat s chlichen und dem erwarteten Verhalten des Systems wird dies als Fehlverhalten in der Tabelle zur Bewertung der Testergebnisse im Dokument A Validation dokumentiert Anschlie end werden die beschriebenen Fehlverhalten auf Fehler in der System Dokumentation zur ckgef hrt und die Fehler werden in der Fehlerta belle im Dokument K Verifikation festgehalten Die Tabelle zur Bewertung der Testergebnisse wird um Verweise auf die Fehlernummern erweitert Folgende Produkte werden im Prozess Systemtest durchf hren konsumiert e Simulator e Ausf hrbarer System Kode Folgende Produkte werden modifiziert e A Validation e K Verifikation Prozess Rework Systemtest Im Prozess Rework Systemtest werden die in der System Dokumentation lokali sierten und in der Fehlertabelle im Dokument K Verifikation dokumentierten Feh ler behoben Die Strategie zur Behebung der Fehler wird in den Verifikationskapiteln der zu ndernden Dokumente beschrieben Folgende Produkte werden im Prozess Rework Systemtest modifiziert e Komponenten Kode e K Verifikation e Ausf hrbare Komponente e Ausf hrbares System Entwicklung eingebetteter Software mit UML 219 System Validation e UML Entwurf e Komponenten Anforderungen e Verfolgbarkeitsmatrix Entwurf e E Ver
97. alidation Verification and Testing Diversity Rules IEEE Software Vol 15 Nr 4 S 46 49 Juli 1998 Marco van Meegen Pefer Schless Hrsg Programmkonventionen f r C Softwaretechnik Trends Band 12 Heft 3 S 29 47 August 1992 Entwicklung eingebetteter Software mit UML 185 System Komponenten bearbeiten 186 Entwicklung eingebetteter Software mit UML KAPITEL 6 System Integration Ziel des Prozesses System Integration ist aus den einzelnen ausf hrbaren Kompo nenten ein ausf hrbares Software System zu erstellen Daf r werden die Kompo nenten schrittweise bis zu einem ausf hrbaren System integriert Entstehende Teilsysteme werden validiert Abbildung 96 gibt einen berblick ber die verwendeten Produkte im Prozess Sys tem Integration Folgendes Produkt wird im Prozess System Integration in Teilen produziert e Ausf hrbares System Dieses Produkt umfasst die lauff higen Teilsysteme mit Test Rahmen das lauff hige Software System in der Entwicklungsumgebung und das installierte Software System in der Anwendungsumgebung Dar ber hinaus beinhaltet das ausf hrbare System Makefiles die das Zusammenbinden des bersetzten Komponenten Kodes zu lauff higen Produkten unterst tzen Folgende Produkte werden modifiziert e Probleml sungsdokumentation Dieses Dokument beinhaltet die Anforderungen an das zu entwickelnde Software System aus Sicht der Benutzer Kunden und der Entwickler
98. allen eingesetzten Beschreibungstechniken und methoden durchg ngige aufeinander abgestimmte reale Beispiele f r die Inhalte der Ent wicklungsprodukte ein Rollenkonzept das Rollen z B Anforderungsingenieur Entwurfsingeni eur Validierer definiert und den Rollen Entwicklungsaktivit ten zuweist eine vollst ndige Baseline d h die Charakterisierung des Entwicklungsprozes ses hinsichtlich der wichtigen Kenngr en Aufwand und Fehler im Kontext eines Projekts zur Entwicklung eines Geb udeautomationssystems Dieses Dokument richtet sich haupts chlich an Software Entwickler Die vorliegende Dokumentation kann als Anleitung zur Durchf hrung von Software Entwicklungsaktivit ten verwendet werden Es wird schrittweise erl utert welche Aktivit ten wie durchzuf hren sind Es wird beschrieben wie Aktivit ten mit anderen zusammenh ngen und in welcher Reihenfolge Aktivit ten durchzuf hren sind Dabei wird aufgezeigt welche 1 Nicht beschrieben wird die Entwicklung von Kommunikations und Betriebssystem schichten Entwicklung eingebetteter Software mit UML Zielsetzung Produkte ben tigt bzw erstellt werden und was der Inhalt dieser Produkte ist Abgerundet wird die Dokumentation durch ein durchg ngiges Beispiel das einen Eindruck von den entstehenden Produkten und ihren Inhalten vermittelt Projektmanager und planer die eine objektorientierte Methodik f r die Ent wicklung eingebetteter Software
99. ammen nachgezogen wurden z B wenn zwei Methoden zu einer Methode mit Parametern im Sequenzdiagramm zusammenge fasst wurden muss diese nderung auch im Klassendiagramm nachvollzogen wer den Die Konsistenzbedingungen aus dem Prozess A Klassendiagramme 134 Entwicklung eingebetteter Software mit UML Prozess UML Entwurf bearbeiten bearbeiten gelten weiterhin und werden evtl verfeinert z B muss berpr ft wer den ob e die Methoden mit Parametern und R ckgabewerten die eine Klasse im Zustandsdiagramm geschickt bekommt Events auch als Methoden mit Para metern und R ckgabewerten im Klassendiagramm definiert sind e die Methoden mit Parametern und R ckgabewerten die die Objekte einer Klasse in den Sequenzdiagrammen geschickt bekommen auch als Methoden mit Parametern und R ckgabewerten im Klassendiagramm definiert sind Folgende Produkte werden im Prozess E Klassendiagramme bearbeiten konsu miert e A Klassendiagramme e A Packagediagramme e Data Dictionary e Entwurfsentscheidungen e E Sequenzdiagramme e E Zustandsdiagramme e E Aktivit tsdiagramme Folgende Produkte werden produziert e E Packagediagramme e E Klassendiagramme e Unterschiede zur Analyse Prozess Klassenbeschreibungen Class Tables bearbeiten Im Teilprozess Class Tables bearbeiten werden die Klassen aus dem E Klassendiagramm mit ihren Attributen und ffentlichen Methoden erkl rt Einige CASE Werk
100. arbeiten 4 8 Prozess Verfolgbarkeitsmatrix Entwurf bearbeiten Im Prozess Verfolgbarkeitsmatrix Entwurf bearbeiten wird eine Beziehung zwi schen den Methoden und Attributen der Klassen des Entwurfs und den Methoden und Attributen der Klassen der E Anforderungen hergestellt F r jede Methode Attribut einer Klasse im Entwurf die das an der Realisierung einer Methode eines Attributs einer Klasse aus den E Anforderungen beteiligt ist wird ein Kreuz in die Matrix eingef gt Abbildung 75 zeigt den Prozess Verfolgbarkeitsmatrix Entwurf bearbeiten mit konsumierenden und produzierenden modifizierenden Produkten Software System Dokumentation U Probleml sungs O WM dokumentation UML Entwurf V Entwurfs S ingenieur U E Anforderungen A Klassendiagramme E Klassendiagramme Verfolgbarkeitsmatrix Entwurf ABBILDUNG 75 Verwendete Produkte des Prozesses Verfolgbarkeitsmatrix Entwurf bearbeiten Verfolgbarkeitsmatrix Entwurf bearbeiten Im Prozess Verfolgbarkeitsmatrix Entwurf bearbeiten werden folgende Produkte konsumiert Entwicklung eingebetteter Software mit UML 141 System Entwurf bearbeiten e A Klassendiagramme e E Klassendiagramme Folgendes Produkt wird produziert e Verfolgbarkeitsmatrix Entwurf Eine Generierung der Verfolgbarkeitsmatrix Entwurf aus vorhandenen Verfolgbar keitsbeziehungen ist grunds tzlich m glich Im Geb udeautomationsprojekt konnte di
101. as Klassendiagramm A Klassendia gramme bearbeiten und evtl in das Zustandsdiagramm A Zustandsdiagramme bearbeiten eingef gt werden Die Konsistenz zwischen den verschiedenen Dia grammen muss gew hrleistet werden Zu jedem Teilprozess werden im Weiteren Beispiele f r Konsistenzbedingungen angegeben Prozess A Klassendiagramme bearbeiten W hrend des Prozesses A Klassendiagramme bearbeiten werden Teilsysteme und Klassen innerhalb der Teilsysteme bestimmt und in Packagediagrammen und Klas sendiagrammen festgehalten Au erdem werden Beziehungen zwischen Klassen erarbeitet Beziehungen zwischen Klassen in verschiedenen Teilsystemen werden durch Beziehungen zwischen Packages verdeutlicht F r Teilsysteme und Klassen wird eine kurze Erl uterung eingef gt 76 Entwicklung eingebetteter Software mit UML Prozess E Anforderungen bearbeiten Klassen die in mehreren Teilsystemen verwendet werden sollten zu einem ausge zeichneten Teilsystem geh ren in dem Methoden und Attribute der Klasse bear beitet werden In anderen Teilsystemen d rfen die Klassen verwendet aber nicht bearbeitet werden Diese Beschr nkung ist sinnvoll um Inkonsistenzen zwischen Teilsystemen zu vermeiden und eindeutige Schnittstellen zu bilden Klassen innerhalb eines Teilsystems werden anhand der Begriffe aus der Anwen dung gebildet Referenzdokument Systemumgebung Attribute und Methoden werden anhand des gew nschten Verhaltens bestimmt
102. as in dem Geb udeautoma tionsprojekt verwendet wurde OO Dokumentation eines Testverfahrens Beim Integrations und Systemtest wurde im Geb udeautomationsprojekt das glei che Testverfahren verwendet Es wurde ein quivalenzklassentest durchgef hrt der zur berdeckung der Szenarien f hrte Das Testverfahren lie sich auch f r den Integrationstest anwenden da Teilsysteme nach den Verwendungsweisen des Sys tems gebildet wurden Entwicklung eingebetteter Software mit UML 63 System Anforderungen bearbeiten F r jede Ein und Ausgabevariable wurden g ltige und wenn m glich ung ltige quivalenzklassen gebildet Basierend auf den Szenarien wurden Kombinationen der quivalenzklassen der Eingabevariablen gebildet die zu einem identischen funktionalen Verhalten f hren Ein identisches funktionales Verhalten l sst sich dabei als quivalenzklasse einer Ausgabevariable ausdr cken Die aufgestellten Testpl ne f hrten zur berdeckung der Szenarien aus den B Anforderungen und damit zu einer berdeckung der informellen funktionalen und inversen Anforde rungen Zur berpr fung der nicht funktionalen Anforderungen wurden keine Testpl ne entwickelt Abbildung 35 zeigt einen Ausschnitt aus der Dokumentation des Testverfahrens Ziel des Systemtests ist es das System in der Entwicklungsumgebung gegen ber den B Anforderungen zu validieren Der Systemtest soll auf den Szenarien aus Kapitel 1 3 1 5 2 basieren da diese die B An
103. ationsquellen beobachten k nnen um Entwicklungen der Umwelt zu erkennen 2 vorbereitet sein auf zuf llig eintretende Ereignisse 3 f hig sein Ent scheidungen zu treffen die auf Ereignissen und der Beobachtung beruhen 4 in der Lage sein Aktionen in der Umwelt zu veranlassen Vier wesentliche Charakteristika eingebetteter Software seien an dieser Stelle her vorgehoben da sie auf den in diesem Bericht beschriebenen Entwicklungsprozess signifikanten Einfluss aus ben 1 Eingebettete Software muss weitgehend fehlerfrei sein Dies hat mehrere Ursachen Zum einen erwartet der sp tere Benutzer ein korrekt arbeitendes System zum anderen ist der Austausch der Software oftmals nicht m glich und somit kann auch keine Software Wartung stattfinden Einfluss auf den Entwicklungsprozess Aus den hohen Anforderungen an die Korrektheit resultiert die Qualit tsorientierung des Entwicklungsprozesses Hohe Qualit t eingebetteter Software wird insbesondere durch fr hzeitige Erkennung bzw systematische Vermeidung von Fehlern erzielt 2 Nicht funktionale Eigenschaften z B Echtzeitf higkeit Zuverl ssigkeit Feh lertoleranz haben eine besondere Bedeutung Dies hat seine Ursache vor allem in den Anwendungsgebieten von eingebetteten Systemen Echtzeitf higkeit ist beispielsweise in der Robotersteuerung von gro er Bedeutung Zuverl ssigkeit und Fehlertoleranz spielen eine gro e Rolle bei sicherheitskritischen Anwen dungen wie Flugzeugsteue
104. auch in den System Anforderungen und im Entwurf behoben Die Behebung wird in den Dokumenten A Verifikation und E Verifikation beschrieben Im Prozess Rework Komponenten Kode wird folgendes Produkt konsumiert e Entwicklungsrichtlinien Folgende Produkte werden modifiziert e A Use Cases e Szenarien e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation e A Validation e UML Entwurf e Komponenten Anforderungen e Verfolgbarkeitsmatrix Entwurf e E Verifikation 178 Entwicklung eingebetteter Software mit UML Prozess Ausf hrbare Komponente bearbeiten e E Validation e Komponenten Kode e Ausf hrbarer Komponenten Kode e K Verifikation 5 6 Prozess Ausf hrbare Komponente bearbeiten Im Prozess Ausf hrbare Komponente bearbeiten werden Komponententest Rah men f r den Test der Komponenten implementiert und bersetzt Zur Durchf h rung eines Tests wird der bersetzte Komponenten Kode mit dem zum Test geh renden Test Rahmen zusammengebunden Das Ergebnis ist ein ausf hrbares Binary Das ausf hrbare Binary wird ausgef hrt und Testausgaben werden im Dokument E Validation protokolliert Die Testausgaben werden mit dem erwarte ten Verhalten das in den Testpl nen beschrieben ist verglichen und Fehlverhalten werden dokumentiert Die Fehlverhalten werden auf Fehler in der System Doku mentation zur ckgef hrt und behoben Abbildung 94 zeigt den Prozess Ausf hrbar
105. barkeitsmatrix Anforderungen bearbeiten wird eine Beziehung zwischen den informellen tabellarischen B Anforderungen und den Klassen aus den E Anforderungen hergestellt F r jede Klasse die an der Realisierung einer informellen B Anforderung beteiligt ist wird ein Kreuz in der Matrix eingef gt Mit Hilfe von CASE Werkzeugen z B StP UML ist eine Generierung der Ver folgbarkeitsmatrix aus vorhandenen Verfolgbarkeitsbeziehungen m glich Um Ver folgbarkeitsbeziehungen anzulegen werden beispielsweise Beziehungen zwischen informellen B Anforderungen und Klassen per Mausklick gesetzt Abbildung 44 zeigt den Prozess Verfolgbarkeitsmatrix Anforderungen bearbeiten mit konsumierenden und produzierenden modifizierenden Produkten Entwicklung eingebetteter Software mit UML SI System Anforderungen bearbeiten Probleml sungs Dokumentation O B Anforderungen Informelle Anforderungs B Anforderungen ingenieur H E Anforderungen Verfolgbarkeitsmatrix D D Anforderungen bearbeiten u A Klassendiagramme Verfolgbarkeitsmatrix Anforderungen ABBILDUNG 44 Verwendete Produkte des Prozesses Verfolgbarkeitsmatrix Anforderungen bearbeiten Folgende Produkte werden konsumiert e Informelle B Anforderungen e A Klassendiagramme Folgendes Produkt wird produziert e Verfolgbarkeitsmatrix Anforderungen 82 Entwicklung eingebetteter Software mit UML Prozess System Anforderungen verifizie
106. be des Entwurfsingenieurs ist beim Teilsystem test gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben Qualit tsmanager Die Aufgabe des Qualit tsmanagers ist entsprechend den l ngerfristigen Bed rfnissen und Erwartungen einer Software Entwicklungsor ganisation Wissen Erfahrung in geeigneter Form zu verwalten einzelnen Pro jekten auf Anfrage zur Wiederverwendung zur Verf gung zu stellen und kontinuierlich aufgrund gemachter Projekterfahrungen zu verbessern Wissen Erfahrungen kann vom Qualit tsmanager im Prozess System Integration z B in Form von Fehlerklassifikationen zur Verf gung gestellt werden Diese sind zum Teil Bestandteil von Produkten f r die andere Rollen verantwortlich sind Entwicklung eingebetteter Software mit UML 199 System Integration O O ei O O System Validierer Anforderungs Entwurfs Kodierer integrations ingenieur ingenieur i ingenieur verantwortlich verantwortlich verantwortlich f r f r f r verantwortlich a f r f r Ausf hrbare X Komponente A Validation Software Komponenten Probleml sungs Dokumentation H Ausf hrbares dokumentation H System o x Teilsystemtest oftware System Dokumentation O Rahmen g ABBILDUNG 103 Ressourcen und Produkte des Prozesses System Integration 6 4 Kontrollfluss Die Reihenfolge der Bearbeitung der Teilprozesse ist in Form eines Pr zedenzgra phen in Abbildung 104 dargestellt Die Iterationen in denen die Kontrollfl
107. bleml sungsdokumentation diese umfasst die Analyse die Software System Dokumentation diese umfasst den Entwurf die Software Komponenten Doku mentation diese umfasst die Komponenten Entw rfe und den Kode sowie das ausf hrbare System Die Prozesse System Anforderungen bearbeiten System Entwicklung eingebetteter Software mit UML 17 Einf hrung Entwurf bearbeiten und System Komponenten bearbeiten umfassen jeweils eine abschlie ende Inspektion der erstellten Dokumente Die meisten Fehler die w h rend der Analyse gemacht wurden konnten w hrend der Anforderungsinspektion entdeckt werden Nur 0 46 der Analysefehler wurden erst in der Entwurfsphase und nur 0 76 bei der System Validation gefunden Dies spricht f r eine sehr effektive Anforderungsinspektion und einen hohen Reifegrad der verwendeten Checklisten Entwurfsfehler konnten nicht in diesem Umfang bei der Entwurfsveri fikation entdeckt werden 5 23 wurden erst in sp teren Phasen entdeckt Eine Analyse ergab dass vor allem auf Inkonsistenzen beruhende Fehler 24 sowie Unvollst ndigkeitsfehler 48 im Entwurfsdokument vorherrschten Dies ist auf eine unzureichende horizontale Verfolgbarkeit zwischen verschiedenen UML Ent wurfssichten zur ckzuf hren Bei der Komponentenentwicklung sind ca 20 der Fehler aufgetreten jedoch konnten die meisten 18 28 bei der Kodeinspektion entdeckt und daraufhin behoben werden Da das Modell die Fehler entspreche
108. ck ber die verwendeten Produkte im Prozess System Validation Folgende Produkte werden im Prozess System Validation konsumiert e Simulator Der Simulator ist ein Software System zur Simulation der Syste mumgebung Das Verhalten der Aktuatoren und Sensoren wird simuliert Die Schnittstelle des Simulators zum entwickelten Software System sollte der Schnittstelle der realen Aktuatoren und Sensoren entsprechen Entwicklung eingebetteter Software mit UML 209 System Validation Reale Systemumgebung Die reale Systemumgebung umfasst die real existieren den Sensoren und Aktuatoren In der Umgebung gelten die Beschr nkungen der realen Welt Die reale Systemumgebung ist nicht tats chlich ein Produkt Sie wurde an dieser Stelle als Produkt modelliert um die verschiedenen Tests des Systems zu beschreiben Folgende Produkte werden modifiziert Probleml sungsdokumentation Dieses Dokument beinhaltet die Anforderun gen an das zu entwickelnde Software System aus Sicht der Benutzer Kunden und der Entwickler Software System Dokumentation Dieses Dokument umfasst den UML Ent wurf f r das zu implementierende Software System Au erdem beinhaltet es Anforderungen an die zu implementierenden Komponenten im System Software Komponenten Dokumentation Dieses Dokument umfasst den Quell kode der implementierten Komponenten Ausf hrbare Komponente Dieses Produkt umfasst den bersetzten und mit einem Treiber und einer Menge Stubs zusammen
109. d dies als Fehlverhalten in der Tabelle zur Bewertung der Testergebnisse im Dokument A Validation doku mentiert Anschlie end werden die beschriebenen Fehlverhalten auf Fehler in der System Dokumentation zur ckgef hrt Die Fehler werden in der Fehlertabelle im Dokument K Verifikation festgehalten Die Tabelle zur Bewertung der Testergeb nisse wird um Verweise auf die Fehlernummern erweitert Der Kunde entscheidet dar ber ob er das vorliegende installierte System abnimmt oder nicht Eventuell akzeptiert der Kunde das System nur unter der Vorausset zung dass aufgedeckte Fehlverhalten noch im bereits installierten System behoben werden Folgende Produkte werden im Prozess Akzeptanztest durchf hren konsumiert e Reale Systemumgebung e Installiertes System Folgende Produkte werden modifiziert e A Validation 222 Entwicklung eingebetteter Software mit UML Prozess Test im Betrieb e K Verifikation Prozess Rework Akzeptanztest Im Prozess Rework Akzeptanztest werden die in der System Dokumentation lokali sierten und in der Fehlertabelle im Dokument K Verifikation dokumentierten Feh ler behoben Die Strategie zur Behebung der Fehler wird in den Verifikationskapiteln der zu ndernden Dokumente beschrieben Die Fehler werden entweder im installierten System beim Kunden nachgezogen oder die Korrektur wird mit einem sp teren Release des Systems herausgegeben Folgende Produkte werden im Prozess Rework
110. dem Dom nenwissen A Use Cases und Szenarien erarbeitet Das System selbst wird auf Ebene der B Anforderungen als Black box betrachtet Das Verhalten des Systems wird mittels Beziehungen zwischen Ein und Ausgabe gr en beschrieben Der Prozess B Anforderungen bearbeiten geschieht in Interaktion mit dem Benut zer Kunden Hauptziel ist ein gemeinsames Verst ndnis der Aufgabenstellung und des Anwendungsgebiets zwischen dem Anforderungsingenieur und dem Kunden Benutzer zu schaffen Abbildung 42 zeigt den Prozess B Anforderungen bearbeiten mit konsumierenden produzierenden und modifizierenden Produkten 70 Entwicklung eingebetteter Software mit UML Prozess B Anforderungen bearbeiten O O E Ee Probleml sungs Anforderungs Kunde dokumentation ingenieur Problem beschreibung B Anforderungen bearbeiten Dom nenwissen B Anforderungen Informelle B Anforderungen System A Use Cases bearbeiten umgebung A Use Cases Referenz Dokumente 2 Szenarien bearbeiten ABBILDUNG 42 Verwendete Produkte des Prozesses B Anforderungen bearbeiten Folgende Produkte werden konsumiert e Systemumgebung Dieses Dokument beschreibt spezielle Eigenschaften der Dom ne e Referenz Dokumente Diese Dokumente pr zisieren einzelne Systemaspekte oder schildern Erfahrungen aus hnlichen Projekten e Problembeschreibung Dieses Dokument beschreibt das zu l
111. der die Spalten die Attribute und Methoden der Klasse aus dem UML Entwurf Fehlende Kreuze in Spalten oder Zeilen sollten im Dokument Unterschiede zur Analyse erkl rt sein LightController Entwurf S SS e AE a 2 sIiz gt 5 3 2 2 0 8 81 3 2 2 2 lightStatus X LightController Gs z E Anforderungen switchLightOnO 2 switchLightOffO X ABBILDUNG 59 Ausschnitt aus der Verfolgbarkeitsmatrix der Klasse LightController Komponenten Anforderungen Die Komponenten Anforderungen erweitern die Beschreibung der Komponenten d h Klassen aus dem UML Entwurf Hauptziel der Komponenten Anforderun gen ist es eine unabh ngige Implementierung der Komponenten zu erlauben Daf r werden verwendete Datentypen definiert Private Methoden von Klassen sind bereits im E Klassendiagramm aufgetreten allerdings noch nicht beschrieben worden Konstruktoren und Destruktoren von Klassen werden aufgelistet Au er dem wird angegeben wie Assoziationen und Aggregationen zu realisieren sind Von einer Klasse importierte Datentypen und Methoden werden beschrieben Entwicklung eingebetteter Software mit UML 111 System Entwurf bearbeiten Die Komponenten Anforderungen umfassen zwei Kapitel 1 Allgemeine Datenty pen und 2 Klassendefinitionen Allgemeine Datentypen Die Allgemeinen Datentypen definieren die Datentypen die im UML Entwurf ver wendet wurden Die Datentypen k nnen
112. der Kunde Eine Rolle kann von mehreren Agenten gespielt werden ein Agent kann auch mehrere Rollen spielen In manchen F llen sind Rollen direkt f r Produkte verantwortlich Abbildung 4 zeigt wie Rol len und ihre Produktverantwortlichkeiten in diesem Bericht grafisch dargestellt werden e Entwurfs Verifizierer ingenieur TARIN f r verantwortlich f r Entwurfs Verfolgbarkeitsmatrix entscheidungen Entwurf K erifikations omponenten Anforderungen ABBILDUNG 4 Repr sentation von Rollen 12 Entwicklung eingebetteter Software mit UML Der Prozess im berblick 1 5 Der Prozess im berblick Abbildung 5 gibt einen berblick ber den Gesamtprozess In Anlehnung an zwei wesentliche Eigenschaften Dom nenorientierung und Iterativit t wird der Pro zess als Do it Prozess bezeichnet Es werden die Hauptprozesse auf der obersten Abstraktionsstufe gezeigt sowie die wesentlichen Produktfl sse Zur deutlicheren Darstellung des Gesamtprozesses werden nicht alle Produktfl sse dargestellt In der Abbildung sind jeweils nur diejenigen Rollen gezeigt die an der Durchf hrung der Prozesse wesentlich beteiligt sind Tats chlich sind jeweils eine Reihe weiterer Rollen involviert Software wird entwickelt und nicht produziert Somit ist auch jeder Prozess ein Unikat Der Do it Prozess ist nicht als allgemeing ltiger Prozess f r alle Software Entwicklungsprojekte in der Dom ne Eingebettete Systeme anzusehen Vielmehr
113. des Use Cases Flurlichtregelung_durch_Anwesenheit E Sequenzdiagramme Das E Sequenzdiagramm verfeinert das A Sequenzdiagramm zu Szenario 1 Abbildung 26 Ausschnitt aus dem Sequenzdiagramm zu Szenariol Flurlichtre gelung durch Anwesenheit auf Seite 52 Die Nachrichten die zwischen den Objekten verschickt werden sind im E Sequenzdiagramm beispielsweise angerei chert um Parameter Au erdem wurden Entscheidungen hinsichtlich der Klassen struktur umgesetzt wie das Zusammenfassen von Methoden z B personIn und personOut zu occupancyMessage zOccupancyType Existierende CASE Werkzeuge z B StP UML erlauben automatische berpr fungen der Konsistenz zwischen verschiedenen UML Diagrammen beispielsweise zwischen Sequenzdiagrammen und Klassendiagrammen Bei StP UML wird z B berpr ft ob die Nachrichten mit Parametern die ein Objekt im Sequenzdiagramm geschickt bekommt auch im Klassendiagramm als Methoden der Klasse definiert sind Da ein Sequenzdiagramm eine konkrete Benutzung des Software Systems wiederspiegelt m ssten im Sequenzdiagramm Parameter eigentlich konkrete Werte annehmen z B lightControl zLightStatusType cLightOn Eine konkrete Belegung der Parameter mit Werten macht allerdings die berpr fung der Konsis tenz zwischen Sequenzdiagramm und Klassendiagramm f r StP UML unm glich Aus diesem Grund werden im Beispiel konkrete Werte von Parametern und R ck gabewerte mit Bedingungen formuliert
114. durchg ngig von der Analyse bis zur Implementierung verwendet Ein bergang zwischen den Entwicklungsschritten ist ohne Paradig menwechsel m glich Entwicklung eingebetteter Software mit UML Charakterisierung des Entwicklungsprozesses Verhaltensorientiert Der Entwicklungsprozess legt einen Schwerpunkt auf die Beschreibung des Ver haltens des Systems Dies liegt einerseits an der komplexen Interaktion von einge betteter Software mit ihrer Umgebung Andererseits ist die Komplexit t eingebetteter Systeme urs chlich in ihren dynamischen Verhalten begr ndet und weit weniger in ihrer Architektur Die Verhaltensorientierung des Prozesses spie gelt sich beispielsweise in der umfassenden Modellierung von Zustands Sequenz und Kollaborationsdiagrammen w hrend der Anforderungsanalyse wider Qualit tsorientiert Der Prozess sieht an wichtigen Meilensteinen Verifikations und Validationsaktivi t ten vor die f r eingebettete Software ma geschneidert sind z B durch die Nut zung dom nenspezifischer Checklisten Ziel ist Fehler m glichst fr hzeitig zu erkennen und zu entfernen Um eine m glichst effektive und effiziente Fehlerer kennung und beseitigung zu unterst tzen sieht der Prozess eine systematische Dokumentation s mtlicher Entwicklungsdokumente auf allen Abstraktionsstufen vor Die Verfolgbarkeit dieser Dokumente wird durch matrixartige Tabellen beschrieben Dies erleichtert eine konsistente Durchf hrung von
115. e Integriere Teilsystem Integrationstest ABBILDUNG 98 Prinzip der System Integration 6 2 Produkte Im folgenden wird eine bersicht ber die im Prozess System Integration verwen deten Produkte gegeben Die bersicht beschreibt die interne Strukturierung der Dokumente Anschlie end erfolgt eine Beschreibung der Inhalte der Dokumente soweit dies nicht bereits in vorangegangenen Kapiteln erfolgt ist Entwicklung eingebetteter Software mit UML 191 System Integration Probleml sungsdokumentation Software System Dokumentation Siehe Abbildung 20 auf Seite 41 Siehe Abbildung 49 auf Seite 95 Ausf hrbares System Ausf hrbares Teilsystem Teilsystem Makefile Ausf hrbarer Teilsystem Kode Ausf hrbare Komponente Komponententest Rahmen Komponententest Stubs Komponententest Treiber Teilsystemtest Rahmen Ausf hrbarer Komponenten Kode Teilsystemtest Stubs Teilsystemtest Treiber Software Komponenten Dokumentation Ausf hrbarer System Kode Installiertes System Komponenten Kode K Verifikation ABBILDUNG 99 Produkt bersicht f r den Prozess System Integration Ausf hrbares System Das Ausf hrbare System umfasst alle zusammengesetzten ausf hrbaren Produkte dies sind die Ausf hrbaren Teilsysteme der Ausf hrbare Systemkode und das Installierte System Wenn ein Software System aus
116. e Beschrei bung der Systemumgebung Entwicklung eingebetteter Software mit UML 91 System Entwurf bearbeiten Folgende Produkte werden im Prozess System Entwurf bearbeiten modifiziert e Probleml sungsdokumentation Dieses Dokument beinhaltet die Anforderun gen an das zu entwickelnde Software System aus Sicht der Benutzer Kunden und der Entwickler e Software System Dokumentation Dieses Dokument umfasst eine Reihe von Entwurfsentscheidungen die beispielsweise auf die Systemumgebung oder auf Qualit tsanforderungen an das Software System zur ckzuf hren sind Es bein haltet den UML Entwurf und die Komponenten Anforderungen Der UML Ent wurf beschreibt die endg ltige Aufteilung des Software Systems in Komponenten die Interaktion zwischen diesen und das Verhalten der Kompo nenten Die Komponenten Anforderungen erg nzen die Beschreibungen der Komponenten aus dem UML Entwurf Die Software System Dokumentation umfasst au erdem eine Verfolgbarkeitsmatrix Entwurf mit deren Hilfe Zusam menh nge zwischen den System Anforderungen und dem UML Entwurf expli zit gemacht werden Des Weiteren enth lt die Dokumentation Dokumente zu Verifikationsaktivit ten auf System Entwurfsebene z B eine Fehlerklassifika tion eine Checkliste zur Inspektion des Entwurfs Fehlertabellen zur Dokumen tation gefundener Fehler und Fehlerursachen und Dokumente zu Validationsaktivit ten z B Testpl ne zum Test von Komponenten sowie Tabellen zur Do
117. e Data Dictionary Prozess A Sequenzdiagramme bearbeiten F r jedes Szenario aus den B Anforderungen wird ein Sequenzdiagramm gebildet Das Verhalten des Systems wird als Interaktion von Objekten der Klassen aus dem Klassendiagramm beschrieben Die Namenskonventionen geben Richtlinien f r Benennungen von Bezeichnern z B Bezeichner werden der engl Sprache ent nommen Die Konsistenz der anderen UML Diagramme mit dem Sequenzdia gramm muss sichergestellt sein Daf r muss u a gepr ft werden ob e Methoden einer Klasse im Klassendiagramm im Sequenzdiagramm verwendet werden e Events im Zustandsdiagramm als Nachrichten modelliert sind die ein Objekt einer Klasse geschickt bekommt e Aktionen im Zustandsdiagramm als Nachrichten modelliert sind die ein Objekt einer Klasse verschickt Folgende Produkte werden im Prozess A Sequenzdiagramme bearbeiten konsu miert e Systemumgebung e Referenz Dokumente e Namenskonventionen e A Use Cases e Szenarien e A Packagediagramme 78 Entwicklung eingebetteter Software mit UML Prozess E Anforderungen bearbeiten e A Klassendiagramme e A Zustandsdiagramme e A Aktivit tsdiagramme Folgendes Produkt wird produziert e A Sequenzdiagramme Prozess A Kollaborationsdiagramme bearbeiten Im Prozess A Kollaborationsdiagramme bearbeiten werden aus den Sequenzdia grammen Kollaborationsdiagramme abgeleitet Mit CASE Werkzeugen z B StP UML k
118. e Haus falsch geschrieben F umlentwbearb ABBILDUNG 33 Ausschnitt aus der Fehlertabelle Lichtregelung Flur A Fehlerbehebungsstrategien In den Tabellen zur Dokumentation der Fehlerbehebungsstrategie wird verdeut licht welche Fehler aus den A Fehlertabellen in den System Anforderungen beho ben wurden und wie dies geschehen ist Au erdem wird in den Tabellen die Behebung von Anforderungsfehlern dokumentiert die die Ursache f r Fehler in folgenden Entwicklungsprodukten waren und erst dort entdeckt wurden Diese Fehler sind in den E und K Fehlertabellen dokumentiert Die A Fehlerbehebungs strategien geben Aufschluss ber den Stand der Rework Aktivit ten Anhand der Tabellen kann au erdem entschieden werden ob eine erneute Verifikation der ge nderten B und E Anforderungen notwendig ist Entwicklung eingebetteter Software mit UML 61 System Anforderungen bearbeiten Abbildung 34 zeigt einen Ausschnitt aus einer solchen Tabelle f r das Teilsystem LichtregelungFlur BANJA A Fehlerbehebungsstrategien In der Tabelle werden alle Fehler aus den A Fehlertabellen der A Verifikation auf gef hrt Au erdem dokumentiert die Tabelle die Behebung eines Anforderungsfeh lers der erst im Kode entdeckt wurde K LF FNr3 K f r Kode Die Beschreibung der Strategie zur Behebung der Fehler erlaubt das Nachvollziehen was sich in den System Anforderungen ge ndert hat Referenz auf Behebung des F
119. e Komponente bearbeiten mit konsu mierenden produzierenden und modifizierenden Produkten Folgende Produkte werden im Prozess Ausf hrbare Komponente bearbeiten modi fiziert e Ausf hrbare Komponente e Komponenten Kode e K Verifikation e UML Entwurf e Verfolgbarkeitsmatrix Entwurf e Komponenten Anforderungen e E Verifikation e E Validation e A Use Cases e Szenarien Entwicklung eingebetteter Software mit UML 179 System Komponenten bearbeiten e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation e A Validation 180 Entwicklung eingebetteter Software mit UML Prozess Ausf hrbare Komponente bearbeiten o o I CH Validierer Kodierer O Software Komponenten e i Dokumentation Entwurfs Anforderungs Komponenten Kode ingenieur ingenieur Ausf hrbare K Verifikation Komponente bearbeiten Komponententest Software System Rahmen erstellen Dokumentation Ausf hrbare Komponente Ay Komponententest Ausf hrbare Komponente LU Rahmen erstellen d Komponententest N Komponententest Stubs durchf hren E Validation Komponententest Treiber Probleml sungs dokumentation Rework Komponententest D Ausf hrbarer Komponenten Kode ABBILDUNG 94 Verwendete Produkte des Prozesses Ausf hrbare Komponente bearbeiten Prozess Komponententest Rahmen erstellen Im Prozess Komponentente
120. e Matrix nicht generiert werden da die E Anforderungen und der UML Entwurf als zwei StP Systeme verwaltet werden Beziehungen zwischen zwei Sys temen lassen sich unter StP UML nicht herstellen 4 9 Prozess System Entwurf verifizieren Im Prozess System Entwurf verifizieren wird der erstellte Systementwurf die Kom ponenten Anforderungen und die Verfolgbarkeitsmatrix Entwurf gegen die E Anforderungen verifiziert Anleitungen f r und Ergebnisse der Verifikation werden im Dokument E Verifikation dokumentiert Im folgenden wird sich auf die Inspektion als Verifikationsaktivit t eingeschr nkt Ein Inspektionsprozess umfasst drei Teilprozesse 1 Lesen des zu inspizierenden Dokuments System Entwurf Review vorbereiten 2 Durchf hren einer Inspekti onssitzung zur Besprechung aufgedeckter Fehler Reviewsitzung System Entwurf und 3 berarbeiten des verifizierten Dokuments zur Behebung von Fehlern Rework System Entwurf Abbildung 76 zeigt den Prozess System Entwurf verifizieren mit konsumierenden produzierenden und modifizierenden Produkten 142 Entwicklung eingebetteter Software mit UML Prozess System Entwurf verifizieren O F Verifizierer Probleml sungsdokumentation O O E LU B Anforderungen Entwurfs Anforderungs Software System ingenieur ingenieur Dokumentation U gp Entwurfs System Entwurf verifizieren entscheidungen H U System Entwurf Review vorbereiten U
121. e facility manager and the cont rol system The control system is composed of hardware and software components The building is influenced by its environment mainly the weather Building Structure Sections The fourth floor of building 32 consists of three sections and shares two staircases SCE and SCW with other floors of the building as shown in figure 1 A section consists of adjacent or separated groups of rooms accessible via hall ways and or connecting doors Sections are divided into offices O computer labs CL peripheral rooms P mee ting rooms M and hallways H There are three hallways and 22 rooms to control Figure 1 also shows the six outdoor light sensors ols1 ols6 and the major compass directions The sensors cover the six directions of the different walls The number in the rooms express the kind and a unique number ABBILDUNG 13 Ausschnitt aus der Beschreibung der Geb udearchitektur 28 Entwicklung eingebetteter Software mit UML Produkte Referenz Dokumente In einzelnen Projekten kann es zus tzliche Dokumente geben die z B einzelne Systemaspekte pr zisieren oder Erfahrungen aus hnlichen Projekten schildern Abbildung 14 und Abbildung 15 zeigen Ausschnitte aus derartigen Referenz Doku menten Referenz Problembeschreibung und Zeit Referenzmodell BANJA Referenz Problembeschreibung Die Referenz Problembeschreibung wurde vom Kunden bereitgestellt und dient dem n heren Verst nd
122. e interne Strukturierung der Dokumente Anschlie end erfolgt eine Beschreibung der Inhalte soweit dies f r das Verst ndnis des Prozesses Projekt ini tialisieren erforderlich ist Probleml sungsdokumentation N Problembeschreibung Verfolgbarkeitsmatrix Anforderungen B Anforderungen A Verifikation A Checkliste Fehlerklassifikation Informelle B Anforderungen Funktionale B Anforderungen A Fehlertabellen A Fehlerbehebungsstrategien A Validation A Use Cases Szenarien A Testverfahren A Testpl ne Nicht funktionale B Anforderungen Inverse B Anforderungen A Testergebnisse E Anforderungen A Ergebnisbewertung A Packagediagramme A Klassendiagramme Data Dictionary A Sequenzdiagramme A Kollaborationsdiagramme A Zustandsdiagramme A Aktivit tsdiagramme Dom nenwissen Systemumgebung Referenz Dokumente ABBILDUNG 10 Produkt bersicht f r den Prozess Projekt initialisieren 24 Entwicklung eingebetteter Software mit UML Produkte Problembeschreibung Dieses Dokument beschreibt den Bedarf f r ein zu entwickelndes Software Sys tem Es beschreibt die in einer speziellen Dom ne existierenden Probleme oder strategischen Ziele die durch das Einf hren des Systems gel st oder erreicht wer den sollen Die Problembeschreibung enth lt au erdem die wichtigsten Anforde rungen an die Funktionalit t des Systems Die Problembeschreibung dient als Motivation f r die
123. eb udeauto mationsprojekt verwendeten Simulators TO Simulator Der Simulator simuliert die Sensoren und Aktuatoren im Geb ude Er stellt eine graphische Oberfl che zum Anzei gen und Manipulieren der Aktuatoren und Sensoren zur Verf gung Der Geb ude Simulator ist ein ERLANG Programm Es bietet folgendes Basisfunktionalit t f r eine diskrete Simulation _Funktionaltit t f r eine diskrete Simulation von kontinuierlichen Systemen Eine Menge von Simulationsobjekten die n tzlich sind um physikalische Effekte in Geb uden zu simulieren Verschiedene Hilfsmittel um auf den Zustand der Simulationsobjekte w hrend der Simulation zuzugreifen Die Schnittstelle des Simulators entspricht der Schnittstelle der tats chlichen Aktuatoren und Sensoren Im BuildungSimulationWindow k nnen verschiedene Objekte z B Fenster Heizk rper R ume und die Umge bung des Hauses angew hlt und ber den Button Objekt Fenster ge ffnet werden Daraufhin werden die Eigen schaften dieser Objekte in eigenen Fenstern angezeigt In diesen Fenstern kann man die Zust nde der einzelnen Aktuatoren ablesen und die Werte der Sensoren ver ndern ABBILDUNG 110 Ausschnitt aus der Beschreibung eines Simulators Reale Systemumgebung Die reale Systemumgebung umfasst die real existierenden Sensoren und Aktuato ren im Geb ude In der realen Systemumgebung herrschen die Beschr nkungen der realen Welt die nicht beeinflusst werden
124. ef hrt und behoben Dieser Prozess wird nicht in der letzten Iteration d h nach der Integra tion zum Gesamtsystem durchgef hrt Abbildung 106 zeigt den Prozess Integrationstest mit konsumierenden produzie renden und modifizierenden Produkten 204 Entwicklung eingebetteter Software mit UML Prozess Integrationstest Ausf hrbares System Software System Dokumentation Ausf hrbares Teilsystem Teilsystemtest Ausf hrbare Rahmen Komponente O Ausf hrbarer LI Teilsystem Kode Validierer O Teilsystem O O LI LI Makefile Anforderungs Entwurfs i ingenieur ingenieur Kei Probleml sungs dokumentation A Validation Integrationstest Teilsystemtest durchf hren Ausf hrbarer System Kode Installiertes System Rework Teilsystem Software Komponenten Dokumentation K Verifikation ABBILDUNG 106 Verwendete Produkte im Prozess Integrationstest Folgende Produkte werden im Prozess Integrationstest modifiziert e Probleml sungsdokumentation e Software System Dokumentation e Software Komponenten Dokumentation e Ausf hrbare Komponente e Ausf hrbares System Entwicklung eingebetteter Software mit UML 205 System Integration Prozess Teilsystemtest durchf hren Im Prozess Teilsystemtest durchf hren werden die lauff higen Teilsystem Binaries ausgef hrt W hrend der Ausf hrung werden Testausgaben produziert u
125. ehlers Strategie zur Behebung des Fehlers durchgef hrt FNr IN A LF FNr1 Package LichtregelungFlur wurde mit passendem J Kommentar eingef gt A LF FNr2 Die Klasse Haus wurde in House umbenannt J Aufruf beim Zustands bergang wurde von EENG SwitchOff in SwitchOn ge ndert J ABBILDUNG 34 Ausschnitt aus der Tabelle zur Dokumentation der Fehlerbehebungsstrategie Teilsystem Lichtregelung Flur A Validation Das Produkt A Validation umfasst alle Dokumente die f r die Validation von zusammengesetzten ausf hrbaren Produkten d h von Teilsystemen und von dem System gegen die System Anforderungen wichtig sind Dies sind 1 eine Beschreibung der durchgef hrten Testverfahren f r Teilsystem System und Akzeptanztest 2 die aufgestellten Tesrpl ne 3 die Ergebnisse der durchgef hrten Tests sowie 4 eine Bewertung der Testergebnisse und die Dokumentation von Fehl verhalten 62 Entwicklung eingebetteter Software mit UML Produkte Es ist wichtig Testpl ne aufzustellen und durchgef hrte Tests und Testergebnisse zu dokumentieren um gegebenenfalls Tests wiederholen zu k nnen Regressions test F r das weitere Verst ndnis werden zun chst die Begriffe Integrationstest System test und Akzeptanztest definiert Beim Integrationstest auch Teilsystemtest genannt werden ausf hrbare Teilsysteme unter Zuhilfenahme eines Testrahmens gegen die B Anforderungen getestet Ein Test von
126. ehrfacher Ausf hrung vorhanden sein Dies ist im Kontext der jeweiligen Beschreibung erkennbar Die hier eingef hrte Produktstruktur muss sich nicht unmittelbar auf Dateiebene widerspiegeln eine eindeutige Zuordnung von Produkten und Teilpro dukten zu Dateien ist jedoch erforderlich In diesem Bericht werden die Produkte jeweils in einem gr eren Zusammenhang vor den zugeh rigen Entwicklungsakti vit ten beschrieben da zum einen Entwickler oftmals sehr viel mehr mit Entwick lungsprodukten vertraut sind als mit deren Ei stellungs bzw Bearbeitungsprozeduren und zum anderen die Beschreibung der Entwicklungsakti vit ten eine Kenntnis der Produkte voraussetzt Entwicklung eingebetteter Software mit UML 9 Einf hrung Prozesse Ein Prozess synonym Aktivit t beschreibt eine Menge partiell geordneter Schritte um ein Ziel zu erreichen Beispiele f r Prozesse sind das Erstellen der System Anforderungen die Bearbeitung des Entwurfs die Verifikation von Kode komponenten die Integration von Teilsystemen oder ein Akzeptanztest Prozesse k nnen als Verfeinerung eine Menge von Teilprozessen besitzen die wiederum verfeinert sein k nnen Im Anhang ist eine bersicht ber die gesamte Prozesshie rarchie enthalten Prozesse sind gegenstandslose Ph nomene der realen Welt Des halb werden in diesem Bericht grafische Repr sentationen zur Darstellung von Prozessen benutzt Abbildung 2 zeigt beispielsweise den Prozess Problembe sc
127. em Anforderungen Im Prozess Rework System Anforderungen werden die Fehler aus der Fehlerliste behoben Dabei wird die Strategie zur Behebung des Fehlers dokumentiert um nderungen an den Dokumenten zu verdeutlichen Dies geschieht mit Hilfe der Tabelle zur Dokumentation der Fehlerbehebungsstrategie im Dokument A Verifi kation Im Prozess Rework System Anforderungen werden folgende Produkte modifiziert e A Use Cases 86 Entwicklung eingebetteter Software mit UML Prozess Testf lle bearbeiten e Szenarien e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation 3 9 Prozess Testf lle bearbeiten Entsprechend des f r den Teilsystem System und Akzeptanztest ausgew hlten Testverfahrens werden Testpl ne entwickelt Ein m gliches Testkriterium zum Test der Funktionalit t des Systems besteht in der berdeckung der in den B Anforde rungen entwickelten Szenarien Daf r werden beispielsweise in einem ersten Schritt Kombinationen von quivalenzklassen von Eingabewerten gebildet die zu einem identischen funktionalen Verhalten f hren In einem zweiten Schritt werden die eigentlichen Testpl ne erstellt in denen f r jede Eingangsvariable Eingangs werte f r die Testdurchf hrung und jede Ausgangsvariable Ausgangwerte d h erwartetes Systemverhalten konkrete Werte festgelegt werden Neben Testpl nen zum Test des Verhaltens des Systems sollten Testpl ne zum Test der nicht fun
128. em Anforderungen und des Entwurfs drei Aspekte berpr ft werden 1 Sind die Dokumentationsrichtlinien erf llt d h ist das Dokument syntaktisch korrekt 2 Ist die Qualit t des Dokuments ausreichend d h ist das Dokument semantisch korrekt und 3 Ist das Dokument mit dem Vorg ngerdokument konsistent In der Checkliste werden zu jedem Aspekt Fragen gestellt Werden Fragen in der Check liste mit Nein beantwortet dann K nnte es sich um einen Fehler handeln Abbildung 83 zeigt einen Ausschnitt aus einer Checkliste zur berpr fung des Komponenten Kodes BANJA K Checkliste berpr fe zu jeder Klasse die hh und cc Datei auf Einhaltung der Dokumentationsrichtlinien 1 Wurden die Entwicklungsrichtlinien eingehalten Hier ist insbesondere die Einhaltung der Programmierrichtlinien zu berpr fen Namenskonventionen Vermeidung von bestimmten Anweisungstypen Gestaltung und Dokumentation des Kodes usw Interne Konsistenz des Kodes 1 Wenn einer Variablen ein Wert zugewiesen wird die Variable wird definiert Wird die Variable im weite ren verwendet referenziert Zwei Arten von Anomalien k nnen gefunden werden DD Definiert Definiert und DU Definiert Undefiniert Diese Anomalien sind Fehler die nicht direkt zu einem Fehlverhalten des Systems f hren Konsistenz zum Entwurf 1 Sind alle Attribute aus den Class Tables im Kode enthalten 2 Sind alle Methoden mit Parametern und R ckgabetypen aus den Class
129. en Die funktionalen BA F und inversen BA Inv informellen B Anforderungen wur den im Beispiel nach Teilsystemen geordnet Der Ausschnitt zeigt funktionale B Anforderungen f r die Lichtregelung in einem Flurbereich abgek rzt LichtF und inverse Anforderungen f r die Temperaturregelung abgek rzt Temp Die nicht funktionalen BA NF informellen B Anforderungen betreffen Qualit tsanforde rungen an das Gesamtsystems und lassen sich nicht Teilsystemen zuordnen Abk rzung Beschreibung der Anforderung nisseichend Wenn ein Flurbereich von einer Person belegt ist dann soll das Licht in LichtF BA Fl Flurlicht diesem Bereich angeschaltet werden damit sich die Person sicher bewegen kann d h die Lichtintensit t muss gt 14 LUX sein Bevor eine Person einen Flurbereich betritt muss das Licht in dem zu LichtF BA F2 Eintrittslicht betretenden Bereich angeschaltet werden wenn das Licht in diesem Bereich nicht ausreichend ist BA NF Abk rzung Beschreibung der Anforderung BA NFI Flexibilit t Das System soll leicht nderbar sein BA Inv Abk rzung Beschreibung der Anforderung Die Raumtemperatur darf nicht unter eine Temperatur fallen bei der die Tom BA Einfrierschutz Heizungsrohre einfrieren Das System muss garantieren dass dies niemals passiert ABBILDUNG 12 Ausschnitt aus den informellen B Anforderungen f r ein Geb udeautomationssystem Entwicklung eingebetteter Software m
130. en ver vollst ndigt Daf r ist ein Verst ndnis der Dom ne Dom nenwissen wichtig Die 1 Fehlverhalten Failure Abweichung zwischen dem tats chlichen Verhalten des ausge f hrten Systems und seinem geforderten erwarteten Verhalten 2 Fehler Fault In der Dokumentation d h in einem Produkt befindliches Problem z B Schnittstellenfehler Initialisierungsfehler oder unklare Beschreibung Ein Fehler kann zu Fehlverhalten des Systems f hren 3 Fehlerursache Error Menschlicher Defekt Fehlhandlung der zu Fehlern f hrt z B Nichtverstehen des zu l senden Problems 38 Entwicklung eingebetteter Software mit UML Prozessverfeinerung B Anforderungen werden im Prozess E Anforderungen bearbeiten in eine f r Ent wickler vertraute Notation berf hrt und verfeinert die sog E ntwickler Anforde rungen Beim Verfeinerungsprozess flie t erneut Wissen aus der Dom ne ein Namenskonventionen gew hrleisten eine einheitliche Namengebung in allen weite ren Entwicklungsprodukten Zus tzlich wird im Prozess Verfolgbarkeitsmatrix Anforderungen bearbeiten eine Verfolgbarkeitsmatrix aufgestellt die sog Verfolg barkeitsmatrix Anforderungen in der Zusammenh nge zwischen den B Anforde rungen und den E Anforderungen beschrieben werden Im Prozess System Anforderungen verifizieren werden die B Anforderungen gegen die Problembe schreibung und die E Anforderungen gegen die B Anforderungen sowie die Ver folgbarke
131. en werden alle Klassen und die zu der jeweiligen Klasse geh rigen Attribute Methoden und Assoziationen beschrieben Im Gegensatz zu den Klassendiagrammen beschreibt das Data Dictionary keine Sichten auf eine Klasse sondern fasst die Informationen bez einer Klasse aus allen Klassendiagrammen zusammen Abbildung 25 zeigt einen Ausschnitt aus einem Data Dictionary f r die Klasse LightControlUnit aus dem Teilsystem Lichtre gelungFlur des Geb udeautomationssystems 50 Entwicklung eingebetteter Software mit UML Produkte OO Data Dictionary Das Beispiel zeigt einen Ausschnitt der informellen Beschreibung der Klasse LightControlUnit aus dem Data Dictionary Erl utert wird die Klasse mit Ihren Attributen Methoden und Beziehungen Die Methoden fmSwitchOff und fmSwitchOn sind im Klassendiagramm der LichtregelungFlur nicht enthalten Sie sind im Klassendiagramm Benutzungsschnittstelle beschrieben Zu beschreibendes Attribut Methode Objekt Assoziation Beschreibung Diese Klasse beschreibt eine Einheit die aus den Informationen ber Anwesenheit im Flur und ber den Status der Lichtanlage das entsprechende Verhalten dieser Lichtanlage ausl st mSwitchOffO Diese Methode wird aufgerufen falls der Hausmeister das Licht im Flur ber das ControlPanelFM ausschalten m chte SwitchOnO Diese Methode wird aufgerufen falls der Hausmeister ber age den ControlPanelFM das Licht im
132. entierte Softwareentwicklung mit der Unified Modeling Language Oldenburg Verlag 4 aktualisierte Auflage 1998 James Rumbaugh Michael Blaha William Premerali Objektorientiertes Modellieren und Entwerfen Hanser Elektronik M nchen 1993 M Shaw D Garlan Software architecture perspectives on an emerging disci pline Prentice Hall 1996 148 Entwicklung eingebetteter Software mit UML Weiterf hrende Literatur 12 Wolfgang Wagenbichler Erstellung einer SW Systemdokumentation mit StP Projektarbeit Fachbereich Informatik Universit t Kaiserslautern 67653 Kai serslautern 1999 URL http wwwagse informatik uni kl de access system publications html 8 Entwicklung eingebetteter Software mit UML 149 System Entwurf bearbeiten 150 Entwicklung eingebetteter Software mit UML KAPITEL 5 System Komponenten bearbeiten Ziel des Prozesses System Komponenten bearbeiten ist die Implementierung und Validierung der im UML Entwurf und den Komponenten Anforderungen beschrie benen Komponenten Die Implementierung und Validierung kann f r jede Kompo nente unabh ngig erfolgen Der Komponenten Kode als Ergebnis der Implementierung wird in der Software Komponenten Dokumentation fixiert Abbildung 78 gibt einen berblick ber die verwendeten Produkte im Prozess Sys tem Komponenten bearbeiten Folgendes Produkt wird konsumiert es Entwicklungsrichtlinien Dieses Dokument beinhaltet Richtlinien f
133. er Kodierer Systemintegrations ingenieur Qualit tsmanager eck ITT Rework Akzeptanztest gt lt Kunde Test im Betrieb Test im Betrieb durchf hren Rework Test im Betrieb 234 Entwicklung eingebetteter Software mit UML ANHANG C Kontrollfluss Im Folgenden wird die Abarbeitungsreihenfolge der einzelnen Prozesse in Form eines Pr zedenzgraphen angegeben N here Angaben hierzu k nnen den entspre chenden Kapiteln entnommen werden Entwicklung eingebetteter Software mit UML 235 Kontrollfluss Projekt initialisieren Problembeschreibung bearbeiten Informelle B Anforderungen Dom nenwissen bearbeiten bearbeiten A Use Cases bearbeiten Szenarien bearbeiten B Anforderungen bearbeiten A Sequenz A Klassen A Zustands A Aktivit ts diagramme diagramme diagramme diagramme bearbeiten bearbeiten bearbeiten bearbeiten A Kollaborations Data Dictionar diagramme an y bearbeiten Verfolgbarkeitsmatrix Anforderungen bearbeiten l 5 E 52 EE S S 3 KE lt w Testf lle y System Anforderungen Review bearbeiten vorbereiten y Reviewsitzung System Anforderungen Rework System Anforderungen m Teilprozess von Teilprozess von y System Integration System Entwurf Entwurfentscheidungen Teilsystemtest bearbeiten erstellen Rahmen erstellen System Anforderungen verifiziere
134. er Zusammenh nge zwischen den E Anforderungen und dem UML Entwurf beschrie ben werden Im Prozess System Entwurf verifizieren werden der UML Entwurf die Komponenten Anforderungen und die Verfolgbarkeitsmatrix Entwurf gegen die E Anforderungen und die Entwurfsentscheidungen inspiziert Im Prozess Komponen ten Testf lle bearbeiten werden aus dem UML Entwurf und den Komponenten Anforderungen Testpl ne f r einen sp teren Test der fertiggestellten Komponenten abgeleitet Entwicklung eingebetteter Software mit UML 93 System Entwurf bearbeiten Dom nen wissen D Namens konventionen Probleml sungs Dokumentation System Entwurf bearbeiten Entwurfsentscheidungen erstellen Software System Dokumentation Problem beschreibung UML Entwurf H bearbeiten Entwurfs entscheidungen B Anforderungen c Komponenten Anforderungen erstellen E Anforderungen Komponenten Verfolgbarkeitsmatrix Entwurf bearbeiten Anforderungen Verfolgbarkeitsmatrix Anforderungen Verfolgbarkeitsmatrix Entwurf A Verifikation System Entwurf verifizieren E Verifikation A Validation Komponenten Testf lle bearbeiten E Validation ABBILDUNG 48 Verfeinerung des Prozesses System Entwurf bearbeiten 94 Entwicklung eingebetteter Software mit UML Produkte 4 2 Produkte Im Folgenden wird eine b
135. er eines Raums Au erdem wird in den Dokumenten beschrieben wie die Akteure das System benutzen 2 Welche Aufgaben soll das System erf llen Diese Frage kann einerseits unter Verwendung der Problembeschreibung und der informellen B Anforderungen beantwortet werden Andererseits sollte fest gestellt werden welche Gr en gemessen und vom System kontrolliert werden sollen Aus diesen Gr en l sst sich ableiten was das System leisten soll Zur Bestimmung der Gr en kann wieder die Beschreibung der Sensoren und Aktuatoren aus der Systemumgebung herangezogen werden Jeder Use Case wird kurz mit Hilfe des bereitgestellten Schemas beschrieben Use Cases k nnen in Teil Use Cases verfeinert werden z B wenn mehrere Use Cases in einem Teil vollst ndig gleich sind kann der gleiche Teil in einem separa ten Use Case beschrieben werden Die anderen Use Cases benutzen dann den aus gelagerten Use Case Erfahrungen aus dem Geb udeautomationsprojekt zeigen jedoch dass eine Verfeinerung von Use Cases durch die Entwickler als eine funkti onale Zerlegung des Systems verstanden werden kann Mit einer Verfeinerung sollte deshalb vorsichtig umgegangen werden Folgende Produkte werden im Prozess A Use Cases bearbeiten konsumiert e Systemumgebung 72 Entwicklung eingebetteter Software mit UML Prozess B Anforderungen bearbeiten e Referenz Dokumente e Problembeschreibung e Informelle B Anforderungen Folgendes Produkt
136. ergeordnet und der PresenceController ist wiederum dem PRHallwayLight Controller untergeordnet Das Klassendiagramm wurde mit dem CASE Werkzeug StP UML erstellt Ein Minus vor einem Attribut oder einer Methode bedeutet dass es sich um ein inter nes Attribut oder eine interne Methode handelt nach au en nicht sichtbar Ein Plus kennzeichnet eine ffentliche Methode ffentliche Attribute sollten aus Gr n den des Information Hidings vermieden werden Eine Tabelle an der linken obe ren Ecke einer Klasse zeigt an dass zu der Klasse eine Klassentabelle existiert In dieser k nnen Attributen und Methoden zus tzliche Eigenschaften zugewiesen werden Entwicklung eingebetteter Software mit UML 49 System Anforderungen bearbeiten PresenceController entry Time exitTime LightControlUnit setExitTime setEntryTime personln setCurrentTime personOut getStatus changedLightStatus timeRunOut LichtStatus beeinflusse erung weiterleiten Anwesenheit weiterleiten PRHallwayLightController ZA LightController EEE s switchLightOn switchLightOff Klassendiagramm LichtregelungFlur Dieses Diagramm zeigt alle Klassen die an der Erbringung der Funktionalit t der Lichtregelung in den Flurabschnitten beteiligt sind ABBILDUNG 24 Klassendiagramm des Teilsystems LichtregelungFlur Data Dictionary Im Data Dictionary der E Anforderung
137. ern erweitert Folgendes Produkt wird im Prozess Komponententest durchf hren konsumiert e Ausf hrbarer Komponente Kode Folgende Produkte werden modifiziert e E Validation e K Verifikation Prozess Rework Komponententest Im Prozess Rework Komponententest werden die in der System Dokumentation lokalisierten und in der Fehlertabelle im Dokument K Verifikation dokumentierten Fehler behoben Die Strategien zur Behebung der Fehler werden in den Verifikati onskapiteln der zu ndernden Dokumente beschrieben Folgende Produkte werden modifiziert e Komponenten Kode e Ausf hrbare Komponente e K Verifikation e UML Entwurf e Komponenten Anforderungen e Verfolgbarkeitsmatrix Entwurf e E Verifikation e E Validation e A Use Cases e Szenarien e E Anforderungen 184 Entwicklung eingebetteter Software mit UML Weiterf hrende Literatur Verfolgbarkeitsmatrix Anforderungen A Verifikation A Validation 5 7 Weiterf hrende Literatur 1 A F Ackerman L S Buchwald F H Lewski Software Inspections An Effec tive Verification Process In Donald J Reifer EDS Software Management Sth Edition IEEE Computer Society Kapitel 10 S 416 421 1997 Karsten Buch Richtlinien zur Ableitung von C Kode aus OMT Statemodels der Entwurfsphase Projektarbeit Fachbereich Informatik Universit t Kaisers lautern 67653 Kaiserslautern Mai 1997 Barbara Kitchenham Steve Linkman V
138. ersicht ber die im Prozess System Entwurf bearbeiten verwendeten Produkte gegeben Die bersicht beschreibt die interne Strukturie rung der Dokumente Anschlie end erfolgt eine Beschreibung der Inhalte der Dokumente soweit dies nicht bereits im vorangegangenen Kapitel erfolgt ist Probleml sungsdokumentation Namenskonventionen Siehe Abbildung 20 auf Seite 41 Dom nenwissen Systemumgebung Referenz Dokumente Software System Dokumentation Entwurfsentscheidungen UML Entwurf Unterschiede zur Analyse E Klassendiagramme Class Tables E Use Cases E Sequenzdiagramme E Kollaborationsdiagramme E Zustandsdiagramme E Aktivit tsdiagramme E Packagediagramme Verfolgbarkeitsmatrix Entwurf Komponenten Anforderungen Allgemeine Datentypen Klassendefinitionen E Verifikation E Checkliste Fehlerklassifikation E Fehlertabellen E Fehlerbehebungsstrategien E Validation E Testverfahren E Testpl ne E Testergebnisse E Ergebnisbewertung ABBILDUNG 49 Produkt bersicht f r den Prozess System Entwurf bearbeiten Entwicklung eingebetteter Software mit UML System Entwurf bearbeiten Entwurfsentscheidungen Die Entwurfsentscheidungen beschreiben Implementierungsentscheidungen f r das zu entwickelnde Software System Sie schr nken die Menge der m glichen Reali sierungen ein Entwurfsentscheidungen resultieren beispielsweise aus
139. erungen aufgedeckt worden sein Er kann aber auch in nachfolgen den Prozessen gefunden worden sein z B beim Erstellen des Entwurfs Der Pro zess w hrend dessen ein Fehler gefunden wurde ist in der Tabelle vermerkt z B sysanfrevvorb als Abk rzung f r System Anforderungen Review vorbereiten Die Fehler werden mit Hilfe des Produkts und des Teilsystems in dem sie aufge 60 Entwicklung eingebetteter Software mit UML Produkte treten sind gekennzeichnet Produkt Teilsystem FNr Nummer Ein Fehler wird durch das betroffene Diagramm und das betroffene Element sowie durch eine kurze Fehlerbeschreibung charakterisiert Abbildung 33 zeigt einen Ausschnitt aus einer A Fehlertabelle f r das Teilsystem LichtregelungFlur A Fehlertabellen Die A Fehlertabelle dokumentiert zwei Fehler im Teilsystem LichtregelungFlur in den System Anforderungen Beide Fehler befinden sich in der Beschreibung der statischen Struktur des Systems Packagediagramm und Klassendiagramm Der eine Fehler wurde beim Lesen der Anforderungen gefunden Der andere Fehler wurde erst bei der Erstellung des UML Entwurfs gefunden Prozess 2 w hrend R 8 dessen der betroffenes betroffenes allgemeine ke FNr f Fehler Diagramm Element Fehlerbeschreibung 2 gefunden ZS wurde Abk rzung A LE FNr1 Packagestruk Package Lichtrege Package Beschrei U sysanfrevvorb tur lungFlur bung fehlen A LF FNr2 Klassendiag Klass
140. erwendete Produkte des Prozesses Akzeptanztest Prozess Installiere System Im Prozess Installiere System wird das System beim Kunden eingerichtet d h Sensoren und Aktuatoren werden installiert und das entwickelte Software System wird auf den Zielrechner portiert Folgendes Produkte werden im Prozess Installiere System konsumiert Entwicklung eingebetteter Software mit UML 221 System Validation e Ausf hrbarer System Kode e Reale Systemumgebung Folgendes Produkt wird produziert e Installiertes System Prozess Akzeptanztest durchf hren Im Prozess Akzeptanztest durchf hren wird das System in der realen Systemumge bung getestet Gew hnlich wird dieser Test durch den Kunden Benutzer durchge f hrt Dabei wird das Verhalten des installierten Systems mit dem in den B Anforderungen beschriebenen Verhalten verglichen Das installierte System wird im Einsatz getestet Wenn das System den Test besteht dann wird das System vom Kunden akzeptiert Zur Durchf hrung des Tests kann der Kunde die Testpl ne aus dem Dokument A Validation verwenden Das w hrend des Akzeptanztests gezeigte Verhalten des Systems wird im Doku ment A Validation im Abschnitt Dokumentation der Testergebnisse beschrieben und mit dem erwarteten Verhalten des System verglichen Das erwartete Verhalten kann den Testpl nen entnommen werden Gibt es Unterschiede zwischen dem tat s chlichen und dem erwarteten Verhalten des Systems wir
141. es die Beziehungen zwischen den Klassen sowie Attribute und Methoden von Klassen beschreibt In jedem Klassendiagramm sind die Methoden und Attribute einer Klasse darge stellt die f r die Erbringung der im Klassendiagramm beschriebenen Funktionali t t erforderlich sind Tritt eine Klasse in mehreren Klassendiagrammen auf d h wird sie zur Erbringung unterschiedlicher Funktionalit ten ben tigt dann zeigen einzelne Klassendiagramme nur Sichten auf diese Klasse Die E Klassendiagramme sind verfeinerte und berarbeitete A Klassendiagramme Da das E Klassendiagramm die endg ltige Struktur des Software Systems beschreibt und Beziehungen zwischen den Klassen entsprechend des Diagramms Entwicklung eingebetteter Software mit UML 101 System Entwurf bearbeiten realisiert werden wird das A Klassendiagramm unter Entwurfsgesichtspunkten berarbeitet und verfeinert Parameter und R ckgabewerte werden bestimmt und Datentypen festgelegt Damit Werte im Software System Klassen erreichen k n nen m ssen Durchreichmethoden in Klassen erg nzt werden das Initialisieren und L schen von Objekten muss sichergestellt werden und die System Struktur sollte optimiert werden d h die Kopplung im Software System wird minimiert und die Koh sion maximiert Au erdem wird das A Klassendiagramm hinsichtlich der getroffenen Entwurfsentscheidungen z B hinsichtlich Verteilung oder Paralleli t t berarbeitet Jedes Klassendiagramm wird kurz e
142. essen f r das System Gr en aus der Umgebung und ber Aktuato ren beeinflusst das System die Umgebung Die Beschreibung der Sensoren und Aktuatoren erfolgt gleichzeitig mit der groben Beschreibung der Funktionalit t des Systems Erst wenn klar ist welche Funktionalit t das System bieten soll kann definiert werden welche Aktuatoren und Sensoren vom System zur Erbringung der Funktionalit t ben tigt werden Im Dokument Systemumgebung sollte es au erdem ein ausgezeichnetes Data Dictionary geben in dem die Begriffe des Anwendungsbereichs erl utert werden Auf diese Weise wird eine Interaktion zwischen dem Kunden und den Entwicklern erleichtert Dar ber hinaus wird im Prozess Dom nenwissen bearbeiten gepr ft ob bereits hnliche Projekte initialisiert wurden Wenn dies der Fall ist werden Erfahrungen aus diesen Projekten in Referenz Dokumenten f r die weitere Entwicklung zur Verf gung gestellt Folgendes Produkt wird im Prozess Dom nenwissen bearbeiten konsumiert e Informelle B Anforderungen Entwicklung eingebetteter Software mit UML 33 Projekt initialisieren Folgendes Produkt wird modifiziert e Dom nenwissen 2 7 Prozess Informelle B Anforderungen bearbeiten Im Prozess Informelle B Anforderungen bearbeiten werden die in der Problembe schreibung festgehaltenen Anforderungen an das zu entwickelnde System pr zi siert und erweitert Die informellen B Anforderungen werden durch den Kunden in
143. estLightStatus gibt den Status der Lichtanlage Licht ein ausgeschaltet zur ck Signatur void setLightControlUnit lightControlUnitPtr LightControlUnit Beschreibung Die Methode setLightControlUnit dient der nachtr glichen bergabe eines Pointers auf ein Objekt der Klasse LightControlUnit Die Notwendigkeit dieser Methode ergibt sich aus der Initialisierungsreihenfolge das LightController Objekt wird vor dem LightControlUnit Objekt erzeugt der Objekte der Klassen LightControlUnit und LightController ABBILDUNG 54 Ausschnitt aus der Klassenbeschreibung der Klasse LightController E Use Case Diagramm E Use Cases Zur Einordnung der verfeinerten E Sequenzdiagramme wird das Use Case Dia gramm A Use Cases aus den B Anforderungen wiederholt Das Diagramm und eine Erl uterung kann Abbildung 26 Ausschnitt aus dem Sequenzdiagramm zu Szenariol Flurlichtregelung durch Anwesenheit auf Seite 52 entnommen wer den An den A Use Cases werden keine Ver nderungen vorgenommen 104 Entwicklung eingebetteter Software mit UML Produkte E Sequenzdiagramme Die E Sequenzdiagramme des UML Entwurfs beschreiben das Verhalten des Soft ware Systems durch die Interaktion zwischen den zu implementierenden Objekten Die E Sequenzdiagramme sind verfeinerte und berarbeitete A Sequenzdia gramme Sie sind an die Entwurfsentscheidungen und kriterien angepasst Abbildung 10 zeigt ein E Sequenzdiagramm zu Szenariol
144. forderungen berdecken Vor Erstellung der Testpl ne werden zuerst Eingangs und Ausgangsvariablen festgelegt die wiederum in quivalenz klassen eingeteilt werden Die in den Szenarien angegebenen Werte werden anschlie end den quivalenzklassen zugeordnet Im folgenden werden zuerst die quivalenzklassen der einzelnen Variablen aufgef hrt Im Anschluss stehen die Pl ne der Systemtestf lle die sich aus der Angabe der Werte f r die Eingangs und Ausgangsvariablen zusammenset zen Eingangs bzw Ausgangsvariable g ltige quivalenzklasse offen AnwesenheitskontaktImd1Doorl geschlossen on LichtstatusFlur off ABBILDUNG 35 Ausschnitt aus der Dokumentation eines Testverfahrens Dokumentation der Testpl ne A Testpl ne In der Beschreibung eines Testplans werden die Werte der Eingangsvariablen beschrieben Au erdem wird notiert welche Werte die Ausgangsvariablen einneh men m ssen d h wie sich das System verhalten muss Abbildung 36 zeigt einen Testplan zur berdeckung des Szenariol des Use Cases Lichtregelung_durch_Anwesenheit 64 Entwicklung eingebetteter Software mit UML Produkte Dokumentation der Testpl ne Die Anzahl der Testpl ne entspricht der Anzahl der Szenarien Da die Testpl ne die Szenarien berdecken wurde bei der Beschreibung ein Verweis auf den Szenario Schritt integriert Die Werte der Ausgabevariablen zeigen das Verhalten des Sys tems
145. forderungen an die Funktionalit t des Systems abgeleitet Der Bedarf wird in der Problembeschreibung motiviert dies geschieht im Prozess Problembeschreibung bearbeiten Zur Unterst tzung der weiteren System Entwicklung wird Dom nenwissen dokumentiert im Prozess Dom nenwissen bearbeiten Daf r wird einerseits die Systemumgebung beschrie ben Andererseits wird berpr ft ob bereits hnliche Projekte initialisiert wurden Ist dies der Fall werden Erfahrungen aus diesen Projekten in Referenz Dokumen ten bereitgestellt Im Prozess Informelle B Anforderungen bearbeiten werden die Anforderungen aus der Problembeschreibung konkretisiert und erweitert O O O Kunde Dom nen Anforderungs experte ingenieur Projekt initialisieren Probleml sungs dokumentation Problembeschreibung bearbeiten Problem beschreibung Dom nenwissen B Anforderungen bearbeiten Informelle B Anforderungen Informelle B Anforderungen bearbeiten ABBILDUNG 9 Verfeinerung des Prozesses Projekt initialisieren Entwicklung eingebetteter Software mit UML 23 Projekt initialisieren 2 2 Produkte Im Folgenden wird eine bersicht ber die im Prozess Projekt initialisieren ver wendeten Produkte gegeben Enth lt ein Produkt weitere Produkte werden alle Teilprodukte aufgef hrt auch wenn sie nicht im Prozess Projekt initialisieren ben tigt werden z B E Anforderungen oder A Verifikation Die bersicht beschreibt di
146. ftware System Dokumentation Dieses Dokument umfasst den UML Ent wurf f r das zu implementierende Software System Au erdem beinhaltet es Anforderungen an die zu implementierenden Komponenten im System Probleml sungs dokumentation System H Komponenten bearbeiten SW Komponenten A Dokumentation Software System Dokumentation Ausf hrbare Komponente Entwicklungs richtlinien ABBILDUNG 78 Verwendete Produkte des Prozesses System Komponenten bearbeiten 152 Entwicklung eingebetteter Software mit UML Prozessverfeinerung 5 1 Prozessverfeinerung Der Prozess System Komponenten bearbeiten unterteilt sich in zwei Prozesse siehe Abbildung 79 Ausgehend vom UML Entwurf und den Komponenten Anforderungen wird im Prozess Quellkode bearbeiten der Komponenten Kode f r die einzelnen Komponenten entwickelt Die Entwicklungsrichtlinien geben Anlei tungen zur Durchf hrung des Prozesses Anschlie end wird der Komponenten Kode bersetzt Teil des Prozesses Quellkode bearbeiten ist au erdem die Verifika tion des Quellkodes gegen den Entwurf und die Entwicklungsrichtlinien Die Ergebnisse der Verifikation werden im Kapitel X Verifikation der Software Kompo nenten Dokumentation dokumentiert Im Prozess Ausf hrbare Komponente bear beiten werden f r jede Komponente Test Rahmen entsprechend der im Dokument E Validation festgehaltenen Testpl ne entwickelt Der bersetzte
147. gebundenen Kode der Kompo nenten Ausf hrbares System Dieses Produkt umfasst alle zusammengesetzten ausf hr baren Produkte Dies sind die ausf hrbaren Teilsysteme das ausf hrbare Sys tem und das installierte System 210 Entwicklung eingebetteter Software mit UML Prozessverfeinerung Probleml sungs dokumentation Software System 5 Dokumentation Software Komponenten Dokumentation Ausf hrbare Komponente Ausf hrbares o System ABBILDUNG 107 Verwendete Produkte des Prozesses System Validation System Validation o Reale Systemumgebung 7 1 Prozessverfeinerung Der Prozess System Validation unterteilt sich in drei Teilprozesse siehe Abbildung 108 Im Prozess Systemtest wird das System gegen die B Anforderungen unter Verwendung des Simulators getestet Der Simulator simuliert dabei die Systemum gebung W hrend des Prozesses Akzeptanztest wird das System gegen die B Anforderungen in der Anwendungsumgebung d h der realen Systemumgebung getestet Real existierende Sensoren werden gelesen und Aktuatoren angesteuert Wenn der Kunde das System nach dem Test akzeptiert wird es in den laufenden Betrieb bernommen Es folgt der Prozess Test des Systems im Betrieb Wenn w hrend der verschiedenen Tests Fehlverhalten des Systems auftreten werden diese auf Fehler in der Dokumentation zur ckgef hrt und behoben Entwicklung eingebetteter Software mit
148. gestellt sein Daf r muss berpr ft werden ob nderungen in den anderen UML Diagrammen im Zustandsdiagramm nachgezogen wurden Die Konsistenzbedingungen aus dem Prozess A Zustandsdiagramme bearbeiten gel ten weiterhin und werden evtl verfeinert z B muss berpr ft werden ob e die Methoden mit Parametern und R ckgabewerten die die Objekte einer Klasse in den Sequenzdiagrammen geschickt bekommen in dem Zustandsdia gramm der Klasse als Events mit Parametern und R ckgabewerten modelliert sind e die Methoden mit Parametern und R ckgabewerten die die Objekte einer Klasse in den Sequenzdiagrammen verschicken als Aktionen im Zustandsdia gramm modelliert sind Entwicklung eingebetteter Software mit UML 137 System Entwurf bearbeiten Folgende Produkte werden im Prozess E Zustandsdiagramme bearbeiten konsu miert e A Zustandsdiagramme e Entwurfsentscheidungen e E Packagediagramme e E Klassendiagramme e E Sequenzdiagramme e E Aktivit tsdiagramme Folgendes Produkt wird produziert e E Zustandsdiagramme Prozess E Aktivit tsdiagramme bearbeiten Im Prozess E Aktivit tsdiagramme bearbeiten werden die A Aktivit tsdiagramme aus den E Anforderungen verfeinert und hinsichtlich der Entwurfsentscheidungen und weiterer Entwurfskriterien berarbeitet Informelle Beschreibungen von Ope rationen in den E Anforderungen werden pr zisiert F r komplexe Operationen die w hrend des System Entw
149. ghtControlUnit 124 Entwicklung eingebetteter Software mit UML Produkte E Ergebnisbewertung Nachdem die Tests anhand der Testpl ne durchgef hrt und die Testergebnisse dokumentiert sind kann die Auswertung der Tests erfolgen Daf r werden die Tes tergebnisse mit dem im Testplan dokumentierten Ausgabeverhalten d h Ausga ben und Aufrufe von Stubs der Komponente verglichen Die Ergebnisse der Auswertung d h entdeckte Fehlverhalten der Komponente werden mit Hilfe einer Tabelle dokumentiert Abbildung 68 zeigt einen Ausschnitt aus einer Tabelle zur Dokumentation von gefundenen Fehlverhalten E Ergebnisbewertung Die Fehlverhalten werden zur leichteren Referenzierung durchnummeriert wobei die Nummer den Validationsschritt KV Komponentenvalidation und das Teilsys tem LF LichtregelungFlur enth lt Die Angabe des Schritts im Testplan erlaubt das leichtere Nachvollziehen der aufgedeckten Fehlverhalten Verweis FV Nr aus Schritt im Beschreibung des Fehlverhaltens Verweis auf KomprTest Fehler Nr KompfTest KV LE FVNrl Kompfest3 Schritt 6 Das Licht wird ausgeschaltet anstelle ange K LE FNr 23 schaltet Der Methodenaufruf Timer getCurrent Schritt 4 Time fehlt Schritt 4 und 8 wobei in fal K LF FNr 25 5 7 8 9 sche Zust nde gesprungen wird Schritt 5 7 K LF FNr 26 9 KV LF FVNr2 KompTest7 ABBILDUNG 68 Ausschnitt aus der Tabelle zur Bewertung der
150. gramme Die Kollaborationsdiagramme verfeinern wie die Sequenzdiagramme die Szena rien aus den B Anforderungen Sie bilden das in den Szenarien beschriebene Ver halten des Systems auf die Interaktion zwischen Objekten innerhalb des Systems ab Die Kollaborationsdiagramme betonen die Zusammenarbeit von Objekten Mit Hilfe eines CASE Werkzeugs z B des CASE Werkzeugs StP UML lassen sich die Kollaborationsdiagramme automatisch aus den Sequenzdiagrammen gene rieren Abbildung 27 zeigt ein Kollaborationsdiagramm zu Szenariol des Use Cases Flurlichtregelung_durch_Anwesenheit Die Kollaborationsdiagramme beschreiben die gleiche Informationen wie die Sequenzdiagramme Welche Darstellungsweise zum Verst ndnis des Systems her angezogen wird bleibt der benutzenden Rolle berlassen Beispielsweise kann es f r den Benutzer einfacher sein das in den Szenarien beschriebene Verhalten in den Sequenzdiagrammen wiederzufinden F r den Verifizierer mag die horizontale Konsistenz z B zwischen Klassen und Kollaborations Sequenzdiagrammen leichter unter Verwendung der Kollaborationsdiagramme berpr fbar sein OO A Kollaborationsdiagramm Szenario1 UmlUseCase Flurlichtregelung_durch_Anwesenheit imd1 Contact Actor PresenceController 1 getValue 2 getStatus PRHallwayLightController 3 personin LightControlUnit 4 switchLightOn 5 switchOn 6 isOn ABBILD
151. he Modellierung verschiedener UML Sichten zur ckzuf hren 16 Entwicklung eingebetteter Software mit UML Planung Die Produktivit t bezogen auf den Gesamtaufwand lag im Anwendungsprojekt jedoch mit 8 LOC h Lines of Code Stunde weit ber dem Durchschnitt indus trieller Projekte 5 LOC h f r Organisationen mit CMM Level 3 Das Fehlerslippagemodell in Abbildung 7 zeigt eine Verteilung der Fehler auf Pro dukte Es ist nach den Produkten in denen die Fehler auftreten gegliedert und gibt Auskunft ber den jeweiligen Zeitpunkt der Entdeckung eines Fehlers Besonders f llt auf dass die meisten der besonders teuren Anforderungsfehler 96 bereits fr hzeitig bei der Anforderungsinspektion entdeckt wurden 45 0 15 Sys Val Fehler 0 76 Sys Val Sys Val 40 4 Entdeckungsprozess p 5 07 Sys Komp bea gsp 0 46 Sys 35 Ent 2 E System Validation OSystem Integration 30 O System Komponenten bearbeiten E System Entwurf bearbeiten 25 ElSystem Anforderung bearbeiten 1 54 Sys Val 20 35 67 Sys Ent bea 15 4 18 28 Sys 10 4 Komp bea 38 1 Sys 54 Anf bea 0 0 7 r r Probleml sungs Software System Software Komponenten Ausf hrbares System Ursprungsprodukt dokumentation Dokumentation Dokumentation 39 32 40 89 19 82 0 ABBILDUNG 7 Fehlerverteilung Das dargestellte Fehlerslippagemodell zeigt die Verteilung der Fehler ber die Pro
152. he Schritte im Use Case durchgef hrt werden e Expected behavior beschreibt was das Ziel des Use Cases ist und womit der Use Case endet e Exceptions beschreiben m gliche Ausnahmen und Abweichungen vom Pfad der in der Description beschrieben wurde e Restrictions beschreiben nicht funktionale Anforderungen die sich einzelnen Verwendungen des Systems zuordnen lassen e Post condition beschreibt den Zustand nach Durchf hrung des Use Cases Das Use Case Diagramm mit Erl uterungen zu den einzelnen Use Cases dient als Diskussionsgrundlage zwischen Benutzern Kunden und Entwicklern um ein gemeinsames Verst ndnis des gew nschten Systems und des Anwendungsgebiets zu f rdern Jeder abstrakte Use Case wird mit einer Reihe von Szenarien veran schaulicht PANJA Use Case Diagramm A Use Cases Das Beispiel zeigt den Use Case Flurlichtregelung_durch_Anwesenheit Jeder Use Case wird mit Hilfe eines vorgegebenen Schemas erl utert Au erdem werden zu jedem Use Case die zugeh rigen Szenarien angegeben Der Use Case Flurlichtregelung_durch_Anwesenheit wird durch einen Benutzer engl User externer Akteur ausgel st der einen Flurabschnitt betritt oder verl sst Die Perso nenan oder abwesenheit wird durch den PresenceController interner Akteur der Teil des Systems ist festgestellt Der Anwesenheitssensor wurde in diesem Bei spiel nicht als Akteur modelliert da er ein passiver Sensor ist und damit die Sys temreakti
153. hecklisten basierten Inspektionstechnik als Verifikationsaktivit t Das Dokument A Verifika tion umfasst dann 1 eine A Checkliste 2 eine Fehlerklassifikation 3 eine Liste der gefundenen Fehler A Fehlertabellen und 4 eine Beschreibung der Fehlerbe hebungsstrategie A Fehlerbehebungsstrategien 58 Entwicklung eingebetteter Software mit UML Produkte A Checkliste Die A Checkliste unterst tzt das Lesen der zu verifizierenden B und E Anforde rungen und erleichtert das Finden von Problemen in den Dokumenten Pro Dokument m ssen drei Aspekte berpr ft werden 1 Sind die Dokumentationsrichtlinien erf llt d h ist das Dokument syntaktisch korrekt 2 Ist die Qualit t des Dokuments ausreichend d h ist das Dokument semantisch korrekt und 3 Ist das Dokument mit dem Vorg ngerdokument konsistent In der Checkliste werden zu jedem Aspekt Fragen gestellt Werden Fragen in der Checkliste mit Nein beantwortet dann k nnte es sich um einen Fehler handeln Abbildung 31 zeigt einen Ausschnitt aus einer A Checkliste zur berpr fung der Use Cases im Use Case Diagramm BANJA A Checkliste In diesem Abschnitt sind die Aspekte aufgelistet die bei der Verifikation der B und E Anforderungen zu beachten sind berpr fe jeden Use Case im Use Case Diagramm auf Einhaltung der Dokumentationsrichtlinien LE Wurde die UML Syntax eingehalten 2 Existiert ein Akteur f r den Use Case 3 Existiert zu dem Use
154. hreibung erstellen F r diesen Prozess werden die Teilprodukte Systemumge bung und Referenzdokumente beides Teilprodukte des Dom nenwissens ben tigt Resultat des Prozesses ist eine Problembeschreibung die Teil der Pro bleml sungsdokumentation ist Prozessverfeinerungen werden analog zu Produkt verfeinerungen dargestellt Manche Prozesse k nnen mehrfach instantiiert werden So kann es beispielsweise f r jede Systemkomponente einen Prozess zu ihrer Imp lementierung geben Die Beziehungen zwischen Prozessen und Produkten auch Produktfluss genannt lassen sich folgenderma en unterscheiden 1 ein konsumie render Produktfluss bedeutet dass ein Produkt in einem Prozess gelesen werden kann 2 ein produzierender Produktflu bedeutet dass ein Produkt in einem Pro zess erstellt wird schreibender Zugriff und 3 ein modifizierender Produktfluss bedeutet dass auf ein Produkt sowohl schreibend als auch lesend zugegriffen wer den darf Die grafischen Darstellungen vermitteln eine grobe Beschreibung der erlaubten Produktfl sse Detailliertere Beschreibungen befinden sich jeweils in den Erl uterungen zu den einzelnen Prozessen 10 Entwicklung eingebetteter Software mit UML Prozessbeschreibung Dom nenwissen S Probleml sungs System dokumentation umgebung Problembeschreibung Problem erstellen g beschreibung Referenz Dokumente Legende DL Produkt wird von Prozess konsumiert C lt Produkt wird
155. htController o HallwaySection o House o Yearlnterval o Light o LightController o LightControlUnit o PRBlindController o Pres enceController o PresenceControllerHallway o PresenceControllerRoom o PRHallwayLightController o PRLight Controller o PRTempController o RadiatorController o RadiatorValve o Room o RoomLightController o RoomLightControllerWithBlinds o RoomLightControllerWithoutBlinds o RoomLightRegulator o RoomLightRegu latorWithBlinds o RoomLightRegulatorWithoutBlinds o RoomTemperatureController o RoomWithBlinds o Room WithoutBlinds o ScheduledFct o Schedulero Section o Slist o DayIntervals o TemperatureData o Temperatureregulator o TemperatureregulatorWithBlinds o TemperatureregulatorWithoutBlinds o DefinitionOfTem pOpModus o Time o Timer o Holidays o Valuelnterface o ValuelnterfaceWithBlinds o ValuelnterfaceWithout Blinds o Weekintervals o TimelntervalExit o HeatingPeriod o ClassTimelntervalEntryNormal o Linke die lokalen OBJS und die globalen GLOBALOBJS zum Systemtest Teilsystemtest OBJS CXX LDFLAGS o OBJS GLOBALOBJS_FULLPATH echo Teilsystemtest erfolgreich erzeugt ABBILDUNG 102 Ausschnitt aus einem Teilsystem Makefile Ausf hrbarer Teilsystem Kode Der Ausf hrbare Teilsystem Kode enth lt f r jedes Teilsystem die bersetzten Test Rahmen Au erdem umfasst er f r jedes Teilsystem ein lauff higes Binary zur Durchf hrung der Tests Ausf hrbarer System Kode Der Ausf hrbare System Kode umfasst das
156. icht ausgeschaltet Expected behavior Die Lampe wird an oder ausgeschaltet Postcondition Eine Person ist im Flurabschnitt anwesend und die Lampe ist angeschaltet oder keine Person ist seit ZeitspanneVerlassen Minuten im Flurabschnitt und die Lampe ist ausgeschaltet Restrictions Combination with Use Case Dieser Use Case wird in folgenden Szenarien verdeutlicht Flurlichtregelung_durch_Anwesenheit_Szenariol Flurlichtregelung_durch_Anwesenheit_Szenario2 Flurlichtregelung_durch_Anwesenheit_Szenario3 ABBILDUNG 21 Ausschnitt aus einem Use Case Diagramm mit Erl uterung des Use Cases Flurlichtregelung_durch_Anwesenheit 44 Entwicklung eingebetteter Software mit UML Produkte Szenarien Ein Use Case repr sentiert ein m gliches Verhalten des Systems abstrakt z B das Licht im Flur wird durch Anwesenheit geregelt Ein Szenario beschreibt eine kon krete Interaktionssequenz zwischen einem Akteur und dem System die zu einem Systemverhalten f hrt F r einen Use Case kann es verschiedene Szenarien geben die abh ngig von den konkreten Eingabevariablen sind z B eine Person betritt den Flur oder eine Person verl sst den Flur F r jedes m gliche initiating event eines Use Cases wird ein Szenario entwickelt Die Szenarien werden nach den zugeh rigen Use Cases durchnummeriert Jedes Szenario enth lt eine kurze Beschreibung und die Vorbedingungen die zum Durchlaufen des Szenarios erf ll
157. ieur Die Aufgabe des Anforderungsingenieurs ist bei den Tests gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben Entwurfsingenieur Die Aufgabe des Entwurfsingenieurs ist bei den Tests gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben Kodierer Die Aufgabe des Kodierers ist bei den Tests gefundene Fehler in den ihm zugeordneten Dokumenten zu beheben Systemintegrationsingenieur Die Aufgabe des Systemintegrationsingenieurs ist bei den Tests gefundene Fehler im Ausf hrbaren System zu beheben Qualit tsmanager Die Aufgabe des Qualit tsmanagers ist entsprechend den l ngerfristigen Bed rfnissen und Erwartungen einer Software Entwicklungsor ganisation Wissen Erfahrung in geeigneter Form zu verwalten einzelnen Pro jekten auf Anfrage zur Wiederverwendung zur Verf gung zu stellen und kontinuierlich aufgrund gemachter Projekterfahrungen zu verbessern Entwicklung eingebetteter Software mit UML 215 System Validation O O O N O Validierer Anforderungs Entwurfs Kodierer System ingenieur ingenieur integrations verantwortlich verantwortlich ingenieur verantwortlich f r f r f r er H verantwortlich verantwortlich f r idati f r Ausf hrbare A Validation Komponente o robleml sungs N Software Komponenten Dokumentation oO S dokumentation U System oftware System Dokumentation 4 ABBILDUNG 111 Ressourcen und Produkte des Prozesses System Validation 7 4 Kont
158. ifikation e E Validation e A Use Cases e Szenarien e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation e A Validation 7 6 Prozess Akzeptanztest Im Prozess Akzeptanztest wird das System in der Anwendungsumgebung d h der realen Systemumgebung beim Kunden getestet Daf r muss das System zuerst beim Kunden installiert werden Prozess Installiere System Das Ergebnis des Akzeptanztests entscheidet ber die Abnahme des Systems durch den Kunden Im Gegensatz zur Verwendung des Simulators lassen sich die realen Umgebungsbe dingungen beim Test nicht beeinflussen Entdeckte Fehlverhalten werden protokol liert auf Fehler in der Dokumentation zur ckgef hrt und behoben Abbildung 113 zeigt den Prozess Akzeptanztest mit konsumierenden produzieren den und modifizierenden Produkten 220 Entwicklung eingebetteter Software mit UML Prozess Akzeptanztest 7 ER Software Komponenten Validierer Kunde System integrations Dokumentation a ingenieur K Verifikation O Reale E T LI Systemumgebung Anforderungs Entwurfs Kodierer j ingenieur ingenieur Akzeptanztest Installiere System Ausf hrbares System Ausf hrbarer D System Kode UN Akzeptanztest durchf hren dokumentation Installiertes System Rework Akzeptanztest Probleml sungs De dokumentation A Validation 3 Software System u Ausf hrbare Komponente ABBILDUNG 114 V
159. ildung 30 zeigt einen Ausschnitt aus einer Verfolgbarkeitsmatrix Anforderungen f r die informel len B Anforderungen des Teilsystems LichtregelungFlur des Geb udeautomati onssystems Entwicklung eingebetteter Software mit UML 57 System Anforderungen bearbeiten Mit Hilfe eines CASE Werkzeugs das Verfolgbarkeitsbeziehungen zwischen B und E Anforderungen verwaltet l sst sich die Verfolgbarkeitsmatrix Anforderun gen automatisch generieren Eine Schnittstelle zu einem Requirements Manage ment Werkzeug wie DOORS ist in diesem Kontext ebenfalls n tzlich OO Verfolgbarkeitsmatrix Anforderungen Die Verfolgbarkeitsmatrix zeigt beispielsweise dass an der Realisierung der infor mellen Anforderung LichtF BA F1 f nf Klassen beteiligt sind Light Light ControlUnit LightController PRHallwayLightController und PresenceController Light LightControlUnit LightController Outdoor TemperatureSensor PRBlindController PRHallwayLightController PRLightController PRTempController PresenceController LichtF BA Fl X X X X X LichtF BA F2 X X X X X ABBILDUNG 30 Ausschnitt aus der Verfolgbarkeitsmatrix Anforderungen A Verifikation Das Dokument A Verifikation enth lt Hinweise zu und Ergebnisse von durchge f hrten Verifikationsaktivit ten auf Ebene der System Anforderungen Die fol gende Beschreibung beschr nkt sich auf die Anwendung einer C
160. in ihrer Software Entwicklungsorganisation etablieren m chten Der hier vorgestellte Prozess mit der zugeh rigen Doku mentationsstruktur kann als Grundlage genutzt werden Der Prozess und die ihm zugrundeliegenden Konzepte wurden in mehreren Projekten erprobt und haben sich bew hrt beanspruchen jedoch keine Allgemeing ltigkeit f r die Software Entwicklung im Bereich Eingebetteter Systeme Vielmehr bedarf es Anpassungen an konkrete Aufgabenstellungen sowie an den System den Pro jekt und den Organisationskontext In diesem Bericht angegebene Aufwands und Fehlerverteilungen k nnen unter Ber cksichtigung des Projektkontexts als Ausgangspunkt f r die Aufwands und Qualit tssicherungsplanung verwendet werden Qualit tssicherer Der hier vorgestellte Prozess beinhaltet eine Methodik zur systematischen Verifikation und Validation im Kontext objektorientierter Ent wicklung eingebetteter Software Es wird beschrieben zu welchen Zeitpunkten Verifikations und Validierungsaktivit ten durchgef hrt werden k nnen und wie deren Ergebnisse dokumentiert werden Es wird aufgezeigt wie Verifikati ons und Validationsaktivit ten genutzt werden k nnen um m glichst fr hzei tig Fehler zu finden und zu korrigieren Voraussetzung f r das Verst ndnis dieses Berichts sind Erfahrungen mit der Ent wicklung von Software sowie Grundkenntnisse in UML Bei der Beschreibung des Entwicklungsprozesses wurde angestrebt bekannte Schw chen existiere
161. ird folgendes Produkt modifiziert e K Verifikation Prozess Reviewsitzung Komponenten Kode Im Prozess Reviewsitzung Komponenten Kode werden die beim Lesen gefundenen Fehler besprochen An der Inspektionssitzung nehmen Kodierer und Verifizierer teil Die Aufgabe der Verifizierer ist es nicht die erkannten Fehler zu l sen son dern lediglich diese w hrend der Sitzung in den Dokumenten aufzuzeigen Die Verifizierer f hren durch die Liste der Fehler Ergebnis der Inspektionssitzung ist eine berarbeitete Fehlerliste die im Dokument K Verifikation festgehalten wird Im Prozess Reviewsitzung Komponenten Kode werden folgende Produkte konsu miert e E Klassendiagramme Entwicklung eingebetteter Software mit UML 177 System Komponenten bearbeiten e Class Tables e E Zustandsdiagramme e E Aktivit tsdiagramme e Komponenten Anforderungen e Entwicklungsrichtlinien e Komponenten Kode Im Prozess wird folgendes Produkt modifiziert e K Verifikation Prozess Rework Komponenten Kode Im Prozess Rework Komponenten Kode werden die Fehler aus der Fehlerliste behoben Dabei werden die Strategie zur Behebung des Fehlers dokumentiert um nderungen an den Dokumenten zu verdeutlichen Dies geschieht mit Hilfe der Tabelle zur Dokumentation der Fehlerbehebungsstrategien im Dokument K Verifi kation L sst sich ein Fehler auf einen Fehler in den System Anforderungen oder im Entwurf zur ckf hren wird der Fehler
162. ispiele f r Konsistenzbedingungen angegeben Zum Teil werden Kon sistenzchecks zwischen den Diagrammen von existierenden CASE Werkzeugen bernommen Prozess E Use Cases bearbeiten Im Teilprozess E Use Cases bearbeiten werden die A Use Cases aus den B Anfor derungen in den UML Entwurf unver ndert bernommen Sie dienen im UML Entwurf zur Einordnung der E Sequenzdiagramme Folgendes Produkt wird im Prozess E Use Cases bearbeiten konsumiert e A Use Cases Folgendes Produkt wird produziert e E Use Cases Prozess E Klassendiagramme bearbeiten W hrend des Prozesses E Klassendiagramme bearbeiten werden die A Packagediagramme und die A Klassendiagramme aus den E Anforderungen verfeinert und hinsichtlich der Entwurfsentscheidungen und anderer Entwurfskriterien berarbeitet nderungen in den Klassendiagrammen durch Anpassungen an Entwurfsentscheidungen oder Anwendung von Optimierungskriterien werden im Dokument Unterschiede zur Analyse der Software Systemdokumentation erl utert Dies erlaubt das leichtere Nachvollziehen von getroffenen Entwurfsentscheidungen z B im Fall von sp teren nderungen Die Namenskonventionen geben Richtlinien vor f r die Wahl von Bezeichnern bei Verfeinerungen z B Konstanten beginnen mit c Die Konsistenz der E Klassendiagramme zu den anderen UML Diagrammen muss sichergestellt sein Daf r muss berpr ft werden ob nderungen in den anderen Diagrammen in den Klassendiagr
163. it UML 27 Projekt initialisieren Dom nenwissen Dieses Dokument beschreibt typische Eigenschaften und Charakteristika der Anwendungsdom ne Es umfasst insbesondere eine Beschreibung der Systemum gebung Dar ber hinaus kann es Referenzdokumente umfassen die z B Pr zisie rungen von Angaben der Problembeschreibung beinhalten Systemumgebung Im Dokument Systemumgebung werden spezielle Eigenschaften der Dom ne beschrieben Dies sind z B bei Geb udeautomationssystemen die Architektur des Geb udes f r das das Software System entwickelt werden soll oder Regelungsal gorithmen mit denen die Temperatur in den R umen geregelt werden kann Dar ber hinaus sollte die Systemumgebung ein Data Dictionary f r die Anwendung enthalten in der die Begriffe der Anwendung erkl rt und beschrieben werden Das Data Dictionary auch Glossary ist sehr wichtig weil es eine gemeinsame Begriffsbildung zwischen den Benutzern Kunden und den Entwicklern unterst tzt Meist beinhaltet das Dokument Systemumgebung au erdem eine Beschreibung der verf gbaren Sensoren und Aktuatoren die zur Erbringung der Systemfunktionali t t bereitstehen Abbildung 13 zeigt einen Ausschnitt aus einer Geb udearchitek turbeschreibung TO Geb udearchitektur The total system is composed of a section within an university building namely section building 32 4th floor of Univ of Kaiserslautern with installation including sensors and actuators users on
164. itsmatrix Anforderungen verifiziert Die Ergebnisse der Verifikation werden im Dokument A Verifikation dokumentiert und gefundene Fehler werden behoben Im Prozess Testf lle bearbeiten werden aus den System Anforderungen Testpl ne f r sp tere Tests fertiggestellter Teilsysteme und des Gesamtsystems abgeleitet Die erarbeiteten Testpl ne werden im Dokument A Validation doku mentiert Entwicklung eingebetteter Software mit UML 39 System Anforderungen bearbeiten Dom nenwissen System Anforderungen Probleml sungs bearbeiten dokumentation System umgebung Problem beschreibung Referenz Dokumente E Anforderungen B Anforderungen 5 bearbeiten Lk AT 77 E Anforderungen a Verfolgbarkeitsmatrix Anforderungen TF bearbeiten A erfolgbarkeitsmat rix Anforderungen System Anforderungen 9 S verifizieren A Verifikation Testf lle bearbeiten A Validation ABBILDUNG 19 Verfeinerung des Prozesses System Anforderungen bearbeiten B Anforderungen H bearbeiten Namens konventionen 3 2 Produkte Im folgenden wird eine bersicht ber die im Prozess System Anforderungen bear beiten verwendeten Produkte gegeben Die bersicht beschreibt die interne Struk turierung der Dokumente Anschlie end erfolgt eine Beschreibung der Inhalte der Dokumente soweit dies nicht bereits im vorangegangenen Kapitel erfolgt ist 40 Entwicklung eingebetteter Software mit UML
165. ktion als Verifikationsaktivit t eingeschr nkt Ein Inspektionsprozess umfasst drei Teilprozesse 1 Lesen des zu inspizierenden Dokuments Komponenten Kode Review vorbereiten 2 Durchf hren einer Inspektionssitzung zur Besprechung aufgedeckter Fehler Reviewsitzung Kompo nenten Kode und 3 berarbeiten des verifizierten Dokuments zur Behebung von Fehlern Rework Komponenten Kode Abbildung 93 zeigt den Prozess Komponenten Kode verifizieren mit konsumieren den produzierenden und modifizierenden Produkten Folgendes Produkt wird im Prozess Komponenten Kode verifizieren konsumiert Entwicklungsrichtlinien Folgende Produkte werden modifiziert Komponenten Kode Ausf hrbarer Komponenten Kode K Verifikation UML Entwurf Verfolgbarkeitsmatrix Entwurf Komponenten Anforderungen E Verifikation E Validation A Use Cases Szenarien E Anforderungen Verfolgbarkeitsmatrix Anforderungen A Verifikation A Validation Entwicklung eingebetteter Software mit UML 175 System Komponenten bearbeiten Software System eh E Entwicklungsrichtlinien SNCH Verifizierer Kodierer Kode Ableitungs S O O richtlinien UML Entwurf z T Entwurfs Anforderungs Programmier ingenieur ingenieur richtlinien Komponenten Kode verifizieren U HU Class Tables E Klassendiagramme U HU HU E Zustands diagramme E Aktivit ts i me diagram Rework K Verifikation Komponenten Kode
166. ktionalen Eigenschaften des Systems entwickelt werden Entwicklung eingebetteter Software mit UML 87 System Anforderungen bearbeiten Abbildung 46 zeigt den Prozess Testf lle bearbeiten mit konsumierenden produ zierenden und modifizierenden Produkten O Probleml sungs dokumentation z Validierer B Anforderungen Informelle B Anforderungen Testf lle bearbeiten J D A Validation ABBILDUNG 46 Verwendete Produkte des Prozesses Testf lle bearbeiten Folgende Produkte werden im Prozess Testf lle bearbeiten konsumiert e Nicht funktionale B Anforderungen Teilprodukt der Informellen B Anforde rungen e Szenarien Folgendes Produkt wird produziert e A Validation 88 Entwicklung eingebetteter Software mit UML Weiterf hrende Literatur 3 10 Weiterf hrende Literatur 1 A F Ackerman L S Buchwald F H Lewski Software Inspections An Effec tive Verification Process In Donald J Reifer EDS Software Management 5th Edition IEEE Computer Society Kapitel 10 S 416 421 1997 Maher Awad Juha Kuusela J rgen Ziegler Object Oriented Technology for Real Time Systems A Practical Approach using OMT and Fusion Prentice Hall 1996 Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Addison Wesley Longman 1999 Grady Booch James Rumbaugh Ivar Jacobson The Unified Modeling Langu age User Guide Addison Wesley Longman 1999 Alan Davis Softwa
167. ktuato ren Entwicklung eingebetteter Software mit UML 47 System Anforderungen bearbeiten Benutzungsschnittstelle Systemmodusermittlungf 4 Package LichtregelungFlur Dieses Package enth lt Klassen die die Regelung des Lichts in den Flurabschnitten bernehmen Werte die daf r ben tigt werden werden mit Hilfe der Klassen des Packages Benutzungsschnittstelle gesetzt ABBILDUNG 23 Teilsysteme eines Geb udeautomationssystems und Erl uterung des Package LichtregelungFlur A Klassendiagramme Ein Klassendiagramm beschreibt Klassen Attribute und Methoden von Klassen und Beziehungen zwischen Klassen innerhalb eines Teilsystems Es beschreibt damit die statische Struktur eines Teilsystems F r jedes elementare Teilsystem das sind Teilsysteme die keine weiteren Packages enthalten existiert ein Klassen diagramm In jedem Klassendiagramm sind die Methoden und Attribute einer Klasse darge stellt die f r die Erbringung der im Klassendiagramm beschriebenen Funktionali t t erforderlich sind Tritt eine Klasse in mehreren Klassendiagrammen auf d h wird sie zur Erbringung unterschiedlicher Funktionalit ten ben tigt dann zeigen einzelne Klassendiagramme nur Sichten auf diese Klasse Die Klassen sollten sich an den Objekten der Anwendungsdom ne orientieren z B an der Geb udearchitektur bei einem Geb udeautomationssystem Au er dem werden f r Sensoren und Aktuatoren Klassen gebildet Dies erh ht
168. kumentation gefundener Fehlverhalten Dom nenwissen ir Probleml sungs 3 dokumentation Namens konventionen System Entwurf bearbeiten Software System no Dokumentation ABBILDUNG 47 Verwendete Produkte des Prozesses System Entwurf bearbeiten Entwicklung eingebetteter Software mit UML Prozessverfeinerung 4 1 Prozessverfeinerung Der Prozess System Entwurf bearbeiten unterteilt sich in sechs Teilprozesse siehe Abbildung 48 Zun chst werden aus den B Anforderungen und dem Dom nenwis sen Entwurfsentscheidungen abgeleitet die Festlegungen bez glich der Implemen tierung des zu realisierenden Systems beschreiben Ausgehend von den B und E Anforderungen werden im Prozess UML Entwurf bearbeiten die UML Dia gramme verfeinert und hinsichtlich der Entwurfsentscheidungen berarbeitet Ins besondere f r die Verfeinerung der Diagramme sind Namenskonventionen wichtig die eine einheitliche Namensgebung in den verschiedenen Entwicklungsprodukten und Teilsystemen gew hrleisten Ergebnis dieses Prozesses ist der UML Entwurf der die berarbeiteten UML Diagramme enth lt und nderungen beschreibt Im Prozess Komponenten Anforderungen erstellen werden die Beschreibungen der Komponenten aus dem UML Entwurf erweitert sodass eine unabh ngige Imple mentierung der Komponenten m glich ist Im Prozess Verfolgbarkeitsmatrix Ent wurf bearbeiten wird eine Verfolgbarkeitsmatrix Entwurf aufgestellt in d
169. ldung 32 Ausschnitt aus einer Fehlerklassifikation Spezifische Fehlerklassen auf Seite 60 E Fehlertabellen In den Fehlertabellen werden alle Fehler die im Produkt Software System Doku mentation gefunden wurden und noch nicht auf nachfolgende Produkte bertragen wurden aufgelistet Das bedeutet dass die E Fehlertabelle Fehler umfasst die in der Software System Dokumentation aufgedeckt worden sind Die Fehler k nnen ihren Ursprung in der Probleml sungsdokumentation haben Beispielsweise bein haltet die Fehlertabelle einen Fehler im E Klassendiagramm der w hrend der Inspektion des UML Entwurfs gefunden wurde Ein Entwurfsfehler der die Ursa 116 Entwicklung eingebetteter Software mit UML Produkte che f r einen Kodefehler ist und nur durch den Kodefehler aufgedeckt wurde wird nicht in der E Fehlertabelle beschrieben Ein in der E Fehlertabelle dokumentierter Fehler kann w hrend der Inspektion des UML Entwurfs aufgedeckt worden sein Er kann aber auch in nachfolgenden Pro zessen gefunden worden sein z B beim Implementieren Der Prozess w hrend dessen ein Fehler gefunden wurde ist in der Fehlertabelle vermerkt z B sysent revvorb als Abk rzung f r System Entwurf Review vorbereiten Die Fehler werden dabei mit Hilfe des Produkts und des Teilsystems in dem sie aufgetreten sind gekennzeichnet Produkt Teilsystem FNr Nummer Ein Fehler wird durch das betroffene Diagramm und das betroffene
170. llkode der Treiber und Stubs doku mentiert e Ausf hrbarer Teilsystem Kode In diesem Produkt befinden sich die bersetz ten Treiber und Stubs Prozess Teilsystem Makefile erstellen Im Prozess Teilsystem Makefile erstellen werden Makefiles zum Zusammenbinden von Komponenten eines Teilsystems mit dem passenden Treiber und den passen den Stubs zu einem ausf hrbaren Teilsystem erstellt Folgendes Produkt wird konsumiert e UML Entwurf Folgendes Produkt wird produziert e Teilsystem Makelfile Entwicklung eingebetteter Software mit UML 203 System Integration Prozess Ausf hrbares Teilsystem erstellen Im Prozess Ausf hrbares Teilsystem erstellen wird das Makefile verwendet um ausf hrbare Teilsysteme zu erstellen Der bersetzte Kode der Komponente wird mit dem bersetzten Treiber und den Stubs zusammengebunden Es entstehen lauf f hige Binaries f r jedes Teilsystem Folgende Produkte werden konsumiert e Ausf hrbarer Komponenten Kode e Teilsystem Makefile Folgende Produkte werden produziert e Ausf hrbarer Teilsystem Kode 1 n 1 Iteration Hierbei handelt es sich um das neue umfassendere Teilsystem e Ausf hrbarer System Kode n Iteration Hierbei handelt es sich um das Gesamtsystem 6 6 Prozess Integrationstest Im Prozess Integrationstest werden die lauff higen Binaries ausgef hrt und Tester gebnisse werden protokolliert auf Fehler in der Dokumentation zur ckg
171. lt lt counterSwitchOn lt lt Aufruf Methode Light gt SwitchOn lt lt endl switch counterSwitchOn case 1 cout lt lt gt gt Das Licht wurde eingeschaltet lt lt endl break default cout lt lt Unzulaessiger Aufruf lt lt endl break A Konstruktor Light int SectionNr int RoomNr char ActuatorName counterSwitchOn 0 cout lt lt Light lt lt SectionNr lt lt lt lt RoomNr lt lt lt lt lt lt endl lt lt ActuatorName protected int counterSwitchOn ABBILDUNG 89 Ausschnitt aus einem Stub f r den Test der Komponente LightController 168 Entwicklung eingebetteter Software mit UML Rollen Ausf hrbarer Komponenten Kode Der Ausf hrbare Komponenten Kode enth lt f r jede Komponente den bersetzten Komponenten Kode und die zum Test ben tigten bersetzten Test Rahmen Au erdem umfasst es f r jede Komponente mehrere lauff hige Binarys entspre chend der Anzahl der durchzuf hrenden Tests Pro Test wird der bersetzte Kom ponenten Kode mit dem passenden bersetzten Test Rahmen zusammengebunden 5 3 Rollen Im Prozess System Komponenten bearbeiten sind die Rollen Kodierer Verifizierer Validierer Anforderungsingenieur Entwurfsingenieur und Qualit tsmanager involviert Ihre Verantwortlichkeiten f r die Produkte ergeben sich aus Abbildung 90 Folgende wesentliche T tigkeiten sind im Prozess System Komponenten bear
172. lung der informellen B Anforderungen Er hilft das vorgegebene tabellarische Schema auszuf llen 0 Z Zi LI Kund Anforderungs Dom nen unae ingenieur experte verantwortlich H E f r Problem Informelle beschreibung B Anforderungen Dom nen wissen ABBILDUNG 16 Ressourcen und Produkte des Prozesses Projekt initialisieren 2 4 Kontrollfluss Die Reihenfolge der Bearbeitung der Teilprozesse ist in Form eines Pr zedenzgra phen in Abbildung 17 dargestellt Der Prozess Dom nenwissen bearbeiten wird parallel mit den Prozessen Problembeschreibung bearbeiten und Informelle B Anforderungen bearbeiten durchgef hrt Eine initiale Version des Produkts Dom nenwissen sollte vorhanden sein bevor die anderen Prozesse bearbeitet werden Problembeschreibung bearbeiten Kunde Dom nenwissen O bearbeiten J O es 7 Dom nen 7 nformelle experte Anford B Anforderungen nforderungs ingenieur bearbeiten ABBILDUNG 17 Kontrollfluss f r den Prozess Projekt initialisieren Entwicklung eingebetteter Software mit UML 31 Projekt initialisieren 2 5 Prozess Problembeschreibung bearbeiten Im Prozess Problembeschreibung bearbeiten wird der Bedarf f r ein eingebettetes System in einem bestimmten Anwendungsbereich identifiziert und dokumentiert Der Bedarf kann auf verschiedene Arten identifiziert werden Beispielsweise beob achtet der Kunde seine Umgebung und deckt Probleme auf z B
173. m Kode produziert Der Integrationstest wird in der n Iteration nicht mehr durchgef hrt Entwicklung eingebetteter Software mit UML 189 System Integration O O System es integrations SE oO ingenieur oO Software System Wi Dokumentation LJ L Anforderungs Entwurfs Kodierer ingenieur ingenieur System Integration Ausf hrbares System Integriere Teilsystem Ausf hrbares Teilsystem Teilsystemtest Rahmen erstellen Teilsystemtest Rahmen Teilsystem Makefile erstellen Ausf hrbarer Teilsystem Kode U V Ausf hrbares Teilsystem erstellen Probleml sungs dokumentation Integrationstest Teilsystemtest durchf hren Rework Software Teilsystem Komponenten y pea Dokumentation y ABBILDUNG 97 Verfeinerung des Prozesses System Integration 190 Entwicklung eingebetteter Software mit UML Produkte 1 lteration Integriere Komponenten zu Teilsystem 2 n 1 Iteration en lesen Ausf hrbare Ausf hrbares Komponente Teilsystem Integriere Teilsystem Integrationstest Ausf hrbares Ausf hrbares Teilsystem Teilsystem 41 n teration Integriere Teilsysteme zu System Ausf hrbares Ausf hrbares Teilsystem Teilsystem Integriere Teilsystem Integrationstest y Ausf hrbares System Ausf hrbarer System Kode Ausf hrbares Teilsystemm Ausf hrbare Komponent
174. mentiert Die Tabelle gibt damit Aufschluss ber den Stand der Rework Aktivit ten Anhand der Tabelle kann au erdem entschieden werden ob eine erneute Verifikation des ge nderten Entwurfs notwendig ist Abbildung 64 zeigt einen Ausschnitt aus einer Tabelle zur Dokumentation der Feh lerbehebungsstrategien f r das Teilsystem LichtregelungFlur VANUA Fehlerbehebungsstrategien In der Tabelle werden alle Fehler aus der Fehlertabelle aufgef hrt Au erdem dokumentiert die Tabelle die Behebung eines Entwurfsfehlers Ursprung des Feh lers waren bereits die System Anforderungen der erst im Kode entdeckt wurde K LF FNr3 K f r Kode Die Beschreibung der Strategien zur Behebung der Fehler erlaubt es nachzuvoll ziehen was sich im Entwurf ge ndert hat 118 Entwicklung eingebetteter Software mit UML Produkte Referenz auf Behebung des Fehlers Strategie zur Behebung des Fehlers durchgef hrt FNr IJN E LF FNr1 R ckgabewert erg nzt J E LF FNr2 R ckgabewerte erg nzt J Aufruf beim Zustands bergang wurde von KAPP SwitchOff in SwitchOn ge ndert J ABBILDUNG 64 Ausschnitt aus der Tabelle zur Dokumentation der Fehlerbehebungsstrategien Teilsystem Lichtregelung Flur E Validation Das Produkt E Validation umfasst alle Dokumente die f r die Validation ausf hr barer Komponenten d h Klassen gegen den UML Entwurf und die Komponen ten Anforderungen wichtig sind Dies sind
175. n 236 Entwicklung eingebetteter Software mit UML Teilprozess von System Anforderungen z Rework bearbeiten System Anforderungen System Entwurf bearbeiten Entwurfsentscheidungen erstellen E Use Cases E Klassendiagramme E Zustandsdiagramme E Aktivit tsdiagramme bearbeiten bearbeiten bearbeiten bearbeiten E Sequenzdiagramme bearbeiten Class Tables E Kollaborationsdiagramme bearbeiten bearbeiten Komponenten Anforderungen erstellen Verfolgbarkeitsmatrix Entwurf bearbeiten System Entwurf Review vorbereiten Reviewsitzung System Entwurf Rework System Entwurf Komponenten Testf lle bearbeiten H gd System Komponenten bearbeiten Komponenten Kode bearbeiten Komponententest Komponententest Treiber erstellen Stubs erstellen Komponenten Kode SC Ausf hrbare Komponente erstellen Komponenten Kode Komponententest Rework Komponenten Kode Rework Teilsystemtest _ Teilprozess vo Rahmen erstellen System Integration Entwicklung eingebetteter Software mit UML 237 Kontrollfluss Teilprozess von Teilprozess von System Anforderungen j System Komponenten bearbeiten an bearbeiten Testf lle Rework bearbeiten Komponententest System Integration Teilsystemtest Rahmen erstellen Teilsystem Makefile erstellen
176. n Es lassen sich Optimierungs und Verfeinerungskriterien unter scheiden Optimierungskriterien Auf folgende Aspekte ist zu achten 1 2 3 4 Gemeinsamkeiten zwischen Klassen werden in Oberklassen zusammengefasst Klassen ohne Funktionalit t werden entfernt Die Anwendbarkeit von Entwurfsmustern Design Pattern wird gepr ft Die Kopplung im System wird reduziert Daf r muss gepr ft werden ob sich Beziehungen zwischen Klassen oder Interaktionen zwischen Instanzen von Klassen vereinfachen lassen Verfeinerungskriterien Auf folgende Aspekte ist zu achten 1 Im Klassendiagramm werden Multiplizit ten f r die Klassen die miteinander in Beziehung stehen angegeben Richtungen f r Assoziationen werden festgelegt Ziel und Quelle von Werten z B Bereitstellung eines Werts von der Klasse ControlPanelFM f r eine Klasse die am Raum aggregiert ist m ssen geeignet verbunden sein Wichtig ist dass Werte eine Klasse wenn diese sie ben tigt wirklich erreichen Die Verbindung der Klassen kann auf verschiedene Arten hergestellt werden beispielsweise durch e Assoziationen zwischen zwei Klassen die bei der Initialisierung hergestellt werden e definierte Durchreichmethoden die einen Wert weiterreichen e das Bereitstellen einer getObject Methode von der Klasse die die Objekte verwaltet die den Wert verarbeiten oder e durch die Anwendung des Singleton Pattern wenn es von der Klasse die den Wert bereits
177. n die von der AG Software Engineering und dem Sonderforschungsbereich 501 an der Universit t Kaiserslautern durchgef hrt wurden e dem zur Software Entwicklungsmethode Object Modeling Technique OMT geh renden Software Entwicklungsprozess OMT ist eine der am meisten ver breiteten Methoden im Bereich der objektorientierten Anwendungsentwick lung insbesondere beim Einsatz f r objektorientierte Analyse und Entwurf Basierend auf dem Unified Process wurden Verbesserungen Erweiterungen und Erg nzungen vorgenommen 1 4 Prozessbeschreibung Im Folgenden wird erl utert nach welchem Schema und auf welche Art und Weise der Softwareentwicklungsprozess in diesem Bericht dokumentiert ist Hierbei wer den insbesondere die Begriffe Produkt Prozess und Rolle genauer definiert Produkte Als Produkte synonym Artefakte werden alle Ergebnisse von Software Entwick lungsaktivit ten sowie Informationen die f r deren Durchf hrung ben tigt wer den bezeichnet Beispiele f r Produkte sind ein Anforderungsdokument eine Entwurfsdokument ein UML Klassendiagramm ein Kodest ck oder eine ausf hr bare Kodekomponente Produkte k nnen als Verfeinerung eine Menge von Teilpro dukten besitzen die wiederum verfeinert sein kann So kann beispielsweise ein UML Entwurf aus einer Menge von UML Diagrammen unterschiedlicher Typen bestehen Dieser Bericht enth lt eine vollst ndige Produktstruktur f r die Produkte eines Software Systems Es wird eine
178. n einzelnen Dokumenten zu erkennen Es ist wiederum der Projektkontext zu ber cksichtigen 1 LOC steht f r Lines of Code Programmzeilen hier inklusive Kommentarzeilen Entwicklung eingebetteter Software mit UML 15 Einf hrung Mehrere Projekte die in der Dom ne Hausautomatisierung durchgef hrt wur den haben gezeigt dass die im Folgenden dargestellten Aufwands und Fehlerver teilungen durchaus typisch f r den Do it Prozess in dieser Dom ne sind 40 35 30 n Eu Aufwand N CH E Rework E Ersterstellung System Anforderungen bearbeiten 37 40 System Entwurf bearbeiten 30 14 System Komponenten bearbeiten 21 09 System Integration 8 57 System Validation 2 79 Prozess ABBILDUNG 6 Aufwandsverteilung Das Aufwandsmodell in Abbildung 6 zeigt eine 37 30 21 9 3 Vertei lung auf die Phasen Analyse Entwurf Kodierung mit integrierter Komponenten Validation Integration und System Validation Besonders f llt auf dass e der Aufwand f r die System Validation au ergew hnlich gering 3 ist In industriellen Projekten geht man i a von bis zu 50 aus Der geringe Anteil kann auf die fr hzeitige Entdeckung vieler Fehler bei Inspektionen zur ckge f hrt werden e der Aufwand in den fr hen Prozessschritten Analyse und Entwurf verh ltnis m ig hoch 67 ist Dies ist im wesentlichen auf zwei Analyseschritte und die umfangreic
179. n Test erforderlich sind welche Objekte im Treiber angelegt werden m ssen welche Methoden durch den Treiber aufgerufen werden m ssen und welche R ckgabewerte von Stubs bereitge stellt werden sollen Mit Hilfe des Treibers und der Stubs werden die Eingabewerte f r die zu testende Komponente festgelegt Au erdem muss im Testplan das erwartete Verhalten einer Komponente beschrie ben werden Beispielsweise wird dokumentiert welche Methoden die zu testende Komponente aufruft Die Dokumentation der Testpl ne Ein und Ausgaben der Komponente erfolgt mit Hilfe einer Tabelle 146 Entwicklung eingebetteter Software mit UML Prozess Komponenten Testf lle bearbeiten Die Pl ne zum Test einer Klasse sollten nicht durch den Entwerfer der Klasse erstellt werden Auf diese Weise wird gew hrleistet dass der Testplan von einer unabh ngigen Partei entwickelt wird Abbildung 77 zeigt den Prozess Komponenten Testf lle bearbeiten mit konsumie renden produzierenden und modifizierenden Produkten Software System Dokumentation O D HU TE ML E f Validierer S Ger E Klassendiagramme Zustandsdiagramme Aktivit tsdiagramme Komponenten Anforderungen E Validation Komponenten Testf lle bearbeiten ABBILDUNG 77 Verwendete Produkte des Prozesses Komponenten Testf lle bearbeiten Folgende Produkte werden im Prozess Komponenten Testf lle bearbeiten konsu miert Entwicklu
180. n die Klassenbeschreibungen keine Sichten auf eine Klasse sondern fassen die Informationen bez einer Klasse aus allen Klassendia grammen zusammen Die Klassenbescheibungen sind vergleichbar mit dem Data Dictionary der E Anforderungen Allerdings werden Attribute und Methoden der Klassen in den Klassenbeschreibungen detaillierter beschrieben Abbildung 54 zeigt einen Ausschnitt aus der Klassenbeschreibung der Klasse LightController des Teilsystems LichtRegelungFlur des Geb udeautomations systems Entwicklung eingebetteter Software mit UML 103 System Entwurf bearbeiten PANJA Klassenbeschreibung LightController Attribute Type Default Value roomNr int Operation Arguments Return Type lightControl zLightStatusType LightStatus void setLightControlUnit lightControlUnitPtr LightControlUnit void Attribute der Klasse LightController Attribut Erl uterung Das Attribut roomNr wird zur Erzeugung eines Objekts der Klasse Light ben tigt das die Flur lichtanlage des Flurabschnitts repr sentiert Da sich die Lichtanlage im Flurabschnitt befindet und nicht in einem Raum wird roomNr mit einem Wert initialisiert der diesen Sachverhalt kenn zeichnet Die Lichtanlage kann eindeutig durch ihren Namen identifiziert werden roomNr Methodenschnittstellen der Klasse LightController Signatur void lightControl zLightStatusType LightStatus Beschreibung Die Methode requ
181. n f r Bezeichner und gew hrleisten damit eine einheitliche Namensgebung in allen weiteren Entwicklungsprodukten Bei der Verfeinerung der B Anforderungen hilft Wissen ber die Dom ne Es wird eine Struktur des Systems definiert A Klassendiagramme bearbeiten und beschrieben Data Dictionary bearbeiten und das Verhalten des Systems auf eine Interaktion zwischen den Komponenten im Systems abgebildet A Sequenzdiagramme A Kollaborationsdia gramme bearbeiten und A Zustandsdiagramme bearbeiten Des Weiteren werden Aktivit tsdiagramme A Aktivit tsdiagramme bearbeiten erstellt mit denen ein zelne Operationen verfeinert werden Abbildung 43 zeigt den Prozess E Anforderungen bearbeiten mit konsumierenden produzierenden und modifizierenden Produkten 74 Entwicklung eingebetteter Software mit UML Prozess E Anforderungen bearbeiten O Anforderungs ingenieur Dom nenwissen System umgebung E Anforderungen bearbeiten Probleml sungsdokumentation B Anforderungen A Use Cases i 4 E Anforderungen A Klassendiagramme A Package bearbeiten Referenz Dokumente A Zustandsdiagramme bearbeiten I diagramme A Klassendiagramme A Zustandsdiagramme A Aktivit tsdiagramme Namens bearbeiten konventionen A Sequenzdiagramme bearbeiten A Aktivit ts diagramme A Sequenzdia gramme A Kollaborations di
182. n m Ausf hrbarer NM Teilsystem Kode Ausf hrbares Teilsystem md Teilsystem erstellen G Ge Probleml sungs JI dokumentation Ee A Validation Q Ausf hrbarer System Kode Installiertes System ABBILDUNG 105 Verwendete Produkte im Prozess Integriere Teilsystem Folgende Produkte werden im Prozess Integriere Teilsystem konsumiert e Ausf hrbarer Komponenten Kode e UML Entwurf e A Validation Folgende Produkte werden produziert e Teilsystemtest Rahmen 202 Entwicklung eingebetteter Software mit UML Prozess Integriere Teilsystem e Ausf hrbarer Teilsystem Kode 1 n 1 Iteration e Ausf hrbarer System Kode n Iteration Folgende Produkte werden modifiziert e Teilsystem Makefile Prozess Teilsystemtest Rahmen erstellen Im Prozess Teilsystemtest Rahmen erstellen werden zum Test der Teilsysteme Test Treiber und Stubs implementiert und bersetzt Der UML Entwurf zeigt welche Treiber d h Komponenten die das Teilsystem aufrufen und Stubs d h Kompo nenten die vom Teilsystem aufgerufen werden implementiert werden m ssen Die Testpl ne f r den Systemtest siehe Dokument A Validation legen fest welche Funktionalit t die Test Treiber und Test Stubs bieten m ssen Folgende Produkte werden im Prozess Teilsystemtest Rahmen erstellen konsu miert e UML Entwurf e A Validation Folgende Produkte werden produziert e Teilsystemtest Rahmen Hier wird der Que
183. n mit Software Engineering Kenntnissen an der Universit t Kaiserslautern im Jahr 1999 durchgef hrt Das resultierende Software System hat einen Umfang von 22 KLOC Die Produktivit t betrug 8 LOC Stunde Als Werkzeug zur Modellierung und Teil Generierung der UML Diagramme wurde Software through Pictures StP von Aonix in der UML Version verwendet Die Dokumentation erfolgte weitgehend mit dem Textverarbeitungssystem Frame Maker Gro e Teile der Dokumentation konnten automatisch generiert werden so dass ein einfaches Zusammenspiel von StP und FrameMaker m glich war Hierf r wurde ein eigenentwickelter Generator Wagenbichler 1999 eingesetzt Zur ber setzung von Kode und zur Systemintegration wurden UNIX bliche Werkzeuge verwendet 1 7 Planung Im Folgenden werden eine Aufwands und Fehlerverteilung des Do it Prozesses angegeben die bei der Durchf hrung des oben beschriebenen Anwendungsprojekt ermittelt wurden Ausgehend von einer Sch tzung des Gesamtaufwandes kann die Aufwandsverteilung als Ausgangspunkt f r eine Planung der Aufw nde genutzt werden wobei zu beachten ist dass Unterschiede im Projektkontexts z B andere Anwendungsdom ne andere Entwicklererfahrungen andere Entwicklungswerk zeuge Einfluss auf die Beschaffenheit der Aufwands und Fehlerverteilungen haben Insofern k nnen die angegebenen Verteilungen nur als Richtschnur angese hen werden Die Fehlerverteilung kann helfen ungew hnliche Fehlerh ufungen i
184. nd ihres Ursprungsprodukts zuordnet sind dem ausf hrbaren System keine Fehler zugeordnet Bei der System Validation entdeckte Fehlverhalten werden im Modell auf Fehler in den jeweiligen Dokumentationen abgebildet 1 8 Weiterf hrende Literatur 1 Aonix Software through Pictures User Manuals Aonix Release 2 4 und 3 4 1998 2 Jean Paul Calvez Embedded Real Time Systems A Specification and Design Methodology Wiley 1993 3 Nicolas Halbwachs Synchronous Programming of Reactive Systems Kluwer Academic Publisher 1993 4 Ivar Jacobson Grady Booch James Rumbaugh Unified Software Development Process Addison Wesley Publishing Company 1999 5 Ivar Jacobson and Grady Booch and James Rumbaugh The Unified Process IEEE Software Vol 16 Nr 3 S 96 102 Mai 1999 6 Richard A Johnson B C Hardgrave Object oriented methods current practices and attitudes Journal of Systems and Software Vol 48 Nr 1 S 5 12 August 1999 7 J rgen M nch Anpassung von Vorgehensmodellen im Rahmen ingenieurm i ger Softwarequalit tssicherung Im Tagungsband des 6 Workshops der Fach gruppe 5 1 1 GI Vorgehensmodelle Prozessverbesserung und Qualit tsmanagement Kaiserslautern 19 20 April 1999 18 Entwicklung eingebetteter Software mit UML Weiterf hrende Literatur 8 James Rumbaugh Michael Blaha William Premerlani Frederick Eddy Bill Lorensen Object Oriented Modeling and Design Prentice Hall 1990
185. nd im Dokument A Validation im Abschnitt Dokumentation der Testergebnisse beschrieben Nach der Durchf hrung eines Tests werden die produzierten Testaus gaben mit dem erwarteten Verhalten des Teilsystems verglichen Das erwartete Verhalten kann den Testpl nen zum Systemtest entnommen werden Gibt es Unter schiede zwischen dem tats chlichem und dem erwarteten Verhalten eines Teilsys tems wird dies als Fehlverhalten in der Tabelle zur Bewertung der Testergebnisse im Dokument A Validation dokumentiert Anschlie end werden die beschriebenen Fehlverhalten auf Fehler in der System Dokumentation zur ck gef hrt Die Fehler werden in der Fehlertabelle im Dokument K Verifikation fest gehalten Die Tabelle zur Bewertung der Testergebnisse wird um Verweise auf die Fehlernummern erweitert Folgende Produkte werden im Prozess Teilsystemtest durchf hren konsumiert e Ausf hrbarer Teilsystem Kode Folgende Produkte werden modifiziert e A Validation e K Verifikation Prozess Rework Teilsystem Im Prozess Rework Teilsystem werden die in der System Dokumentation lokalisier ten und in der Fehlertabelle im Dokument K Verifikation dokumentierten Fehler behoben Die Strategie zur Behebung der Fehler wird in den Verifikationskapiteln der zu ndernden Dokumente beschrieben Folgende Produkte werden modifiziert e Komponenten Kode e K Verifikation e Ausf hrbare Komponente e Ausf hrbares Teilsystem e UML Entwurf
186. nder Soft ware Entwicklungsstandards und Beschreibungen von Vorgehensmodellen zu beheben Solche Beschreibungen sind vielfach gekennzeichnet durch den Anspruch f r ein sehr breites Anwendungsspektrum geeignet zu sein z B Eignung sowohl f r interaktive Systeme als auch f r transformationelle und eingebettete Systeme Angaben zur tats chlichen Eignung der Vorge hensmodelle f r diese verschiedenen Dom nen und hiermit verbundene Anpas 1 2 Verifikation alle Aktivit ten die der berpr fung der Korrektheit eines Softwaredoku ments z B UML Entwurf oder Komponenten Kode dienen Validation alle Aktivit ten die der berpr fung der Zuverl ssigkeit von ausf hrbaren Produkten z B ausf hrbares Teilsystem oder System dienen Entwicklung eingebetteter Software mit UML 3 Einf hrung sungsvorschl ge fehlen jedoch oftmals g nzlich oder sind nur rudiment r vorhanden Dies l sst h ufig auf eine geringe Erprobung der Prozesse in ver schiedenen Dom nen schlie en die Behauptung effiziente Softwareentwicklung zu erm glichen Es existieren jedoch oftmals keinerlei Nachweise z B in Form von Baselines die dies quantitativ untermauern w rden abstrakte Beschreibungen Es fehlen h ufig detaillierte Vorgehens und Doku mentbeschreibungen sowie durchg ngige Beispiele einen hochgradig iterativen Prozess Dies spiegelt meist nur die geringe Erfah rung mit dem Prozess wider und erschwert eine sys
187. ng bernommen Abbildung 82 zeigt einen Ausschnitt aus der Header und der Implementationsda tei f r die Klasse LightController des Teilsystems LichtRegelungFlur des Geb udeautomationssystems Komponenten Kode Die Komponenten des Geb udeautomationssystems wurden in der Sprache C programmiert Die Klassenheader lie en sich mit Hilfe des verwendeten CASE Werkzeugs StP UML generieren Zur Generierung verwendet StP UML die Infor mationen aus den E Klassendiagrammen und den Class Tables Die Informationen aus den E Zustands und Aktivit tsdiagrammen bleiben ungenutzt Im Geb udeautomationsprojekt stellte sich eine Generierung der Klassenheader und das bernehmen von informellen Beschreibungen als effizienter heraus als eine vollst ndige manuelle Implementierung der Komponenten Allerdings lie sich generierter und anschlie end bearbeiteter Kode nicht neu generieren ohne die durchgef hrten nderungen am Kode zu verlieren Das folgende Beispiel zeigt einen Ausschnitt aus der Headerdatei der Klasse LightController Die Headerdatei lie sich mit Hilfe von StP UML fast vollst n dig generieren 156 Entwicklung eingebetteter Software mit UML Produkte A Class LightController A Description A Ein LightController Objekt dient einerseits als aktiver Melder A andererseits als Steurungseinheit fuer die Lichtanlage im Flur Als Melder A gibt er Zustandsaenderungen der Lichtanlage das Licht wu
188. ng eingebetteter Software mit UML 147 System Entwurf bearbeiten E Klassendiagramme E Zustandsdiagramme E Aktivit tsdiagramme Komponenten Anforderungen Folgendes Produkt wird produziert E Validation 4 11 Weiterf hrende Literatur 1 10 1 ch A F Ackerman L S Buchwald F H Lewski Software Inspections An Effec tive Verification Process In Donald J Reifer Software Management 5th Edi tion IEEE Computer Society 1997 Kapitel 10 S 416 421 Len Bass Paul Clements Rick Kazman Software Architecture in Practice SEI Series in Software Engineering Addison Wesley Publishing Company 1997 Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Addison Wesley Longman 1999 Grady Booch James Rumbaugh Ivar Jacobson The Unified Modeling Langu age User Guide Addison Wesley Longman 1999 Pankaj Jalote Integrated approach to software engineering 2nd ed Springer Verlag 1997 Barbara Kitchenham Steve Linkman Validation Verification and Testing Diversity Rules IEEE Software Vol 15 Nr 4 Juli 1998 S 46 49 P Liggesmeyer M Rothfelder M Rettelbach T Ackermann Oualit tssiche rung Software basierter technischer Systeme Problembereiche und L sungs ans tze GI Informatik Spektrum Vol 21 Nr 5 Oktober 1998 S 249 258 Bertrand Meyer Object oriented Software Construction Prentice Hall 1988 Bernd Oesterreich Objektori
189. ng zur Verf gung zu stellen und kontinuierlich aufgrund gemachter Projekterfahrungen zu verbessern Wissen Erfahrungen kann vom Qualit tsmanager im Prozess System Entwurf bearbei ten z B in Form von Checklisten Namenskonventionen Fehlerklassifikatio nen oder wiederverwendbarer Komponenten zur Verf gung gestellt werden Diese sind zum Teil Bestandteil von Produkten f r die andere Rollen verant wortlich sind Eigenverantwortlich ist der Qualit tsmanager hier f r das Pro dukt Namenskonventionen Entwurfs Verifizierer Validierer Qualit ts Case manager verantwortlich verantwortlich Sich d f r f r CE v Goal Se E Namens Goal konventionen en Komponenten aD CO ABBILDUNG 70 Ressourcen und Produkte des Prozesses System Entwurf bearbeiten Entwicklung eingebetteter Software mit UML 127 System Entwurf bearbeiten 4 4 Kontrollfluss Die Reihenfolge der Bearbeitung der Teilprozesse ist in Form eines Pr zedenzgra phen in Abbildung 71 dargestellt Die Beziehung zwischen den Prozessen UML Entwurf bearbeiten und Komponenten Anforderungen bearbeiten ist keine strikt sequenzielle Abfolge Bei der Bearbeitung der Komponenten Anforderungen erfolgt eine Vervollst ndigung des UML Entwurfs der daraufhin m glicherweise ge ndert werden muss Letzteres geschieht wiederum im Prozess UML Entwurf bearbeiten Die Folgeprozesse k nnen erst begonnen werden wenn diese beiden Prozesse vollst ndig beendet sind
190. nis des zu entwickelnden Systems bei Unklarheiten Die Beschreibung wurde im Rahmen eines vergleichbaren Projekts erstellt Description Class LightSensor INTENTION This class provides all definitions of a sensor determining whether a light is on or not Note that this is not a sensor measuring the illuminance Therefore on means that the circuit of the light is closed BASE CLASSES Binary Sensor Intention All definitions of a binary sensor are also provided here DOMAIN KNOWLEDGE Formal noMalSensreactionTime 10 NL The reaction time of a light sensor is 10 m ABBILDUNG 14 Ausschnitt aus der Referenz Problembeschreibung Entwicklung eingebetteter Software mit UML 29 Projekt initialisieren BANJA Zeit Referenzmodell Das Zeit Referenzmodell fasst Erfahrungen aus einem vorangegangenen Projekt hinsichtlich der Realisierung von Zeitspannen zusammen Jahreszeitintervalle Jahreszeitintervalle J werden mit datum datum angegeben Datum enth lt keine Jahresangabe nur Angaben ber Tag und Monat z B 15 09 welches den 15 September eines beliebigen Jahres beschreibt Dies bedeutet da die definierten Intervalle entweder fortlaufend ihre G ltigkeit behalten Typ ohne Verfallsdatum oder ung ltig wer den sobald sie einmal durchlaufen wurden einmalig g ltiger Typ Ein einmalig g ltiger Typ verh lt sich bspw wie der 365 Tage Timer in einem Videorecorder Die jeweiligen Intervalle werden
191. ode bernehmen Wichtig hierbei ist dass die vorgegebenen Programmierrichtlinien mit der Generierung des CASE Werkzeugs abgestimmt sind und sich nicht widersprechen Eine Nachbear beitung des generierten Kodes insbesondere hinsichtlich Gestaltungsrichtlinien z B Klammerung oder Namenkonventionen sollte vermieden werden F r die manuelle Implementierung der Information aus den E Zustands und E Aktivit tsdiagrammen bedarf es zus tzlicher Unterst tzung Die Kode Ableitungs richtlinien leiten den Prozess der Ableitung von Kode aus den E Zustandsdiagram men an Nach der fertiggestellten Implementierung wird der Komponenten Kode bersetzt Folgende Produkte werden im Prozess Komponenten Kode bearbeiten konsumiert e Entwicklungsrichtlinien e E Klassendiagramme e Class Tables e E Zustandsdiagramme e E Aktivit tsdiagramme e Komponenten Anforderungen Folgende Produkte werden produziert e Komponenten Kode e Ausf hrbarer Komponenten Kode Prozess Komponenten Kode verifizieren Im Prozess Komponenten Kode verifizieren wird der Komponenten Kode gegen die E Klassendiagramme die Class Tables die E Zustands und E Aktivit tsdia gramme sowie die Entwicklungsrichtlinien verifiziert Anleitungen f r und Ergeb nisse der Verifikation werden im Dokument K Verifikation dokumentiert 174 Entwicklung eingebetteter Software mit UML Prozess Quellkode bearbeiten Im Folgenden wird sich auf die Inspe
192. oden kann aus den Informationen der E Sequenzdiagramme des UML Entwurfs heraus mit Hilfe eines CASE Werzeugs z B StP UML generiert werden Abbildung 61 zeigt einen Ausschnitt aus einer Klassendefinition der Klasse Light Controller Klassendefinition Assoziationen werden im Beispiel nur in die Richtung in die eine Klasse Metho den einer anderen Klasse aufruft realisiert durch einen Zeiger auf die Klasse Aggregationen von anderen Klassen werden ebenfalls als Zeiger auf diese Klassen realisiert Entwicklung eingebetteter Software mit UML 113 System Entwurf bearbeiten Klasse LightController Assoziationen zu Objekten anderer Klassen Keine Aggregationen von Objekten anderer Klassen Pointername Klassenname des aggregierten Objektes lightPtr Light Methodenschnittstellen Signatur LightController sectionNr int initialRoomNr int Beschreibung Konstruktor Imports Importierte Methoden Herkunft Light e Ten e SwitchOn e SwitchOff Herkunft LightControlUnit e changedLightStatus Importierte Datentypen Herkunft SimpleTypes e zLightStatusType ABBILDUNG 61 Ausschnitt aus der Klassendefinition der Klasse LightController E Verifikation Das Dokument E Verifikation enth lt Hinweise zu und Ergebnisse von durchge f hrten Verifikationsaktivit ten auf Entwurfsebene Im Folgenden wird sich auf eine Inspektion mit Checklisten als Verifikationsaktivi
193. on dokumentiert Im Prozess System Entwurf Review vorbereiten werden folgende Produkte konsu miert A Use Cases E Anforderungen Verfolgbarkeitsmatrix Anforderungen Entwurfsentscheidungen UML Entwurf Komponenten Anforderungen Verfolgbarkeitsmatrix Entwurf Im Prozess wird folgendes Produkt modifiziert 144 Entwicklung eingebetteter Software mit UML Prozess System Entwurf verifizieren e E Verifikation Prozess Reviewsitzung System Entwurf Im Prozess Reviewsitzung System Entwurf werden die beim Lesen gefundenen Fehler besprochen An der Inspektionssitzung nehmen Entwurfsingenieure und Verifizierer teil Die Aufgabe der Verifizierer ist es nicht die erkannten Fehler zu l sen sondern lediglich diese w hrend der Sitzung in den Dokumenten aufzuzei gen Die Verifizierer f hren durch die Liste der Fehler Ergebnis der Inspektionssit zung ist eine berarbeitete Fehlerliste die im Dokument E Verifikation festgehalten wird Im Prozess Reviewsitzung System Entwurf werden folgende Produkte konsumiert e A Use Cases e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e Entwurfsentscheidungen e UML Entwurf e Komponenten Anforderungen e Verfolgbarkeitsmatrix Entwurf Folgendes Produkt wird modifiziert e E Verifikation Prozess Rework System Entwurf Im Prozess Rework System Entwurf werden die Fehler aus der Fehlerliste behoben Dabei wird die Strategie zur Behebung des
194. on gefundener Fehler K Fehlertabellen Die K Fehlertabelle dokumentiert einen Fehler im Teilsystem LichtregelungFlur im Komponenten Kode der beim Lesen des Kodes gefunden wurde Der Fehler befindet sich in der Datei LightController cc die die Implementierung der Klasse LightController enth lt Die Fehlertabelle enth lt au erdem Fehler im Kode die Ursachen f r Fehlverhalten sind Die Fehlverhalten wurden bei verschiedenen Tests KV Komponentenvalidation und ST Systemtest gefunden und auf Fehler im Kode zur ckgef hrt Ein Verweis auf die Fehler wird in der Tabelle zur Dokumen tation der Fehlverhalten erg nzt Der Fehler K LF FNr3 ist ein Folgefehler eines Fehlers in den System Anforde rungen Der Fehler muss im Kode im Entwurf und in den Anforderungen behoben werden Die Behebung der Fehler wird in den Tabellen zur Dokumentation der Fehlerbehebungsstrategien in den Verifikationskapiteln dokumentiert 160 Entwicklung eingebetteter Software mit UML Produkte 3 Prozess S w hrend betroffene allgemeine er F Nr i Fehler Datei Fehlerbeschreibung 2 gefunden wurde K LF FNr1 LightCont Methode lightControl definiert aber nicht imple U k mk dtevv rb roller cc mentiert K LF FNr2 LightCont Die Abfrage der aktuellen Zeit wurde vergessen U komtestdur roller cc K LF FNr3 LightCont Beim Zustands bergang wird SwitchOff F systestdur roller cc anstelle SwitchOn aufgerufen
195. on nicht direkt ausl sen kann Die aktive Komponente PresenceController fragt den Sensor laufend ab und l st die Systemreaktion aus Der Use Case f hrt dazu dass das Licht angesteuerter Aktuator in einem Flurab schnitt an oder abgeschaltet wird Das Licht interner Akteur beeinflu t die Hel ligkeit externer Akteur als beobachtete Gr e in der Umgebung Entwicklung eingebetteter Software mit UML 43 System Anforderungen bearbeiten Das Use Case Diagramm wurde mit Hilfe des CASE Werkzeugs StP UML erstellt Ein Rechteck innerhalb eines Use Cases deutet an dass eine weitere Verfeinerung des Use Cases in Form von einer Menge von A Sequenzdiagrammen existiert AnwesenheitTemp Flurlichtregelung_durch_Anwesenheit lt lt beeinflusst gt gt PresenceController KS 2 Lights Bright ness lt lt beeinflusst gt gt Flurlichtregelung manuell PushButton Use Case Flurlichtregelung_durch_Anwesenheit Initiating event Eine Person betritt oder verl t den Flur Der PresenceController meldet die An bzw Abwesen heit von Personen dem System Pre condition Der Flur ist seit ZeitspanneVerlassen Minuten nicht belegt und die Helligkeit im Flur ist lt 14 Lux oder eine Person ist im Raum anwesend und die Lampe ist angeschaltet Description Wenn die Anwesenheit von Personen im Flur registiert wird wird das Licht eingeschaltet Wenn der Flur seit ZeitspanneVerlassen Minuten nicht belegt ist wird das L
196. ponenten Anfor derungen soll eine unabh ngige Implementierung der Komponenten m glich sein Daf r werden die Richtungen von Assoziationen festgelegt und Pointernamen f r die Realisierung von Assoziationen und Aggregationen festgelegt Au erdem wer den importierte Datentypen und Methoden pro Klasse aufgelistet Private Metho den sowie Konstruktoren und Destruktoren werden erl utert Die Information ber die importierten Methoden kann aus den Sequenzdiagram men abgeleitet werden Die Vervollst ndigung des UML Entwurfs kann zu einer nderung des UML Ent wurfs f hren Beispielsweise wird beim Festlegen der Richtungen f r Assoziatio nen das E Klassendiagramm ver ndert Abbildung 74 zeigt die im Prozess Komponenten Anforderungen erstellen verwen deten Produkte Entwicklung eingebetteter Software mit UML 139 System Entwurf bearbeiten Software System Dokumentation Entwurfs O entscheidungen Entwurfs UML Entwurf ingenieur E Klassen diagramme E Sequenz diagramme Komponenten Anforderungen erstellen Komponenten Anforderungen ABBILDUNG 74 Verwendete Produkte des Prozesses Komponenten Anforderungen erstellen Im Prozess Komponenten Anforderungen erstellen werden folgende Produkte modifiziert e UML Entwurf Folgende Produkte werden produziert e Komponenten Anforderungen 140 Entwicklung eingebetteter Software mit UML Prozess Verfolgbarkeitsmatrix Entwurf be
197. rde durch den A Benutzer manuell ein ausgeschaltet an das LightControlUnit Objekt weiter A Als Steuerungseinheit verfuegt die Klasse ueber Methoden zum Ein bzw A Ausschalten der Lichtanlage class LightController public ScheduledFet I stp class members public Operation lightControl A Description A Die Methode lightControl ruft in Abhaengigkeit von ihrem Parameter A LichtStatus die Methoden SwitchOn bzw SwitchOff eines Objekts A der Klasse Light auf um die Lichtanlage des Flurabschnitts entsprechend A anzusteuern void lightControl zLightStatusType LightStatus A Operation callBack A Description A Diese Methode wird von der Klasse ScheduledFct geerbt A Sie dient der Abwicklung der zeitabhaengigen Ablaeufe void callBack void private A Attribute zLCState A Description A Die Enumeration definiert die gueltigen Zustaende A eines Objekts der Klasse LightController enum cStatusLichtAus cStatusLichtAn zLCState zLightStatusType zLightStatus ABBILDUNG 81 Ausschnitt aus der Headerdatei der Klasse LightController Das n chste Beispiel zeigt einen Ausschnitt aus der mplementierungsdatei der Klasse LightController Die Realisierung der Methode lightControl wird beschrieben Der Header der Methode konnte generiert werden Der Methoden rumpf musste manuell eingef gt werden Entwicklung eingebetteter Software mit UML 157 System Komponenten bearbeiten
198. rderungen 111 Komponenten Anforderungen erstellen 139 Komponenten Kode bearbeiten 174 Komponenten Kode Review vorbereiten 177 Komponenten Kode verifizieren 174 Komponenten Testf lle bearbeiten 146 Komponententest Rahmen 166 Komponententest Rahmen erstellen 181 Komponententest Stubs 167 Komponententest Treiber 166 Kunde 30 68 215 K Verifikation 158 N Namenskonventionen 67 126 P Package 99 Problembeschreibung 25 Problembeschreibung bearbeiten 32 Probleml sungsdokumentation 38 92 152 187 210 Produkt 8 Programmierrichtlinien 164 Projekt initialisieren 21 Entwicklung eingebetteter Software mit UML Prozess 10 Q Qualit tsmanager 69 127 169 199 215 Quellkode bearbeiten 171 R Reale Systemumgebung 210 214 Referenz Dokumente 29 Reviewsitzung Komponenten Kode 177 Reviewsitzung System Anforderungen 86 Reviewsitzung System Entwurf 145 Rework Akzeptanztest 223 Rework Komponenten Kode 178 Rework System Anforderungen 86 Rework System Entwurf 145 Rework Systemtest 219 Rework Teilsystem 206 Rework Test im Betrieb 225 Rolle 12 S Simulator 209 Software Komponenten Dokumentation 152 188 210 Software System Dokumentation 92 152 188 210 System Anforderungen bearbeiten 37 System Anforderungen Review vorbereiten 85 System Anforderungen verifizieren 83 System Entwurf bearbeiten 91 System Entwurf Review vorbereiten 144 System Entwurf verifizieren 142 System Integration 18
199. re requirements Analysis and Specification Prentice Hall 1990 Richard A DeMillo W Michael McCracken R J Martin John G Passafiume Software testing and evaluation Benjamin Cummings Publishing Inc 1987 Pankaj Jalote Integrated Approach to Software Engineering 2nd ed Springer Verlag 1997 Barbara Kitchenham Steve Linkman Validation Verification and Testing Diversity Rules IEEE Software Vol 15 Nr 4 S 46 49 Juli 1998 Antje von Knethen Barbara Paech Reflections on the Object Oriented Design of Embedded Systems OMER Workshop May 28 29 1999 P Hofmann A Sch rr EDS OMER Workshop Proceedings Bericht Nr 1999 01 Mai 1999 P Liggesmeyer M Rothfelder M Rettelbach T Ackermann Oualit tssiche rung Software basierter technischer Systeme Problembereiche und L sungs ans tze GI Informatik Spektrum Vol 21 Nr 5 S 249 258 Oktober 1998 Bernd Oesterreich Objektorientierte Softwareentwicklung mit der Unified Modeling Language Oldenburg Verlag 4 aktualisierte Auflage 1998 James Rumbaugh Michael Blaha William Premerali Objektorientiertes Modellieren und Entwerfen Hanser Elektronik M nchen 1993 Wolfgang Wagenbichler Erstellung einer SW Systemdokumentation mit StP Projektarbeit Fachbereich Informatik Universit t Kaiserslautern 67653 Kai serslautern 1999 URL http wwwagse informatik uni kl de access system publications html 8 Klaus Weidenhaupt Klaus Pohl
200. realisiert Die Funktionalit t der Test Treiber und Stubs kann den Testpl nen f r den Systemtest siehe Kapitel A Vali dation entnommen werden Dies ist m glich weil die Testpl ne f r den System test aus den Teilsystem spezifischen Szenarien abgeleitet wurden und damit das Verhalten einzelner Teilsysteme beschreiben Teilsystemtest Treiber Der Teilsystemtest Treiber ist ein Modul z B Teilsystemtest cc mit der Funktion main Das Teilsystem wird initialisiert Aufrufe des zu testenden Teilsystems durch andere Teilsysteme werden simuliert Abbildung 100 zeigt einen Ausschnitt aus einem Teilsystemtest Treiber f r das Teilsystem LichtRegelungFlur des Geb udeautomationssystems Teilsystemtest Treiber Dem UML Entwurf kann entnommen werden dass das Teilsystem Lichtrege lungFlur vom Teilsystem Benutzungsschnittstelle aufgerufen wird Aufrufe durch die Benutzungsschnittstelle d h durch die Klasse ControlPanelFm werden durch den Teilsystemtest Treiber simuliert Dar ber hinaus ist das Teilsystem aktiv d h das Teilsystem fragt Sensorwerte laufend ab und reagiert auf Zustands nde rungen in Abh ngigkeit bestimmter Zeitintervalle Um dieses Verhalten zu beob achten muss der Scheduler aktiviert und die Zeit initialisiert werden Entwicklung eingebetteter Software mit UML 193 System Integration include lt Teilsystemtest hh gt int TestCase Zeitpunkt vergangene Minuten seit Simulationss
201. regelung_durch_Anwesenheit PANJA A Sequenzdiagramm Der PresenceController ist in diesem Sequenzdiagramm als ausl sender Akteur besonders gekennzeichnet Er fragt den Anwesenheitssensor regelm ig ab und l st durch seine Zustands nderung eine Systemreaktion aus Der PRHallway LightController ist wie der PresenceController ein aktives Objekt dass den Zustand des PresenceControllers regelm ig abfragt Die Trennung von PRHall wayLightController und PresenceController wurde vorgenommen um den Pres enceController m glichst allgemein zu halten Er wird mit gleicher Funktionalit t auch f r die Temperaturregelung in den R umen eingesetzt Wenn jemand den Raum betritt wird an die LightControlUnit personIn geschickt und der LightController wird dazu veranlasst das Licht anzuschalten Wenn das Licht nicht bereits angeschaltet ist schaltet der LightController es an Flurlichregelung_durch_Anwesenheit_Szenario1 UmIUse Case Flurlichtregelung_durch_Anwesenheit Actor imd1 Contact PresenceController 9 PRHallwayLightController LightController 1 getValue 2 getStatus 3 personin 4 switchLightOn LichtStatus aus 5 switchOn 6 isOn LichtStatus an ABBILDUNG 26 Ausschnitt aus dem Sequenzdiagramm zu Szenariol Flurlichtregelung durch Anwesenheit 52 Entwicklung eingebetteter Software mit UML Produkte A Kollaborationsdia
202. ren 3 8 Prozess System Anforderungen verifizieren Im Prozess System Anforderungen verifizieren werden die A Use Cases und Szenarien gegen die informellen B Anforderungen die Problembeschreibung die Systemumgebung und die Referenz Dokumente verifiziert Die E Anforderungen werden gegen die B Anforderungen die Systemumgebung die Referenz Dokumente und die Namenskonventionen verifiziert Au erdem wird die Verfolgbarkeitsmatrix Anforderungen berpr ft Anleitungen f r und Ergebnisse der Verifikation werden im Dokument A Verifikation dokumentiert Im folgenden wird sich auf die Inspektion als Verifikationsaktivit t eingeschr nkt Ein Inspektionsprozess umfasst drei Teilprozesse 1 Lesen des zu verifizierenden Dokuments System Anforderungen Review vorbereiten 2 Durchf hrung einer Inspektionssitzung zur Besprechung aufgedeckter Fehler Reviewsitzung System Anforderungen und 3 berarbeiten des verifizierten Dokuments zur Behebung von Fehlern Rework System Anforderungen Entwicklung eingebetteter Software mit UML 83 System Anforderungen bearbeiten Abbildung 45 zeigt den Prozess System Anforderungen verifizieren mit konsumie renden produzierenden und modifizierenden Produkten Q O Probleml sungs E m dokumentation Verifizierer Anforderungs ingenieur Problem beschreibung O I B Anforderungen Kunde Informelle B Anforderungen A Use Cases Dom nenwissen
203. rf f r ein Software System festgestellt werden die wichtigsten Anforderungen an das System zur L sung der identifizierten Probleme oder zum Erreichen der strategischen Ziele aufgestellt F r die Formulierung dieser ersten Anforderungen sind genauere Kenntnisse der Anwendungsdom ne z B Wissen 1 An dieser Stelle wird der Entwicklungsprozess idealisiert dargestellt In vielen F llen wird ein Software System nicht v llig neu auf der gr nen Wiese entwickelt Es m s sen existierende Software Systeme erweitert werden oder existierende Software Systeme dienen als Referenzentwicklungen Entwicklung eingebetteter Software mit UML 21 Projekt initialisieren ber das Gebiet Geb udeautomatisierung notwendig Solches Wissen wird im Fol genden als Dom nenwissen bezeichnet Abbildung 8 gibt einen berblick ber die verwendeten Produkte im Prozess Pro Jekt initialisieren Folgende Produkte werden modifiziert e Dom nenwissen Dieses Dokument beschreibt typische Eigenschaften und Charakteristika der Anwendungsdom ne Es umfasst insbesondere eine Beschreibung der Systemumgebung e Probleml sungsdokumentation Dieses Dokument umfasst eine Problembe schreibung in der der Bedarf f r das zu entwickelnde eingebettete Software System erl utert wird Das Dokument enth lt au erdem eine Beschreibung der Anforderungen aus Sicht des Benutzers Kunden und eine Beschreibung der Anforderungen aus Sicht der Entwickler
204. rl utert Abbildung 53 zeigt einen Ausschnitt aus dem E Klassendiagramm des Teilsystems LichtRegelungFlur des Geb udeautomationssystems E Klassendiagramm Das E Klassendiagramm des Teilsystems LichtRegelungFlur ist ein verfeinertes A Klassendiagramm vgl Abbildung 24 Klassendiagramm des Teilsystems LichtregelungFlur auf Seite 50 Aus dem E Klassendiagramm k nnen im Gegensatz zum A Klassendiagramm Parameter und R ckgabewerte sowie deren Datentypen entnommen werden Au erdem sind Defaultwerte f r Attribute im E Klassendiagramm angegeben Beispielsweise ist das Attribut timelntervalExit der Klasse PRHallwayLightController vom Typ DurationType und hat einen Defaultwert von 10 min Die Ableitung der aktiven Klasse LightController von der Klasse Schedu ledFct kann nicht diesem Klassendiagramm entnommen werden Die Vererbungs struktur wird im Klassendiagramm Scheduling deutlich das Klassen und Beziehungen zur Realisierung des Scheduling Mechanismusses umfasst Attribute und Methoden der Sensor und Aktuatorklassen sind im Klassendiagramm Hard ware Wrapper beschrieben Ebenfalls wurden die Klassen Section und Hall waysSection um Durchreichmethoden z B setTimelntervalExit timelntervalExitParam durationType erweitert Dies kann dem Klassendia gramm Benutzungsschnittstelle entnommen werden 102 Entwicklung eingebetteter Software mit UML Produkte
205. rleichtern das Zusammenbinden von bersetzten Komponenten zu ausf hrba ren Teilsystemen Makefiles k nnen auch zum Kompilieren von Komponenten mit ihren Abh ngigkeiten eingesetzt werden Abbildung 102 zeigt einen Ausschnitt aus einem Teilsystem Makefile zum Zusam menbinden der Komponenten des Teilsystems LichtRegelungFlur des Geb u deautomationssystems Teilsystem Makefile Mit Hilfe des Makefiles zur Erstellung eines lauff higen Teilsystems LichtRege lungFlur werden Treiber und Stubs bersetzt Anschlie end werden die Kompo nenten zu einem ausf hrbaren Teilsystem Teilsystemtest zusammengebunden Entwicklung eingebetteter Software mit UML 197 System Integration Makefile C Compiler CXX g Praeprozessorflags CPPFLAGS I TESTDIR I TESTDIR include I TESTDIR init C Compiler Flags CXXFLAGS g Variablen fuer Dateien EXECUTABLES Teilsystemtest SRCS Teilsystemtest cc Actuator cc Contact cc DimmableLight cc OutdoorLight Sensor cc Portbaustein cc RealRadiatorValve cc RealBlind cc RoomTemperatureSensor cc Sensor cc StatusLine cc WaterTemperatureSensor cc init cc OBJS SRCS cc o GLOBALOBJS UserDataTempType o UserDataDurationType o Blind o BlindController o ClassDT2 o ClassDT2Standby o ClassTimelntervalHeatingUpNormal o ClassTimelntervalHeatingUpStandbyNormal o ClassTi melntervalEntryStandbyNormal o Clock o ControlPanel o ControlPanelFm o Day o DimmableLig
206. rlicht aus status_line sl1 off Szenariol 2 Der Flur ist leer ein Benutzer betritt den Flur durch die g Flurt r Das Flurlicht yig angeschaltet l l l LichtF BA F1 Annahme Die erforderliche Mindestlichtst rke wird LichtE B F2 auch bei ge ffneten T ren nie erreicht ABBILDUNG 22 Beschreibung des Szenariosl1 Flurlichtregelung durch Anwesenheit E Anforderungen Die E Anforderungen beschreiben das Verhalten des zu entwickelnden Software Systems aus Sicht der Entwickler Daf r wird das System in Komponenten Klassen aufgeteilt Das erwartete Verhalten wird basierend auf der Interaktion der Komponenten auf Objektebene beschrieben Es werden sieben verschiedene UML Diagramme zur Beschreibung des gew nschten Systems verwendet 1 Packagediagramme 2 Klassendiagramme 3 ein Data Dictionary 4 Sequenzdiagramme 5 Kollaborationsdiagramme 6 Zustandsdiagramme und 7 Aktivit tsdiagramme A Packagediagramme Bei gro en Systemen is es sinnvoll ausgezeichnete Packagediagramme zu erstel len die eine Aufteilung des Gesamtsystems in Teilsysteme aufzeigen und Bezie hungen zwischen den existierenden Teilsystemen verdeutlichen statische Struktur des Systems Derartige Packagediagramme werden wieder durch Packagedia gramme oder auf unterster Ebene durch Klassendiagramme verfeinert Eine Auftei lung in Teilsysteme reduziert die Komplexit t des Gesamtsystems und erlaubt die parallele Bearbeitung ve
207. rolUnit und LightController aus dem Teilsystem LichtRege lungFlur des Geb udeautomationssystems BANJA Unterschiede zur Analyse Die kurze Beschreibung erl utert f r jede Klasse aus dem UML Entwurf wie sich die Entwurfsentscheidungen und Optimierungskriterien auswirken Aktive Klassen werden im betrachteten Geb udeautomationssystem beispielsweise von einem Scheduler abgeleitet der f r die regelm ige Aktivierung der Klassen sorgt Klasse LightControlUnit Die Methoden personIn und personOut wurden zur Methode occupancyMessage zOccupancyType zusammen gefasst Die Methoden fmSwitchOn und fmSwitchOff wurden zur Methode fmLightControl zLightStatusType zusammengefasst Klasse LightController Die Klasse LightController wird aufgrund ihres aktiven Verhaltens von der Klasse ScheduledFct abgeleitet Die Attribute sectionNr und roomNr wurden eingef gt um Anwesenheitsdetektoren und Lichter auf der Hardware Ebene eindeutig initialisieren bzw ansprechen zu k nnen Die Methoden switchLightOn und switchLightOff wurden in der Methode lightControl zLightStatusType zusammengefa t Die Methode setLightControlUnit dient der Initialisierung ABBILDUNG 51 Dokumentation von nderungen am A Klassendiagramm E Packagediagramme Packages werden verwendet um die Aufteilung des Gesamtsystems in Teilsysteme Packages aufzuzeigen und Beziehungen zwischen den Teilsystemen zu verdeutli chen Im Vergleich zu den A
208. rollfluss Die Reihenfolge der Bearbeitung der Teilprozesse ist in Form eines Pr zedenzgra phen in Abbildung 112 dargestellt 216 Entwicklung eingebetteter Software mit UML Prozess Systemtest O O O o I I AE Sysiemiest Validierer Anforderungs Entwurfs Kodierer System ingenieur ingenieur integrations ingenieur O O O a 7 Zi Akzeptanztest Validierer Kunde Anforderungs Entwurfs Kodierer System ingenieur ingenieur integrations ingenieur O O O O z O Test im Betrieb 7 Validierer Kunde Anforderungs Entwurfs Kodierer System ingenieur Ingenieur integrations ingenieur ABBILDUNG 112 Kontrollfluss f r den Prozess System Validation 7 5 Prozess Systemtest Im Prozess Systemtest wird der ausf hrbare Systemkode in der Entwicklungsum gebung getestet Die Systemumgebung wird durch einen Simulator simuliert Die Zuverl ssigkeit des Systems wird hinsichtlich der funktionalen Funktionstest und nicht funktionalen Anforderungen berpr ft Als Grundlage f r den Test dienen die Testpl ne im Dokument A Validation Das Verhalten des Systems bei der Test durchf hrung wird protokolliert und entdeckte Fehlverhalten werden auf Fehler in der Dokumentation zur ckgef hrt und behoben Abbildung 113 zeigt den Prozess Systemtest mit konsumierenden produzierenden und modifizierenden Produkten Folgendes Produkt wird im Prozess Systemtest konsumiert e Simulator
209. rschiedener Teilsysteme Auf Anforderungsebene lassen sich bereits erste Teilsysteme anhand der Funktionalit ten die das System ber 46 Entwicklung eingebetteter Software mit UML Produkte nehmen soll identifizieren Im Entwurf werden die bereits identifizierten Teilsys teme weiter verfeinert Zum besseren Verst ndnis sollte jedes Package kurz erl utert werden Abbildung 23 zeigt ein Packagediagramm f r das Geb udeautomationssystem mit einer Erl u terung des Package LichtregelungFlur A Packagediagramm Im betrachteten Geb udeautomationssystem wurde eine Aufteilung in sechs Teil systeme Benutzungsschnittstelle Systemmodusermittlung Temperaturregelung LichtregelungRaum LichtregelungFlur und Hardware Wrapper vorgenommen um eine fr hzeitige parallele Bearbeitung des Systems zu erlauben Die Teilsys teme Systemmodusermittlung Temperaturregelung LichtregelungRaum und LichtregelungFlur wurden anhand der gew nschten Funktionalit ten des zu entwi ckelnden Systems gebildet Sie sind weitgehend unabh ngig und k nnen parallel entwickelt werden Das Teilsystem Benutzungsschnittstelle bildet die Schnittstelle zum Benutzer und greift zum Setzen von verschiedenen Werten auf die funktiona len Teilsysteme zu Das Teilsystem Hardware Wrapper bildet die Schnittstelle zu den konkreten Sensoren und Aktuatoren Die funktionalen Teilsysteme verwenden dieses Teilsystem zur Abfrage von Sensorwerten und zum Ansteuern von A
210. rungen Einfluss auf den Entwicklungsprozess Der besonderen Bedeutung nicht funkti onaler Anforderungen tr gt der Entwicklungsprozess durch eine gesonderte Behandlung solcher Anforderungen Rechnung z B durch spezielle Beschrei bungsformen 3 Die Softwareentwicklung setzt ein genaues Verst ndnis der umgebenden Hard ware voraus Dies resultiert aus der Integration eingebetteter Software in ein sie umgebendes Hardware System das vielfach anwendungsspezifisch ist Das Vorhandensein offener Plattformen ist bei eingebetteten Systemen noch un b lich Einfluss auf den Entwicklungsprozess Aus der Integration eingebetteter Soft ware in ein Hardware System und der starken Interaktion eingebetteter Soft ware mit der physikalischen Umgebung resultiert insbesondere die Verhaltensorientierung des Prozesses Entwicklung eingebetteter Software mit UML 5 Einf hrung 4 Wirtschaftliche Aspekte wie Entwicklungskosten und zeit spielen eine gro e Rolle Der Markt f r eingebettete Systeme ist einer der am st rksten wachsen den M rkte im Informations und Telekommunikationssektor Hieraus resultiert die Forderung nach immer k rzer werdenden Produktzyklen sowie kosteneffizi enteren Entwicklungs und Produktionsverfahren Einfluss auf den Entwicklungsprozess Aus den wirtschaftlichen Anforderungen resultiert die besondere Beachtung der Plan und Kontrollierbarkeit des Prozes ses die mittels kontrollierter Iterationen erreicht wird
211. ruppe Software Engineering Fachbereich Informatik Universit t Kaiserslautern Postfach 3049 D 67653 Kaiserslautern 2000 Antje von Knethen und J rgen M nch Kaiserslautern Alle Rechte vorbehalten Inhalt KAPITEL 1 KAPITEL 2 Einf hrung 1 1 Zielsetzung 1 2 Charakterisierung des Entwicklungsprozesses 1 3 Herkunft des Prozesses 1 4 Prozessbeschreibung 1 5 Der Prozess im berblick 1 6 Das Anwendungsbeispiel 1 7 Planung 1 8 Weiterf hrende Literatur Projekt initialisieren 2 1 Prozessverfeinerung 2 2 Produkte Problembeschreibung B Anforderungen Dom nenwissen on N 15 15 18 21 22 24 25 26 28 Entwicklung eingebetteter Software mit UML iii Inhalt 2 3 Rollen 24 Kontrollfluss 2 5 Prozess Problembeschreibung bearbeiten 2 6 Prozess Dom nenwissen bearbeiten 2 7 Prozess Informelle B Anforderungen bearbeiten 2 8 Weiterf hrende Literatur KAPITEL 3 System Anforderungen bearbeiten 3 1 Prozessverfeinerung 3 2 Produkte B Anforderungen E Anforderungen Verfolgbarkeitsmatrix Anforderungen A Verifikation A Validation Namenskonventionen 33 Rollen 3 4 Kontrollfluss 3 5 Prozess B Anforderungen bearbeiten 3 6 Prozess E Anforderungen bearbeiten 3 7 Prozess Verfolgbarkeitsmatrix Anforderungen bearbeiten 3 8 Prozess System Anforderungen verifizieren 3 9 Prozess Testf lle bearbeiten 3 10 Weiterf hrende Literatur KAPITEL 4
212. s verfeinern Die informellen tabellarischen B Anforderungen wurden bereits im Kapitel Projekt initialisieren erl utert daher werden im Folgenden nur die A Use Cases und die Szenarien beschrieben Use Case Diagramm A Use Cases Das Use Case Diagramm umfasst die m glichen Use Cases d h die Anwen dungsf lle f r das zu entwickelnde System Damit stellt es die m glichen Verwen dungsweisen des Systems dar Es berdeckt die funktionalen Anforderungen an das System Ein Use Case beschreibt eine Aktivit t die durch das zu entwickelnde System unterst tzt werden soll Dies kann eine konkrete Systemfunktionalit t sein z B das Aufdrehen des Heizk rperventils zum Heizen Die Aktivit t kann aber auch eine abstrakte Beschreibung vom gew nschten Verhalten des Systems sein z B die Raumtemperatur soll auf die gew nschte Temperatur steigen Ein Use Case umfasst eine Beschreibung der Ber hrungspunkte der Aktivit t zu ihrer Umwelt z B welche Benutzer sind an der Aktivit t beteiligt Ein Use Case wird durch einen Akteur ausgel st In eingebetteten Systemen k nnen Akteure von Use Cases einerseits au erhalb des zu entwickelnden Systems liegen wie z B ein Benutzer Andererseits k nnen Akteure auch Teil des Systems sein wie z B Sen soren Zum Teil beeinflussen externe Akteure interne Akteure derart dass eine Sys temreaktion ausgel st wird beispielsweise wenn ein Benutzer den Flur betritt und der Anwesenheitssensor Anwe
213. sanforderungen resul tieren Namenskonventionen Das Dokument beschreibt Richtlinien f r die Wahl von Bezeichnern Folgendes Produkt wird produziert UML Entwurf Das Dokument beinhaltet die berarbeiteten und verfeinerten UML Diagramme Die E Klassen und Packagediagramme beschreiben die Struktur des zu implementierenden Systems Unterschiede zwischen dem A und dem E Klassendiagramm werden im Dokument Unterschiede zur Ana lyse dokumentiert Die Klassenbeschreibungen Class Tables beschreiben die Klassen Attribute Methoden und Beziehungen aus den Klassendiagrammen Die E Sequenz und E Kollaborationsdiagramme beschreiben das Verhalten des Systems durch die Interaktion von Objekten Die E Zustandsdiagramme beschreiben das Verhalten einzelner Klassen Die E Aktivit tsdiagramme ver feinern einzelne Operationen Die Teilprozesse E Klassendiagramme bearbeiten E Sequenzdiagramme bearbei ten E Zustandsdiagramme und E Aktivit tsdiagramme bearbeiten beeinflussen sich gegenseitig und lassen sich nicht unabh ngig voneinander durchf hren Wer den z B zu einer Methode im Klassendiagramm Parameter und R ckgabewerte Entwicklung eingebetteter Software mit UML 133 System Entwurf bearbeiten angegeben dann muss diese Verfeinerung auch im Sequenz und Zustandsdia gramm nachvollzogen werden Die Konsistenz zwischen den verschiedenen Dia grammen muss gew hrleistet werden Zu jedem dieser Teilprozesse werden im weiteren Be
214. se in den Sequenzdiagram men verschickt werden Folgende Produkte werden im Prozess E Sequenzdiagramme bearbeiten konsu miert e A Sequenzdiagramme e Entwurfsentscheidungen e E Use Cases e E Packagediagramme e E Klassendiagramme e E Zustandsdiagramme e E Aktivit tsdiagramme e Namenskonventionen Folgendes Produkt wird produziert 136 Entwicklung eingebetteter Software mit UML Prozess UML Entwurf bearbeiten e E Sequenzdiagramme Prozess E Kollaborationsdiagramme bearbeiten Im Prozess E Kollaborationsdiagramme bearbeiten werden die E Kollaborations diagramme aus den E Sequenzdiagrammen abgeleitet Mit CASE Werkzeugen z B StP UML k nnen aus den Sequenzdiagrammen Kollaborationsdiagramme automatisch generiert werden Die Generierung sollte geschehen wenn sich die Sequenzdiagramme in einem stabilen Zustand befinden Folgendes Produkt wird in dem Prozess E Kollaborationsdiagramme bearbeiten konsumiert e E Sequenzdiagramme Folgendes Produkt wird produziert e E Kollaborationsdiagramme Prozess E Zustandsdiagramme bearbeiten Im Prozess E Zustandsdiagramme bearbeiten werden die A Zustandsdiagramme aus den E Anforderungen verfeinert und hinsichtlich der Entwurfsentscheidungen und weiterer Entwurfskriterien berarbeitet Die Namenskonventionen geben Richtlinien f r die Wahl von Bezeichnern Die Konsistenz der E Zustandsdiagramme zu den anderen UML Diagrammen muss sicher
215. sen aus einer Fehlerklassifikation OO Fehlerklassifikation Die w hrend der Verifikation aufgedeckten Probleme Fehler werden den folgenden Fehlerklassen zugeordnet Um die Fehler zu klassifizieren bitte die Fehlerklassen in der angegebenen Reihenfolge durchgehen Unvollst ndigkeit U Es fehlen Informationen zu einem Objekt Beispielsweise ist eine Klasse nicht im Data Dictionary beschrieben obwohl sie im Klassendiagramm vorhanden ist Falsche Information F Eine gegebene Information zu einem Objekt ist offensichtlich falsch Beispielsweise kann ein Zustand in einem Zustandsdiagramm der Klasse Fenster nie erreicht werden ABBILDUNG 32 Ausschnitt aus einer Fehlerklassifikation Spezifische Fehlerklassen A Fehlertabellen In den A Fehlertabellen werden alle Fehler die im Produkt Probleml sungsdoku mentation gefunden und noch nicht auf nachfolgende Produkte bertragen wurden aufgelistet Das bedeutet dass die A Fehlertabelle Fehler umfasst die ausschliess lich in der Probleml sungsdokumentation enthalten sind Beispielsweise beinhaltet die Fehlertabelle einen Fehler im A Klassendiagramm der w hrend der Inspektion der System Anforderungen gefunden wurde Ein Anforderungsfehler der die Ursa che f r einen Entwurfsfehler ist und nur durch den Entwurfsfehler aufgedeckt wurde wird nicht in der A Fehlertabelle beschrieben Ein in der A Fehlertabelle dokumentierter Fehler kann w hrend der Inspektion der System Anford
216. sende Problem und das Anwendungsgebiet informell Es wird vom Kunden vorgegeben e Informelle B Anforderungen Dieses Dokument beschreibt die funktionalen nicht funktionalen und inversen Anforderungen an das zu entwickelnde System in tabellarischer Form und in nat rlicher Sprache Es verfeinert die Problembe schreibung Entwicklung eingebetteter Software mit UML 71 System Anforderungen bearbeiten Folgendes Produkt wird modifiziert e B Anforderungen Neben den informellen tabellarischen B Anforderungen enth lt das Dokument A Use Cases und Szenarien Die A Use Cases beschrei ben die m glichen Verwendungsweisen des zu entwickelnden Systems Die Szenarien verfeinern die A Use Cases Sie geben Beispiele f r konkrete Inter aktionssequenzen zwischen den Akteuren und dem System Prozess A Use Cases bearbeiten Im Prozess A Use Cases bearbeiten wird ein Use Case Diagramm erstellt und jeder Use Case informell beschrieben F r die Erstellung eines Use Case Dia gramms und von einzelnen Use Cases sind u a folgende Fragen wichtig 1 Welche Akteure gibt es im System und wie benutzen sie das System Zur Beantwortung dieser Frage sollte die Beschreibung der Sensoren und Aktu atoren aus der Systemumgebung herangezogen werden Au erdem werden evtl in den Beschreibungen des erwarteten Verhaltens des Systems Problembe schreibung informelle B Anforderungen verschiedene Akteure eingef hrt z B ein Hausmeister und ein Benutz
217. senheit meldet Der Use Case endet mit einem nach au en sichtbaren Verhalten Die vom Use Case beeinflussten Gr en in der Umgebung werden im Use Case Diagramm ebenfalls als Akteure dargestellt In eingebetteten Systemen f hrt ein Systemverhalten h ufig zu einem Ansteuern von Aktuatoren z B einer Lampe Die Aktuatoren sind Teil des Systems und werden damit als interne Akteure modelliert Die beeinflusste Gr e der Umgebung repr sentiert als externer Akteur ist beispielsweise die Helligkeit im Raum Das Use Case Diagramm kann helfen Sensoren und Aktuatoren die f r die Ver wendungsweisen des Systems ben tigt werden zu bestimmen Im Folgenden wird von dem einfachen Fall ausgegangen dass die notwendigen Sensoren und Aktuato ren bereits bekannt und im Dokument Dom nenwissen beschrieben sind Es gilt zu berpr fen ob alle vorgesehenen Aktuatoren siehe Dokument Dom nenwissen auch tats chlich f r das Verhalten des Systems ben tigt werden und umgekehrt Abbildung 21 zeigt einen Ausschnitt aus einem Use Case Diagramm 42 Entwicklung eingebetteter Software mit UML Produkte mit einer Erl uterung eines Use Cases Die Beschreibung eines Use Cases geschieht nach einem vorgegebenen Schema e Initiating event beschreibt durch welche Aktion eines actors der Use Case ausgel st wird e Pre condition beschreibt den Ausgangszustand der gegeben ist bevor der Use Case startet e Description beschreibt welc
218. sollte er als Rahmen angesehen werden der jeweils an den Projekt den Organisations und den Systemkontext angepasst werden muss Der vorliegende Bericht gliedert sich entlang der Beschreibungen der Hauptpro zesse Entwicklung eingebetteter Software mit UML 13 Einf hrung Projekt initialisieren Dom nenwissen Ei System Anforderungen 0 bearbeiten Namens konventionen Probleml sungs o Dokumentation ystem Validation ol Ausf hrbares o System System Entwurf o bearbeiten System Integration EB Software System o Dokumentation System Komponenten Ausf hrbare E Komponente Entwicklungs o SW Komponenten o richtlinien Dokumentation bearbeiten ABBILDUNG 5 Der Gesamtprozess 14 Entwicklung eingebetteter Software mit UML Das Anwendungsbeispiel 1 6 Das Anwendungsbeispiel Der Bericht ist durchg ngig mit Beispielen f r Inhalte von Produkten versehen Diese Beispiele stammen alle aus einem Anwendungsprojekt Dieses Projekt sowie die dabei verwendeten Werkzeuge sollen hier kurz charakterisiert werden Im Rah men des Projekts wurde ein Geb udeautomationssystem mit einer Licht und Tem peraturregelung erstellt Hierbei wurden als wesentliche Techniken UML C Checklisten orientierte Inspektionen und Black Box Testen eingesetzt Die Ent wicklung erfolgte entsprechend des Do it Prozesses Das Projekt wurde von 17 Software Entwicklern Studente
219. sst werden z B an die Verwendung eines Schedulers kann der Implementierungsprozess sehr detailliert angeleitet werden 162 Entwicklung eingebetteter Software mit UML Produkte Abbildung 86 zeigt einen Ausschnitt aus den Kode Ableitungsrichtlinien die im Geb udeautomationsprojekt verwendet wurden Kode Ableitungsrichtlinien Die im Projekt verwendeten Kode Ableitungsrichtlinien waren wie folgt aufgebaut Problem zeigt kurz worum es in der Richtlinie geht Richtlinien sind aus dem Problem abgeleitet und verbindlich f r den Imple mentierer Bemerkungen zur Problematik oder zur Verwendung der Richtlinien Empfehlungen sollten nach M glichkeit ber cksichtigt werden Beispiel kurzes Kodebeispiel zur Verdeutlichung der Richtlinien Es folgt ein Ausschnitt aus den Richtlinien der beschreibt wie man eine Zustands konfiguration eines Zustandsautomaten implementiert Entwicklung eingebetteter Software mit UML 163 System Komponenten bearbeiten Die Zustandskonfiguration ohne Verwendung von IN Problem Ein Objekt muss sich merken in welcher Zustandskonfiguration sich sein Zustandsautomat momentan befindet Dabei sollen an das Zustandsdiagramm angelehnte Zustandsbezeichnungen verwendet werden Richtlinien Zur Darstellung der Zustandskonfiguration einer Klasse wird eine Reihe von Attributen definiert Dies geschieht nach folgenden Regeln wobei auf die rekursive Anwendbarkeit auf Substates zu achten
220. st Rahmen erstellen werden zum Test der Komponenten Test Treiber und Stubs implementiert und bersetzt Die Testpl ne f r den Test der Komponenten siehe Dokument E Validation legen fest welche Funktionalit t Entwicklung eingebetteter Software mit UML 181 System Komponenten bearbeiten die Test Treiber und Test Stubs bieten m ssen Der Quellkode der Test Treiber und Test Stubs wird im Komponententest Rahmen abgelegt die bersetzten Test Trei ber und Test Stubs im Produkt Ausf hrbarer Komponenten Kode Abbildung 95 zeigt den Prozess Komponententest Rahmen erstellen mit konsumie renden produzierenden und modifizierenden Produkten Folgende Produkte werden im Prozess Komponententest Rahmen erstellen konsu miert e E Validation Folgende Produkte werden produziert e Komponententest Stubs e Komponententest Treiber Folgendes Produkt wird modifiziert e Ausf hrbarer Komponenten Kode 182 Entwicklung eingebetteter Software mit UML Prozess Ausf hrbare Komponente bearbeiten O Validierer Komponententest Ausf hrbare Komponente Software System Rahmen erstellen F Dokumentation omponententest Komponententest Rahmen Stubs erstellen Komponententest Stubs E Validation Komponententest Treiber erstellen Komponententest Treiber Ausf hrbarer Komponenten Kode ABBILDUNG 95 Verwendete Produkte des Prozesses Komponententest Rahmen erstellen
221. stem Entwurf Review vorbereiten Reviewsitzung System Entwurf Rework System Entwurf Komponenten Testf lle bearbeiten EINBEIBBEIEEEIEEEEIN BEIEIBEEE Gala KIKIKI K I a a a Sdt Ss K x 232 Entwicklung eingebetteter Software mit UML Systemintegrations ingenieur Prozess System Komponenten bearbeiten Quellkode bearbeiten Komponenten Kode bearbeiten Komponenten Kode verifizieren Dom nenexperte ingenieur ingenieur Qualit tsmanager gt lt Verifizierer lt Validierer Gi gt d Anforderungs Gelb Gel gt S Kodierer ER GC Komponententest Rahmen erstellen Komponententest Stubs erstellen Komponenten Kode Review vorbereiten Reviewsitzung Komponenten Kode Rework Komponenten Kode Ausf hrbare Komponente bearbeiten Komponententest Treiber erstellen Ausf hrbare Komponente erstellen Komponententest durchf hren System Integration X Teilsystemtest Rahmen erstellen X Ausf hrbares Teilsystem erstellen Integrationstest Teilsystemtest durchf hren Rework Teilsystem System Validation X X Systemtest Systemtest durchf hren Rework Systemtest Akzeptanztest Installiere System Entwicklung eingebetteter Software mit UML 233 Prozesshierarchie Prozess Dom nenexperte Anforderungs ingenieur Entwurfs ingenieur Verifizierer Validier
222. t in welcher Reihenfolge Methoden der zu testenden Klasse vom Treiber aufgerufen werden sollen Au erdem werden gegebenenfalls Ausgaben des Treibers aufgelistet 3 Das erwartete Verhalten der zu testenden Klasse gibt an wie die zu testende Klasse reagieren soll z B welche Methode einer weiteren Klasse aufgerufen werden soll 4 Die gew nschte Reaktion der zu erstellenden Stubs gibt Anweisungen zur Imp lementierung der Stubs z B welche Werte an die zu testende Klasse zur ckge liefert werden sollen 5 Die Spalte berdeckte Kante im Zustands Aktivit tsdiagramm gibt an wel che Kante oder welcher Zustand des Zustands oder Aktivit tsdiagramms einer Klasse durch den Schritt des Testplans berdeckt wird Dies erleichtert ein Ver stehen und ndern des Testplans Entwicklung eingebetteter Software mit UML 121 System Entwurf bearbeiten Klasse LightControlUnit Testplan zu KompTestl Folgende Stubs sind f r den Test erforderlich LightController void lightControl zLightStatusType zLightStatusType requestLightStatus Der Test testet den Zustandsautomaten der Klasse LightControlUnit g2 Vom Treiber Erwartetes Gew nschte Reaktion berdeckte Kante im d aufgerufene E Me a deza Verhalten der zu der zu erstellenden Zustands E testenden Klasse Stubs Aktivit tsdiagramm testenden Klasse 1 Init gt FM Betrieb LightControlU f G _ LightController
223. t t eingeschr nkt Das Dokument E Verifikation umfasst dann 1 eine Checkliste 114 Entwicklung eingebetteter Software mit UML Produkte 2 eine Fehlerklassifikation 3 eine Liste der gefundenen Fehler und 4 eine Beschreibung der Fehlerbehebungsstrategien E Checkliste Die E Checkliste unterst tzt das Lesen des zu verifizierenden UML Entwurfs der Komponenten Anforderungen und der Verfolgbarkeitsmatrix Entwurf und erleich tert das Finden von Problemen in den Dokumenten Pro Dokument m ssen wie bei der Verifikation der System Anforderungen drei Aspekte berpr ft werden 1 Sind die Dokumentationsrichtlinien erf llt d h ist das Dokument syntaktisch korrekt 2 Ist die Qualit t des Dokuments ausreichend d h ist das Dokument semantisch korrekt und 3 Ist das Dokument mit dem Vor g ngerdokument konsistent In der Checkliste werden zu jedem Aspekt Fragen gestellt Werden Fragen in der Checkliste mit Nein beantwortet dann k nnte es sich bei einem Aspekt um einen Fehler handeln Abbildung 62 zeigt einen Ausschnitt aus einer Checkliste zur berpr fung der Klassen im E Klassendiagramm Entwicklung eingebetteter Software mit UML 115 System Entwurf bearbeiten IO Checkliste berpr fe jede Klasse im Klassendiagramm auf Einhaltung der Dokumentationsrichtlinien 1 Wurden die Namenskonventionen eingehalten 2 Wenn es sich bei der Klasse um eine aktive Klasse handelt Wurde die Klasse von der
224. t sein m ssen letztere k nnen z B im ersten Schritt des Szenarios beschrieben werden F r jedes in den informellen funktiona len und inversen B Anforderungen beschriebene Verhalten sollte ein Szenario exis tieren Zu berpr fen ob dies geschehen ist kann durch eine Referenzierung der informellen tabellarischen B Anforderungen im Szenario erleichtert werden Ein Szenario endet mit einer nach au en hin sichtbaren Reaktion des Systems z B der Ansteuerung eines Aktuators In einem Szenario kann auch beschrieben werden dass das System in einer bestimmten Situation nicht reagiert z B wenn eine Per son einen Raum vorzeitig wieder verl sst und das System aus diesem Grund nicht regelnd eingreift Informelle nicht funktionale B Anforderungen die sich einzel nen Verwendungen des Systems zuordnen lassen werden in der Szenario Beschreibung vermerkt Abbildung 22 zeigt eine m gliche Beschreibung eines Szenarios Das Beispiel zeigt ein Szenario zur Regelung des Flurlichts d h der Use Case Flurlichtregelung_durch_Anwesenheit wird verfeinert Das Szenario beschreibt den Fall dass ein Benutzer einen leeren Flur betritt Entwicklung eingebetteter Software mit UML 45 System Anforderungen bearbeiten Nr E Beschreibung der Szenarien B Anf E Szenariol f r Use Case Flurlichtregelung_durch_Anwesenheit Ein Benutzer betritt den leeren Flur i Keine Anwesenheit Anwesensheitsdetektor imd3 0 Flu
225. t verwendet wurde OO Dokumentation des Testverfahrens Beim betrachteten Geb udeautomationssystem wurde f r jede Komponente ein Black box Test durchgef hrt Basis f r den Test waren die Zustands und Aktivi t tsdiagramme der Klassen und deren ffentlichen Methoden Es wurden folgende Testkriterien zugrunde gelegt 1 berdeckung der Kanten des Zustands und des Aktivit tsdiagramms der zu testenden Klasse 2 Es gibt Klassen die kein Zustandsdiagramm oder Aktivit tsdiagramm besitzen weil ihre Aufgabe im wesentli chen im Setzen und Abfragen von Werten besteht Au erdem gibt es Methoden die nicht im Zustands oder Akti vit tsdiagramm verwendet werden F r diese F lle sind die Testpl ne folgenderma en zu kreieren bzw zu erweitern e Methoden ohne R ckgabewert werden wenigstens einmal aufgerufen e Let der R ckgabewert ein Aufz hlungstyp Alle definierten R ckgabewerte der einzelnen Methoden werden wenigstens einmal angenommen Methoden die dem Setzen von Werten dienen werden dadurch berpr ft dass ein gesetzter Wert anschlie Bend direkt oder indirekt wieder abgefragt wird Sollte eine Abfrage des gerade gesetzten Wertes nicht m glich sein so wird die Methode nicht getestet e Methoden die dem Abfragen von Werten dienen werden berpr ft indem abzufragende Werte vorher gezielt gesetzt werden Wenn der R ckgabewert einer Methode von Methodenaufrufen von anderen Klas sen abh ngt sollen die Me
226. tabellarisch aufgelistet Die Produkthierarchie wird durch Einr ckungen wiedergegeben Den einzelnen Produkten sind Rollen zugeordnet Diese Zuordnung spiegelt eine Verantwortlichkeit der Rollen in Bezug auf die Erstellung Wartung und Bereitstellung der Produkte wider Dom nenexperte Systemintegrations ingenieur Entwurfs ingenieur Verifizierer Validierer Kodierer Produkt Probleml sungsdokumentation Gi Anforderungs Problembeschreibung B Anforderungen Informelle B Anforderungen A Use Cases Szenarien E Anforderungen Gei A Packagediagramme Entwicklung eingebetteter Software mit UML 227 Produkthierarchie h 2 S IS El SIS E E bi EI SI BP Ei SIS 5 E D EI s s5 amp 5 52 5 85 o 5 E2152S8 2 5 582 58 s I158 33 amp 8 3 21335 DIER EERIEIRKEER Produkt 2131 lt 2532 2 2 335 A Klassendiagramme X Data Dictionary X A Sequenzdiagramme X A Kollaborationsdiagramme A Zustandsdiagramme A Aktivit tsdiagramme Verfolgbarkeitsmatrix Anforderungen A Verifikation A Validation Software System Dokumentation Entwurfsentscheidungen UML Entwurf Unterschiede zur Analyse E Klassendiagramme Class Tables E Use Cases E Sequenzdiagramme E Kollaborationsdiagramme E Zustandsdiagramme E Aktivit tsdiagramme E Packagediagramme Verfolgbarkeitsmatrix Entwurf Komponenten Anforderungen E Verifikation E
227. tart zu dem der Hausmeister ueber das ControlPanelFM das Licht A ein Testfall 6 7 bzw ausschalten Testfall 8 soll int testCase6_pointOfTime_fMLightControl 11 int testCase7_ pointOfTime_fMLightControl 11 int testCase8_pointOfTime_fMLightControl 11 A Anzahl der Minuten die ein bestimmter Testfall dauert int timeDuration_testCase 9 0 15 30 30 0 30 20 20 20 void main House HousePtr Section SectionPtr cout lt lt Gruppe 3 Teilsystemtest n cout lt lt WE Initjalisierung gestartet ERFEREREEEE E n n cout lt lt Erzeugung des Schedulers Scheduler S 600000 cout lt lt erfolgreich beendet n int StartHour 0 int StartMinute 0 Time StartTime StartHour StartMinute 0 1 1 1997 Timer SystemTime StartTime 60 Time CurrentTime cout lt lt Erzeugung der Gebaeudestruktur HousePtr init SystemTime S cout lt lt erfolgreich beendet n SectionPtr HousePtr gt GetSectionPtr 1 cout lt lt hh Initjalisierung beendet Zenn do cout lt lt Welcher Testfall 1 3 5 8 soll ausgefuehrt werden lt lt endl cin gt gt TestCase while TestCase lt 1 II TestCase gt 8 TestCase 4 cout lt lt nTestfall lt lt TestCase lt lt wird ausgefuehrt lt lt endl lt lt endl cout lt lt cout lt lt cout lt lt Hmmm Variable die festhaelt ob der Aufruf HousePtr gt
228. tation Komponenten Kode Headerdatei Probleml sungsdokumentation Siehe Abbildung 20 auf Seite 41 Software System Dokumentation Siehe Abbildung 49 auf Seite 95 Implementationsdatei K Verifikation K Checkliste Fehlerklassifikation Entwicklungsrichtlinien Kode Ableitungsrichtlinien K Fehlertabellen K Fehlerbehebungsstrategien Programmierrichtlinien Ausf hrbare Komponente N Komponententest Rahmen Komponententest Stubs Komponententest Treiber Ausf hrbarer Komponenten Kode ABBILDUNG 80 Produkt bersicht f r den Prozess System Komponenten bearbeiten Komponenten Kode Der Komponenten Kode beschreibt die Realisierung einer Komponente in einer konkreten Programmiersprache Zur Unterst tzung der Verst ndlichkeit und Wart barkeit des Kodes sollten pro Komponente zwei Kode Dateien angelegt werden 1 eine Headerdatei die die Schnittstelle der Komponente zu anderen Komponen ten beschreibt und 2 eine Implementationsdatei die die Realisierung der Kompo nente enth lt Die Verwendung eines CASE Werzeugs wie z B StP UML erlaubt eine Gene rierung der Klassenheader mit Attributen und Methoden so wie sie in den E Klas sendiagrammen und den Class Tables definiert sind In dem generierten Entwicklung eingebetteter Software mit UML 155 System Komponenten bearbeiten Komponenten Kode werden au erdem angelegte informelle Beschreibungen als Kommentieru
229. teKameraOW enum cOwKeinAuto cOwEinAuto cOwZweiAutos stateZaehlerOW ABBILDUNG 86 Ausschnitt aus den Kode Ableitungsrichtlinien Programmierrichtlinien Im Dokument Programmierrichtlinien werden Richtlinien gegeben die zu einer einheitlichen Gestaltung des Quellkodes f hren z B durch Vorgaben zur Klam merung oder zur Gestaltung von Headern von Dateien Die Richtlinien gew hr leisten eine einheitliche Gestaltung von Komponenten Kode der von verschiedenen Implementierern entwickelt wurde Sie erleichtern ein Verst ndnis 164 Entwicklung eingebetteter Software mit UML Produkte des Quellkodes beispielsweise f r den Wartungsingenieur oder Verifizierer Die Programmierrichtlinien enthalten au erdem Regeln die die M chtigkeit der ver wendeten Programmiersprache einschr nken Das ist insbesondere bei m chtigen Programmiersprachen wie C sinnvoll Abbildung 87 zeigt einen Ausschnitt aus den Programmierrichtlinien des Geb u deautomationsprojekts IO Programmierrichtlinien Aufbau der Header Datei s Die Header Datei beginnt immer mit den beiden Statements ifndef _KLASSE_H define _KLASSE_H und endet mit der Zeile endif Dabei ist KLASSE durch den jeweiligen Klassennamen zu ersetzen s Im Kopf der Datei steht als Kommentar der Autor das Erzeugungsdatum und die Dateihistorie Die Ein tr ge werden von RCS automatisch generiert e Danach kommen alle include Statements die ben tigt werden
230. tellt nur eine Instanz gibt Vom einzelnen Fall h ngt ab welche L sung am geeignetsten ist Die Parameterliste jeder Methode muss vervollst ndigt werden Es m ssen Datentypen von Parametern und R ckgabewerten angegeben wer den Die Sichtbarkeit von Methoden und Attributen public protected private wird festgelegt Entwicklung eingebetteter Software mit UML 97 System Entwurf bearbeiten 7 Defaultwerte f r Attribute werden wenn m glich festgelegt 8 Eine Klasse wird als abstrakt definiert wenn keine Instanzen von ihr abgeleitet werden 9 Konstruktoren und Destruktoren f r die Initialisierung und das L schen von Instanzen von Klassen m ssen angelegt werden Daf r ist eine Initialisierungs reihenfolge der Klassen zu definieren 10 Wird in einem Zustandsdiagramm eine Methode einer anderen Klasse aufgeru fen Beim Methodenaufruf wird der Klassename mit angegeben Klasse Methode UML Entwurf Der UML Entwurf beschreibt die Zerlegung des zu entwickelnden Software Systems in Komponenten die implementiert werden sollen Au erdem wird die Interaktion und das Verhalten der Komponenten beschrieben Daf r werden die UML Diagramme aus den E Anforderungen hinsichtlich der Entwurfsentscheidungen und der weiteren Entwurfsaspekte berarbeitet und verfeinert Unterschiede zwischen den UML Diagrammen aus den E Anforderungen und denen des UML Entwurfs werden im Dokument Unterschiede zur Analyse festgehalten Der
231. tematische Kontrolle des Projektablaufs 1 2 Charakterisierung des Entwicklungsprozesses Der hier vorgestellte Prozess l sst sich charakterisieren als dom nenspezifisch objektorientiert verhaltensorientiert qualit tsorientiert und kontrolliert iterativ Es wird ein Ersterstellungsprozess beschrieben Teile des Prozesses k nnen auch im Rahmen der Wartung von eingebetteten Systemen angewandt werden Dies erfordert jedoch eine sorgf ltige Integration des hier beschriebenen Eirsterstellungs prozesses mit dem Wartungsprozess 3 Eingebettete Systeme lassen sich einerseits gegen ber transformationellen Systemen abgrenzen die zu gegebenen Eingabedaten ein Endresultat berechnen um dann in einen Terminierungszustand berzugehen Auf der anderen Seite lassen sich eingebettete Sys teme gegen ber interaktiven Systemen abgrenzen die zwar auch mit ihrer Umgebung in Wechselwirkung stehen aber nur in dem vom System vorgegebenen Takt Eine termino logische Abgrenzung der Begriffe transformationelles System und interaktives Sys tem findet sich in Halbwachs 1993 Entwicklung eingebetteter Software mit UML Charakterisierung des Entwicklungsprozesses Dom nenspezifisch Der vorgestellte Entwicklungsprozess ist f r Software in eingebetteten Systemen ausgelegt Eingebettete Systeme sind durch Hardware gekapselt und interagieren stark mit dem physikalischen System in ihrer Umgebung Sie m ssen 1 Inform
232. test Treiber angelegt und welche Methoden der zu testenden Komponente aufgerufen werden m ssen ist in den Testpl nen vermerkt Relevante Testergebnisse werden vom Test Treiber nach cout geschrieben Abbildung 88 zeigt einen Ausschnitt aus einem Test Treiber f r die Klasse Light Controller des Teilsystems LichtRegelungFlur aus dem Geb udeautomations system 166 Entwicklung eingebetteter Software mit UML Produkte ANUA Komponententest Treiber include lt Testfall hh gt void main cout lt lt lt lt endl cout lt lt Ausfuehrung von Testfall 1 KompTestl zur Klasse LightController lt lt endl Cout lt lt Hmmm lt lt endl lt lt endl cout lt lt Verwendete Stubs lt lt endl lt lt endl cout lt lt Light lt lt endl cout lt lt gt IsOn zLightStatusType lt lt endl cout lt lt gt SwitchOn void lt lt endl cout lt lt gt SwitchOff void lt lt endl lt lt endl cout lt lt LightControlUnit lt lt endl cout lt lt gt changedLightStatus void lt lt endl lt lt endl int sectionNr 1 int roomNr 0 zLightStatusType lightStatus cout lt lt Schritt 1 Aufruf des LightController Konstruktors lt lt endl LightController lightControllerPtr new LightController sectionNr roomNr A Erzeugen des LightControlUnit
233. thoden der aufgerufenen Klasse entsprechende Werte zur Verf gung stellen ABBILDUNG 65 Ausschnitt aus der Dokumentation des Testverfahrens Dokumentation der Testpl ne E Testpl ne Die Anzahl der Testpl ne wird durch das Testkriterium bestimmt In einem Test plans wird beschrieben wie der Treiber die zu testende Komponente aufrufen muss d h die Eingaben an die Komponente werden festgelegt Au erdem wird notiert 120 Entwicklung eingebetteter Software mit UML Produkte welche Methoden von der zu testenden Komponente aufgerufen werden d h das Verhalten der Komponente wird beschrieben Das Verhalten l sst sich aus den E Zustandsdiagrammen E Aktivit tsdiagrammen und den Klassenbeschreibungen Class Tables ableiten Zu jedem Testplan geh rt eine kurze Beschreibung der ben tigten Stubs und Trei ber Dies erlaubt eine Realisierung der Testumgebung ausschlie lich basierend auf der Beschreibung der Testpl ne Abbildung 66 zeigt einen Ausschnitt aus einem Testplan f r die Klasse LightControlUnit des Geb udeautomationssystems Dokumentation der Testpl ne Ein Testplan ist in der Dokumentation des Geb udeautomationssystems wie folgt aufgebaut 1 Die Angabe eines Testschritts erlaubt den leichteren Vergleich von Testausgabe und erwartetem Testergebnis 2 Die Spalte vom Treiber aufgerufene Methoden der zu testenden Klasse gibt Anweisungen f r die Implementierung des Treibers Es wird notier
234. ts anhand des oben aufgef hrten Testplans Dokumentation der Testergebnisse Testergebnis SystemTestl AnwesenheitskontaktImdl Door 1 offen AnwesenheitskontaktImd2 Door 2 offen Lichtstatus Flur o AnwesenheitsheitskontaktImdl Door 1 geschlossen Lichtstatus Flur o ABBILDUNG 37 Dokumentation zum System Test des Teilsystems Lichtregelung Flur A Ergebnisbewertung Nachdem die Tests anhand der Testpl ne durchgef hrt und die Testergebnisse dokumentiert sind kann die Auswertung der Tests erfolgen Daf r werden die Tes tergebnisse mit dem im Testplan dokumentierten Ausgabeverhalten des Teil Sys tems verglichen Die Ergebnisse der Auswertung d h entdeckte Fehlverhalten werden mit Hilfe einer Tabelle dokumentiert Abbildung 38 zeigt einen Ausschnitt aus einer Tabelle zur Dokumentation von gefundenen Fehlverhalten Entwicklung eingebetteter Software mit UML Produkte A Ergebnisbewertung Die Fehlverhalten werden zur leichteren Referenzierung durchnummeriert wobei die Nummer den Validationsschritt TT Integrationstest ST Systemtest AT Akzep tanztest und TB Test im Betrieb und das Teilsystem LF LichtregelungFlur ent h lt Die Angabe des Schritts im Testplan erlaubt das leichtere Nachvollziehen der aufgedeckten Fehlverhalten Verweis auf Schritt P Verweis auf FV Nr Test imTest Beschreibung des Fehlverhaltens Fehler Nr ST LF FVNr1 SystemTest1 Schritt 3 Das Licht
235. ung e Installiertes System Folgende Produkte werden modifiziert e A Validation e K Verifikation Prozess Rework Test im Betrieb Im Prozess Rework Test im Betrieb werden die in der System Dokumentation loka lisierten und in der Fehlertabelle im Dokument K Verifikation dokumentierten Fehler behoben Die Strategie zur Behebung der Fehler wird in den Verifikations kapiteln der zu ndernden Dokumente beschrieben Die Fehler werden entweder im beim Kunden installierten System nachgezogen oder die Korrektur wird mit einem sp teren Release des Systems herausgegeben Folgende Produkte werden im Prozess Rework Test im Betrieb modifiziert e Komponenten Kode e K Verifikation Entwicklung eingebetteter Software mit UML 225 System Validation e Ausf hrbare Komponente e Ausf hrbares System e UML Entwurf e Komponenten Anforderungen e Verfolgbarkeitsmatrix Entwurf e E Verifikation e E Validation e A Use Cases e Szenarien e E Anforderungen e Verfolgbarkeitsmatrix Anforderungen e A Verifikation e A Validation 7 8 Weiterf hrende Literatur 1 Peter Liggesmeyer Modultest und Modulverifikation state of the art BI Wiss Verlag Mannheim Wien Z rich 1990 2 Glenford J Meyers Methodisches Testen von Programmen Oldenbourg Ver lag M nchen Wien 1982 226 Entwicklung eingebetteter Software mit UML ANHANG A Produkthierarchie Im Folgenden werden die Produkte
236. urfs lokalisiert wurden werden neue Aktivit tsdia gramme eingef gt Die Konsistenz der E Aktivit tsdiagramme zu den anderen UML Diagrammen muss sichergestellt sein Daf r muss berpr ft werden ob nderungen in den anderen UML Diagrammen in den Aktivit tsdiagrammen nachgezogen wurden Die Konsistenzbedingungen aus dem Prozess A Aktivit tsdiagramme bearbeiten gelten weiterhin und werden evtl verfeinert z B muss berpr ft werden ob e die Methoden mit Parametern und R ckgabewerten die die Objekte einer Klasse in den Sequenzdiagrammen geschickt bekommen in dem Aktivit tsdia gramm der Klasse als Events mit Parametern und R ckgabewerten modelliert sind e die Methoden mit Parametern und R ckgabewerten die die Objekte einer Klasse in den Sequenzdiagrammen verschicken als Aktionen im Aktivit tsdiagramm modelliert sind Folgende Produkte werden im Prozess E Aktivit tsdiagramme bearbeiten konsu miert e A Aktivit tsdiagramme 138 Entwicklung eingebetteter Software mit UML Prozess Komponenten Anforderungen erstellen e Entwurfsentscheidungen e E Packagediagramme e E Klassendiagramme e E Sequenzdiagramme e E Zustandsdiagramme Folgendes Produkt wird produziert e E Aktivit tsdiagramme 4 7 Prozess Komponenten Anforderungen erstellen Im Prozess Komponenten Anforderungen erstellen wird die Information des UML Entwurfs vervollst ndigt Nach der Fertigstellung der Kom
237. von Methoden manueller Betrieb changedLightStatus occupancyMessage cPersonOut Automatik Betrieb occupancyMessage cPersonIn ba occppancyMessage cPersonIn FM Betrieb occupancyMessage cPeysonOut Zeitverz gerung Entry Aktion f r State Automatik Betrieb LightController lightControl cLightOn Entry Aktion f r State FM Betrieb LightController lightControl cLightOff Internal Aktion f r State FM Betrieb Event fmLightControl cLightOn Action LightController lightControl cLightOn Event fmLightControl cLightOff Action LightController lightControl cLightOff Zustandsdiagramm der Klasse LightControlUnit Die Klasse kennt vier Zust nde FM Betrieb Automatik Betrieb manueller Betrieb und Zeitverz gerung W hrend des FM Betriebs ist es dem Hausmeister erlaubt niemand ist im Flur anwesend das Flurlicht ber das ControlPa nelFM einzuschalten Wenn ein Benutzer im Flurabschnitt anwesend ist wird unterschieden ob er den Flurlicht schalter bet tigt hat manueller Betrieb oder nicht Automatik Betrieb Der manuelle Betrieb wird wieder aufgehoben wenn alle Benutzer den Flurabschnitt verlassen haben Im Zustand Zeitverz gerung wird verweilt bis alle Benutzer ber eine bestimmte Zeitspanne den Flur verlassen haben Erst dann wird das Licht ausgeschaltet ABBILDUNG 57 Zustandsdiagramm der Klasse LightControlUnit mit einem Ausschnitt aus den vorhandenen Entry Do und Exit Aktionen
238. von Prozess produziert LCD Produkt wird von Prozess modifiziert ABBILDUNG 2 Repr sentation von Prozessen Der Produktflu sagt zun chst nichts aus ber die Reihenfolge der Durchf hrung der Prozesse Die Durchf hrungsreihenfolge auch Kontrollfluss genannt wird in diesem Bericht mit Pr zedenzgraphen veranschaulicht Ein Pr zedenzgraph beschreibt die Abh ngigkeiten der Prozesse hinsichtlich der Abarbeitungsfolge Ein Beispiel ist in Abbildung 3 gegeben Die Pfeile geben die Reihenfolge der Abarbeitung vor Eine T tigkeit kann erst begonnen werden sobald alle T tigkei ten mit eingehendem Pfeil beendet sind Genauere Angaben zum Kontrollfluss befinden sich in der textuellen Beschreibung Eine Gesamt bersicht ber die Abar beitungsfolge aller Prozesse findet sich im Anhang Entwicklung eingebetteter Software mit UML 11 Einf hrung UML Entwurf a bearbeiten Verfolgbarkeitsmatrix Entwurf bearbeiten System Entwurf o Legende veritizieren __ __ Abarbeitungsreihenfolge ABBILDUNG 3 Repr sentation der Abarbeitungsreihenfolge Rollen Software Entwicklungsprozesse werden von Agenten Personen oder Werkzeugen durchgef hrt Diese spielen bei der Durchf hrung eines Prozesses bestimmte Rol len Eine Rolle tr gt die Verantwortung f r die Erledigung der mit dem Prozess verbundenen Aufgaben Beispiele f r Rollen sind der Anforderungsingenieur der Entwurfsingenieur der Validierer oder
239. wird Die nderungen der Sensorwerte sind beim Teilsystemtest von der Zeit abh ngig Das Verhalten der Sensoren in Abh ngigkeit der Zeit und des Testfalls wird im Stub durch die Definition eines Arrays mit zwei Dimensionen TESTFALL und Entwicklung eingebetteter Software mit UML 195 System Integration SCHRITTE eingef hrt Die erste Array Dimension legt die Abh ngigkeit der Sen sorwerte von der Testfallnummer fest In jedem Testfall haben die Sensoren ein unterschiedliches Verhalten Die zweite Array Dimension teil das Verhalten des Sensors in einzelne Schritte F r jeden Schritt ist der Zeitpunkt der Wert nderung und der Sensorwert selbst anzugeben Wenn zu einem beliebigen Zeitpunkt ein Sensor abgefragt wird kann der R ckga bewert mit Hilfe des Arrays bestimmt werden Testfall 1 Flurlichtregelung durch Anwesenheit Wertefolge zum Erreichen des Startzustandes fuer den Testfall A Keine Anwesenheit im Flurabschnitt Anwesen Anwesen Anwesen Anwesen Anwesen Anwesen Anwesen Anwesen Anwesen eitskonta eitskonta eitskonta eitskonta eitskonta eitskonta eitskonta eitskonta eitskonta ktImd1Door1 1 0 Minuten 0 ktImd1Door1 1 0 Wert offen ktImd2Door1 1 0 Minuten 0 ktImd2Door1 1 0 Wert offen ktImd1Door2 1 0 Minuten 0 ktImd1Door2 1 0 Wert offen ktImd2Door2 1 0 Minuten 0 ktImd2Door2 1 0 Wert offen ktImd3 1 0 Minuten 0 b eitskonta
240. wird produziert e A Use Cases Prozess Szenarien bearbeiten Die einzelnen Use Cases werden mittels Szenarien konkretisiert Die Szenarien sollten dabei die informellen tabellarischen B Anforderungen berdecken Bei der Beschreibung der Szenarien sollte Folgendes beachtet werden 1 Zu jedem Szenario sollten die Vorbedingungen beschrieben werden die erf llt sein m ssen damit das Szenario eintreten kann 2 Jedes Szenario beginnt mit einer Aktion des Akteurs 3 Jedes Szenario sollte genau eine Interaktionssequenz zwischen Akteur und Sys tem darstellen d h 1 Die Vorbedingungen des Szenarios sind so zu konstruieren dass nur eine Systemreaktion ausgel st wird z B nicht Temperaturregelung und Lichtrege lung gleichzeitig 2 Das Szenario endet wenn das System eine Reaktion zeigt z B Licht wird angeschaltet 4 Das Szenario sollte konkrete Werte enthalten Folgende Produkte werden in dem Prozess Szenarien bearbeiten konsumiert e Systemumgebung e Referenz Dokumente e Problembeschreibung e Informelle B Anforderungen e A Use Cases Folgendes Produkt wird produziert e Szenarien Entwicklung eingebetteter Software mit UML 73 System Anforderungen bearbeiten 3 6 Prozess E Anforderungen bearbeiten Im Prozess E Anforderungen bearbeiten werden die B Anforderungen verfeinert und in eine f r die Entwickler vertraute Notation berf hrt Die Namenskonventio nen geben Richtlinie
241. wird trotz Personenanwesenheit K LF FNr 45 nicht angeschaltet ABBILDUNG 38 Ausschnitt aus der Tabelle zur Bewertung der Testergebnisse Die beim Test entdeckten Fehlverhalten lassen sich auf Fehler im Kode zur ckf h ren und werden in der K Fehlertabelle im Dokument K Verifikation dokumentiert In die Tabelle zur Bewertung der Testergebnisse wird ein Verweis auf die Fehler nummern erg nzt Namenskonventionen Die Einf hrung von Namenskonventionen bereits auf Ebene der System Anforde rungen gew hrleistet die Namensgleichheit zu sp teren Entwicklungsprodukten und unterst tzt damit die Verst ndlichkeit und nderbarkeit der System Dokumen tation Au erdem erleichtert sie eine Abstimmung im Team Abbildung 39 zeigt m gliche Namenskonventionen f r System Anforderungen Entwicklung eingebetteter Software mit UML 67 System Anforderungen bearbeiten BANNER Namenskonventionen e Bezeichner tragen nat rlichsprachliche oder problemnahe Namen oder sind verst ndliche Abk rzungen solcher Namen e Kein Name beginnt mit einem Underscore _ e Zwei Bezeichner d rfen sich in einem Sichtbarkeitsbereich nicht ausschlie lich durch Unterschiede in der Gro Kleinschreibung unterscheiden e Alle Bezeichner werden der englischen Sprache entnommen e Bilden mehrere Teilworte einen Namen so sollten zur optischen Trennung der Teilworte einzelne Gro buchsta ben verwendet werden Underscores werden
242. zeuge erlauben das Dokumentieren einzelner Diagrammelemente Wird diese Funktionalit t genutzt k nnen die Class Tables mit Hilfe des CASE Werkzeugs z B StP UML generiert werden Folgende Produkte werden im Prozess Klassenbeschreibungen Class Tables bearbeiten konsumiert e E Klassendiagramme Entwicklung eingebetteter Software mit UML 135 System Entwurf bearbeiten e Data Dictionary Folgendes Produkt wird produziert e Class Tables Prozess E Sequenzdiagramme bearbeiten Im Prozess E Sequenzdiagramme bearbeiten wird das A Sequenzdiagramm aus den E Anforderungen verfeinert und hinsichtlich der Entwurfsentscheidungen und anderer Entwurfskriterien berarbeitet Die Namenskonventionen geben Richtli nien f r die Wahl von Bezeichnern Die Konsistenz der E Sequenzdiagramme zu den anderen UML Diagrammen muss sichergestellt sein Daf r muss berpr ft werden ob nderungen in den anderen UML Diagrammen in den Sequenzdiagrammen nachgezogen wurden Die Konsis tenzbedingungen aus dem Prozess A Sequenzdiagramme bearbeiten gelten wei terhin und werden evtl verfeinert z B muss berpr ft werden ob e die Methoden mit Parametern und R ckgabewerten einer Klasse im Klassendiagramm in den Sequenzdiagrammen an Objekte der Klasse mit Parametern und R ckgabewerten geschickt werden e die Methoden mit Parametern und R ckgabewerten die im Zustandsdiagramm als Aktionen modelliert sind von Objekten der Klas

Entwicklung eingebetteter Software mit UML

Contents

Download Pdf Manuals

Related Search

Related Contents