Home

POTAD - Digitale Bibliothek Thüringen

1. Sensor Context _ lt Actuator gt Actuator sm gt lt Sensor gt Sensor_getMethod 7 Ure ae Actuator_setMethod periodic call_step _ lt AbstractState gt Context Class AbstractState AbstractControlLoop Class ConcreteState s 1 Sensor Class q a 1 Actuator Class s 1 Sensor_getMethod Operation a 1 Actuator_setMethod Operation AbstractState Class c 1 ConcreteState Class 1 _ lt ControlLoop gt c 1 ConcreteControlLoop Class AbstractControlLoop ee ReactiveControlLoop gt un N or initialize ConcreteControlLoop step shutDown 219 11 3 Erlauterung Dieses Muster von Douglass 99 ist eine Erweiterung des Musters ControlLoop Es unterst tzt zustandsabhangiges Steuerungs bzw Regelungsverhalten in dem es das State Muster integriert Dies wird im Muster durch den Zusammenhang zwischen jeweils einem Zustand AbstractState und einem Regelkreis AbstractControl Loop realisiert Diese konnen durch konkrete Vertreter ConcreteState und ConcreteControlLoop ausgestaltet werden wobei darauf zu achten ist dass jedem Zustand genau ein Regelkreis zugeordnet ist In den Kontext ein gebunden wird das Muster ber die Klasse Context die die vorhandenen Zust nde aggregiert Laut Douglass eignet
2. Messung Sensor Messeinheit send sensorValue signal sensorValue signal sensorValue Abbildung 3 34 Das Template Messung Abbildung 3 35 zeigt das Paket Wetterstation bevor es mit dem Template Messung gebunden wird Es enth lt zwei leere Klassen und ein Signal die nicht ber Assoziationen miteinander verbunden sind Messung_Wetterstation Thermometer signal Wetterstation Temperatur Abbildung 3 35 Das Paket Messung_Wetterstation vor der Template Instanziierung 85 3 Stand der Technik In Abbildung 3 36 ist das Paket nach der Bindung und Instanziierung zu sehen Die beiden Klassen Thermometer und Wetterstation fungieren als tats chliche Parameter f r die formalen Parameter Sensor und Messeinheit das Signal Temperatur ist sensorWert zugewiesen Die im Template definierte Struktur wurde mit dem Zielpaket verschmolzen Entsprechend wird die Assoziation zwischen Thermometer und Wetterstation die Operation send_sensorValue bei Thermometer und der Signalempfang von Temperatur bei Wetterstation angelegt Messeinheit Class sensorWert Signal Sensor Class Messung A bind Bind sensor Wert Temperatur Sensor Thermometer Messeinheit Wetter station Messung_Wetterstation
3. L Sensor aaa _ _ _ Sollwert Aktuator geber 2 1 2 1 Bus 1 Transceiver I Bus 1 Abbildung 1 2 Logische und technische Systemarchitektur Umfeld lm Kontext dieser Sichtweise ergibt sich das Entwurfsproblem der Softwareentwicklung durch Verknupfungen zwischen Funktionen und Steuergerat bzw CPU rot markiert Fur einen Mikrocontroller muss ein Programmcode bereitgestellt werden der einerseits alle dem Steuer gerat zugewiesenen Funktionen der logischen Systemarchitektur realisiert und andererseits auf die durch die technische Systemarchitektur beschriebene Plattform abgestimmt ist Dar ber hinaus m ssen weitere Anforderungen ber cksichtigt werden insbesondere auch nicht funktionale Dazu geh ren z B gesetzliche Bestimmungen Industriestandards und klassische Anforderungen wie Wiederverwendung Wartbarkeit oder Variabilit t Sch uffele et al 03 Die logische und technische Systemarchitektur der Systementwicklung sind somit Analyse gegenstand der Softwareentwicklung Stark vereinfacht k nnte dieser Zusammenhang auch wie folgt formuliert werden Das Designmodell der Systementwicklung ist das Analysemodell der Softwareentwicklung Eine entscheidende Herausforderung bei der Erstellung des Softwaredesigns die dem Softwar
4. 5 3 Erl uterung Das ExceptionMonitor Muster von Douglass 99 stellt einen Mechanismus f r die Behandlung von Ausnahmen auf Designebene dar Die ExceptionSafeClass stellt eine abstrakte Schnittstelle zur Benutzung dieses Mechanismus bereit die ein Client durch Beerbung verwenden kann Sie sendet einzelne Exceptions an den ExceptionMonitor der eine Aufzeichnung ber die Ausnahmen f hrt ExceptionLog und ExceptionRecord und sie gegebenenfalls an die globale Ausnahme behandlung GlobalExceptionHandler weiterleitet Jede Exception verweist auf den f r sie zu st ndigen ExceptionHandler der wiederum der ExceptionSafeClass bzw dem GlobalExceptionHandler mitteilt ob die Ausnahme behandelt werden konnte oder nicht Die Multiplizitaten der Parameter sind so gesetzt dass sich das Muster immer auf eine Kombination von ExceptionMonitor ExceptionHandler und ExceptionSafeClass bezieht Die Klassen ExceptionLog und GlobalExceptionHandler sollten laut Douglass als Singleton siehe Designmuster Singleton implementiert werden 214 6 HeterogeneousRedundancy 6 1 Zweck Heterogene Redundanz in einem Objektmodell abbilden 6 2 Struktur Context useSecondChannel Boolean periodic call _getChannelState ensor 1 Class Channel Class First_ lt Channel gt Controller Class Actuator Class Second_ lt Channel gt 5 _ lt Channel
5. _ExceptionLog 1 251 Abbildungsverzeichnis Abbildung 1 1 Vernetzte Steuerger te in einem Oberklassenfahrzeug ceeeeennneen 2 Abbildung 1 2 Logische und technische Systemarchitektur cccccc cece cece cece eee eeeneeeeeeeeeseeee cesses nennen 4 Abbildung 2 1 Logische Systemarchitektur des KFS can se a a u 11 Abbildung 2 2 Skizze der technischen Systemarchitektur der Fallstudie informell 13 Abbildung 2 3 Softwaresimulator f r das K PS RR Hein 14 Abbildung 3 1 Uberblick der Themen rest tinurina er ETa T a Ln 17 Abbildung 3 2 Das System Fahrer Fahrzeug Umwelt Schauffele et al 03 18 Abbildung 3 3 Ein Kernprozess f r System und Softwareentwicklung Schauffele et al 03 21 Abbildung 3 4 Artefakte und deren Beziehung in der EAST ADL L nn et al 04 30 Abbildung 3 5 Ausschnitt einer m glichen funktional Analysis Architecture f r das KFS 34 Abbildung 3 6 Ausschnitt einer m glichen Hardware Architecture f r das KFS 35 Abbildung 3 7 Modellinhalte des E E Konzept Tools Aquintos 06 2222200000 gt 36 Abbildung 3 8 Ausschnitt eines m glichen Funktionsnetzwerks f r das KFS 0 39 Abbildung 3 9 Ausschnitt einer m g
6. A i bind Bind sensorWert Temperatur Luftfeuchtigkeit Sensor Thermometer Hygrometer Messeinheit Wetterstation Messung_Wetterstation Thermometer gt Wetterstation send_sensorValue signal Luftfeuchtigkeit signal Temperatur Hygrometer send_sensorValue signal signal Temperatur Luftfeuchtigkeit Abbildung 3 37 Instanz des Musters Messung mit mehreren Sensoren Die Zuweisung mehrerer Elemente an einen Parameter f hrt jedoch zu einem Problem wenn es Abh ngigkeiten zu anderen Parametern gibt Im Beispiel gibt es eine solche Abh ngigkeit zwischen Sensor und sensorValue Nach der Instanziierung ist nicht mehr klar welches Signal von welchem Sensor gesendet wird Der Zusammenhang von Thermometer und Temperatur sowie Hygrometer und Luftfeuchtigkeit ist nicht modelliert Ein entsprechender Gruppierungs mechanismus oder ein Konstrukt mit dem die Abh ngigkeit zwischen den Parametern Sensor und sensorWert bei der Modellierung des Templates ausgedr ckt werden kann steht in der 87 3 Stand der Technik UML nicht zur Verf gung In dem in Kapitel 4 2 1 vorgestellten selbst modifizierten Meta modell wird f r diese L cke ein entsprechendes Konstrukt vorgeschlagen Im Rahmen der Recherchen konnte nicht geklart werden was passiert wenn bei der Bindung eines Pa
7. e Functional Design Hardware Architecture Architecture y Refined into Appears as id Function Instance Platform Model Model Allocated to Results in Allocation Model Abbildung 3 4 Artefakte und deren Beziehung in der EAST ADL L nn et al 04 Die Artefakte Vehicle View Functional Analysis Architecture Functional Design Architecture und Function Instance Model stehen in der Vertikalen in einer Verfeinerungsbeziehung Auf dieser Achse werden Funktionen ausgehend von Benutzeranforderungen in Richtung realisierender Softwarekomponenten verfeinert wobei die Hardware weitgehend unber ck sichtigt bleibt Auf der Horizontalen stehen die einzelnen Artefakte in einer Allokations oder Mapping Beziehung Die realisierungsunabh ngig definierten Funktionen werden hier der aus f hrenden Hardware eines Fahrzeugs zugeordnet Die Verlinkung zwischen function Instance 30 Systementwicklung Model und Platform Model ist sehr umfangreich und wird in einem eigenen Modell dem Allocation Model beschrieben Die Artefakte im Einzelnen Vehicle View Ein Aequirements Modell das unter anderem die kundenerlebbaren Funktionen in Form von Features Merkmalen beschreibt F r die detaillierte Beschreibung der Anforderungen an ein Feature wird auf Modellierungselemente der SysML OMG a zur ckgegriffen Au erdem k nnen die m glichen Varianten bei der Kombination dieser Features f r ein Fahrzeug
8. IABG 97 Industrieanlagen Betriebsgesellschaft IABG V Modell Entwicklungsstandard f r IT Systeme des Bundes Vorgehensmodell Kurzbeschreibung 1997 URL http www v modell iabg de vm97 htm IBM a IBM a Rational Software Architect Produktseite URL http www 306 ibm com software awdtools architect swarchitect index html IBM b IBM b Rational Rose XDE Developer Produktseite URL http www 306 ibm com software awdtools developer rosexde IBM c IBM c MDA toolkit for Rational XDE Java URL http www 306 ibm com software rational mda toolkit html IESE a Fraunhofer IESE a UML 1 x berblick Software Engineering Wissensdatenbank URL http www software kompetenz de IESE b Fraunhofer IESE b Software Engineering Wissensdatenbank URL http www software kompetenz de IESE c Fraunhofer IESE c 4 Schichten Metamodellarchitektur Software Engineering Wissensdatenbank URL http www software kompetenz de INCOSE INCOSE The International Council on Systems Engineering A Consensus of the INCOSE Fellows URL http www incose org practice fellowsconsensus aspx ISO IEC 98 ISO IEC International Organization for Standardization Internation Electrotechnical Commision SO IEC 14977 1996 Information technology Syntactic metalanguage Extended BNF EBNF 1998 ISO IEC 05 ISO IEC International Organization for Standardization Internation Electrotechnical Commision 79501
9. OpenLoopController Class o 1 ControlOutputValueDrain Class o 1 ControlOutputValue Signal i 0 ControllnputValueSource Class i 0 ControllnputValue Signal ReferenceValueSource Class ReferenceValue Signal a OpenLoopControl ee p p _ 0 0 reer vo Relerenice Valle yor lt ControlOutputValue gt ReferenceValueSource 1 OpenLoopCont roller PSE SS SEIE E EAE EIER USE D ControlOutputVa lueDra in Abbildung 4 10 Beispiel f r gruppierte und mit Multiplizit ten versehene Parameter Im Beispiel werden die Parameter ControlOutputValueDrain und ControlOutputValue in der mit Oo bezeichneten Gruppe zusammengefasst Nach den Multiplizitatsangaben muss mindestens eine solche Gruppe angelegt sein und innerhalb dieser Gruppe muss den Parametern ControlOutputValueDrain und ControlOutputValue jeweils ein Element zugewiesen werden Bei der Bindung der Parameter wird die Gruppenbildung dadurch realisiert dass die tats chlichen Parameter geordnet sind und entsprechend der Gruppenmultiplizitat ausgelesen werden Im Beispiel werden somit zun chst die ersten tats chlichen Parameter von ControlOutputValueDrain und ControlOutputValue zu einer Gruppe zusammengefasst dann die an zweiter Stelle usw Diese nicht ganz einfach zu lesende Darstellungsweise ist dem Umstand geschuldet dass Rat onal XDE keine dezidierte Unterst tzung von Parametergruppen bietet
10. Referenced Model Elements A co F ET closedloop tra Faulkhandler tra Et Fallstudie _ Ar Entity Speect 4 Handler_error Accelerator bind errorCode Glok 2 ie UserInterFace HMI_Driver_ Code clc BrakeContro Car Indicator RPM_Error_LED Hal ednalysisCollaborations CC_FaultHandler MPFDisplay Contrali Accelerator m CruiseControlleyver BrakeControl CruiseControllever Menucontrols ResetButton Control EngineContratler walue accel_value brake_value eh 4nalysisCollaboratione Engine Corrector buttonMumber value leverPosition_ lt gt e4nalysisCollaborations EngineOpenLoop value resetButton_value Indicator_ ci vwalue MPFDisplay_walue RPM_LED_ Engine RPMDetector value e EngineRPMSensor Engine Throttle Corrector GlobalPowertrainF aultHandler HMI_ Driver Car eh 4nalysisCollaborations HMI_LI LocalCCFaultHandler LocalEngineRPMFaultHandler LocalSCFaultHandler j Main Model Explorer Navigator Toolbox iri Model Documentation Eigenschaften Tasks Output Model Documentation Abbildung 5 2 Start der Transformation in XDE POTAD Transformation Sele Parameter f r die Transformation Datei des Analysemodells C YEntwicklung DE WorkspacelPOT AD TestTrarsformationen Analaysis mdx Durchsuchen Datei des Designmodells c Entwicklung xDE workspace POTAD TestTransformationen Des
11. Signal ee we a FaultHandler ve Ve eN BEE el J lt InitiateLocalCorrectiveAction gt LocalFaultHandler ee GobalFaultHandler lt GlobalFaultIndication gt e LocalFaultHandler Behandelt lokale Fehler und sendet ggf GlobalFaultIndication an GlobalFaultHandler wenn sich diese nicht lokal beheben lassen e GlobalFaultHandler F hrt nach dem Empfang von GlobalFaultIndication die globale Sicherheitslogik aus und sendet ggf InitiateLocalCorrectiveAction an alle oder einzelne LocalFaultHandler 4 4 Beispiel Das Beispiel zeigt einen LocalFaultHandler der Chassis Domane und einen LocalFaultHandler der Powertrain Dom ne LocalFaultHandler ChassisFaultHandler PowertrainFaultHandler die 200 beide durch eine globale Fehlerbehandlung FlobalFaultHandler CentralFaultManagement koordiniert werden Die globale Fehlerbehandlung kann f r die Durchsetzung der globalen Sicherheitslogik lokale Zustandswechsel ber das Signal ChangeStateTo InitiateLocalCorrectiveAction ChangeStateTo veranlassen BER LocalFaultHandler 1 Class Bind GlobalFaultHandler CentralF aultManagement GlobalFault GlobalFaultHandler Class Indication GlobaleF aultld nitiateLocalCorrectiveAction GlobalFaultindication Signal ee au Se 1 ChangeStateTo l LocalFaultHandler 1 ChassisFault __ IIn
12. Softwareentwicklung Cases und Szenarien zu beschreiben Das Artefakt Vehicle View aus der EAST ADL ist dagegen relativ formalisiert Es beschreibt die Funktionen eines Fahrzeugs als Features klassifiziert die damit verbundenen Anforderungen nach funktionalen und nichtfunktionalen Anforderungen und stellt umfangreiche Mechanismen zur Verf gung um die Variabilitat eines features zu modellieren Auch bei der Beschreibung der logischen Systemarchitektur sind die Vorgaben der EAST ADL formaler Das Metamodell der Functional Analysis Architecture macht sehr konkrete Angaben wie Funktionen und thre Kommunikationsbeziehungen modelliert werden Bei der Verhaltens beschreibung verweist die EAST ADL auf externe Werkzeuge wie z B Simulink ROPES schl gt f r die Strukturbeschreibung insb Festlegung von Subsystemen Klassen und Komponentendiagramme vor ohne jedoch konkretere Angaben zu machen Die Executable Specitication kann als Verhaltensbeschreibung der logischen Systemarchitektur interpretiert werden und wird ebenfalls nicht konkret festgelegt Ebenso wie bei der EAST ADL wird auch bei ROPES auf Werkzeuge wie Simulink oder Statemate verwiesen Bei der Beschreibung der technischen Systemarchitektur stutzt sich ROPES vor allem auf UML Verteilungsdiagramme bei denen Hardware Einheiten als Modes beschrieben werden Kapitel 3 2 1 d kam bereits zu dem Ergebnis dass sich mit UML Verteilungsdiagrammen nur sehr begrenzt die E E Architektur eines F
13. Thermometer gt Wetterstation send_sensorValue signal Temperatur signal Temperatur Abbildung 3 36 Instanz des Templates Messung Der Verschmelzungsprozess ist jedoch komplizierter als das gezeigte Beispiel es vermuten l sst Wenn die an Parameter gebundenen Elemente z B bereits ber Attribute Operationen oder Assoziationen verf gen k nnen sich Konflikte mit der Template Struktur ergeben Bei der Instanziierung aus Abbildung 3 36 stellen sich z B folgende Fragen e Angenommen zwischen Thermometer und Wetterstation existiert bereits vor der Instanziierung des Musters eine gerichtete Assoziation wird durch die Musterinstanziierung eine weitere Assoziation angelegt oder wird die existierende wieder verwendet e Was passiert wenn die Klasse Wetterstation bereits vor der Musterinstanziierung ein Signal mit dem Namen Temperatur empfangen kann dieses aber einen anderen Typ hat als der tatsachliche Parameter aus der Musterbindung Wird der existierende Signalempfang ber schrieben e Was passiert wenn die Klasse Thermometer bereits vor der Musterinstanziierung ber eine Operation mit dem Namen send_sensorValue verfugt diese aber eine andere Signatur hat Wird diese geloscht und mit der Signatur aus der Musterdeklaration ersetzt Fur die Aufl sung dieser Konflikte sind f r die unterschiedlichen Template Arten Ver schmelzungsrege
14. cccccccccccnececccccccccuccececuuceeenaneeeenueeeennuaeenauaneenanes 183 6 1 BERPR FUNG DES EIGENEN ANSATZES arena 183 6 2 A TORE D R EOSUNG 3 ge ie este sea n he 185 6 3 GRENZEN DES ANSATZES 2 ne einer nee ee 187 7 ZUSAMMENFASSUNG UND AUSBLICK uuuuansenanannnnnnnnnnnnnnnnnnnnnnnnnnnn nn nun nun nun nennen 189 7 1 ZURUNE TIGER 2d el ed eee a gee ee ne TO eee er ee Te 190 ANHANG A MUSTER 2 2 een ae neun 193 PER ANAL ae E TE a ee T ENLA VE ee re Tr Ban en Te 193 FREE DB ESET AST ER ehe es nee nen ee ee nr 210 ANHANG B TRANSFORMATIONSREGELN cccccecccccccccccccccccecnccececauaeeennueeenuunenenunes 225 BE KOSEBLEOOPEONTROL Se ee en ee 225 B A OPENLOOP CONTR O SE a N ES ee 230 B et SINT AO sh tee tet a ll EN a a Bas TARA ee Bel act nad hh ie eh aut Pi dese Ae 234 BAUDETECSTOREORRE ET seco encom ct ee one ent E EA Sent A E ee Oe Se ee oe 237 Be Pee Ts HANDLER desas er ee Bagh ied silt lye ee ge 239 BORUL REGELN ict a a ch NaS eS AED PANE tar taal ee 241 ANHANG GC FAELSTUDIE 2 2 ea Ges 242 C 1 KUNDENANEORDERUNGEN tr A en a che en ee nn andl nesitiGwredes 242 KR DAN AEVSER ODE ben en ae a Arena ge Air PN eier 248 DE ICH ODE BI et ee ee aE e Ce 250 ABBIEBUNGSVERZEICHNIS aan elemente 253 TABELEENVERZEICHNIS 2 22 42 Rear 255 EITERATURVERZEICHNIS e 2er E E ESNEA PNN 257 VII 1 Einleitung und Motivation Die Problemstellung dieser Arbeit entstand vor dem Hintergrund neuer Anfor
15. fallen diese Punkte bei der weiteren Diskussion Ein weiteres Ergebnis das aus der Systementwicklung hervorgeht ist die Liste der Mappings Diese verknupfen die logische und technische Systemarchitektur und dokumentieren so einer seits Realisierungsentscheidungen fungieren aber andererseits auch als Navigationsstruktur fur die Verfolgbarkeit siehe Kapitel 1 1 In dieser Arbeit werden die in Tabelle 3 3 gezeigten Mapping Kategorien als f r die Softwareentwicklung relevant betrachtet Funktion Funktionen werden mit einem Mikroprozessor verkn pft Mikroprozessor F2Proz Semantik Zur Laufzeit f hrt dieser Mikroprozessor eine Soft ware aus die das Verhalten dieser Funktion implementiert Logischer Sensor Aktuator Logische Sensoren Aktuatoren werden mit ihren Hardware lt gt E E Komponente Pendants verkn pft Semantik Diese E E Komponente SA2Komp realisiert den logischen Sensor Aktuator Abstraktes Datenelement Ein abstraktes Datenelement wird mit einem Signal in einer Bus Botschaft verkn pft Semantik Dieses Bussignal ist an Bussignal bzw Botschaft der Realisierung der durch das abstrakte Datenelement DE2Sig definierten logischen Kommunikationsbeziehung beteiligt Tabelle 3 3 F r die Softwarteentwicklung relevante Mappings der Systementwicklung 3 1 2 b Prozessschritte und Artefakte der Softwareentwicklung Die Softwareentwicklung beginnt zu einem Zeitpunkt zu dem im Rahmen der Systement wicklung mit
16. get_ExceptionLog ChassisFault _GlobalExceptionHandler ChassisFaultHandler_Exception Handler_Exception 0 1 Handler rae severity String nm singGlobExHand ExceptionID Integer er u an get _GlobalException Einige Rollennamen sind aus Platzgr nden ausgeblendet 240 B 6 Hilfsregeln 1 Hilfsregel makeStandardSafety Rule makeStandardSafety loop gt Den Regelungsalgorithmus absichern Template SecondGuess loop fy Se Onige xe ControlAlgorithm AbstractAlgorithm MES ronan Was irengiop lt Concrete getNames Interface Name des redundanten Regelalgorithmus 1 AlgorithmInterface WreenieroloG Zeit berwachung unterst tzen Template Watchdog Watchdog Watchdog loop MonitoredChannel watchDog 2 Hilfsregel makeStates Rule makeStates context gt UserQuestion Ist die Klasse context zustandsbehaftet false state Template State context Context getNames Name der Zustands Klasse 1 State getNames Namen der konkreten Zust nde 1 ConcreteState getNames Namen der Zustandsoperationen 1 operation 241 Anhang C Fallstudie Die folgenden Inhalte zu der in Kapitel 2 vorgestellten Fallstudie Kombunstrument und Fahrfunktionen System KFS entstanden im Rahmen der studentischen Arbeiten siehe Kapitel 6 2 Das Designmodell wurde unter Verwendung von POTAD
17. ical _ lt lt electrical gt gt lt lt ECUs gt MMI_Kfz Management RAM size ROM size lt lt Processor gt gt ARMProcessor R ckstellknopf lt lt Memory gt gt 128KMemory lt lt electrical gt gt lt lt Memory gt gt 512KFLASH lt lt electrical gt gt Z ndschloss oO lt lt CAN gt gt MainChannel 9 lt lt electrical gt gt lt lt ECU gt gt Antriebstrang und Fahrwerk RAM size ROM size Raddrehzahlsensor lt lt Processor gt gt V850Processor lt lt Memory gt gt 512KFLASH lt lt Memory gt gt 128KMemory lt lt electrical gt gt Motordrehzahlsensor gt lt lt electrical gt gt gt lt lt electrical gt gt Drosselklappe Abbildung 3 6 Ausschnitt einer m glichen Hardware Architecture f r das KFS 35 3 Stand der Technik E E Konzepttool Im Umfeld der DaimlerChrysler AG und des Forschungszentrums Informatik FZI in Karlsruhe entstand das E E Konzept Too Belschner et al 05 das mittlerweile unter dem Namen PREEvision von der Firma Aguintos kommerziell vertrieben wird Aquintos Dabei handelt es sich um ein modellbasiertes Werkzeug f r Entwurf Dokumentation und Bewertung von E E Architekturen Einsatzschwerpunkte sind die fr hen Entwicklungsphasen insb die sogenannte Konzeptphase in der der E E Architekt das Gesamtfahrzeug betrachtet und die grund legenden Architektur Entscheidungen zu f llen hat Abbildung 3 7 zeigt die
18. 2 246 Das Betatigen des Ruckstellknopfes uber einen Zeitraum von 3 Sekunden bewirkt ein Ruck setzen auf Werkseinstellungen Alle Einstellungen Verbrauch Durchschnittsgeschwindigkeit Tageskilometer Schalt programm werden auf 0 bzw auf Standardwerte gesetzt 10 Schaltprogramm ausw hlen Es kann ein Programm C bzw S ber den R ckstellknopf gew hlt werden dass die 1 Schaltvorgange beim Automatikgetriebe optimiert und au erdem das Anfahr bzw Brems verhalten ver ndert 2 Schaltprogramme Comfort f r sanfteres Anfahren Fahrstabilit tsverbesserung und fr hes Hoch schalten Sport f r alle normalen Fahrsituationen 247 C 2 Analysemodell 248 bind LocalFaultHandler LocalS CF ault Handler GlobalF aultHandler Global PowertrainF aultHandler LocalFault Handler_FaultThrowingEntity Speed N Controller LocalFaultHandler_error Code SpeedContr_errorCode Global bind FaultHandler_errorCode Global_ error UserInterface HMI_Driver_ Car Indicator RPM_Error_LED MF Display Control Accelerator Brake Control CruiseControlLever Menu Controls ResetButton Control_ value accel_ value brake_value buttonNumber_value leverPosition_ value resetButton_value Indicator_ value MFDisplay_value RPM_LED_ value bind Director HMI_Driver_Car ClosedLoop Controller S peedController Feedback Sensor RPMSensor Actuator Engine Controlle
19. Das bei Douglass 99 beschriebene Muster SecondGuess beschreibt wie kritische Berechnungen auf Softwareebene abgesichert werden k nnen Die Klasse Context hat zwei Assoziationen zu der Klasse AbstractAlgorithn die die Signatur f r einen Algorithmus vorgibt algorithmInterface Die erbende Klasse ConcreteAlgorithm enth lt entsprechend eine implementierende Operation Ein Objekt vom Typ Context verf gt somit ber zwei Objekte die die Operation bereitstellen und f hrt die Berechnung mit beiden aus blicherweise verf gt das erste Objekt ber einen genauen und laufzeitintensiven Algorithmus und das zweite ber einen weniger laufzeitintensiven Algorithmus dessen Ergebnis auch ungenauer sein kann Das Ergeb nis der ersten Implementierung wird mit dem Ergebnis der zweiten Implementierung verifiziert in dem gepr ft wird ob ein signifikanter Unterschied besteht Die Struktur des Musters hat hnlichkeit mit der Struktur des Musters Strategy 14 Singleton 14 1 Zweck Sicherstellen dass es von einer Klasse nur eine Instanz gibt und diese global zur Verf gung stellen 14 2 Struktur Singleton Class _ Client 1 Class l gt Singl C ingleton Pr an dient Singleton _ lt Singleton gt _ uniquelnstance lt Singleton gt 0 of C 0 i JEE TNE ze e Oet getUniquelnstance lt Singleton gt lt Singleton gt 221 14 3 Erlauterung Dur
20. GlobalExceptionHandler get Exceptionlog ThrottleMalfunctionDetector_ _GlobalExceptionHa ade 0 1 ExceptionHandler 7 get_GlobalExceptionHandler B 5 Fault Handler 1 Transformationsregel Rule FaultHandler Template FaultHandler fh gt Fehler auf der Ebene einer Objektkollaboration erkennen und behandeln Template ExceptionMonitor getNames Namen der Klassen die einen Fehler erzeugt 1 Client ExceptionSafeClass ExceptionSafeClass fh LocalFaultHandler ExceptionHandler ExceptionHandler fh LocalFaultHandler Exception Exception fh LocalFaultHandler ExceptionMonitor exMon Sicherstellen dass es nur Instanz von GlobalExceptionMonitor gibt Template Singleton GlobalExceptionHandler Singleton exMon ExceptionMonitortexMon ExceptionHandler Client singGlobExHand Sicherstellen dass es nur eine Instanz von ExceptionLog gibt Template Singleton ExceptionLog Singleton 239 GlobalkxceptionHandler texMon ExceptionMonitor Client singExLog 2 Beispiel 2 1 Analysemodell bind Bind GlobalFaultHandler CentralFault Management GlobalFault LocalFaultHandler ela Indication GlobaleF aultld nitiateLocal obalr aula CorrectiveAction ChangeState GlobalFaultindication Signal 2 To LocalFaultHandler ChassisF ault Initi
21. InstrumentCluster_ Model 1 _InstrumentCluster_ Model setData getData _InstrumentCluster_Model attach 1 detach _InstrumentCluster_Model _InstrumentCluster_Modef WheelRPMSensor CruiseController AbstractView a a a B _DataHolder viewDecorator modelRe display N U a DataHolder A A N N NumberDecorator ViewDecorator CurrentRPM DesiredRPM lt lt addedBehaviour display display CurrentSpeed 2 3 Designmodell 2 DE Optimierungskriterium Wiederverwendung Reuse Werden die Input Output Daten des User Interfaces ber einen Nein Datenbus zur Verf gung gestellt DE2Sig Sollen die angezeigten Werte durch einen Dekorierer aufbereitet werden Ist die Klasse InstrumentCluster_Controller zustandsbehaftet Ja Name der Zustands Klasse CarState 236 Namen der konkreten Zustande Namen der Zustandsoperationen EngineRunning EngineOff Observer Lever manipulate display Lever 1 1 _Lever Observer update Speedindicator manipulate display Speedindicator _InstrumentCluster Model 1 Speedindicator 1 _InstrumentCluster_ Controller yao Sr mvc Be _InstrumentCluster_Model InstrumentCluste
22. Nano 0 T D Nano gt L Nano 8 2 lt 2 amp 5 O 2 2 O Nano amp D an am c 38 D L c 2 Q D Nano S D GY U 5 U 2 gt O P Nano Or Nano Nano 10 60 Minuten n 4 6 Wochen Abbildung 3 18 Entwicklungszyklen nach ROPES Variante Sem Spira Douglass 04 In der Phase Requirements Analysis Anforderungsanalyse werden alle Anforderungen des Systems erfasst auf Basis derer im folgenden System Engineering Systementwicklung eine Systemarchitektur festgelegt wird Auf der Grundlage dieser Informationen wird die Entwicklung einzelner Hardwarekomponenten begonnen An dieser Stelle geht der Prozess in eine Phase ber bei der verschiedene Disziplinen parallel den bereits oben erw hnten Mikrozyklus nach dem Spiralmodell durchlaufen Abbildung 3 19 zeigt den Mikrozyklus aus Sicht der Softwareentwicklung Er unterteilt sich in f nf prim re Mikrophasen die wiederum in Subphasen aufgeteilt werden e Party Projektplanung und assessment sowie Prozessoptimierung e Analyse Identifikation der wesentlichen Eigenschaften die der Prototyp unabh ngig von jeder Realisierung erf llen muss 51 3 Stand der Technik e Design Identifikation einer spezifischen optimalen Losung die konsistent mit dem Ana lysemodel ist e Translation Erzeugung lauffahiger Einzelkomponenten des Prototyps die durch Unit Tests abgesichert sind
23. Template benutzt Unter dem Begriff Pattern bzw Muster wird in dieser Arbeit ein Problem L sungspaar entsprechend der eingangs zu diesem Kapitel gemachten Definitionen verstanden wobei die L sung als abstrakte Idee beschrieben wird Die hier betrachteten Templates werden als eine M glichkeit betrachtet eine konkrete L sung eines Musters in formalisierter Weise zu beschreiben F r Templates gibt es ber die Muster hinaus noch weitere Einsatz gebiete die Schlussfolgerung dass jedes Template eine L sung eines Musters beschreibt ist daher nicht zulassig 97 3 Stand der Technik 3 2 4 2 Beobachtungen zum Zusammenhang von Analyse und Designmustern Bei der Anwendung von Analyse und Designmustern im Rahmen der Fallstudie wurden hin sichtlich der in der Problemstellung formulierten Frage nach der Systematisierbarkeit des Zu sammenhangs zwischen System und Softwaremodellen einige Beobachtungen gemacht In einem ersten Schritt wurde f r verschiedene Instanzen eines Analysemusters untersucht wie dieses auf der Designebene realisiert werden kann Dabei konnte festgestellt werden dass f r unterschiedliche Instanzen eines Analysemusters dieselbe Designmusterkonstellation auf der Designebene vorkommen kann Beispiele Diese Beobachtung ist anhand von Abbildung 3 45 und Abbildung 3 46 verdeutlicht Abbildung 3 45 zeigt im oberen Bereich eine Instanz des Analysemusters ClosedLoopControl siehe Anhang A
24. bernommen Die hier ebenfalls zu sehende Abh ngigkeit gestrichelter Pfeil zeigt ein Beispiel f r die integrierte Scriptsprache Mit der Anweisung lt ControlOutputValue gt wird der Name des Elements als String zur ckgegeben das dem Parameter ControlOutputValue zu gewiesen wurde 89 3 Stand der Technik F Assets ClosedloopContral ClosedloopController Ww Referencevaluesource ContralQutoutyalueDrain it ChasedLoopController FeedbackvaluesSource i ClosedLoopController gt ClosedLoopContral ReferenceValue ReferenceValue ClosedlLoopController z default value ClosedLoopController ClosedLoopController J ControlGukputyalue s gt signals Feedback aluet 7 signals Referencevaluet a periodic CloseLoopController_contro a send Control ukputyalue 3 Feedbackvalue Feedback alue ControlOutputValue _ontrol ukpubvalue Referenceyaluesource ReferenceValuesource Control utputyalueDrain Control utputyalueDrain Feedbackvaluesource Bal ClosedLoopControl ClassCollaboration Bal ClosedLoopControl_ InforrmationFlow l Abbildung 3 38 Musterdefinition im Modellbaum Teil der Musterdefinition sind im Beispiel zwei Diagramme zu dem Muster entsprechend der Vereinbarung aus Kapitel 3 2 1 c Abbildung 3 39 zeigt das Diagramm ClosedLoopControL_InformationFlow welches das Muster in der nformation Flow Darstellung zeigt ReferenceValue Signal Cl
25. inputRep RepositorytinputRep Repository Sensor Icl FeedbackValueSourcetcl ReferenceValueSource cl ControlOutputValueDrain C Actuator get cl FeedbackValue get cl ReferenceValue Sensor_getMethod set cl Control Output Value Actuator_getMethod PEOD Bis auf den Parameter Sensor erfolgt die Parameterbelegung nach dem bereits bekannten Muster Die Belegung bei Sensor ist abh ngig vom Optimierungskriterium Reuse Wenn Reuse wahr ist werden die beiden Sensorwerte ber das zuvor angelegte Repository mit Namen inputRep bezogen Durch die Zuweisung agiert die Klasse InputRepository des Templates Repository im Kontext von ControlLoop in der Rolle von Sensor Dies ist ein Beispiel wie Muster miteinander verwoben werden Wenn Reuse nicht wahr ist werden zwei Klassen angelegt deren Namen sich wieder aus der Instanz von ClosedLoopControl ableiten Dieser Pfad der Regel wird weiter unten besprochen 176 Beispiel Die Struktur des Musters ControlLoop Context Class ControlLoop Class s 1 Sensor 1 Class a 1 Actuator 1 Class s 1 Sensor_getMethod 1 Operation a 1 Actuator_setMethod 1 Operation Be nr ControlLoop gt pes Sensor Context _ lt Actuator gt Actuator 2 0 lt Sensor gt Eger Actuator _setMethod Sensor_getMethod periodic call step l _ lt ControlLoop gt Con
26. A theory of fault tolerance Proceedings of the International Conference on Distributed Computing Systems ICDCS 1998 S 436 443 ATESST ATESST ATESST Projektwebseite URL http www atesst org AUTOSAR AUTOSAR AUTomotive Open System ARchitecture URL http www autosar org Balzert 99 Balzert Heide Lehrbuch der Objektmodellierung Spektrum Akademischer Verlag 1999 Beck et al 87 Beck Kent Cunningham Ward Using Pattern Languages for Object Oriented Programs Proceedings of OOPSLA 87 1987 Belschner et al 05 Belschner Ralf Bortolazzi J rgen Frees Jascha Hettich Gerhard Mro ko Markus Gesamtheitlicher Entwicklungsansatz f r Entwurf Dokumentation und Bewertung von E E Architekturen Ausgabe 11 2005 Automotive Electronics 2005 S 18 23 Bertram et al 01 Bertram Torsten Opgen Rhein Peter Modellbildung und Simulation mechatronischer Systeme Virtueller Fahrversuch als Schl sseltechnologie der Zukunft ATZ MTZ Automotive Electronics Ausgabe Ausgabe September 2001 2001 S 20 26 Boehm 83 Boehm B Seven Basic Principles of Software Engineering Journal of Systems and Software 1983 S 3 24 Born et al 05 Born Marc Holz Eckhardt Kath Olaf Softwareentwicklung mit UML 2 Addison Wesley Munchen 2005 BOSCH 03 BOSCH Avraftfahrtechnisches Taschenbuch Ausgabe 25 Auflage Vieweg 2003 Braun et al 02 Braun P Marschall F 7ransforming Object Oriented Models with BO
27. Application Scenarios Use Cases Test Vectors Tesina Ben Design Defects Design Patterns Translation Defects Design Object Model Application Components Translation 3rd Party Legacy Code Components Real Time Framework Abbildung 3 20 Phasen und Artefakte des Gesamtprozesses Douglass 99 3 2 2 b Architekturmodell Im Kontext von Architekturen wird bei ROPES von einer Logical und einer Physical Architecture gesprochen Die Logical Architecture beschreibt wie Elemente die zur Ent wicklungszeit existieren z B Klassen oder einfache Datentypen in Modellen organisiert werden Einfluss auf diese Struktur kann z B die Zusammensetzung der Entwicklungs organisation haben Die Physical Architecture beschreibt dagegen die Struktur der Elemente die zur Laufzeit existieren z B Subsysteme Tasks und Objekte Mit einer ogischen Sicht wird bei ROPES also nicht eine realisierungsabh ngige funktionale Beschreibung des Systems verbunden so wie es bei dem Kernprozess der Systementwicklung der Fall ist siehe Kapitel 3 1 Als zentrales Strukturierungsmittel f r die logische Architektur wird das Konzept der Dom ne empfohlen Unter einer Dom ne wird ein abgrenzbarer Themenbereich verstanden der ber ein 53 3 Stand der Technik eigenes Fachvokabular verf gt Beispiele f r Dom nen sind Fahrregelung Benutzerschnittstelle oder Dat
28. CurrentRPM UiOutput UilnputValue Signal pe oe nen Value DesiredRPM User UiOutputValue Signal ane Interface InstrumentCluster Bere Userlnterface Instrument luster dena nn ee ee Se 3 Cluster gt m UserlInterface er LeverMovement CurrentSpeed z baver olosa o eed A eaea u nied gt Speedindicator ee U gr ThrottleValue BUINIEROREENR gt CurrentRPM uec ee CurrentRPM bind Bind ClosedLoopController Cruise Controller FeedbackValue Current ReferenceValue Signal RPM ControlOutputValue Throttle ClosedLoopController Class Value ReferenceValue FeedbackValue Signal Source InstrumentCluster Control ControlOutputValue Signal OutputValueDrain Throttle Feedback ReferenceValueSource Class ValueSource Wheel ControlOutputValueDrain Class RPMSensor ReferenceValue Desired FeedbackValueSource Class a nm RPM En ClosedLoopControl_CruiseControl gt ee EEEE EE OEELA E EEEE EEEE EEE EE gt ClosedLoopControl N See ne ee 3 5 Quelle Verwandte Muster Das hier vorgestellte Muster geht zur ck auf das Analysemuster User nterface von Konrad et al 04a Neben der Pr zisierung bzgl Signale und Musterparameter ist das hier gezeigte Muster auch strukturell leicht erweitert So handelt es sich bei der Klasse UserInterface dezidiert um eine eigene Funktion die zwischen den Bedien und Anzeigeelementen und den Steuerungs und Regelungsfunktionen vermittelt Bei Konrad et al 04a gibt es eine dire
29. Das Paket Messung_Wetterstation vor der Template Instanziierung 85 Abbildung 3 36 Instanz des Templates messing eu 86 Abbildung 3 37 Instanz des Musters Messung mit mehreren Sensoren cuucnseesenesensennsennnneneeneennnnnn 87 Abbildung 3 38 Musterdefinition im Modellbaum 0000020sssesensnnsensnensennnnnnn nennen nennen 90 Abbildung 3 39 Darstellung des Musters im Diagramm ccccccccceccceeee cece eee een eeee een eeeeeeaeeseeeneeeenaeees 90 Abbildung 3 40 Erweiterte Einstellungen f r ein Muster im Pattern Explorer cen 91 Abbildung 3 41 Instanziierung eines Mustes arena ai en 92 Abbildung 3 42 Alternativen f r die Zuweisung der Musterparameter csssesssessesneseseeeeenenen 93 Abbildung 3 43 Das angewendete Muster in der Diagramm Darstellung eseeen 94 Abbildung 3 44 Ein Klassen Template in XDE links und in UML Notation rechts 97 Abbildung 3 45 Analysemuster ClosedLoopControl am Beispiel eines Tempomaten und einem auf Wartbarkeit und Wiederverwendbarkeit optimierten DeSIgN ccccccceceeece seca seen eee eeee eee eeaeeeeenaeees 99 Abbildung 3 46 Analysemuster ClosedLoopControl am Beispiel einer Klimaanlage und einem auf Wartbarkeit und Wiederverwendbarkeit optimierten DeSIgN cccccccecee eee eee seen eeseeeneeaeeaeeeneeaes 100 Abbildu
30. Die Methodik Pattern Oriented Transformations between Analysis and Designmodels POTAD baut auf den im letzten Kapitel vorgestellten Ansatzen auf erweitert und integriert sie zu einem neuen Ansatz f r Modelltransformationen Die bei Khriss et al 99a siehe Kapitel 3 3 4 d und Judson et al 03 siehe Kapitel 3 3 4 e zu findende Idee bei Modelltransformationen Designmuster als Konstruktionselement zu nutzen wird zusammen mit einem erweiterten Template Konzept der UML zu einem Ansatz kombiniert der dem Prinzip der imperativen Transformationssprachen folgt Im Gegensatz zu vielen untersuchten Transformationssprachen die im Matching Teil nach Mustern auf Metamodellebene Ebene M2 in Tabelle 3 4 suchen wird bei POTAD auf Modellebene Ebene M1 nach Template Bindungen eines bestimmten Templates gesucht Damit geh rt POTAD zu den Transformationsans tzen bei denen das Quellmodell Marks enth lt die im Rahmen einer Transformation ausgewertet werden um Templates zu instanziieren siehe Kapitel 3 3 1 b Der Kernteil besteht aus einer Sprache f r Transformationsregeln die den bergang von Ana lyse zu Designmodellen auf der Basis von Mustern systematisieren und automatisierbar machen Entwicklungsmethode ITS _ ale Kapitel 4 1 TTT tee eee nutzt I an _ Kapitel 4 4 Kapitel 4 3 Abbildung 4 1 Die POTAD Bausteine Die folgenden Kapitel beschreiben die einzelnen POTAD Bausteine wie
31. Dieses sieht f r alle Relations und Mappings jeweils eine race Klasse vor die f r jede Auswertung einer Regel instanziiert wird Bei Relations wird die Belegung der Patterns und bei Mappings die Belegung der Parameter festgehalten Die Instanzen der Trace Klassen k nnen mit Hilfe einer speziellen Modelltransformation erzeugt werden die bereits in der Einreichung angegeben ist Als Proof of Concepts wird in dieser Einreichung auf Implementierungen der einzelnen Mitglieder hingewiesen die unterschiedliche Merkmale des Ansatzes erfolgreich realisiert haben 3 3 3 b Compuware Sun EXMOF EXMOF Compuware et al 04a ist eine tiefgreifende Weiterentwicklung des von Compuware und Sun zuvor eingereichten XMOF Das Metamodell von EXMOF setzt sich auf oberster Ebene aus den Paketen EMOF abgleitet von MOF 2 0 und Expressions abgleitet von der OCL 2 0 zusammen Die Struktur einer Transformation umfasst Richtungen Directions und Klassendefinitionen C asses mit enthaltenen Eigenschaften Properties Eine Richtung steht als Variable f r ein oder mehrere Pakete aus einem Metamodell Klassen enthalten Mappings die Elemente aus den ber die Directions definierten Metamodellen verkn pfen Die Eigen schaften der Klassen k nnen optional mit einer Direction assoziiert werden und stehen dann f r Objekte die Quelle oder Ziel einer Transformation sind Ansonsten werden sie als Attribute des jeweiligen Mappings verwendet Die eigentliche Transformation w
32. Hahsler Michael Software Engineering with Analysis Patterns Technical Report 01 2001 nstitut fur Informationsverarbeitung und wirtschaft Wirschaftsuniversitat Wien 2001 URL http wwwai wu wien ac at hahsler research virlib_working2001 virlib Ghezzi et al 91 Ghezzi Carlo Jazayeri Mehdi Mandrioli Dino Fundamentals of software engineering Prentice Hall Englewood Cliffs NJ 1991 S xv 573 p Gomaa 01 Gomaa Hassan Designing concurrent distributed and real time applications with UML Addison Wesley Boston 2001 S XXIII 785 S 258 Guelfi et al 03a Guelfi N Perrouin G Sterges P Ries B Sendall S MEDAL 1 0 Reference University of Luxembourg Faculty of Science Technology and Communication 2003a URL http se2c uni lu tiki se2c bib_download php id 210 Guelfi et al 03b Guelfi N Ries B Sterges P MEDAL A CASE Tool Extension for Model Driven Software Engineering IEEE International Conference on Software Science Technology amp Engineering EEE Herzlia Israel 2003b URL http se2c uni lu tiki se2c bib_download php id 227 Hillside Group Hillside Group Patterns home page Webseite URL http hillside net patterns Homann 04 Homann Matthias OSEK Betriebssystem Standard f r Automotive und Embedded Systems mitp Verl Bonn 2004 S 464 S Hudson Hudson Scott CUP Parser Generator for Java URL http www cs princeton edu appel modern java CUP
33. Komponenten Subsystem Verteilungs strukturdiagramm diagramm diagramm diagramm Zusammensetzung und Schnittstellen gruppierung von Komponenten Zeigt Komponenten Zeigt architekto Zeigt Artefakte und und ihre Verbindun nische Zusammen ihre Verteilung auf gen untereinander h nge von Kompo Knoten und Kompo nenten nenten Verhaltens lt diagramm Aktivit tsdiagramm Zustandsdiagramm Protokollautomat Zusammensetzung Zeigt Komponenten Zeigt architekto und Schnittstellen und ihre Verbindung nische Zusammen gruppierung von Komponenten en untereinander h nge von Kompo nenten Interaktions lt diagramm Kommunikations si ie Interaktions Sequenzdiagramm i Zeitdiagramm i diagramm bersicht Zeigt zeitlich ge Zeigt topologisch Beschreibt zeitliche Kombination von ordnet den Nach geordnet den Nach Bedingungen im Sequenz und i ii richtenaustuasch richtenaustausch Kontext von Objekt Aktivit tsdiagramm zwischen Objekten zwischen Objekten zustanden Abbildung 3 10 Die UML Diagramme im berblick angepasst nach Oestereich 04 Obwohl die UML keine Methode beinhaltet die den Einsatz dieser Diagramme in einem einheit lichen Prozess beschreibt lassen sich den einzelnen Diagrammformen doch bestimmte Ent wicklungsaktivitaten zuordnen Abbildung 3 11 zeigt die Einordnung einiger Diagramme in die Entwicklungsaktivitaten Analyse Design und Implementierung sowie f r we
34. Stand der Technik einheitlichen P attform Model geschehen das eine Sammlung aller technischen Konzepte sowie Anforderungen an die Verbindung und Benutzung einzelner Teile einer Plattform enthalt Ein entscheidender Mehrwert von Modellen wird in der unter dem Begriff Plattformun abh ngigkeit Platform Independence beschriebenen M glichkeit gesehen ein System un abh ngig von der realisierenden Plattform zu beschreiben Die Perspektive einer solchen Abstraktion wird mit sog Viewpoints beschrieben In der MDA werden drei solche Viewpoints definiert e Ein EDV unabh ngiger Viewpoint computation independent viewpoint der sich auf die Umgebung und Anforderungen des Systems konzentriert e Ein plattformunabh ngiger Viewpoint platform independent viewpoint der die grobe Funktionalit t des Systems beschreibt ohne Besonderheiten einzelner Plattformen einzu beziehen e Ein plattformspezifischer Viewpoint platform specific viewpoint der schlie lich auch Details der Benutzung einer bestimmten Plattform miteinbezieht Die dazu korrespondierenden Modelle werden analog CIM Computation Independent Model PIM Platform Independent Model und PSM Platform Specific Model genannt 3 3 1 b Methodik und Modelltransformationen Neben der Beschreibung der Viewpoints und deren Modelle besch ftigt sich der MDA Ansatz ausf hrlicher damit die Beziehungen zwischen den Modellen CIM PIM und PSM zu formalisieren und deren Ent
35. System Engineering ist ein interdisziplinarer Ansatz f r die Analyse und den Entwurf des Systems als Ganzes Schauffele et al 03 Ziel ist unter anderem ein durchgangiger und strukturierter Entwicklungsprozess der alle beteiligten Disziplinen in einen einheitlichen Entwicklungsansatz integriert F r eine ausf hrlichere Definition sei auf INCOSE verwiesen F r die Entwicklung von elektronischen Systemen in Kraftfahrzeugen m ssen nach dem Kern prozess Fachgebiete wie z B Regelungstechnik Hardwareentwicklung und Netzwerktechnik integriert werden Die Softwareentwicklung repr sentiert somit nur eine von vielen Fach disziplinen innerhalb der Systementwicklung Die Prozessschritte und Artefakte eines solchen Kernprozesses sind in Abbildung 3 3 gezeigt Es handelt sich bei diesem Beispiel um eine Pr zisierung des V Modells IABG 97 f r die Automobilindustrie die bei Schauffele et al 03 beschrieben ist Analyse der Akzeptanztest Benutzeranforderungen Spezifikation der Logische Systemarchitektur Systemtest logischen Systemarchitektur fl f R J LRSM LL er bankta Kalibrierung logischen Systemarchitektur Integrationstest des Technische Systemarchitektur Spezifikation der Technischen Systems Systemarchitektur LSSI SSCL Integration der System SG3 9 entwicklung Steuerger t Softwarekomponenten Software Analyse der Software Entwicklung Software Anforderungen Integrationstest der Software Spezifikation der 7 Sof
36. Wird am Ende dieses Schrittes der Beitrag angenommen erfolgen im zweiten Schritt die Diskussion und die Einarbeitung weitere Verbesserungsvorschlage auf der Konferenz Mit der Veroffentlichung in den PLoP Proceedings endet die Phase e Reuse Wiederverwendung In der dritten Phase ist das Muster in den PLoP Proceedings veroffentlicht Bei der Recherche nach Losungen fur ihr Problem stoBen Entwickler auf das Muster und wenden es an Ergeben sich bei der Verwendung in threm Projekt Ver besserungsvorschlage werden diese idealerweise an den Autor zuruckgemeldet 3 2 4 a Historie und Musterarten Der Musteransatz innerhalb des Software Engineering wurde durch Arbeiten des Architekten Christopher Alexander aus den 1970er Jahren inspiriert Alexander 77 Er versuchte mit seinen Ansatzen Architekturen von Bauwerken in elementare Bestandteile und ihre Beziehungen aufzulosen und das Ergebnis zu katalogisieren Der durch Alexander gepragte Musterbegriff wurde 1987 von Kent Beck und Ward Cunningham Beck et al 87 aufgegriffen um Muster fur die Erstellung von graphischen Benutzungsschnittstellen in Smalltalk zu beschreiben Mit dem Buch Advanced C Programming Styles and Idioms ver ffentlichte James Coplien 1991 einen sehr muster hnlichen Ansatz f r die Entwicklung in C Coplien 91 Der Durchbruch f r Muster in der Softwareentwicklung gelang aber 1995 mit dem Buch Design Patterns Elements of Reusable Object Oriented Software von Erich Gamm
37. dass sie in ein elektronisches System mit Sensoren und Aktuatoren eingebettet sind in dem sie Steuerungs und Regelungsaufgaben wahrnehmen Einfluss auf das Design einer solchen Softwarefunktion hat neben der logischen Systemarchitektur die die funktionalen Steuerungs und Regelungsaufgaben definiert insbesondere auch die technische Systemarchitektur Sie beschreibt die relevanten Hardwarekomponenten mit denen eine Funktion realisiert wird und legt z B fest ob ein f r die Funktion relevanter Wert ber einen Bus empfangen werden muss oder lokal ber einen Sensor erfasst wird der direkt am Steuerger t der Funktion angeschlossen ist Dar ber hinaus k nnen in dieser Dom ne Anforderungen bzgl Zuverl ssigkeit Sicherheit Ressourcenverbrauch Wiederverwendung und Portabilitat sowie Variabilitat von besonderer Bedeutung sein Die Gewichtung dieser Anforderungen kann jedoch von Funktion zu Funktion bzw von Subsystem zu Subsystem variieren Mit dem in Kapitel 3 1 2 vorgestellten Kernprozess steht eine grobe Beschreibung von Prozess schritten und Artefakten der Systementwicklung zur Verf gung Es wurden Listen mit m g lichen Inhalten der logischen und technischen Systemarchitektur sowie der Mappings zu sammengestellt die im weiteren Verlauf der Diskussion als Referenz f r Artefakte dienen die von der Systementwicklung an die Softwareentwicklung bergeben werden siehe Tabelle 3 1 Tabelle 3 3 In Kapitel 3 1 3 wurden modellbasierte Ans
38. e Testing Absicherung dass die Einzelkomponenten zur Architektur passen ntegration Testing und dass der Prototyp sein Ziel erreicht Validation Testing z B die geforderte Performance Translation Testing Unit Integration ing Testin Testin alk ae aie 3 Validation Detailed Testing ___ Iterative Design ee oa Sa Prototypes Requirements Analysis Design Architectural a _ Design En N Eaa u System Engineering Object Analysis Analysis Abbildung 3 19 Mikrozyklus der Softwareentwicklung Douglass 04 Eine Mikrophase setzt sich aus Aktivit ten zusammen m ssen durch den Entwickler erledigt werden und erzeugt am Ende Artefakte Ergebnisse von Aktivit ten die Einfluss auf nach gelagerte Phasen haben Artefakte stellen weitgehend verschiedene UML Konstrukte dar wie beispielsweise Szenarien oder Use Cases Abbildung 3 20 zeigt die prim ren Mikrophasen Ellipsen und die ein und ausgehenden Artefakte durch horizontale Striche eingerahmt im berblick Die folgenden Unterkapitel erl utern detaillierter die Aktivit ten der einzelnen Phasen und den Inhalt der Artefakte Zun chst wird jedoch das in ROPES verwendete Architekturmodell vor gestellt da dessen Bestandteile im Rahmen der Prozessbeschreibung referenziert werden 52 Softwareentwicklung Application Requirements Analysis Hazard Analysis Analysis Defects Analysis Object Model Tested
39. ft Grundlage f r die Evaluierung war bei jeder Arbeit das in Kapitel 2 als Fallstudie vorgestellte Kombiinstrument und Fahrfunktionen System KFS 185 6 Validierung und Bewertung Im Rahmen der ersten Arbeit Kolodziejczyk 05 wurde das KFS auf Basis der im Rahmen von POTAD verwendeten ROPES Methode entwickelt ohne den in Kapitel 4 vorgestellten Modell transformationsmechanismus zu verwenden Hierbei wurden in der Design und auch der Ana lysephase intensiv Muster eingesetzt wobei letztere eine Erweiterung der Methode darstellen Ein Thema dieser Arbeit war es auch Designmuster in Hinblick auf die Erf llung unterschied licher nichtfunktionaler Anforderungen zu bewerten und auf dieser Basis die Variabilit t im Designmodell bei wechselnden Anforderungen zu diskutieren Das Ergebnis enth lt im Analyse modell 5 Muster und das letztendlich gew hlte Designmodell 12 Muster Dieses Designmodell diente f r die Verifikation des Modelltransformationsansatzes aus Kapitel 4 als Referenzmodell Hier sollte der Nachweis erbracht werden dass sich dieses manuell erstellte Referenzmodell zu gro en Teilen auch mit der prototypischen Implementierung aus Kapitel 5 erzeugen l sst Dieser Nachweis war neben der Unterst tzung bei der Konzeption der Transformationsregeln und der Implementierung des Transformators Thema der zweiten Arbeit Buchwald 05 Nach den intensiven Untersuchungen einzelner Analysemuster und der Aufstellung ent sprec
40. gbaren Modellelemente k nnen sowohl statische als auch dynamische Aspekte eines Systems be schreiben und wurden mit dem Ziel konzipiert unabh ngig von dem Fach und Realisierungs gebiet zu sein Die UML selbst ist keine Methode unterst tzt an vielen Stellen aber in besonderem Ma e eine objektorientierte Vorgehensweise wie z B die in Kapitel 3 2 2 zusammengefasste ROPES Methode Die bereitgestellten Modellelemente und Diagrammarten decken viele Phasen des Softwarelebenszyklus ab wie z B Anforderungserfassung Analyse Design und Dokumentation Entwickelt und spezifiziert wird die UML unter dem Dach der Object Management Group OMG einer Organisation in der namhafte Firmen aus dem Softwareumfeld vertreten sind Die UML Spezifikation der OMG hat somit den Charakter eines Industriestandards Aktuell ist die Version 2 0 kurz UML2 OMG 05c die ltere Version 1 4 ist ein ISO IEC Standard ISO IEC 05 Die UML Spezifikation setzt sich aus einem formalisierten Metamodell einer textuellen Be schreibung der Semantik f r jedes dort spezifizierte Modellelement und der Festlegung der graphischen Darstellung zusammen Diese Beschreibung der Semantik enth lt bei manchen Modellelementen sog Semantic Variation Points Dabei handelt es sich um Bereiche der Spezi fikation die bewusst nicht vollst ndig spezifiziert wurden um dom nenspezifischen Er weiterungen mehr Freiheiten zu lassen Die Semantik dieser Elemente muss also p
41. glichen Initialisierungstask ausgef hrt werden und wie das Ausf hrungsmodell in den einzelnen Betriebszustanden aussieht Hierbei kann unterschieden werden ob die Prozesse periodisch oder episodisch ausgef hrt werden Design und Implementierung der Softwarekomponenten In den bisherigen Prozessschritten wurde soweit wie m glich von der Implementierungsplattform abstrahiert Beim Design und der Implementierung m ssen diese Abstraktionen durch ent sprechende Designentscheidungen aufgel st werden Eine besondere Rolle spielen hier die ge forderten nichtfunktionalen Produkteigenschaften Aus Anforderungen nach Variabilit t leitet sich z B ein Design ab bei dem Programm und Datenstand deutlich getrennt werden Der Forderung nach m glichst minimalen Hardwareressourcen muss durch eine entsprechende Optimierung bei den Datenstrukturen und Algorithmen begegnet werden Entsprechend muss beim Design und der Implementierung des Datenmodells festgelegt werden ob die einzelnen Daten Variablen und unver nderliche Parameter sind Des Weiteren muss eine Abbildung der physikalischen Spezifikation auf einen Implementierungsdatentyp erfolgen Bei Kennlinien und Kennfeldern muss z B festgelegt werden welches tabellarisches Ablageschema und welche Interpolationsmethode verwendet wird Entsprechend dem zu erwartenden Zugriff 26 Systementwicklung muss entschieden werden in welchem Speichersegment die Daten abgelegt werden Beim Design und der
42. heteroRed Typische Sicherheitsmechanismen ber Hilfsregel einbringen OptimCriteria Safety makeStandardSafety Reactive reacloop AbstractControlLoop cloop ControlLoop Die Regel OpenLoop hat gro e hnlichkeiten mit der Regel ClosedLoop Die Unterschiede resultieren haupts chlich aus der Tatsache dass im Template des Analysemusters OpenLoopControl dem Parameter ControlInputValueSource beliebig viele tats chliche Parameter zugewiesen werden k nnen e Das Repository Muster wurde durch das Blackboard Muster ausgetauscht Es hat einen ahnlichen Zweck wie das Muster Repository generiert jedoch nicht f r jeden Sensorwert ein Methodenpaar getX setX Stattdessen wird der Zugriff auf die Sensorwerte ber die Methoden getData und setData generisch gel st e Da ControlInputValueSource beliebig viele tats chliche Parameter zugewiesen werden k nnen muss das Muster PubSubscriber auch entsprechend oft instanziiert werden Dies ge schieht durch das Anh ngen von elements bei der Parameterzuweisung von Publisher 232 2 Beispiel 2 1 Analysemodell bind Bind o 1 ControlOutputValueDrain Fuellnjection Ignition OpenLoopController Class System Throttle o 1 ControlOutputValue Fuellnjection o 1 ControlOutputValueDrain Class Value IgnitionValue ThrottleValue i 0 ControllnputValue o 1 ControlOutputValue Signal
43. kann jeweils f r Quelle und Ziel vorgegeben werden definiert werden Zudem k nnen bei der Definition von Patterns Bedingungen eingeflochten sowie freie Variablen ver wendet werden die bei einem Matching des Pattern mit passenden tats chlichen Elementen im Modell belegt werden Sowohl bei den Ae ations als auch bei Mappings kommt das Pattern Matching zur Anwendung Realt ons bestehen aus einer Definition der freien Variablen und Domains die wiederum jeweils ein Pattern und eine Bedingung beinhalten Auch f r die gesamte Ae ation kann eine globale Bedingung festgelegt werden Jede Domain steht f r ein Modell wobei eine Transformation beliebig viele Domains verwenden kann F r eine Transformation mit einem Quell und einem Zielmodell werden entsprechend zwei Domians verwendet In der mitgelieferten textuellen Syntax besitzen Relations folgende Struktur relation lt Name der Relation gt var lt freie Variablen gt domain lt Pattern_1 gt when lt Bedingung_1 gt domain lt Pattern_n gt when lt Bedingung_n gt when lt globale Bedingung gt Bei einem Mapping handelt es sich um eine Verfeinerung einer Ae ation Es umfasst eine Liste mit typisierten Parametern einen sog W chter guard der als Bedingung oder Matching 116 Modelltransformationen formuliert werden kann und einem Rumpf body Domains die sich in der Relation auf Quell modelle beziehen werden zu Input Parametern auf Zielmodelle bezogene D
44. obwohl sich bei einigen Designmustern von Douglass 02 die Frage stellt ob der Abstraktionsgrad des Musters nicht auch zur Analyse 150 Muster phase passt z B bei den Mustern MonitorActuator HomogeneousRedundancy und HeterogeneousRedundancy Eine Vertiefung dieser offenen Punkte bietet sich als eine mogliche zukunftige Arbeit an siehe Kapitel 7 1 4 2 3 a Muster fur die Analyse Die hier gesammelten Muster basieren auf dem in Kapitel 3 2 4 c beschriebenen Begriff fur Analysemuster Entsprechend der hier betrachteten Domane modelliert ein solches Muster einen wiederholt anzutreffenden Sachverhalt der bei der Entwicklung von Automotive Software in der Analysephase modelliert werden muss Es bildet komplexe Zusammenhange aus der Systement wicklung modellhaft nach und verwendet die Sprache des Systementwicklers Das UML Modell ist aus Sicht der Software rein konzeptuell und enthalt keine Designaspekte Aus Sicht der Systementwicklung handelt es sich um Muster fur die logische Systemarchitektur Aus dieser Perspektive kann nur eingeschr nkt von Analysemustern gesprochen werden weil auf dieser Ebene die modellierten Konzepte als Realisierungsentscheidung betrachtet werden k nnen Die inhaltliche Granularitat und die Beschreibungsform orientieren sich an den Mustern von Konrad et al 04b Die Klassenstruktur des Musters wird allerdings durch die Verwendung des in Kapitel 4 2 1 vorgestellten Template Konzepts formaler beschrie
45. pfungen zwischen den unterschiedlichen Modellen sind ein 29 3 Stand der Technik zentrales Element um die fur die Komplexitatsbeherrschung so wichtige Verfolgbarkeit herzu stellen In den folgenden Unterkapiteln werden Modellierungssprachen fur die Systement wicklung ausfuhrlicher vorgestellt EAST ADL Die FAST EEA Architecture Description Language EAST ADL L nn et al 04 ist eine Modellierungssprache fur die Beschreibung elektronischer Architekturen im Automobilbereich Sie wurde im Rahmen des von der Europ ischen Union gef rderten Forschungsprojekts EAST EEA von bedeutenden Automobilherstellern und Zulieferern entwickelt Die in diesem Projekt ebenfalls begonnen Uberlegungen zu einer offenen Standardarchitektur fiir Software in Kraft fahrzeugen m ndete in der Entwicklung des Industriestandards Autosar Das im Rahmen der Autosar Aktivitaten entwickelte Metamodell stellt f r manche Teile der hier vorgestellten EAST ADL eine Weiterentwicklung dar siehe nachstes Unterkapitel lasst dabei jedoch ins besondere die Teile aus die der logischen Systemarchitektur hinzugerechnet werden konnen Die EAST ADL betrachtet die Systemarchitektur mit Hilfe unterschiedlicher Artefakte die miteinander verlinkt sind Abbildung 3 4 zeigt diese Artefakte im berblick Defines features in Functional Analysis Architecture Refined in Tentatively allocated to Vehicle View
46. r z B Kommunikation Energiemanagement oder Diagnose Au erdem kann f r das Scheduling z B ein Echtzeitbetriebssystem zum Einsatz kommen Obwohl es mit OSEK OSEK VDX 05 Bem hungen f r eine entsprechende Standardisierung gibt finden sich in der Praxis immer noch viele herstellerspezifische Basiskomponenten Es ist angestrebt diesen Zustand mit der Initiative Autosar AUTOSAR zu beenden Trotz der j ngsten Standardisierungsbem hungen hat es die Softwareentwicklung in der Automobilindustrie immer noch mit einer vergleichsweise hohen Anzahl von Plattformen zu tun 3 1 1 e Weitere nichtfunktionale Anforderungen Nichtfunktionale Anforderungen sind in der Automobilindustrie von hoher Bedeutung Aus den oben genannten Merkmalen leiten sich bereits einige solcher Randbedingungen f r die Soft wareentwicklung ab z B Sicherheit und Zuverl ssigkeit Dar ber hinaus gibt es noch einige weitere nichtfunktionale Anforderungen die im Vergleich zu anderen Dom nen besonders hervorstechen und sich haupts chlich durch Kostenaspekte motivieren 19 3 Stand der Technik e Ressourcenverbrauch Aufgrund der hohen St ckzahlen dominieren in der Automobil industrie die proportionalen Herstellkosten den Stuckpreis Fur elektronische Komponenten bedeutet dies dass moglichst gunstige Hardware eingesetzt werden muss was mit ver gleichsweise geringen Hardwareressourcen Speicher Rechenleistung Kommunikationsmittel etc verbunden ist Dies ha
47. spezifikation handelt es sich um Textdokumente die detailliert die Anforderungen der zu geordneten Verantwortlichkeiten zu diesen Bereichen beschreiben Die Test Vecotrs Test 58 Softwareentwicklung vektoren umfassen im Rahmen des System Engineerings Sequenzdiagramme modellieren Szenarien mit denen das System getestet werden soll und einen Testplan der die Testaktivi taten fur das Gesamtsystem zeitlich und inhaltlich plant Es wird darauf hingewiesen dass die UML und objektorientierte Modellierung generell in der Phase System Engineering weniger akzeptiert ist als in anderen Phasen Daher sind auch Modelle die nicht UML konform sind ausdrucklich erlaubt Beispielhaft werden die Werkzeuge Statemate und Simulink The Mathworks 04 genannt Object Analysis In dieser Phase werden die zuvor gesammelten Use Cases die fur die Softwareentwicklung relevant sind in ein objektorientiertes Modell berf hrt Die wesentlichen Konzepte und Objekte die f r das korrekte Verhalten notwendig sind werden identifiziert und ihr essentielles Verhalten beschrieben Im Rahmen der Objekt Strukturanalyse engl object structural analysis werden diese Objekte zu Klassen abstrahiert und ihre m glichen Beziehungen modelliert In dem Domain Mode werden die Schl sselkonzepte und das Vokabular einer beteiligten Dom ne z B User Interface Hardwareanbindung in eine projektweit geltenden Klassen Vererbungshierarchie eingeordnet und verein
48. tze vorgestellt die diese Inhalte in formalisierten Modellen erfassen und abschlie end in Tabelle 3 7 in Bezug auf ihre Inhalte anhand der erw hnten Listen verglichen 41 3 Stand der Technik Ein zentrales Modell bzgl der funktionalen Anforderungen das von der System an die Soft wareentwicklung bergeben wird ist die logische Systemarchitektur in dieser Arbeit auch Funktionsnetzwerk genannt Sie beschreibt die hierarchische Struktur der Funktionen die vorhandenen logischen Sensoren und Aktuatoren und die Kommunikationsbeziehungen in Form von abstrakten Signalen Alle untersuchten Modellierungssprachen f r Systemarchitekturen aus Kapitel 3 1 3 enthalten ein solches Modell der logischen Systemarchitektur Die Br cke von der logischen zur technischen Systemarchitektur wird von den untersuchten Modellierungssprachen durch die sog Mappings geschlagen Diese verbinden z B die Funktionen mit den Steuerger ten auf denen sie implementiert sind oder die abstrakten Signale mit den konkreten Signalen eines realisierenden Kommunikationssystems Die ber diese Br cke verlinkten Modelle der technischen Systemarchitektur enthalten einige Informationen die f r die Softwareentwicklung ebenfalls relevant sind Schwerpunkte sind der Aufbau von Hardware komponenten sowie deren Vernetzung Die in Kapitel 3 1 3 untersuchten Modellierungssprachen behandeln diese Ebenen grenzen die einzelnen Modelle jedoch unterschiedlich voneinander ab Au
49. 22 ai 1 1 1 NOE EID scare ee sea d ai acetate Er NE 2 1 2 PROBEEMSTEELUNG uses een esse 6 1 3 ABGRENZUNG na na ee T 1 4 ORGANISATION DER ARBET een N 8 2 FALLBEISPIEL KOMBIINSTRUMENT UND FAHRFUNKTIONEN cccceeeeeeeeeees 11 2 1 UBER IC EE ee ee 11 2 2 DESIGN DER SOF TWAREFUNK TIONEN ae lores a r a a Er 14 3 STAND DER TECHNIK essen et 17 3 1 SYA EMENT WICK LUNG ae ee ee ee 17 3 1 1 Grundlegende Anforderungen der Dom ne u22242222220nnsnnnennnnnnnnnnnneneneneneen 18 3 12 Der Kernprozess der Systementwicklung 22 22242224222nnsnnenensnnnnnnnnnenennnenenenenenennnenn 21 313 Modellbasierte Entwicklung 22 50 2800 200er 27 3 1 4 ZWISCHENEr SEDNIS EE E T T E E TT R E 41 3 2 SOFTWAREENTWICKLUN G ae ee ee pas aene Ron aantin Sa mening east banatte 43 32 4 Die Unified Modeling Language u un 0 unnaRneane na 43 322 He ROES Method E eara een aan einen 50 323 Weitere UML basierte Methoden cc ccccccccccc sec ccc nec necceeneee nee neeeneeneeenesneseneenestnesnesenesnesens 66 3 2 4 WAIST OF sense erneuern 67 F220 ZWISCHEN EI CEDING Sansa 104 3 3 IVIODELETRANSFORMATIONEN esse 109 Fi Model Driven Architecture Engineering uumnnsssssssseeeeeeeeenennnennennnnnnn nn 109 II GEINOISBEN en E E EE T EE E S 113 BIT Ansatze aus dem Umfeld der OMG 22u022ssssnssennssnnsennnennneenennnenneenenennnenn 116 3 3 4 Ansatze aus dem akademischen Umfeld oo cccccccccccccc
50. 4 c Visual Model Transformation VMT Ein weiterer Ansatz f r die Transformation von UML Modellen dessen abstrakte Semantik auf Graphtransformationen beruht wird mit der deklarativen Transformationssprache VMT in Sendall et al 03b pr sentiert Hier setzt sich eine Transformation aus einer Menge von Transformationsregeln zusammen die sich wiederum in ein Matching Schema und ein Ergebnis Schema untergliedern Ein Matching Schema enth lt Ausf hrungsbedingungen und Input Argumente f r die Regel und wird als Graph repr sentiert in dem die Knoten als Platzhalter f r Elemente oder Mengen im Quellmodell dienen die vorhanden sein m ssen bzw nicht vor handen sein d rfen Das Ergebnis Schema definiert ein Zieldiagramm als Funktion der Elemente aus dem Matching Schema und wird ebenfalls als Graph repr sentiert In einem Regelanordnungs Schema kann durch Iteration oder bedingte Verzweigung der Kontrollfluss zwischen verschiedenen Transformationsregeln festgelegt werden In dem Beitrag werden alle VMT Konzepte auf Begriffe der Theorie zu Graphtransformationen zur ckgef hrt um den Ansatz formal zu fundieren Inspiriert wurde der Ansatz unter anderem durch das Werkzeug MEDAL Guelfi et al 03b Dieses Add in zu der UML Moddellierungsumgebung BM Rational XDE IBM b siehe Kapitel 3 2 4 f realisiert einen Modelltransformator der eine in einem eigenen UML Profil definierte Transformationssprache interpretieren kann Diese Transformationss
51. 4 g be schriebenen Idee der Verlinkung von Musterinstanzen siehe insb Abbildung 3 49 Ein ent sprechendes Metamodell ist in Abbildung 4 12 zu sehen Es zeigt den Inhalt des Pakets POTAD_Traceability das sich wie in Abbildung 4 5 gezeigt in die restliche Metamodelllandschaft integriert Kernel Relationship templateTrace Abbildung 4 12 Metamodell f r Verfolgbarkeitsinformationen Bei dem Element DesignTrace handelt es sich um eine gerichtete Beziehung zwischen einer Designmuster und einer Analysemusterinstanz In dem Attribut traceInfo sind Designent scheidungen in maschinenlesbarer Form dokumentiert Im Werkzeug wird diese Verlinkung der Musterinstanzen durch die Einf hrung einer Abh ngig keitsbeziehung mit dem Stereotyp lt lt Design For gt gt zwischen Design und Analysemuster Bindungen realisiert F r die Dokumentation von Designentscheidungen wurde ein XML Format definiert dass die Designentscheidungen f r eine Ausf hrung einer Transformationsregel protokolliert und dem zugrunde liegenden Analysemuster als tagged value des Stereotyps lt lt AnalysisCollaboration gt gt hinzugef gt wird Diese mit der brigen Begriffswelt von POTAD nicht ganz konsistente Bezeichnung hat implementierungstechnische Gr nde Abbildung 4 13 zeigt die Verfolgbarkeitselemente beispielhaft 164 Verfolgbarkeitsmechanismus lt trace gt lt designmodel id 2819C5E1 path C Design mdx gt l
52. Antriebstrang und Fahrwerk empfangen werden e Antriebstrang und Fahrwerk An diesem Steuerger t sind die f r die Fahrfunktion not wendigen Aktuatoren und Sensoren angeschlossen Zu den lokal ausgef hrten Software funktionen geh ren die Tempomat und SpeedtronicFunktion die Motorsteuerung und das Ansteuern der Bremsen Um diese Funktionen ausf hren zu k nnen ist das Steuerger t darauf angewiesen dass die Eingabewerte des Brems und Gaspedals das eingestellte Fahr programm und die Stellung des Z ndschl ssels durch das Steuerger t MMI und Kfz Management ber den Bus gesendet werden Es ist zu beachten dass diese Architektur nicht der in aktuellen Serienfahrzeugen entspricht So sind kritische Eingabelelemente wie z B das Brems oder Gaspedal in der Regel direkt an das verarbeitende Steuerger t angebunden und nicht wie hier ber einen Bus Au erdem verteilt sich die gezeigte Funktionalit t bei heutigen Fahrzeugen auf mehr als die hier gezeigten zwei Steuerger te So unterteilt sich beispielsweise die Funktionalit t des Steuerger ts Antriebstrang und Fahrwerk oft auf mindestens drei Steuerger te z B Bremsfunktionen Motorsteuerung und Geschwindigkeitsfunktionen oft kombiniert mit Getriebesteuerung Bremsfunktionen und Motorsteuerung sind in der hier gezeigten Architektur zudem stark vereinfacht und wurden nur mit aufgenommen um den Fahrfunktionen die ben tigten Schnittstellen zur Verf gung zu stellen Eine Motorst
53. Designmodell global in Richtung 1 Per formance 2 Ressourcenverbrauch 3 Sicherheit und Verf gbarkeit oder 4 Wartbarkeit Portabilitat Erweiterbarkeit und Wiederverwendung optimiert werden Mit diesen vier Kate gorien wurden nichtfunktionale Anforderungen zusammengefasst die haufig zusammen auf treten Die Benutzerr ckfragen erm glichen Variabilit t in Bezug sehr spezifischer Details der technischen Systemarchitektur oder lokaler Optimierungsfragen F r diese Variabilitaten sind die Anforderungen unter Punkt 2 erf llt Das in Kapitel 4 4 vorgestellt Verfolgbarkeitskonzept verlinkt die Analysemusterinstanzen mit den Designmusterinstanzen die durch eine Transformation aus dieser Analysemusterinstanz hervorgegangen sind Die gesetzten globalen Optimierungsaspekte und Antworten auf Benutzer r ckfragen werden dabei in einem maschinenlesbaren Format gespeichert Auf diese Weise wird der Zusammenhang zwischen Analyse und Designmodell systematisiert und Designent scheidungen sind auch im Nachhinein nachvollziehbar Damit sind die Anforderungen unter Punkt 3 erf llt Abschlie end zeigt Tabelle 6 1 durch welche konkreten POTAD Elemente die Anforderungen aus Kapitel 3 2 5 erf llt werden 184 Anforderung Kapitel 3 2 5 UML Klassenmodelle UML Template Definition und Bindung TEM Template Expansion EXP Template Instanz als Ausfuhrungskriterium einer Regel AKR Zusatzinformation ZI Bedingungen BED V
54. Deutsches Institut f r Normung e V DIN D N 19226 1 Leittechnik Regelungstechnik und Steuerungstechnik Allgemeine Grundbegrifte 1994 Douglass 99 Douglass Bruce Powel Doing Hard Time Developing Real Time Systems with UML Objects Frameworks and Patterns Addison Wesley Pub Co 1999 Douglass 02 Douglass Bruce Powel Real Time Design Patterns Robust Scalable Architecture for Real Time Systems Addison Wesley Professional 2002 Douglass 04 Douglass Bruce Powel Rea Time UML Advances in the UML for Real Time Systems 3rd Edition Addison Wesley Professional 2004 Fernandez et al 00 Fernandez E B Yuan X Semantic Analysis Patterns Proceeding of the 19th International Conference on Conceptual Modeling ER 2000 2000 S 183 195 Fischer 05 Fischer Florian Werkzeugunterstutzung f r musterbasierte Modelltransformationen Diplomarbeit Universitat Ulm 2005 flex flex flex The Fast Lexical Analyzer URL http flex sourceforge net Fowler 97 Fowler Martin Analysis patterns reusable object models Addison Wesley series in object oriented software engineering Addison Wesley Menlo Park Calif 1997 5 xxi 357 Gamma et al 95 Gamma Erich Helm Richard Johnson Ralph Vlissides John Design patterns elements of reusable object oriented software Addison Wesley professional computing series Addison Wesley Reading Mass 1995 S xv 395 Geyer Schulz et al 01 Geyer Schulz Andreas
55. Ebenen werden durch dasselbe Modell adressiert Da aber von zahlreichen Realisierungsaspekten abstrahiert werden kann lasst sich das Funktionsnetzwerk f r die Modellierung der logischen Systemarchitektur weitgehend nutzen Abdeckung durch Modellierungsansatz Inhalt nach Kernprozess siehe Tabelle 3 1 Tabelle 3 3 Konzept E E Tool 1 Funktionsnetzwerk 2 Abstrakte Datenelemente Eero OOO a mermer Stmergestenman Kommniaionnerindingen Bisonmuniation OO engeren OO onen OOO union amp Mirror 2 Loge Sese iato E EKomponene e 3 Abvaies Dtensement Bunga bw Sorc Wird im vollen Umfang unterst tzt Wird eingeschr nkt unterst tzt O Wird nicht unterst tzt m 3 dee 0 e SE un YV 1 2 E 2 3 E 5 G E i eb k Q gt o0 Technische System architektur EAST ADL Tabelle 3 7 Vergleich der unterschiedlichen Modellierungsans tze in Bezug auf die Inhalte des Kernprozesses Bei der technischen Systemarchitektur zeigt sich dass die Definition von E E Komponenten und die Beschreibung ihrer Kommunikationsverbindungen Busse konventionelle Verbindungen von allen Ans tzen unterst tzt werden Unterschiede gibt es bei der Beschreibung des internen Steuerger teaufbaus Die Themen Leistungsversorgung Leitungen und Fahrzeugtopologie werden nur vom E E Konzept Tool ausf hrlich adressiert Die Mappings lassen sich bei allen 40 Systementwicklung A
56. Eine Condition kann zwei weitere Bedingungen mit AND und OR logisch ver knupfen sowie eine andere Condition mit NOT negieren OptimCriteria Optimisation Criteria Stellt eine globale boolesche Variable fur eine nichtfunktionale Anforderung dar die die Trans formationsregel von auBen vorgegeben bekommt und wird uber den Namen angesprochen Query Abstraktion fur eine Abfrage Eine abgeleitete Abfrage liefert einen booleschen Wert zuruck der in der Variable BoolVariable gespeichert wird Fur den Fall dass die Abfrage nicht durchgefuhrt werden kann kann ein Standardwert vorgegeben werden MachineQuery Eine Abfrage die maschinell durchgefuhrt wird In dem Attribut queryExpression kann eine maschinenlesbare Abfrage gespeichert werden die den geforderten booleschen Wert zuruck liefert Mit dieser Abfrage werden insbesondere die Modelle der technischen Systemarchitektur abgefragt Die Syntax von queryExpression kann implementierungsspezifisch festgelegt werden Die Implementierung muss einen entsprechenden Interpreter zur Verfugung stellen UserQuestion Eine Benutzerabfrage die vom Benutzer wahrend der Transformation beantwortet wird Die in question gespeicherte Frage muss mit Ja oder Nein beantwortet werden BoolVariable Speichert die Antwort einer Query fur die restliche Dauer der Ausfuhrung der Regel zur spateren Wiederverwendung in einer Bedingung und wird uber den Namen angesprochen InstanceVariable Kennze
57. Einreichungen zu QVT hat ergeben dass auch der sich jetzt durchsetzende Ansatz nicht alle erarbeiteten Anforderungen erf llt Wie eine exemplarische Pr fung ergeben hat lasst sich eine POTAD Transformationsregel nur sehr umst ndlich und mit vielen Nach teilen in QVT nachbilden Sobald der Standard aber verabschiedet ist und entsprechende Werkzeuge verf gbar sind erscheint es trotzdem sinnvoll zu pr fen inwiefern POTAD in QVT integriert werden kann Vermutlich ist im Bereich der Behandlung von Mustern eine Erweiterung notwendig Der Vorteil einer Integration ware jedoch dass sich in einer Trans formationsregel neben POTAD Konzepten auch andere Transformationsans tze nutzen lie en Im Rahmen der POTAD Transformationsregeln wurden bisher nur Muster verwendet die ein Klassenmodell beschreiben In Konrad et al 04b umfasst ein Analysemuster aber auch Sequenz und Zustandsmodelle In dem Werkzeug Rational XDE lassen sich f r Muster ebenfalls Sequenz und Zustandsmodelle beschreiben die ebenso wie Klassenmodelle para metrisiert und instanziiert werden k nnen In Douglass 99 werden zudem zahlreiche Muster f r Zustandsmodelle beschrieben Hier ist zu pr fen ob auf Basis solcher Muster auch Verhaltensmodelle transformiert werden k nnen Die Designmuster im Beispielkatalog weisen inhaltliche berlappungen auf Hier ist zu pr fen inwiefern die Muster in atomare Muster zerlegt werden k nnen und ob dies Vor teile bei der
58. Formulierung der Transformationsregeln bringt 191 7 Zusammenfassung und Ausblick 192 Template Instanzen erhohen das Datenaufkommen eines Modells Es ist daher zu prufen inwiefern das Metamodell f r eine Template Bindung in Richtung Speicherverbrauch optimiert werden kann Die im Rahmen dieser Arbeit gezeigten Transformationsregeln erzeugen ein Design das sich auf Expertenwissen begr ndet Es gibt keinen formalen Nachweis dass das erzeugte Design mit den Eigenschaften des Analysemusters kompatibel ist Eine Pr fung ob und wie ein solcher Nachweis f r eine POTAD Transformationsregel erbracht werden kann steht noch aus Zun chst m ssten die einzuhaltenden Eigenschaften eines Analysemusters formal erfasst werden Ein Ansatzpunkt k nnten hier die bei Konrad et al 04b beschriebenen Constraints f r Analysemuster auf Basis temporaler Logik sein POTAD setzt UML basierte Modellierungswerkzeuge voraus Obwohl UML bereits in vielen Dom nen etabliert ist und es auch spezialisierte UML Werkzeuge und Methoden f r ein gebettete Systeme gibt werden im Automobilbereich oft noch propriet re Modellierungs sprachen verwendet Um POTAD auch in diesem Kontext zu verwenden ist eine An passung des Mustermetamodells an die Modellierungssprache notwendig Anhang A Muster A 1 Analysemuster 1 ClosedLoopControl 1 1 Zweck Einen geschlossenen Regelkreis engl feedback contro beschreiben 1 2 Motivation Viele F
59. Implementierung des Verhaltensmodells mussen u a Genauigkeitsfragen z B in Bezug auf Rundungsfehler geklart werden 3 1 3 Modellbasierte Entwicklung Eine eng verzahnte System und Softwareentwicklung in der z B verteilte Funktionen mit Sicherheits und Zuverl ssigkeitsanforderungen interdisziplin r realisiert werden muss mit einem hohen Ma an Komplexit t durch Abh ngigkeiten umgehen Die Informatik besch ftigt sich seit ihrer Entstehung mit der Fragestellung wie Komplexit t beherrschbar gemacht werden kann Bekannte Prinzipien sind z B Formalisierung engl rigor and formality Trennung unter schiedlicher Belange engl separation of concerns und Abstraktion engl abstraction Ghezzi et al 91 Ein Ansatz der diese Prinzipien adressiert und auch von neueren Systementwicklungsmethoden propagiert wird Schauffele et al 03 ist die Modellbildung Hierbei handelt es sich um einen Abstraktionsprozess mit dem man versucht die Komplexit t eines Systems auf ein bew ltig bares Ma zu reduzieren Grundlage ist eine Modellierungssprache die f r modellierungs relevante Begriffe feste Bezeichner definiert deren Semantik m glichst genau beschreibt und m gliche Beziehungen zwischen diesen Begriffen festlegt Ergebnis ist ein Mode des Systems in dem die entscheidenden Eigenschaften Funktionalit ten des Systems enthalten sind IESE b Dar ber hinaus enth lt eine Modellierungssprache oft eine graphische Notatio
60. Inhalte der Systementwicklung beschrieben werden stellt sich die Frage wie der von ROPES beschriebene Prozess zu dem automobilspezifischen Kernprozess der Systement wicklung aus Kapitel 3 1 2 passt Au erdem definiert ROPES Modelle die sich der logischen und technischen Systemarchitektur zuordnen lassen Damit wird die Frage aufgeworfen welche 63 3 Stand der Technik Uberschneidungen es zwischen den ROPES Modellen und den in Kapitel 3 1 3 b vorgestellten Architekturbeschreibungssprachen gibt Abbildung 3 26 zeigt auf der linken Seite die Prozesse und Artefakte aus dem Kernprozess auf der rechten Seite Phasen und resultierende Artefakte der ROPES Methode und in der Mitte die Artefakte der EAST ADL Dem Schwerpunkt der Arbeit entsprechend siehe Kapitel 1 3 beschrankt sich die Gegenuberstellung auf den linken Teil des V Modells Requirements Analysis Use Cases Analyse der Scenarios Vehicle View Benutzeranforderungen Requirements Systemarchitektur Hardware Architecture Architectural Model System Spezifikation der Technischen Systemarchitektur Specification Spezifikation der Logische logischen Systemarchitektur Systemarchitektur Functional Analysis Executable Architecture Specfication System Analyse der LEI LS a logischen Systemarchitektur 9 9 Technische Systementwicklung Software Entwicklung Analyse der Fun
61. Modellen oder in einem separaten Verfolgbarkeitsmodell realisiert werden Zugriff auf bereits erzeugte Elemente im Zielmodell ZBE Es kommt vor dass innerhalb einer Transformation auf bereits erzeugte Elemente im Zielmodell zugegriffen werden muss um diese z B f r eine Parameterbelegung bei einer weiteren Template Instanziierung zu verwenden verweben von Templates Dies impliziert die weitere An forderung dass die Reihenfolge der Template Instanziierung festgelegt werden kann Iterationsmechanismus f r Mengen von Modellelementen IT F r Mengen von Modellelementen mit bestimmter Charakterisierung z B mengenwertige Parameter von Template Instanzen ist die M glichkeit zur Durchf hrung einer bestimmten Aktion f r alle Elemente der Menge erforderlich z B die Instanziierung eines weiteren Templates f r jedes Element aus einer Menge Dies setzt einen impliziten oder expliziten Iterations mechanismus f r Mengen von Modellelementen voraus der folgenden Untersuchung von Ans tzen zu Modelltransformationen soll entsprechend der oben beschriebenen Systematik gepr ft werden ob sich Musterinstanziierungen als wesentliches Element der Modellkonstruktion nutzen lassen und die beschriebene Variabilit t im Design modell m glich ist Die oben gesammelten konkreten Anforderungen sollen im Rahmen der Bewertung Verwendung finden 108 Modelltransformationen 3 3 Modelltransformationen Nach dem in den vorherigen Kap
62. Nutzung des Plug ins separat installiert werden muss Schlie lich konnte das gesamte Projekt als Plug in in ein Java Archiv exportiert werden so dass es in alle XDE Installationen die das MDA Toolkit enthalten integrierbar ist 5 1 2 Scanner und Parser f r die Transformationsregeln Da f r die Formulierung der Transformationsregeln die erarbeitete textuelle Syntax aus Kapitel 4 3 3 verwendet werden sollte war nach einer M glichkeit gesucht solche Regeln einzulesen und auszuwerten Aufgrund der Charakteristik einer Programmiersprache wurde entschieden eine Kombination aus Scanner und Parsergenerator zu verwenden die bedingt durch die Integration in XDE jedoch auf der Basis von Java arbeiten musste Eine hierzu passende L sung bieten die freien Werkzeuge JFlex Klein und CUP Hudson JFlex ist ein Java basierter Scannergenerator der sich an dem verbreiteten C C Tool flex flex orientiert und CUP ist ein Generator f r LALR Parser der die meisten Funktionen des oft referenzierten YACC Corbett bietet CUP ist selbst in Java geschrieben und produziert Parser die ebenfalls in Java implementiert sind Er bietet eine Scannerschnittstelle die zu JFlex kompatibel ist und erlaubt die Integration von beliebigem Java Code in den semantischen Regeln Mit diesen beiden Werkzeugen ist es m glich einen Java basierten Parser f r einzelne Transformations 169 5 Prototypische Umsetzung regeln zu erzeugen und einen GroBteil d
63. OSEK OSEK VDX 05 oder in Zukunft Autosar AUTOSAR zur ck gegriffen werden Eine weitere Designentscheidung die unabhangig von den einzelnen Software funktionen in dieser Phase getroffen wird sind die moglichen Betriebszustande des Steuer gerats So werden z B fur die Parametrierung oder das Software Update besondere Betriebs zust nde ben tigt bei denen die Uberwachungsfunktionen abgeschaltet sind On und Off Board Schnittstellen konnen ebenfalls Gegenstand von Architekturentscheidungen sein Spezifikation der Softwarekomponenten Mit diesem Prozessschritt wechselt die Entwicklungsperspektive von der Architektur zu der Spezifikation der Interna einer einzelnen Komponente Hierbei lassen sich folgende Aktivitaten identifizieren e Spezifikation des Datenmodells Die zu verarbeitenden Daten werden abstrakt Skalar Vektor oder Matrix und unabh ngig von konkreten Implementierungstypen spezifiziert Beispielsweise werden die grundlegenden Datenstrukturen f r Kennlinien oder Kennfelder festgelegt e Spezifikation des Verhaltensmodells Der interne Daten und Kontrollfluss einer Komponente wird spezifiziert Auf diese Weise ergibt sich der Weg der Dateninformation zwischen einzelnen Anweisungen und Kontrollstrukturen f r die Ausf hrung dieser An weisungen e Spezifikation des Echtzeitmodells Die Anweisungen einer Softwarekomponente werden Prozessen bzw Tasks zugeordnet Hier wird entschieden welche Anweisungen in einer m
64. Scenarios Szenarien die in Form von Sequenz und Timing Diagrammen beschrieben werden Das Ergebnis der Hazard Analys s wird als Tabelle 5 3 Stand der Technik dargestellt in der die Gefahrdungen zeilenweise aufgelistet sind und in den Spalten Attribute wie z B Fehlertoleranzzeiten vermerkt sind Mit Test Vectors Testvektoren werden in ROPES Testbeschreibungen in Textform verstanden mit denen das zu entwickelnde System gegen die Anforderungen getestet werden kann Schlie lich sieht ROPES mit der Requirements Specification Anforderungsspezifikation die Erstellung eines klassischen Textdokuments vor das unter anderem den Inhalt des Systems die Schnittstellen die externen Akteure das von au en sichtbare Verhalten und zu erf llenden Randbedingungen beschreibt In der Semi SpiratVariante wird die Requirements Analysis nur einmal durchlaufen in der Standardvariante k nnen die Anforderungen mit jeder Iteration erweitert werden System Engineering Die Phase System Engineering in fr heren Publikationen auch als System Analysis bezeichnet Douglass 99 ist eine optionale Phase f r komplexere Projekte wie z B in der Luftfahrt oder Automobilindustrie Sie partitioniert das System in Subsysteme und identifiziert f r die be teiligten Disziplinen Software Elektronik Mechanik und Chemie die relevanten Anteile siehe Abbildung 3 21 Ein Hauptziel ist die Kl rung von Verantwortlichkeiten zwischen den be teilige
65. Sch uffele et al 03 nicht f r die logische Systemarchitektur erw hnt Andere Ans tze erachten die Spezifikation von Abtastraten aber bereits in dieser fr hen Phase als sinnvoll siehe Kapitel 3 1 3 b und 3 2 2 22 Systementwicklung Funktions Ein Netzwerk aus Funktionen insb Steuerungs und Regelungs netzwerk funktionen logischen Sensoren bzw Sollwertgeber und Aktuatoren Die FNetz Kanten zwischen diesen Elementen symbolisieren logische Kommunikationsbeziehungen Die Elemente des Netzwerks k nnen in einer Hierarchie organisiert sein Kompositionen und auf diese Weise das System in Subsysteme aufteilen Abstrakte Die ber Kommunikationsbeziehungen zwischen Elementen des Funktions Datenelemente netzwerks ausgetauschten Datenelemente werden implementierungs DElem unabh ngig beschrieben Schnittstellen Datenelemente die Funktionen logische Sensoren oder Aktuatoren Schnitts empfangen oder senden k nnen werden zu einer Schnittstelle zusammen gefasst Zeitangaben Elemente des Funktionsnetzwerks werden mit Zeitangaben versehen die ZAng f r die Realisierung als Ober oder Unterschranken zu verstehen sind Beispielsweise kann f r einen logischen Sensor eine Abtastrate spezifiziert werden Tabelle 3 1 M gliche Inhalte der logischen Systemarchitektur Analyse der logischen Systemarchitektur und Spezifikation der technischen Systemarchitektur In diesem Prozessschritt wird die logische Systema
66. Uber die gerichtete Assoziation wird entsprechend der UML Semantik modelliert dass Sensor zu ControlFunction zur Laufzeit eine Verbindung hat und somit zu jeder Zeit Nachrichten an ControlFunction senden kann FunctionalDevice AnalysisF unction Sensor gt ControlFunction periodic send_sensorValue Signal sensorValue Signal sensorValue sensorValue int Abbildung 3 14 Funktionsnetzwerk als Klassendiagramm Um die Lesbarkeit zu erhohen wird im Rahmen dieser Arbeit fur diese Modellierung eine alter native Darstellung vereinbart die in Abbildung 3 15 gezeigt ist Hierbei wird der Signalfluss mit Hilfe der in der UML2 neu eingef hrten nformation Flows siehe OMG 05c modelliert Information Flows werden durch Abh ngigkeitsbeziehungen mit dem Stereotyp lt lt flow gt gt modelliert periodic sensorValue Sensor Ra AE I TUN PRE REET gt ControlFunction period 10 gt Abbildung 3 15 Modellierung von Signalen mit Hilfe von nformation Flows Die Semantik dieser Abhangigkeitsbeziehung ist im UML Standard wie folgt definiert eine oder mehrere Informationseinheiten flie en von der Quelle zum Ziel Als Name des nformation Flows wird in dieser Arbeit der Name des entsprechenden Signals verwendet Da bei den hier modellierten Funktionsnetzen aber jede Abhangigkeitsbeziehung diese Sema
67. Wiederverwendung F r verschiedene Analysemuster wurde zu jeweils einem dieser Optimierungskriterien eine ent sprechende Designmusterkonstellation gesucht F r jede dieser Designmusterkonstellationen wurde dar ber hinaus gepr ft inwiefern sich unterschiedliche Plattformen variierend auf das Design auswirken k nnen Systematik Auf Basis dieser Grundlage konnte im Rahmen der Untersuchungen der Zusammenhang zwischen Analyse und Designmustern f r mehrere Beispiele systematisiert beschrieben werden Im Kern beruht diese Systematik darauf die Parameter eines Analysemusters auf Parameter eines Designmusters abzubilden Abbildung 3 48 zeigt die Grundidee anhand einer informellen und inhaltlich unvollst ndigen Illustration Eine Abbildung zwischen zwei Parametern wird durch einen Pfeil symbolisiert Hat ein Para meter mehr als einen eingehenden Pfeil so wird das dazugeh rige Muster auch entsprechend oft instanziiert Dabei gilt f r die brigen Parameter dass die eingehenden Pfeile bei jeder Instanz anliegen Das PublisherSubscriber Muster wird im Beispiel daher einmal mit ReferenceValueSorce und einmal mit FeedbackValueSource als Publisher angelegt wobei der Parameter ConcreteSubscriber jedes Mal mit dem Inhalt des Parameters Blackboard aus dem Blackboard Muster belegt wird An dieser Stelle der Abbildung wird deutlich dass die Design muster auch untereinander verwoben sind Eine solche Verwebung von zwei Designmuster instanzen liegt
68. Zu einem sp teren Zeitpunkt kann dieser Parameter an einen konkreten Typ gebunden werden Dies geschieht im Rahmen der Template Instanziierung bei der allen formalen Template Parametern tats chliche Template Parameter engl actual template parameter zugewiesen werden und die im Template definierte Struktur ins Modell bernommen wird Besondere Eigenschaften Die UML Templates unterst tzen ber die einfache Template Definition und Template Instanziierung hinaus einige weitere Merkmale So ist es m glich Einschr nkung bzgl der tats chlichen Parameter zu formulieren Beispiel Der tats chliche Parameter muss ein Subtyp von Typ X sein Um Namen f r Modellelemente automatisch aus anderen Modellteilen oder 81 3 Stand der Technik Parametern abzuleiten stehen String Ausdr cke zur Verf gung die einfache String Operationen wie z B Konkatenation unterst tzen Auch f r die systematische Verfeinerung von Templates bietet der UML Standard Ans tze So sind einerseits prinzipiell Vererbungen zwischen Templates m glich Andererseits gibt es auch grunds tzlich verschachtelte Templates Templates die andere Templates instanziieren Leider ist der UML Standard bei diesen letzten beiden Punkten in Bezug auf die genaue Semantik unprazise Das Template Metamodell im Detail Die relevanten Teile des Metamodells befinden sich im Paket Templates des UML Standards OMG 05c Abbildung 3 29 zeigt einige Paket Beziehungen die f
69. als Aufgabe an ein Modellierungswerkzeug formuliert 3 3 4 e Judson et al Kontrolliertes Refactoring von Modellen In Judson et al 03 wird ein auf perfektionierende Modellevolution abzielender Ansatz vor gelegt der hnlich wie bei dem zuvor betrachteten Ansatz von Khriss et al 99a durch den Einsatz von Designmustern eine schrittweise Verfeinerung eines Modells erreicht Eine solche Verfeinerung wird in einem Transformation Pattern beschrieben das aus drei Teilen besteht e Einem Source Pattern das die Menge von Elementen aus dem Quellmodell definiert auf die die Transformation angewendet wird Das Source Pattern wird als Metamodellfragment ausgedr ckt das aus Unterklassen der Klassen im UML Metamodell besteht e Einem Transformation Schema das die Struktur des Zielmodells beschreibt indem es die Klassen von Modellelementen zeigt die von den Transformationen erzeugt werden und die Klassen von Quellmodellelementen die entfernt werden Dies wird in einer speziellen Notation ebenfalls als Metamodellfragment ausgedr ckt e Einem Transformation Constraint welches als eine Art Nachbedingung die Beziehungen bestimmt die nach der Transformation zwischen Ziel und Quellelementen gelten Das in dem Beitrag verwendete Beispiel f r ein ransformation Pattern auf der Basis des Musters Abstract Factory von Gamma et al 95 ist in Abbildung 3 54 gezeigt 122 Modelltransformationen Characterization of UML models that con
70. als Template deklariert werden Die String Ausdr cke verwenden nicht die im UML Standard definierte Syntax sondern die von Rational XDE siehe Kapitel 3 2 4 f Abbildung 4 7 zeigt die Modifikation im Bereich der Template Bindung Hier sind als nderung die Einf hrung der Klassen TemplateParameterGroupSubstitution und TemplateInstance zu nennen Nachdem mit TemplateParameterGroup die M glichkeit geschaffen wurde Parameter bei der Template Definition zu gruppieren realisiert TemplateParameterGroupSubstitution diese Gruppenbildung entsprechend bei der Bindung Da es wie bereits erw hnt nur noch eine Template Art gibt wird TemplateableElement durch TemplateInstance ersetzt Neu hinzu gekommen ist au erdem eine Assoziation zwischen TemplateBinding und Package Das so assoziierte Package nimmt alle nicht parametrisierten Elemente auf und fungiert so als Root Context siehe Kapitel 3 2 4 f Abschlie end wurde die Kompositionsbeziehung zwischen TemplateParameterSubstitution und ParameterableElement entfernt 147 4 Eigener Losungsansatz POTAD formal 1 actual templateParameterS ubstitution parameterSubstitution eee ordered templateBinding jemplateParameterGroupSubstitution P Aus anderem Paket des E Beibehalten aus Template Paket des EI Im Rahmen von POTAD neu UML2 Metamodells UML2 Metamodells definiert Abbildung 4 7 Modifiziertes Metamodell
71. aus der logischen System architektur unter Ber cksichtigung der technischen Systemarchitektur und weiterer An forderungen ein Softwaredesignmodell erstellt werden Aktuelle modellbasierte Entwicklungs ans tze versprechen mit Hilfe des Konzepts der Modelltransformation den bergang zwischen Modellen unterschiedlicher Entwicklungsphasen automatisieren zu k nnen Dieses Konzept bietet sich dazu an aus einem Systemarchitekturmodell ein Grundger st eines Softwaredesign modells zu erzeugen und damit einen Teil der Softwareentwicklungsaktivitaten zu auto matisieren Die Analyse dieser Arbeit zeigt dass die erarbeiteten domanenspezifischen Anforderungen die fur solch ein Szenario an einen Modelltransformationsmechanismus gestellt werden mussen durch aktuelle Ansatze nicht vollstandig erfullt werden Der eigene Ansatz Pattern Oriented Transformations between Analysis and Designmodels POTAD verwendet die logische Systemarchitektur im Rahmen der Softwareentwicklung als Analysemodell und systematisiert dessen Zusammenhang mit dem Designmodell auf der Basis von Analyse und Designmustern Fur ein im Analysemodell gefundenes Analysemuster instanziiert eine POTAD Transformationsregel mit Hilfe dieser Systematik in Abh ngigkeit nichtfunktionaler An forderungen und der technischen Systemarchitektur unterschiedliche Designmuster im Design modell Gleichzeitig werden Verkn pfungen zwischen den Analyse und Designmustern angelegt die zur sp teren Ver
72. beschrieben werden handelt es sich berwiegend um PC oder Server Anwendungen Neben dieser unterschiedlichen Schwerpunktbildung bzgl der Dom ne sind aber auch in der Prozessgestaltung im Detail Unterschiede zu finden Eine weitere UML basierte Methode die speziell f r die Entwicklung verteilter Echtzeit anwendungen mit Nebenl ufigkeit optimiert wurde ist COMET Gomaa 01 Wie bei ROPES und RUP ist der Prozess iterativ und durch Use Cases getrieben die im Rahmen der An forderungsphase modelliert werden In der Analysephase werden statische und dynamische Modelle entwickelt Das statische Modell definiert strukturelle Beziehungen zwischen Klassen die mit Hilfe durch die Methode bereitgestellter Strukturierungskriterien gebildet werden Die Modellierung der Dynamik erfolgt mit Objektmodellen die zeigen wie Objekte an jedem Use Case partizipieren und wie sie dabei interagieren Zustandsbehaftete Objekte werden durch Zustandsdiagramme beschrieben In der Design Phase wird zunachst ein Architekturmodell erstellt Bei der Bildung von Subsystemen kommen wieder spezielle Strukturierungskriterien zum Einsatz Ein besonderes Gewicht der Methode liegt auf der Bildung von Komponenten bei verteilten Systemen Hierzu geh ren Regeln f r die Aufteilung von Verantwortlichkeiten zwischen Clients und Servern und die Frage ob Daten und Steuerungsaufgaben zentralisiert oder verteilt werden Ein weiteres ausf hrlich behandeltes Thema ist die Auslegung von
73. ckstellknopf auf der linken Seite des Cockpits lassen sich Einstellungen wieder zur cksetzen 1 R ckstellknopf 245 5 Tages und Kilometerzahler 1 2 Anzeige der gefahrenen Tageskilometer Rucksetzen mit Ruckstellknopf Anzeige der gesamt gefahrenen Kilometer 6 Digitaler Tachometer 1 Anzeige der aktuellen Geschwindigkeit 7 Wartungsanzeige 1 2 Der Service findet alle 25 000 km statt Informationen ber den n chsten Service Termin werden angezeigt In Kilometern Termin ist f llig Sobald der Service Termin berschritten wird werden die berzogenen Kilometer angezeigt und au erdem ert nt ein akustisches Signal Die Service Anzeige geht nach 30 Sekunden automatisch aus oder mit Hilfe des R ckstell knopfes Service Termine k nnen jederzeit abgerufen werden Die Wartungsanzeige kann nur durch einen Service Techniker zur ckgesetzt werden 8 Fehleranzeige 1 Sobald Storungen im Kfz auftreten werden diese von einem Kontrollmodul erfasst und konnen in Form von Textmeldungen oder Symbolen im Display angezeigt werden Das Fehleranzeigemen wird automatisch aufgerufen wenn ein Fehler w hrend der Fahrt auftaucht oder wenn das Fahrzeug gestartet wird und die St rung noch nicht beseitigt wor den ist Die Fehlermeldungen k nnen mit jeder beliebigen Taste 4 und 5 am Multifunktionlenkrad oder dem R ckstellknopf quittiert werden 9 Auf Werkseinstellungen zur cksetzen 1
74. der logischen und technischen Systemarchitektur bereits umfangreiche Informationen bzgl der Softwareanforderungen vorliegen Die Analyse der Softwareentwicklung ist entsprechend eng mit den Modellen und Methoden der Systementwicklung verzahnt Die genaue Auspr gung der Softwareentwicklung ist stark von der eingesetzten Entwicklungs methode abh ngig In Kapitel 3 2 2 wird die Methode ROPES besprochen die im Rahmen dieser Arbeit als Referenzmethode dient Im Folgenden werden bersichtsartig die groben Prozessschritte und Artefakte erlautert die f r die Softwareentwicklung im Kernprozess vor gesehen sind und von der eingesetzten Softwareentwicklungsmethode entsprechend unterst tzt werden mussen Analyse der Softwareanforderungen und Spezifikation der Softwarearchitektur Die Analyse der Softwareanforderungen sammelt prim r Festlegungen aus der technischen Systemarchitektur die Auswirkung auf das Design und die Implementierung der Software haben Dazu geh rt die Analyse des zugewiesenen Steuerger ts z B Prozessor Bus anschl sse die technische Vernetzung mit interagierenden Funktionen und Zeitanforderungen die sich aus Abtastraten ableiten Auf dieser Basis wird die Softwarearchitektur eines Steuer 25 3 Stand der Technik gerats spezifiziert Zu den Architekturentscheidungen gehoren die Wahl des Schichtenmodells die Festlegung von Komponenten und die Bereitstellung von Tasks Hier kann auf Standard architekturen wie z B
75. des Detailed Design noch offen l sst siehe Kapitel 6 2 In Kapitel 6 2 wird ebenfalls auf die M glichkeit hingewiesen den Trans formationsmechanismus f r Transformationen zwischen Designmustern und Detailed Design Mustern zu nutzen dieser Weg wird im Folgenden aber nicht naher beschrieben Bis auf die Nutzung der Verfolgbarkeitsinformationen wird der ROPES Prozess anschlie end ohne nderungen durchlaufen 144 Muster 4 2 Muster Im vorangegangenen Unterkapitel wurde bereits auf den breiten Einsatz von Analyse und Designmustern hingewiesen Fur beide Ebenen wird der Musterbegriff in den folgenden Unter kapiteln pr zisiert und ein Beispielkatalog vorgestellt Fur die POTAD Modelltransformation m ssen Mustertypen in einer besonders formalisierten Weise beschrieben und instanziiert werden Der hierbei verwendete Template Mechanismus den die Musterkataloge nutzen wird im folgenden Unterkapitel beschrieben 4 2 1 Template Metamodell POTAD verwendet eine modifizierte Variante der UML2 Templates Das entsprechende Paket Templates im UML2 Metamodell wird durch das Paket POTAD_Templates ersetzt Abbildung 4 5 zeigt das neue Paket und wichtige Nachbarpakete inklusive der Beziehungen Das Paket POTAD_Transformations enth lt das Metamodell der Transformationssprache und wird in Kapitel 4 3 n her erl utert Der Inhalt des Pakets POTAD Traceability definiert den Verfolgbarkeits mechanismus zwischen Template Instanzen und wird in
76. die Ratschlage zum methodischen Aufbau und die kritischen Fragen zur Eingrenzung des Themas Pers nlich und auch stellvertretend f r die DaimlerChrysler AG m chte ich Herrn Hohlfeld f r die Unterst tzung dieser Arbeit und meiner beruflichen Ent wicklung danken Die Finanzierung von Konferenzbesuchen und die Genehmigung von Diplomandenstellen im Umfeld dieser Arbeit haben zu dem Gelingen entscheidend beigetragen Ein Kompliment auch an die Diplomanden die sich mit viel Interesse in ein umfangreiches Gebiet eingearbeitet haben und sich mit Engagement an der Fallstudie und der Werkzeug implementierung beteiligten Ein pers nlicher Dank an diejenigen die mich trotz meiner wissen schaftlichen T tigkeiten nicht vergessen haben und nun insgesamt f nf Jahre Geduld und R cksicht aufgebracht haben Bei der wichtigsten Person in meinem Leben m chte ich mich daf r bedanken dass sie da ist und ihr Stella diese Arbeit widmen Kurzfassung Eine Antwort auf viele aktuelle Anforderungen im Elektrik Elektronik Bereich der Fahrzeugent wicklung ist ein durchgangig modellbasierter Entwicklungsprozess der Modelle der System und Softwareentwicklung integriert Ein Systemmodell beschreibt mit der logischen System architektur die Funktionen eines Fahrzeugs und mit der technischen Systemarchitektur die realisierende Elektrik Elektronik wie z B Steuerger te Sensoren Aktoren und Bussysteme Im Rahmen der Softwareentwicklung muss f r einzelne Funktionen
77. die Softwareentwicklung vorgesehen das inhaltlich starke berschneidungen mit der logischen Systemarchitektur hat Der Zusammenhang mit dem entsprechenden Modell in der Systementwicklung ist nicht systematisch beschrieben Hier herrscht ein gewisser Bruch in der Durchg ngigkeit der Modelle In Kapitel 3 2 2 8 wurde eine m gliche Modelllandschaft auf gezeigt in der die inhaltlichen L cken von ROPES bzgl formalisierter Modelle der Systement wicklung durch Modelle der EAST ADL geschlossen werden Die Erstellung des Analysis Object Models reduziert sich nach dieser Festlegung auf eine einfache Konvertierung aus dem Modell der Systementwicklung Ab der Designphase gibt es in dieser Modelllandschaft keinen Modell austausch mit der Systementwicklung mehr so dass ab hier die ROPES Methode in ihrer ur spr nglichen Form angewendet wird Da im Folgenden immer dieselbe Standardarchitektur angenommen wird beschrieben in Kapitel 4 1 2 bleibt die Phase Architectural Design in den weiteren Ausf hrungen unber cksichtigt Auch die Phase Detailed Design und alle nach gelagerten Phasen werden nicht vertieft Die Diskussion konzentriert sich somit auf die ber f hrung des von der Systementwicklung bernommenen Analysis Object Model in das Mechanistic Design Model Bei dem bergang von Analyse zu Designmodellen st tzt sich die ROPES Methode schwer punktm ig auf textuelle Regeln und Designmuster Wann welches Designmuster angewendet werden kann muss
78. direkt erf llt wird sondern vielmehr beurteilt in welchem Ma e die ge forderte Funktionalit t durch Mechanismen des jeweiligen Ansatzes realisiert werden kann Die ausf hrlicher untersuchten Ans tze werden zun chst anhand des Schemas von Czarnecki et al 03 siehe Kapitel 3 3 2 charakterisiert Um weiter betrachtet zu werden m ssen sie mit den Vorgaben aus Tabelle 3 11 bereinstimmen die sich aus den bisher gesammelten An forderungen ableiten 128 Modelltransformationen Ziel Automatisierung des Softwareentwicklungsprozesses Einsatzzweck Generizitat Stereotypisierte UML Klassendiagramme m ssen unterst tzt werden Beziehung Quelle und Ziel sind unterschiedliche Modelle Quelle Ziel Unidirektional Analyse zu Designmodell Verfolgbarkeit M glichst dediziertter Mechanismus Festhalten von Designent scheidungen Variabilitat Ja in Abh ngigkeit von nicht funktionalen Anforderungen und Plattform Tabelle 3 11 Vorgegebene Merkmale entsprechend des Schemas von Czarnecki et al 03 Fur das Merkmal Variabilit t reicht es aus wenn der Ansatz die M glichkeit bietet die Aus f hrung einer Regel an eine Bedingung zu kn pfen die ein Modell abfragt Auf diese Weise kann ein Transformationsparameter als zus tzliches Modellelement realisiert werden Das Merkmal Verfolgbarkeit ist zwar grunds tzlich erforderlich ein dezidierter Mechanismus wird aber in diesem ersten Vergleich nicht zwingend gefo
79. ein Entwickler nach der ROPES Methode auf der Grundlage der textuellen Beschreibung des Musters entscheiden F r die Nutzung im Kontext der angestrebten Modell transformation zeigt sich die Methode an dieser Stelle zu wenig formalisiert Die in ROPES verwendeten Muster liefern jedoch einen ersten Anhaltspunkt f r die systematische Erstellung von Modellen Kapitel 3 2 4 beschreibt zun chst einige Grundlagen 105 3 Stand der Technik und Kategorien von Mustern Analyse und Designmuster werden fur die Fragestellung dieser Arbeit als besonders relevant erachtet und die in diesen Bereichen publizierten Muster daher eingehender untersucht Im Bereich der weniger verbreiteten Analysemuster wurde eine Sammlung von Mustern gefunden deren Abstraktionsgrad zur logischen Systemarchitektur passt und die sich inhaltlich auf die Dom ne der eingebetteten Steuerungs und Regelungs systeme ausrichten Im Bereich der sehr umfangreich publizierten Designmuster wurde eine Auswahl von Mustern zusammengestellt die auf typische Designfragestellungen der hier be trachteten Dom ne abzielen Im Rahmen der Untersuchung der UML Templates siehe Kapitel 3 2 4 e in Hinblick auf formalisierte Beschreibungsm glichkeiten von Mustern wurden einige kleine M ngel identi fiziert Dazu geh ren die in der UML definierten Verschmelzungsregeln die bei der Instanziierung eines Templates zum Einsatz kommen Das Werkzeug Rational XDE das in Kapitel 3 2 4 f untersuch
80. einer Klasse belegt die den Namen der Klasse ClosedLoopController aus dem Analysemuster tragt durch Auslesen der Variable cl Mit dem _Operator wird der Postfix Master angeh ngt Dem Template Parameter Repository wird 175 5 Prototypische Umsetzung eine Klasse mit konstantem Namen InputRepository zugewiesen Der Template Parameter Data erhalt mit Hilfe des Operators zwei Klassen Diese haben die Namen der beiden Ein gangssignale aus dem ClosedLoopControl Muster FeedbackValue und ReferenceValue Der nach gestellte Bezeichner inputRep gibt der Instanz einen Namen und macht sie f r sp tere An weisungen in der Regel referenzierbar Im Beispiel wird die Struktur des Musters Repository Repository Client _ lt Repository gt BE re set lt Data gt get lt Data gt Client 1 Class Repository Class C _ Data 1 ae 0 1 _ lt Data gt Repository a a Data wie folgt in das Zielmodell eingebracht DesiredSpeed o _CurrentSpeed bind Bind Repository InputRepository Data DesiredSpeed Current Speed Client CruiseController_Master _InputRepository Im n chsten Schritt wird in jedem Fall das Template ControlLoop instanzilert Template ControlLoop cl ClosedLoopController Master Context cl ClosedLoopController _ControlLoop ControlLoop Reuse
81. f r Transformationen eignet deren Komplexit t mit der des Beispiels aus Kapitel 3 2 4 8 vergleichbar ist 3 3 5 Weitere Ans tze Bidirectional Object Oriented Transformation Language BOTL Die in Braun et al 03a vorgestellte graphische Transformationssprache BOTL ist vor allem durch die Integration von Werkzeugen motiviert die Objekte austauschen die nach unter schiedlichen Metamodellen strukturiert sind Der Einsatzzweck liegt daher schwerpunktm ig bei horizontalen Transformationen Der Beitrag enth lt einen Modellierungssprachen unabhangigen Formalismus sowie eine konkrete Abbildung desselbigen auf ein UML Profil Eine BOTL Spezifikation besteht aus einer Menge von Regeln die jeweils Fragmente aus einem Quellmodell in Zielmodellfragmente ber f hren und letztere mit dem bestehenden Zielmodell vereinigen Die Fragmente werden als sog Modellvar ablen dargestellt die UML Objektdiagrammen entsprechen in denen Attribute und Bezeichner mit Termen anstatt konkreter Werte belegt sind Wird eine Regel angewendet so wird im Quellmodell nach einem Auftreten des definierten Quellfragments gesucht Ist die Suche erfolgreich so werden die zugeh rigen Zielmodellfragmente erzeugt Mit Hilfe der Unter legung des Ansatzes durch einen mathematischen Formalismus der in Braun et al 02 be schrieben ist kann die Anwendbarkeit von Regeln oder die Konformit t des Ergebnisses zu einem Metamodell verifiziert werden das im Rahmen von BOTL
82. for faut thet was reported to loca faut handler 2 9 a reset of the device IntiateRecoveryActon RecoveryID InitiateRecovery Action dovinttiate corresponding recovery action Figure 7 5 UML state diagram for the Corrector in the Detector Corrector Pattern Participants e Watchdog Watchdog monitoring the device The Watchdog can be implemented in hardware to protect it from software faults e Device Device monitored by the Watchdog e FaultHandler Central fault handler of the system Collaborations e The Detector waits for a message from a Device or monitors conditions of a device such as the value of a sensor on a periodic basis If this message does not arrive on time or a con dition is violated then the watchdog performs recovery actions such as resetting a device or shutting the system down and reports the fault to the FaultHandler e The FaultHandler handles the fault message and may initiate additional actions 207 LocalFaultHandler GlobalF aultHandler l l l l l l en l l l Upare I I I I I I A l l l l l l I I I I Updater l l l l Device times out the l l detector reports te l l timeout to the local x I 1 1 fault handler which in Samen i i tum initiates comective RepotlocalFauli Device timed cut Scans Reset l nillateRecoveryAction 1 ReportGlobalFaull Device timeout I a Upda
83. geeignete Grundlage um den Zu sammenhang zwischen Analyse und Designmodellen unter Ber cksichtigung dieser Variabilit t zu systematisieren Eine im ersten Teil der Arbeit nur grob skizzierte Systematik basiert im Kern darauf f r eine Analysemusterinstanz in Abh ngigkeit von nichtfunktionalen An forderungen und der Zielplattform Designmuster zu instanziieren wobei die Parameter der Designmuster mit Inhalten des Analysemusters belegt werden Die sich daraus ergebenden Verkn pfungen zwischen Analyse und Designmusterinstanzen lassen sich auch f r Verfolgbar keitsfragen nutzen Aus dieser Systematik leiten sich weitere Anforderungen an den Modell transformationsmechanismus ab insbesondere in Bezug auf den Umgang mit Mustern und die Erzeugung geeigneter Verkn pfungen f r die nachtr gliche Verfolgung von Designent scheidungen Bei der Untersuchung des Stands der Technik konnte kein Ansatz f r Modell transformationen gefunden werden der diese Kernanforderungen in befriedigender Weise adressiert Aufgrund der erkannten M ngel wurde der hier vorgestellte Ansatz POTAD entwickelt Er besteht aus der Erweiterung der Softwareentwicklungsmethode ROPES einem erweiterten Template Metamodell der UML2 einer neuen Modelltransformationssprache und einem Ver folgbarkeitsmodell 189 7 Zusammenfassung und Ausblick Die ROPES Methode ist bei POTAD an den Kernprozess und die Modelllandschaft der Systementwicklung angepasst und die Analysepha
84. gt _ HeterogeneousRedundancy y an Channel lt Channel gt 1 channelState Boolean lt Channel gt setChannelState getChannelState Arstinput Secondinput Data Data Second lt Sensor gt Validation Validation 7 7 First lt Sensor gt _InputDataValidation V InputData Validation 1 oaks lt Sensor gt Se call setChannelState a er lt 9 Ls lt Controller gt Controller _ lt Sensor gt lt Sensor gt 1 1 First_ lt Controller gt lt Actuator gt A E Second_ lt Controller gt i N orvali sg 1 ne Ree en _ActuationValidation 2 Actuator gt lt Actuator gt a ActuationValidation i 1 call_setChannelState i A N Arst lt Actuator gt First Second Actuation Actuation Second lt Actuator gt Validation Validation 6 3 Erlauterung Das hier gezeigte HeterogeneousRedundancy Muster wurde von Douglass 02 bernommen Es unterscheidet sich von dem Muster HomogeneousRedundancy dadurch dass redundante Elemente unterschiedlich implementiert werden Auf diese Weise k nnen auch systematische Implementierungsfehler behandelt werden Im Klassenmodell schl gt sich diese Tatsache dadurch nieder dass es eigene Klassen f r j
85. htm Compuware et al 04a Compuware Sun Microsystems EXMOF MOF 2 0 Q V T 2nd revised submission presentation 2004a URL http www omg org cgi bin doc ad 04 11 06 pdf Compuware et al 04b Compuware Sun Microsystems EXMOF Queries Views and Transformations on Models using MOF OCL and EXMOF 2004b URL http www omg org docs ad 04 10 03 pdf Coplien 91 Coplien James Advanced C Programming Styles and Idioms Addison Wesley 1991 Corbett Corbett Robert Berkeley Yacc byacc URL http dickey his com byacc byacc html Cross 02 Cross Joseph K Proactive and Reactive Resource Allocation PLoP 2002 Proceedings 2002 URL http jerry cs uiuc edu 7Eplop plop2002 final ProReResReal_Lardieri pdf Czarnecki et al 00 Czarnecki Krzysztof Eisenecker Ulrich Generative programming methods tools and applications Addison Wesley Boston 2000 S xxvi 832 p Czarnecki et al 03 Czarnecki Krzysztof Helsen Simon Classification of Model Transformation Approaches Online proceedings of the 2nd OOPSLA 03 Workshop on Generative Techniques in the Context of MDA Anaheim October 2003 2003 URL http www swen uwaterloo ca kczarnec ECE750T 7 czarnecki_helsen pdf Dehayni et al 03 Dehayni M F raud L An Approach of Model Transformation Based on Attribute Grammars Object Oriented Information Systems Ausgabe Lecture Notes in Computer Science Springer Verlag 2003 S 412 423 DIN 94
86. in diese Richtung zu erweiterten als g nstig eingesch tzt siehe Kapitel 7 1 Hier gibt es Ans tze die bei der Instanziierung eines Musters neben einem Struktur auch ein Verhaltensmodell Instanzilieren Im Rahmen der Arbeit wird das in Kapitel 3 1 2 erlauterte V Modell zu Grunde gelegt Der besondere Fokus liegt auf dem bergang zwischen System und Softwareentwicklung im linken Ast des V Modells Die Verwendung der erl uterten Modelle und Modelltransformationen hat auch Implikationen auf den rechten Ast des V Modells Diese werden aber nicht weiter unter sucht Die in der Arbeit gezeigten Beispiele gehen davon aus dass die Software f r eine Funktion vollst ndig neu nach top down Vorgehensweise entwickelt wird In der Praxis wird aber oft auf bestehenden Implementierungen aufgesetzt die mit neuentwickelten Anteilen integriert werden Da es Muster f r diese Problematik gibt wird davon ausgegangen dass sich auch Trans formationsregeln formulieren lassen die statt der Erzeugung eines neuen Designs existierende Implementierungen integrieren Im Fokus der Arbeit steht die Entwicklung der Modelltransformationssprache Die gezeigten Beispiele f r Modelltransformationsregeln erzeugen ein Design das von einzelnen Experten als sinnvoll f r einen bestimmten Kontext erachtet wird Die Regeln wurden aber nicht systematisch anhand vieler Systeme evaluiert Eine solche Evaluierung ist ein m gliches Thema f r zuk nftige Arbeiten siehe
87. in dem hier betrachteten Kontext vor wenn bei der Parameterbelegung der einen Designmusterinstanz die Parameterbelegung der anderen Designmusterinstanz ausgelesen wird Durch diese Verwebung wird implizit eine Instanziierungsreihenfolge der Muster festgelegt da die Muster deren Parameterbelegungen ausgelesen werden zuerst instanziiert werden m ssen Der Fall dass ein Muster mehr als einen Parameter mit mehreren eingehenden Pfeilen hat kommt hier nicht vor 102 Softwareentwicklung ReferenceValue Signal ClosedLoopController Class FeedbackValue Signal ControlOutputValue Signal ReferenceValueSource Class ControlOutputValueDrain Class FeedbackValueSource Class eed Q ClosedLoopControl gt ESSEN ne Context Class amp ControlLoop Class Sensor Class Actuator Class Client Class Sensor_getMethod Operation Repository Class Context Class Publisher Class Strategy Class ConcreteSubscriber Class ConcreteStrategy Class updateMethod Operation gt algorithminterface Operation Actuator_setMethod Operation Data Class PublishSubscriber gt NO Strategy Cc ControlLoop gt Repository gt ae on ae Wenn Optimierung f r Wartbarkeit und Wiederverwendung Abbildung 3 48 Parameterabhangigkeiten zwischen Analyse und Designmustern Mit dem Operator werden einzelne Elem
88. k nnen Muster bei der Diskussion von L sungs alternativen wie ein Glossar fungieren der die Erkl rung von L sungsideen vereinfacht Muster k nnen demnach auch als wichtige Elemente einer Fachsprache f r Entwickler verstanden werden Zu Mustern gibt es seit einiger Zeit eine Community mit eigenen Konferenzen und Ver ffent lichungsreihen Eine zentrale Anlaufstelle ist die Webseite der Hillside Group Hillside Group Nach den Regeln der Community unterliegt die Entstehung und Verwendung von Mustern einem bestimmten Lebenszyklusmodell Bei Yacoub et al 04 wird dieses mit drei Phasen beschrieben e Mining Entdeckung In der ersten Phase wird ein Muster zum ersten Mal dokumentiert Wenn in der Praxis wiederholt ein bestimmtes Designproblem auftritt und eine L sung be kannt ist die f r dieses Problem in anderen Projekten erfolgreich war ist ein Muster kandidat gefunden Eine Herausforderung in dieser Phase ist es bei der Beschreibung die richtige Verallgemeinerung zu finden 68 Softwareentwicklung e Polishing Polierung In der zweiten Phase wird der Entwurf der Musterbeschreibung evaluiert und verbessert Dies geschieht durch Einreichung zur Begutachtung bei einer PLoP Konferenz Hillside Group bei dem das Muster nach einem f r die Muster Community spezifischen Prozess gereviewed wird In einem ersten Schritt unterstutzt ein er fahrener Musterexperte shepperd den Autor bei der Verbesserung der Musterbeschreibung
89. nnen sondern eher in der Wiederverwendung von L sungskonzepten bzw L sungsideen die zu wiederkehrenden Problemstellungen der jeweiligen Entwicklungsphase passen Eine Definition die zu allen Musterarten siehe folgendes Unterkapitel passt kann wie folgt formuliert werden Ein Muster ist eine wiederverwendbare L sungsvorlage f r ein wiederkehrendes Entwicklungs problem Eine Losungsvorlage ist in diesem Zusammenhang wiederverwendbar wenn sie ihre Tauglichkeit bei einem Projekt in der Vergangenheit nachgewiesen hat und au erdem gezeigt werden konnte dass sie sich auch bei anderen Systemen anwenden l sst Wrederkehrend hei t dass das Problem bei der Entwicklung mehrerer Systeme auftreten muss da sonst niemand von der Musterbeschreibung profitieren w rde Ein Zntwicklungsproblem kann in jeder Phase eines Entwicklungsprozesses auftreten ist Aontextabhangig und muss durch einen Entwickler be arbeitet werden Die durch die Muster beschriebenen L sungen sind somit keine Innovationen sondern ver allgemeinern lediglich L sungen die sich in der Vergangenheit bew hrt haben Aus diesem Grund kann auch von der Systematisierung von best practices in der Praxis bew hrte Vor gehensweisen gesprochen werden Neben der Wiederverwendung von L sungskonzepten verspricht man sich von Mustern auch Vorteile in der Kommunikation zwischen Entwicklern Da Muster einen Namen haben und im optimalen Fall allen Beteiligten bekannt sind
90. notifySubscribers notifySubscribers notifySubscribers atach atach atach atach detach detach detach detach A _Subscriber ae Subscriber x _ Subscriber _ Subscriber Subscriber_ Engine Subscriber_ Subscriber_ Airmass Subscriber RpmSensor TemperatureSensor AcceleratorPedal Sensor setData setData setData setData InputRepository setData getData _InputRepository Throttle Throttle EngineController_ Master setData ee Fuellnjection mes ohren periodic call step z Fuellnjection ae setData DataHolder a ig DataHolder cloop _IgnitionSystem gnitionSystem ee oes setData _EngineController_ControlLoop AirmassValue RPM EngineController_ControlLoop initialize F step Engine Temperature AcceleratorValue F ehutowne B 3 User Interface 1 Transformationsregel Rule UserInterface Template UserInterface ui gt Daten in einem Repository kapseln OptimCriteria Reuse Template Blackboard ul Indicatortui Source tui Draintuil UserInterface Controller ui Userintertace Model eae lee rie Blackboard ui UiInput
91. oft auf informelle Regeln oder Erfahrungswerte Einer der systematischsten Ans tze bei der Softwaredesignerstellung ist die Verwendung von Designmustern Ein Designmuster liefert eine in der Praxis bew hrte L sungsschablone f r ein wiederkehrendes Entwurfsproblem Diese Entwurfsprobleme decken sich in gro en Teilen mit oben angesprochenen nichtfunktionalen Anforderungen So gibt es beispielsweise eine Gruppe von Designmustern die die Wiederver wendbarkeit eines Designs f rdern und eine andere Gruppe die Sicherheits und Verf gbarkeits anforderungen adressieren F r Muster gibt es einheitliche Beschreibungsschemata die z B das Entwurfsproblem die L sungsschablone Vor und Nachteile des Musters sowie Anwendungsbei spiele beinhalten Muster die entsprechend eines solchen Schemas beschrieben sind werden blicherweise in Katalogen organisiert Der Entwickler kann dann anhand von Schl sselw rtern 5 1 Einleitung und Motivation potentielle Muster fur ein Entwurfsproblem finden und anhand der Beschreibung prufen ob es zu dem konkreten Anwendungskontext passt Moderne Entwicklungsumgebungen k nnen L sungsschablonen automatisiert in das Designmodell bernehmen und unterst tzen den Ent wickler bei der Anpassung an das restliche Design Insgesamt ergibt sich folgende Situation Neue Ans tze aus dem Bereich der Systementwicklung formalisieren und standardisieren Informationen auf der Basis von Modellen st rker als bisher und
92. r das Verst ndnis der Inhalte von Templates wichtig sind merge BasicBehaviors De ee RER Interfaces wt N Pe A merge merge a eae merge A B et Dependencies amp merge uo Kernel BasicA tivities Basiclnteractions InternalStructures K 2 i merge En import dep import_dep F g _ import_dep j i merge a merge Models Information Flow s Abbildung 3 29 Paketbeziehungen im Umfeld von Templates Zun chst kann grob zwischen den Metaelementen differenziert werden die eine Template Definition spezifizieren und solchen die die Bindung eines Templates beschreiben Abbildung 3 30 zeigt zunachst den Ausschnitt f r die Template Definition 82 Softwareentwicklung Kernel Pate Element a Templates i an plate 0 1 template Templates Templateable ignature 2 ownedTemplateSignature 1 Element signature Y1 ownedRardmpbrameter Templates 0 1 ownedParameteredElement Templates Template DaB RE ParameterableElement Parameter owningParameter 0 1 parameteredElement templateParameter 1 default SSS SSG SSS Ti 0 1 0 1 ownedDefault B OO owningDefault 0 1 Kernel Kernel Element Eleme
93. sich das Muster vor allem wenn die Eingabedaten f r den Regelkreis st ckweise kontinuierlich sind und verschiedene Berechnungsgleichungen f r einzelne Intervalle verwendet werden mussen 12 Repository 12 1 Zweck Verteilt erzeugte Daten zentral in einem Objekt kapseln 12 2 Struktur Repository Client lt Repository gt 0 1 set lt Data gt get lt Data gt Client 1 Class Repository Class _ Data 1 lt Data gt Repository toes Be _ Data 12 3 Erl uterung Das Muster beschreibt einen zentralen Datenspeicher f r Daten die an unterschiedlichen Stellen erzeugt werden Durch die zentrale Datenhaltung k nnen schreibende und lesende Klassen voneinander entkoppelt werden Die Idee des Musters ist z B bei Lalanda 98 be schrieben 220 13 SecondGuess 13 1 Zweck Eine Berechnung durch unterschiedliche Algorithmen absichern und diese in separaten Objekten kapseln 13 2 Struktur primaryCalc Context me 0 al AbstractAlgorithm secondaryCalc 1 call_alogrithminterface algorithminterface Context Class AbstractAlgorithm Class ConcreteAlgorithm 2 Class _ algorithminterface Operation ConcreteAlgorithm SecondGuess gt algorithmInterface nie ur re 13 3 Erl uterung
94. suchen Elemente im Designmodell zu erzeugen bzw Dialoge f r die Benutzerinteraktion aufzurufen F r die Handhabung von verschachtelten Transformations regeln ruft der Parser erneut die Klasse Au eCoordinator zu Hilfe Die Klasse XDEHandler sorgt f r die Erzeugung von Designmustern inklusive Expansion und Anlegen von Bindungen die Erzeugung der brigen Elemente Klassen Attribute Operationen Assoziationen und Ver erbungsbeziehungen das Auffinden von Analysemustern sowie die Aufl sung von Variablen F r die Erzeugung der Muster wird dabei auf die Pattern Engine von XDE zur ckgegriffen die die ben tigten Informationen ber die Templates aus der als Parameter angegebenen Muster bibliothek bezieht Die Dia ogs Klasse erm glicht schlie lich ber einfache Methodenaufrufe die Realisierung der Benutzerr ckfragen und der Namensabfrage Fur eine Umsetzung des raceabrlity Mechanismus wurde das Anlegen der lt lt design for gt gt Beziehungen bei der Erzeugung eines Designmusters sowie die Protokollierung der Designent scheidungen im XML Format bereits in die semantischen Regeln integriert Die XML Informationen ber erzeugte Designmuster und damit verbundene Designentscheidungen werden dem Analysemuster in einem Tagged Value hinzugef gt welcher zu dem Stereotyp lt lt AnalysisCollaboration gt gt geh rt F r diesen Zweck wurde mit dem ebenfalls zum MDA Toolkit geh renden Profile Manager ein eigenes Profil erstellt das f r die
95. und FPGAs Des Weiteren wird der verbaute Speicher wie z B RAM ROM oder EEPROM modelliert Au erdem k nnen die internen Verbindungen zwischen diesen Bau steinen erfasst sein Bussysteme und konventionelle Verbindungen diskrete Verbindungen durch elektrische Leitungen eines Fahrzeugs die E E Komponenten verbinden F r die beteiligten E E Komponenten werden die ent sprechenden Anbindungen Busanbindung konventionelle Anbindung beschrieben Botschaften und die enthaltenen Signale auf einem Bussystem inkl der Sender und Empf ngersteuerger te K Matrix Verf gt das Netzwerk ber Gateways k nnen auch die Routing Tabellen erfasst sein Batterien Generatoren Massestellen und Leitungsverteiler eines Fahr zeugs Diese Elemente verf gen ebenso wie die E E Komponenten ber Leistungsversorgungsanbindungen Ein und Ausg nge die durch Leistungsversorgungsverbindungen miteinander verbunden werden Pins und Stecker der Anbindungen sowie die Leitungen die diese in einem Fahrzeug verbinden Einbauorte eines Fahrzeugs in denen E E Komponenten verbaut werden k nnen sowie die verbindenden Segmente durch die Leitungen verlegt werden k nnen Tabelle 3 2 M gliche Inhalte der technischen Systemarchitektur 24 Systementwicklung Eine mogliche Auswirkung der Leistungsversorgung der Leitungen und der Fahrzeugtopologie auf die Softwareentwicklung wird im weiteren Verlauf der Arbeit nicht betrachtet Daher ent
96. und auslesen kann In der Formulierung ist absichtlich offen gehalten wie die Blackboard Klasse die Identifikation der konkreten Datenklassen vornimmt M glich ist dies beispielsweise ber die Vergabe von Daten IDs oder die Auswertung von Typinformationen Das Muster kann berall dort eingesetzt werden wo ein lokaler Datenspeicher zur Ablage und zum Austausch von Daten sinnvoll ist 210 2 ControlLoop 2 1 Zweck Den Algorithmus einer Regelung Steuerung in einem Objekt kapseln 2 2 Struktur Context Class ControlLoop Class s 1 Sensor Class a 1 Actuator Class s 1 Sensor_getMethod Operation a 1 Actuator_setMethod Operation ControlLoo nn Sh ot p S a Sensor Context _ lt Actuator gt Actuator 5 lt Sensor gt Sensor _getMethod 7 i periodic call_step Actuator_setMethod _ lt ControlLoop gt ControlLoop initialize step shutDown 2 3 Erl uterung Das ControlLoop Muster von Douglass 99 stellt eine einfache Realisierung einer Regelung oder Steuerung auf Designebene dar Der Regelungsalgorithmus wird in die Klasse ControlLoop ausgelagert und auf die drei Operationen initialize step und shutDown aufgeteilt die von einer bergeordneten Klasse Context aufgerufen werden In den drei Operationen vor allem der Operation step wird das eigentlich
97. und die damit zusammenh ngenden weiteren Standards der OMG richten sich nach der in Kapitel 3 1 3 a vorgestellten Vier Schichten Metamodellarchitektur In den Versionen 1 x der UML wurde f r Metamodellierung die Meta Object Facility MOF OMG 02a verwendet die selbst wiederum auf Grundlage eines Kerns von UML beschrieben war Im Normierungsprozess f r die Versionen 2 0 der beiden Standards wurde die Zielsetzung verfolgt MOF und den notwendigen Kern der UML zu vereinigen und als einheitliche Menge von Basiskonzepten darzustellen Diese Basiskonzepte sind mittlerweile verabschiedet und in der sog nfrastructure Library zusammengefasst die den ersten Teil der Definition von UML dar stellt und eine Sammlung grundlegender Metametaklassen enth lt In dieser Bibliothek ist auch bereits ein Metamodellpaket f r Erweiterungsmechanismen f r Metamodelle durch Profile 45 3 Stand der Technik enthalten Die UML 2 Infrastructure OMG 05b liefert die Grundlage f r den zweiten Teil der Spezifikation die UML 2 Superstructure OMG O5c in der die eigentlichen Modellelemente Notationen und Semantik der UML unter Benutzung der Konzepte aus der nfrastructure beschrieben sind Fur die statische Semantik wird auf die textuelle Spezifikationssprache Object Constraint Language OCL OMG 06 zur ckgegriffen die dynamische Semantik wird f r jedes Modellelement in einem eigenen Abschnitt in englischer Sprache beschrieben Die verschiedenen Diagra
98. und somit ein Workaround gefunden werden muss der die bestehenden Darstellungsmittel nutzt 4 2 3 Musterkatalog In den beiden folgenden Unterkapiteln wird jeweils f r die Analyse und die Designphase ein Musterkatalog f r die hier betrachtete Dom ne vorgestellt Die Auswahl dieser Muster entstand w hrend der Bearbeitung der Fallstudie durch Literaturrecherche und Expertenbefragung Der Katalog von Analysemustern enth lt einige selbst definierte Muster Die hier vorgestellten Kataloge sind als reine Beispiele f r die Dom ne zu verstehen Sie wurden nicht durch eine systematische Analyse der Dom ne ermittelt wie z B durch eine breit an gelegte statistische Untersuchung existierender Systeme Vielmehr zeichnen sich diese Muster dadurch aus dass sie im Rahmen der Fallstudie sinnvoll einsetzbar sind und das Potential zur Wiederverwendung in hnlichen Systemen haben Die getroffene Auswahl an Mustern stellt eine gewisse Konsolidierung der vielen Ver ffent lichungen in diesem Bereich dar Da die ausgew hlten Muster jedoch bzgl des Umfang ohne nderungen von den Autoren bernommen wurden beseitigt diese Konsolidierung jedoch nicht inhaltliche berlappungen zwischen den Mustern So enth lt z B das Muster ReactiveControlLoop implizit des Muster State und das Muster Model View Controller nutzt die Grundidee von Publisher Subscriber Auch wurde die Einordnung des Musters als Analyse oder Designmuster von den Autoren bernommen
99. von Mustern 3 2 5 Zwischenergebnis Das zur ckliegende Kapitel besch ftigt sich mit aktuellen Methoden und Modellierungssprachen der Softwareentwicklung Ein Schwerpunkt bildet die ROPES Methode die im Laufe dieser Arbeit als Referenz bei der Diskussion der Grenzen und m glichen Erweiterungen von Software entwicklungsmethoden verwendet wird Die im Rahmen von ROPES vorgesehenen Design muster werden in einem gesonderten Kapitel vertieft da bei ihnen in Hinblick auf Modelltrans formationen ein besonderes Potential gesehen wird Die Frage aus der Problemstellung siehe Kapitel 1 2 nach der Wiederverwendbarkeit von Modellen der Systementwicklung in der Softwareentwicklung kann aus Sicht der im Rahmen von ROPES verwendeten Modellierungssprache UML eingeschr nkt positiv beantwortet werden Wie in Kapitel 3 2 1 erlautert wird verf gt die UML ber einen Profilmechanismus der die Anpassung der Modellierungssprache an unterschiedliche Dom nen vorsieht F r die Be schreibung der logischen Systemarchitektur konnte f r einige Standardbeispiele aufgezeigt werden wie die Funktionsnetzwerke der Systementwicklungsans tze aus Kapitel 3 1 3 b mit stereotypisierten Klassendiagrammen modelliert werden k nnen F r diese Arbeit wurde eine eigene einfache Modellierungsweise festgelegt die f r die weitere Diskussion ausreichend ist Bei 104 Softwareentwicklung der Modellierung der technischen Systemarchitektur weist die UML noch erheblich
100. 1 f r die Funktion eines Tempomaten vereinfachter Ausschnitt aus der Fallstudie siehe Kapitel 2 ber einen Sollwertgeber SpeedDirector kann die gew nschte Geschwindigkeit eingestellt werden Der Geschwindigkeitsregler CruiseController vergleicht diese fortlaufend mit der ber den Geschwindigkeitssensor SpeedSensor erfassten Ist Geschwindigkeit und be rechnet bei einer Abweichung einen neuen Wert f r die Drosselklappe Throttle Abbildung 3 46 zeigt dasselbe Muster am Beispiel einer Klimaanlage Hier gibt es analog einen Sollwert geber TemperatureDirector und einen Sensor TemperatureSensor f r die Temperatur Der Regler ClimateController berechnet in diesem Fall die ffnung eines Ventils f r einen Kompressor CompressorControlValve Im unteren Bereich von Abbildung 3 45 ist ein m gliches Design unter Verwendung von Designmustern siehe Anhang A 2 zu sehen das in Richtung Wartbarkeit und Portabilit t optimiert ist Die Sensor und Sollwertgeberdaten werden unter Verwendung des Musters PublisherSubscriber zur Verf gung gestellt Das erlaubt das einfache Hinzuf gen von weiteren Konsumenten zu einem sp teren Zeitpunkt und umgeht eine ressourcenintensive Kommunikation durch die Verwendung des Push Prinzips Mit Hilfe des Musters Repository werden alle Eingangsdaten zentral gekapselt Dadurch wird es m glich die Reglung unabh ngig vom Daten bertragungsmechanismus zu realisieren Das Muster ControlLoop stellt ein typisches
101. 140 Abbildung 4 5 Die POTAD Metamodellpakete im Kontext des UML2 Metamodells 145 Abbildung 4 6 Modifiziertes Metamodell zur Template Definition aus der UMI2 146 Abbildung 4 7 Modifiziertes Metamodell zur Template Bindung aus der UML2 148 Abbildung 4 8 Eine Template Definition am Beispiel des Strategy MUStEers ccccccccceeceeeceeeeen scenes 148 Abbildung 4 9 eine Template Instanz am Beispiel des Strategy Musters 222cceeeeesneeeeeneennen 149 Abbildung 4 10 Beispiel bei dem Parameter gruppiert und mit Multiplizit ten versehen sind 150 Abbildung 4 11 Metamodell f r die Transformationsregeln cccccccc cece seen eee eeee een eeee een eeeeeeneeeeenneeees 156 Abbildung 4 12 Metamodell f r Verfolgbarkeitsinformationen cccccccccceccee cece eeee cece eeen seen eeeneeeaeeenes 164 Abbildung 4 13 lt lt Design For gt gt Beziehung mit Dokumentation der Designentscheidungen 165 Abbildung 5 1 Schematische Darstellung der Architektur des XDE Plug ins 168 Abbildung 32 Start der Transformation IN XDE in sears era 171 Abbildung 5 3 Dialog mit Einstellungen f r die Transformation 022222ssseseeseesenneeenneenenennn 171 Abbildung 5 4 Benutzerr ckfragen w hrend der Transformation cccccccecceeeee eee eeeeeeneeeeeenee
102. 18 2 Struktur Watchdog Class MonitoredChannel 1 Class a Watchdog Senn mi a nem Watchdog _ lt MonitoredChannel gt MonitoredChannel _ lt Watchdog gt stroke correctivAction periodic call_stroke 18 3 Erl uterung Das Watchdog Muster dessen Idee von Douglass Douglass 02 bernommen wurde beinhaltet einen einfachen berwachungsmechanismus f r Ger te Ein Wachhund Watchdog ist mit einem Ger t abstrahiert als MonitoredChannel verbunden und erwartet dass dieses in definierten Zeitabst nden die Operation notify aufruft um ein Lebenszeichen von sich zu geben Bleibt dieses aus so sendet der Watchdog auf Hardwareebene ein Signal zum Zur ck setzen des Ger ts dies ist im Klassendiagramm das sich nur auf die Software bezieht nicht darstellbar Das Muster kann in sicherheitskritischen Szenarien eingesetzt werden wenn es nur darum geht die prinzipielle Arbeitsf higkeit einzelner Ger te zu berpr fen und diese ge gebenenfalls neu zu starten 224 Anhang B Transformationsregeln Im Folgenden werden Transformationsregeln f r Analysemuster in der konkreten Syntax aus Kapitel 4 3 3 vorgestellt Der Zweck der in den Regeln instanziierten Designmuster wird jeweils in dem Kapitel Anwendbare Designmuster der Analysemusterbeschreibung in Anhang A 1 erlautert B 1 ClosedLoopControl 1 Transformationsregel Ru
103. 2 1 bersicht Um mit praxistypischen Anforderungen zu arbeiten wurden f r die Fallstudie eine Menge von zusammenh ngenden Funktionen zugrunde gelegt die sich an die Funktionalitat der Mercedes Benz C Klasse Baureihe 203 anlehnen Zu den Fahrfunktionen des KFS geh ren ein klassischer Tempomat und die sog Speedtronic Der Tempomat bringt und halt die Ge schwindigkeit des Fahrzeugs automatisch auf einen vom Fahrer eingestellten Wert Die Speedtronic begrenzt dagegen die H chstgeschwindigkeit des Fahrzeugs auf einen vom Fahrer eingestellten Wert Die Kombiinstrumentfunktionen umfassen die Berechnung Anzeige und Speicherung von Fahrdaten wie der aktuellen Geschwindigkeit Tages bzw Gesamtkilometer Kilometer bis zum n chsten Service Intervall und die aufgetretenen Fehler Au erdem zeigt das Kombiinstrument auch den Status der Fahrfunktionen an Eine ausf hrliche Beschreibung der Benutzeranforderungen findet sich in Anhang C In Abbildung 2 1 ist die logische System architektur des KFS analog zu der Notation aus Schauffele et al 03 skizziert Anzeigetext Kfz Management Anzeige Bremsregelung Bremsintensit t Bremse Tempomat Drosselklappe Speedtronic Offnungswinkel Drehmoment_ Soll Motorsteuerung Kommando Bedienkn pfe Raddrehzahl Raddrehzahlsensor B Istell Bremspedal remspedalstellung Kommando Tempomathebel Gaspedalstellung Gaspedal Motordrehzahlsensor Melordrehzan Abbildung 2 1 Logisc
104. 2 4 c erw hnten Object Analysis Patterns geliefert werden Detector Corrector Intention Monitor a device or system conditions and initiate corrective action s if a violation is found Motivation Embedded systems typically have tight timing and operational constraints Providing a mecha nism to assure that a component is operational or that specific constraints on the system are not violated is the objective of the Detector Corrector Pattern The Detector Corrector Object Analysis Pattern leverages the concept of detectors and correctors from the fault tolerance community Arora et al 98 The objective of the Detector Corrector Pattern is achieved by a local fault handler that interacts with detectors components that detect whether some state predicate is satisfied Arora et al 98 and correctors components that correct the system state in order to satisfy a violated predicate Arora et al 98 Examples of detectors include comparators watchdogs and exception conditions Examples of correctors include recovery procedures such as reset procedures and backup devices or exception handlers In embedded systems detectors commonly capture the following types of inputs Douglass 99 e Timeout messages from watchdogs e Assertions of software errors e Results of built in tests BITs that run on a periodic or continuous basis Applicability The Detector Corrector Pattern is applicable e To detect and correct the violation of
105. 2005 Information technology Open Distributed Processing Unified Modeling Language UML Version 1 4 2 2005 Jacobson et al 99 Jacobson Ivar Booch Grady Rumbaugh James The unified software development process Addison Wesley 1999 Jeckle et al 03 Jeckle Mario Rupp Chris Hahn J rgen Zengler Barbara Queins Stefan UML 2 glasklar Hanser Fachbuchverlag 2003 Judson et al 03 Judson S France R Carver D Specifying Model Transformations at the Metamodel Level Workshop in Software Model Engineering WiISME GUML 2003 San Francisco USA 2003 URL http www metamodel com wisme 2003 19 pdf Kalnins et al 04 Kalnins A Barzdins J Celms E Model Transformation Language MOLA Extended Patterns Proceedings of Baltic DB amp S 2004 Riga Latvia 2004 URL http melnais mii lu lv audris RuleLang3_Final pdf Karsai et al 03 Karsai G Agrawal A Graph Transformations in OMG s Model Driven Architecture Application of Graph Transformations with Industrial Relevance Proc AGTIVE 2003 Ausgabe Lecture Notes in Computer Science Springer 2003 S 243 259 URL http www isis vanderbilt edu publications archive Karsai_G_12_0_2003_Graph_Tran pdf Kempa et al 05 Kempa Martin Mann Zoltan d m Model Driven Architecture In Die Gesellschaft fur Informatik e V Hrsg nformatiklexikon 2005 259 Khriss et al 99a Khriss l Keller R Hamid l Supporting Design by Pattern ba
106. 3 zeigt dies f r den Sonderfall der Abfrage einer unbestimmten Anzahl von Namen bei dem durch Best tigen mit OK dieselbe Abfrage immer wieder erscheint und erst mit Abbrechen beendet wird f Benutzerf rage Namen der konkreten Strategien OK f hrt zur M glichkeit der Eingabe eines weiteren Namens Abbrechen schlielst die Liste der Namen ab Cornfo Strategie Abbildung 5 4 Benutzerr ckfragen w hrend der Transformation Auf diese Weise werden die Transformationsregeln f r alle gefundenen Template Instanzen im Analysemodell durchgef hrt Am Ende wird die erfolgreiche Durchf hrung der gesamten Trans formation mit einem weiteren Dialog best tigt Mit erfolgreicher Durchf hrung findet sich das Ergebnis der Transformation in Form von Modellelementen in dem als Parameter angegebenen Designmodell Die erzeugten Elemente sind zun chst nur in einer Baumansicht im Mode Explorer von XDE zu sehen k nnen aber zu Visualisierungszwecken individuell in Diagrammen angezeigt und angeordnet werden 5 2 Verfolgbarkeitsnavigator Der Verfolgbarkeitsnavigator realisiert die in Kapitel 4 1 2 beschriebenen drei Abfragen der w hrend der Modelltransformation angelegten Verfolgbarkeitsinformationen als Plug in des Werkzeugs Rational XDE Somit erlaubt die prototypische Umsetzung von POTAD die Modellierung die Modelltransformation und die Abfrage der Verfolgbarkeitsverkn pfungen in einem integrierten Werkzeug Das in Java prog
107. 4 4 verfeinert und mit den POTAD Artefakten in Bezug gesetzt Die einzelnen Aktivit ten werden in den folgenden Unterkapitel naher erl utert Logische Systemarchitektur Funktionsnetzwerk Kapitel 4 1 Kapitel4 2 WKapitel4 3 TE Kapitel 4 4 Stand der Technik Kapitel 3 Abbildung 4 4 Typischer Ablauf von Aktivit ten in POTAD 4 1 1 Analyse Im Rahmen von POTAD wird die Analysephase von ROPES erheblich modifiziert Unter der bei ROPES bezeichneten Phase System Engineering wird die in Kapitel 3 1 erlauterte Systement wicklung verstanden im Rahmen derer EAST ADL Modelle erstellt werden Die methodischen Vorgaben zur Phase System Engineering finden daher keine direkte Anwendung Entsprechend der Untersuchungsergebnisse aus Kapitel 3 2 2 g ist die gew hlte Vorgehensweise aber weit gehend mit den nur grob formulierten Vorgaben von ROPES kompatibel Es wird au erdem vorausgesetzt dass der f r das Steuerger t relevante Ausschnitt des Funktionsnetzwerks in Form der EAST ADL vorliegt Die hierin enthaltenen umfangreichen und formalisierten 140 Erweiterung der Entwicklungsmethode Informationen bzgl der logischen Systemarchitektur weisen groBe inhaltliche Uberschneidungen mit dem nach ROPES Vorgabe nun zu erstellenden Analysis Object Mode auf Aus diesem Grund wird das Funktionsnetzwerk unter Verwendung der in Kapitel 3 2 1 c getroffenen Kon vention in ein Klassenmodell umgewandelt das als ini
108. Abstraktes Datenelement gt Information UnitSignalMapping Logische architektur i C x Q O Q ad V gt 7 eb k Q Bol Q H Mappings Bussignal bzw Botschaft Tabelle 3 6 M gliche Elemente aus dem Metamodell des E E Konzept Tools f r die logische und technische Systemarchitektur sowie f r die Mappings 38 Systementwicklung Tempomathebel j 4 Benutzerkommando IF_Benutzerkommando Typ Tempomathebel A Tempomat Speedtronic Benutzerkomma do IF_Benutzerkommando Drehmoment_Soll IF_Drehmoment Typ Tempomat Speedtr A Motorsteuerung Drehmoment_Sdfl_Tempomat IF_Drehmoment Typ Motorsteuerung Abbildung 3 8 Ausschnitt eines m glichen Funktionsnetzwerks f r das KFS MMI_Kfz_ Management m Abbildung 3 9 Ausschnitt einer m glichen Komponentennetzwerk Architektur f r das KFS 39 3 Stand der Technik Vergleich In Tabelle 3 7 werden die beiden betrachteten Modellierungsansatze in Bezug auf die Inhalte des Kernprozesses siehe Tabelle 3 1 Tabelle 3 3 verglichen Die Modellierung der logischen Systemarchitektur ist demnach mit beiden Ansatzen moglich Allerdings gibt es bei dem Funktionsnetzwerk des E E Konzept Tools die Einschrankung dass dieses nicht explizit zwischen einem rein logischen Funktionsnetzwerk und einem Netzwerk aus Software komponenten differenziert Beide
109. Aktivit ten im Rahmen des ntegration Testing geh rt die Sicherstellung dass die Einzelteile zusammenpassen Dazu wird z B berpr ft ob Interfaces richtig genutzt werden und keine gesetzten Constraints verletzt werden Hierf r wird der Prototyp stufenweise zu sammengebaut und die Software mit der Ziel Hardware integriert Im Rahmen des nach gelagerten Validation Testing wird nach dem Black Box Verfahren berpr ft ob der Prototyp sein Ziel erreicht Das Ziel eines Prototypen kann z B die Erf llung bestimmter Use Cases sein oder die Erf llung bestimmter nichtfunktionaler Anforderungen Diese Use Cases und die dazu geh rigen Jest Vectors wurden bereits in der Phase Requirements Analysis definiert Zu den resultierenden Artefakten geh ren die Testpl ne ntegration Validation Test Plan die Beschreibung der Testf lle ntegration Validation Test Procedures und die Dokumentation der Testergebnisse ntegration Validation Test Results Diese Artefakte sind hnlich wie beim oben erw hnten Unit Testing aufgebaut W hrend des Tests identifizierte Probleme werden in der Form von Defects erfasst wobei nach Translation Design und Analysis kategorisiert wird 3 2 2 8 Vergleich mit dem Kernprozess und der Modellbildung in der Systement wicklung In den Phasen Requirements Analysis und System Engineering adressiert ROPES die Ent wicklung des Gesamtsystems also auch der Nicht Softwareanteile wie z B Elektronik Da somit auch
110. Code f r die Transformation erzeugen Der Beitrag erw hnt einige Beispiele und Fallstudien in denen die Transformationstechnik f r die Er zeugung eines in Hinblick auf die Codegenerierung optimierten Zwischenmodells erfolgreich eingesetzt wurde wobei jedoch offen bleibt ob sich der Ansatz auch f r andere Szenarien eignet Ein Verfolgbarkeitsmechanismus wird nicht erw hnt 123 3 Stand der Technik 3 3 4 8 E Willink UMLX Die in Willink 03b vorgestellte Transformationssprache UMLX nutzt ebenfalls erweiterte UML Diagramme fur die Beschreibung von Transformationen zwischen sog Schemata vergleichbar mit Metamodellen Hier werden UML Klassendiagramme durch eine zusatzliche Transformationssyntax erweitert die unter anderem ein Rauten formiges Symbol fur eine Transformation einf hrt Mit diesem in Willink 03a genauer beschriebene Element k nnen Verkn pfungen zwischen Quell und Zielelementen vorgenommen werden Damit lasst sich ber jeweils zusammenh ngende Elemente eine Trennung in die linke Seite Left Hand Side Quelle und die rechte Seite Right Hand Side Ziel einer Transformation vornehmen Die genaue Ausgestaltung der Transformation wird ber die direkte Verbindung von Quell und Zielelementen in Form spezieller Abh ngigkeitspfeile ausgedr ckt Fur diese gibt es drei Trans formationsoperatoren e Erhaltung Preservation Das Quellelement wird bernommen e Weiterentwicklung Evolution Erzeugung eines
111. Dialogs Application Wizard Properties E Application Wizard Icons 7 Callouts 7 Constraints Pg Rook Context 2 63 ClosedLoopContral Ba ClosedloopControl ClassCollaboration Ba ClosedLoopControl_InformationFlow x ControlQutputValueDrainil ClasedLoopController x ClosedLoopController i ReferenceValueSource J Feedback alueSource Wt ClasedLoopController t ReferenceYalue tr ClosedLoopController cal Advanced Properties EQ Custom Dialogs 24 value Sources Application Wizard Properties E Application Wizard Icons Pg Callouks 7 Constraints ClosedLoopController Controloutputyalue s gt ar CloseLoopController_controlFunction send ControloutputValue Default Argument t Feedbackvalue eol ControlQutputvalue Referencevalussource tol ControlQutputvalueDrain o Feedbackvaluesource Abbildung 3 40 Erweiterte Einstellungen f r ein Muster im Pattern Explorer 91 3 Stand der Technik Der Root Context nimmt alle nicht parametrisierten Elemente des Musters auf Er ist im Bei spiel vom Typ Paket und kann generell als ein spezieller Parameter aufgefasst werden dem bel der Instanziierung ein tatsachlicher Parameter zugewiesen werden kann Verhaltensmodelle in Form von Zustands und Sequenzdiagrammen konnen in XDE ebenfalls Teil einer Musterdefinition sein und parametrisierbare Elemente ausweisen Bei der Instanziierung werden in diesen Modellen ebenso wie bei Klassenmodellen die form
112. Drain Class Sensor ControllnputValue Airmass ControlOutputValue Signal Value EngineTemperature ControllnputValueSource Class RPM ReferenceValue ControllnputValue Signal Source AcceleratorPedal Reference ReferenceValueSource Class we BE Value AcceleratorValue OpenLoop ReferenceValue Signal coe Pe te at ae Controller EngineController gor Geantacae a en 00 on ro n ne on ro er Waceedlsccussesweuseseaesaaeees vaseecosseddscosbocetesdedeesectasacasssesicesavscsesesedeneoes OT ERTEILEN on u 3 Aoa ee a penLoopContro AcceleratorValue Endi ntroll AcceleratorPedal NEMEI AO ATT TIIE N E POE A IEI IN STETTEN TEL OHTETTIL T gt gineCo ro er FuellnjectionValue EngineTemperature IE OETA TEEN EEE ELTEETEEEL TESTER EEE Fuellnjection EngineTemperatureSensor PIENI E EE OSTE EOE SEATS TA gt ThrottleValue AirmaeNalie EELEE NIAISE PEIA E EEIEIE IESE FOOT LTE TEE gt Throttle AirmassSensor EEPE E ET EEE EIN TTI covonbasyoas ebdeesetsisees sedeeevs bene ccesuedeesessnree gt IgnitionValue ee a gt IgnitionSystem RpmSensor IEIET ETEA AEE E EA E O EEE T gt 2 5 Anwendbare Designmuster Blackboard Wiederverwendung Die Sensorwerte in einer Klasse kapseln ber eine generische Schnittstelle lesen und schreiben und so die eigentliche Steuerung von der Datenbeschaffung entkoppeln DataBus F r den Fall dass die Sensordaten ber einen Datenbus empfangen werden wird der Zugriff auf diesen in einer einheitlich
113. Kapitel 3 1 4 als wichtige Anforderung f r Transformation in dieser Dom ne erkannt wurden Die Tatsache dass Muster als ein m gliches Mittel f r Modelltransformation genannt werden passt ebenfalls zu der in Kapitel 3 2 4 g erlauterten Systematik und der in der ROPES Methode vorgesehen Vorgehensweise Fur den konzeptionellen Rahmen der durch die MDA gesetzt wird gibt es speziell fur das Thema der Modelltransformationen zahlreiche Arbeiten die konkrete L sungen vorschlagen Aufbauend auf einer Festlegung wichtiger Grundbegriffe sowie konzeptioneller Unter scheidungsmerkmale und technische Alternativen wurden die Arbeiten im zur ckliegenden 132 Modelltransformationen Kapitel vergleichend analysiert Die Analyse umfasst die beiden letzten Einreichungen fur den OMG Standard QVT und EXMOF sowie einige Arbeiten aus dem wissenschaftlichen Umfeld Einige davon basieren auf der OCL Attributgrammatiken logischen Programmiersprachen oder Graphtransformationen Die abschlieBende Bewertung der Ansatze stutzt sich auf die Kapitel 3 2 5 gesammelten An forderungen Viele dieser Kriterien leiten sich dabei aus der Kernanforderung ab die auf der Instanziierung von Mustern basierende Systematik aus Kapitel 3 2 4 g abbilden zu konnen Der zweistufige Abgleich der Ansatze mit diesen Kriterien liefert schlieBlich das Ergebnis dass die Anforderungen von keinem der untersuchten Ansatze im vollen Umfang unterstutzt werden Auch die Prufung ob sic
114. Kapitel 4 4 beschrieben merge merge a neigen a g A import_dep merge 3 merge ra Im po FE de p Abbildung 4 5 Die POTAD Metamodellpakete im Kontext des UML2 Metamodells Die Modifikationen im Template Metamodell schranken zum einen die sehr allgemein ge haltenen UML Templates auf die Falle ein die im Rahmen von POTAD verwendet werden und prazisieren f r diese die Semantik Zum anderen werden auch neue Elemente hinzugef gt um einige der in Kapitel 3 2 4 e identifizierten L cken zu schlie en Die modifizierten Teile im Bereich der Template Definition sind in Abbildung 4 6 farblich markiert 145 4 Eigener Losungsansatz POTAD Kern tfement ownedParameterGroup M ownedTemplateSignature signatureY1l eel ordered 9 ownedParameter ownedParameter parameteredElement templateParameter 0 1 nameExpression 0 1 P Aus anderem Paket des Beibehalten aus Template Paket des fm Im Rahmen von POTAD neu UML2 Metamodells UML2 Metamodells definiert Abbildung 4 6 Modifiziertes Metamodell zur Template Definition aus der UML2 Die Vererbungshierarchie ist in dem Diagramm nach unten hin abgeschlossen d h es gibt keine weiteren Subklassen Im Detail wurden folgende nderungen vorgenommen e Indem die abstrakte Klasse TemplateableElement durch die konkrete Klasse Template ersetzt wird gibt e
115. Kapitel 7 1 Ein klassisches Thema im Softwaredesign ist die Behandlung von Nebenl ufigkeit Die in der Arbeit gezeigten Designbeispiele verwenden ein in der Automobilindustrie verbreitetes Scheduling Verfahren bei dem es keine nebenl ufigen Tasks gibt Die Behandlung von Neben laufigkeit wird somit durch die Transformationsregeln nicht adressiert Da es aber auch hier zahlreiche Muster zu dem Thema gibt wird davon ausgegangen dass sich die Transformations regeln in diese Richtung erweitern lassen 1 4 Organisation der Arbeit In Kapitel 2 wird ein durchg ngig f r diese Arbeit genutztes Fallbeispiel vorgestellt das typische Anforderungen an Automotive Software enth lt Es dient im weiteren Verlauf der Arbeit als Basis f r die Untersuchung der existierenden Ans tze und der Diskussion der eigenen L sung In Kapitel 3 wird der relevante Stand der Technik umrissen und anhand des Fallbeispiels er lautert Nach grundlegenden Betrachtungen zu den Eigenschaften der Dom ne und den Organisation der Arbeit Prozessen und Modellen der System und Softwareentwicklung wird mit Untersuchungen zu Modelltransformationen und Mustern auf den eigentlichen Themenkomplex dieser Arbeit fokussiert Die Ergebnisse resultieren schlieBlich in einer prazisierten Problemstellung Kapitel 4 stellt zu dieser Problemstellung den eigenen L sungsansatz Pattern Oriented Transformations between Analysis and Designmodels POTAD vor Nach einigen Festlegu
116. Kommunikationsschnittstellen hinsichtlich unterschiedlicher Kommunikationsmodelle Die Fest legung von aktiven Objekten die Bildung von Tasks und Spezifikation der Inter Task Kommunikation und Synchronisation wird ebenfalls methodisch adressiert Eine Besonderheit ist die Festlegung eines Verfahrens f r die Laufzeitabsch tzung dass sich insbesondere f r Systeme mit harten Echtzeitanforderungen eine vorgegebene Zeitschranke muss unbedingt eingehalten werden eignet COMET adressiert in besonderem Ma e Fragen die bei hochverteilten nebenl ufigen Systemen behandelt werden m ssen hat aber ansonsten mit ROPES und RUP viele hnlichkeiten ROPES differenziert sich in diesem Vergleich etwas durch den ausf hrlich beschriebenen Ein satz von Mustern die als ein zentrales Hilfsmittel der Methode verwendet werden 3 2 4 Muster Zu den bereits in Kapitel 1 1 angesprochenen Prinzipien des Software Engineerings geh rt auch die Wiederverwendung Boehm 83 Durch Wiederverwendung sollen Zeitaufwand Kosten und Qualit tsrisiken reduziert werden Auf der Code Ebene konnte sich dieses Prinzip z B in der 67 3 Stand der Technik Form von Programmbibliotheken relativ fruh etablieren Die seit Anfang der 1990er Jahre publizierten Muster Ans tze versuchen Wiederverwendung auch in fr heren Phasen zu realisieren insbesondere im Design Der Schwerpunkt bei Mustern liegt nicht in der Lieferung von L sungen die 1 1 bernommen werden k
117. Methodenger st f r eine Regelung zur Verf gung und separiert die eigentliche Regelschleife vom Kontext Mit Hilfe des Musters Strategy wird der Algorithmus f r die Berechnung der Drosselklappenstellung leicht austauschbar In dem hier gezeigten Beispiel kann alternativ eine sportliche Sport oder eine komfortable Geschwindigkeitsregelung Comfort zum Einsatz kommen Der untere Bereich von Abbildung 3 46 zeigt ein Design f r die Klimaanlage das f r dieselben Randbedingungen wie bei dem Design des Tempomaten entwickelt wurde Bis auf die Element namen sind beide Diagramme identisch 98 Softwareentwicklung ReferenceValue Signal ClosedLoopController Class bind FeedbackValue Signal Bind ClosedLoopController CruiseController Feedback ControlOutputValue Signal Value CurrentS peed ControlOutputValue ThrottleSet ReferenceValueSource Class Value ReferenceValueSource S peedAdjustingLever Control ControlOutputValueDrain Class OutputValueDrain Throttle FeedbackValueSource Speed _ FeedbackValueSource Class CCruiseControlier Senso ReferenceValue DesiredSpeed eC Teaco DesiredS peed E TIER eaa a A IEHANNFE ThrottleSetValue SpeedAdjustingLever CruiseController PROTTE PITAA ITEE TEE PETEA EIAI ITIER D Throttle CurrentS peed Spaadsencor ee bind Bind ConcreteSubscriber InputRepository updateMethode set DesiredS peed Publish
118. Modellinhalte des E E Konzept Tools in Form einer Schichtenarchitektur Kundenanforderungen AntorderungsliSie FE Featurelistenansicht Anforder M ungen m 2 Ausstattungskontexteditor Funktionalit ten Architektur Anas eren on leer eS a Funktionalitatenkompositionseditor Ausstattungsbeziehungseditor Q D o Zusammenstellen von Wirkketten Zusammenhang der Modi Se 28 lt 5 En SS Funktions Architektur nm co ze Funktionseditor FN Funktionstypeditor TE o s Funktionsmodell SW HW Funktionsbibliothek SW HW D Z Bi Funktionssystemeditor SF Funktionen Funktionsbeitrag zu einem System Elektronik Komponentennetzwerk Architektur Vernetzungseditor NET Komponenteneditor KMP Kommunikation der Steuergerate Aufbau einer ECU Systemnetzwerkeditor SN Beitrag zu einem System Bedarfsansicht BA Leistungsversorgungseditor LV Elektrische Stromversorgung Verteil icht CA Elektrik erteileransicht CA MA Kabelbaum Leitungssatz en WHE eitungen Physik MA Geometrie a Topologieeditor TOP Physikalische Architektur Lokalisierung der Steuergerate Abbildung 3 7 Modellinhalte des E E Konzept Tools Aquintos 06 Die Inhalte der einzelnen Modelle sind auf der Vertikalen durch Mappings verknupft Da es auch Mappings gibt die einzelne Schichten berspringen handelt es sich jedoch nicht um eine strikte Schichtenarchitekt
119. Muster Model View Controller in der Literatur auch oft als MVC abgek rzt wurde von Buschmann 98 bernommen und in ein Klassendiagramm bertragen Es beschreibt die Unterteilung einer interaktiven Anwendung in drei Komponenten Ein Modell Model das die Kernfunktionalit t und die Daten enth lt Ansichten Views die dem Benutzer Informationen pr sentieren und eine Steuerungskomponente Controller die die Interaktion steuert Ein Benachrichtigungsmechanismus Observer sichert die Konsistenz zwischen den drei Komponenten Ansichten und Steuerung werden beim Model an attach bzw abgemeldet detach Das Modell ruft bei allen angemeldeten Ansichten und Steuerungskomponenten update auf wenn sich Daten ndern Ansichten initialisieren bei Bedarf die Steuerung initialize fragen Daten beim Modell ab getData und implementieren die abstrakte update Operation der Observer Klasse bez glich der konkreten Darstellung aus Controller bersetzen Bedieneingaben in Aufrufe von Operationen an das Modell oder Darstellungsanforderungen an die Ansicht handleEvent Falls notwendig k nnen sie ebenfalls die abstrakte update Operation von Observer implementieren 217 9 MonitorActuator 9 1 Zweck Ein Uberwachungskonzept eines Aktuators in einem Objektmodell abbilden 9 2 Struktur Context Class ActuatorMonitorSensor Class Monitor Class Actuator Class Actuator_setMethod Operation ReferenceValueSource Clas
120. Notation von EXMOF anhand eines Beispiels Compuware et al 04b Da auf Basis der graphischen Notation jedoch nicht alle Feinheiten der abstrakten Syntax realisiert werden konnen gibt es daruber hinaus noch eine grammatikalische Syntax Diese ist bez glich des Sprachumfangs relativ einfach und dadurch leicht verst ndlich f hrt aber auf grund der Vielzahl an Klassen in einer Transformationsdefinition zu einer gro en Menge an Code Insgesamt ist der Ansatz rein deklarativ und unterst tzt so auch die Ausf hrung von Trans formationen in verschiedene Richtungen und eine inkrementelle Anwendung F r die Realisierung von Verfolgbarkeit wird darauf verwiesen dass die Mappings auf MOF zur ckf hr bar sind und somit ber existierende Technologien persistent gehalten und ausgelesen werden k nnen Ein eigener Mechanismus wird daher nicht bereitgestellt Als Proof of Concept wird auf das Werkzeug Optimal von Compuware verwiesen 118 Modelltransformationen 3 3 4 Ans tze aus dem akademischen Umfeld Die im letzten Unterkapitel erl uterten Ans tze sind Antworten auf den RFP f r QVT die berwiegend aus dem industriellen Umfeld stammen und auf die durch die OMG formulierten Anforderungen ausgerichtet sind Daneben gibt es aber auch in der wissenschaftlichen Literatur eine Vielzahl von Beitr gen die unabh ngig von QVT Modelltransformationsans tze pr sentieren Ausgehend von verschiedenen anderen Zusammenfassungen wie z B in Guel
121. Object Structural Model Analysis Object Model Abbildung 3 22 Artefakte der Phase Analysis Douglass 99 Requirements Analysis In der Anforderungsanalyse werden alle funktionalen und nichtfunktionalen Kunden anforderungen strukturiert und in eine m glichst konsistente Form gebracht Zu den Aktivit ten geh ren das Identifizieren und Beschreiben von Use Cases die sich aus den Gespr chen mit dem Kunden ergeben Dazu m ssen unter anderem die externen Ereignisse die das System beeinflussen identifiziert werden Mit der Aufstellung von Szenarien kann das Verhalten der identifizierten Use Cases genauer beschrieben werden Bei sicherheitsrelevanten Anwendungen oder bei Systemen bei denen ein Ausfall mit hohen Kosten verbunden ist m ssen Gef hrdungs situationen und Risiken analysiert werden engl hazard analysis Schlie lich m ssen Randbe dingungen des zu erstellenden Systems erfasst werden wie z B vorgegebene Schnittstellen oder Performance Anforderungen Zu den resultierenden Artefakten dieser Phase sind an erster Stelle die Use Cases zu nennen Eine Use Case Beschreibung umfasst ein Use Case Diagramm Zustandsdiagramme bei re aktivem Verhalten eine Liste mit externen Ereignissen und ein Kontextdiagramm Bei dem Kontextdiagramm handelt es sich um ein UML Objektdiagramm mit einem System Objekt und Akteuren die mit dem System durch den Austausch von Nachrichten interagieren Weiteres Artefakt ist die Sammlung von
122. POTAD Kollaborationen hinsichtlich der nichtfunktionalen Anforderungen und der technischen System architektur Die Modelle haben bereits einen sehr starken Bezug zur _ letztendlichen Implementierung Diese bisher manuelle T tigkeit wird mit Hilfe eines Modelltransformators automatisiert Der Transformator durchsucht dazu das Analysis Object Model nach Analyse musterinstanzen um f r die am Muster beteiligten Elemente eine Designvorlage im Mechanistic Design Model zu erzeugen Dies geschieht durch die Instanziierung von Designmustern die bereits in der urspr nglichen ROPES Methode so vorgesehen sind Im Rahmen von POTAD werden Muster jedoch auf Basis formalisierter Templates eingebracht die in Kapitel 4 2 1 beschrieben sind Welche Designmuster f r ein Analysemuster instanziiert werden und wie Informationen aus dem Analysemuster f r die Parameterbelegung des Designmusters verwendet werden ist in Trans formationsregeln hinterlegt die in einer eigens daf r entwickelten Syntax definiert werden Eine Transformationsregel bezieht sich somit auf einen Analysemustertyp und beschreibt die Instanziierung von einem oder mehreren Designmustern Vor dem Start einer Transformation kann sowohl der Transformationsregelsatz alternative Regeln f r denselben Analysemustertyp als auch der Designmusterkatalog ausgew hlt werden dessen Muster bei der Instanziierung verwendet werden Die Templates in den Designmusterkatalogen m ssen namens und signaturglei
123. Paketen ber eine zus tzliche gerichtete Assoziation ohne Namen verf gen weil diese so im Template definiert wurde und die Verschmelzung nur auf der Basis von Namensgleichheit durchgef hrt wird Im Kontext eines Musters k nnte aber der Name der Assoziation bewusst offen gelassen werden da es aus Sicht des Musters nur wichtig ist dass irgendeine Assoziation zwischen den Klassen besteht und bereits existierende Assoziationen demnach wiederverwendet werden sollen Ein weiteres Beispiel sind Operationen Nach den Regeln f r Pakete werden diese nur ver schmolzen wenn sie namensgleich sind und ber dieselbe Parameterliste verf gen Unter scheiden sich die Parameterlisten sind im Verschmelzungsergebnis zwei namensgleiche Operationen mit unterschiedlichen Parameterlisten vorhanden Dieses Verhalten kann gewollt sein wenn ein berladen der Operation bewirkt werden soll Im Fall eines Musters kann es aber auch sinnvoll sein im Template eine Operation mit Parameter anzulegen und diese mit einer namensgleichen Operation im Modell zu verschmelzen die ber keine Parameter verf gt Dies ist z B der Fall wenn im Modell eine leere Operation als Platzhalter angelegt wurde in der Erwartung dass sie durch die Anwendung des Musters in Bezug auf ihre Parameter verfeinert wird Eine im Modell mit Parametern versehene Operation mit einer parameterlosen Operation aus dem Template zu verschmelzen ist ebenso denkbar Ein Beispiel ware ein parameterlo
124. Pattern Oriented Transformations between Analysis and Design Models POTAD DISSERTATIONSSCHRIFT zur Erlangung des akademischen Grades Doktoringenieur Dr Ing vorgelegt der Fakultat fur Informatik und Automatisierung der Technische Universitat Ilmenau von Diplom Wirtschaftsinformatiker Gabriel Schwefer geb Vogler geboren am 18 September 1976 Gutachter 1 Prof Dr Ing habil Ilka Philippow 2 Prof Dr Ing Ina Schieferdecker 3 Prof Dr Ing habil Wolfgang Fengler Eingereicht 10 Oktober 2007 Datum der Promotion 19 Februar 2008 urn nbn de gbv ilm1 2008000021 Vorwort Diese Arbeit entstand im Rahmen meiner Doktorandentatigkeit in der Abteilung Software Architekturen mittlerweile Software Strukturen der DaimlerChrysler Forschung in Ulm die von Dr Bernhard Hohlfeld geleitet wird Das bearbeitete Thema war in das vom BMBF ge forderten Verbundprojekt ntegrative Pattern und UML orientierte Lern und System Entwicklungsumgebung InPULSE eingebettet An diesem Projekt war neben der Daimler Chrysler AG unter anderem auch das Fachgebiet Prozessinformatik der TU Ilmenau beteiligt das von Frau Prof Dr Ing habil Ilka Philippow geleitet wird Sie bernahm die wissenschaft liche Betreuung dieser Arbeit und erg nzte somit Dr Thomas Flor der die Arbeit seitens DaimlerChrysler begleitete F r die Betreuung m chte ich Ilka Philippow und Thomas Flor herzlich danken Sehr hilfreich waren unter anderem
125. Programm aufgef hrt Hybride Ans tze beinhalten Elemente aus beiden Paradigmen e Darstellung Viele Ans tze legen sich bereits bez glich der Notation auf eine graphische oder textuelle Darstellung fest obwohl die abstrakte Syntax einer Sprache grunds tzlich beide M glichkeiten offen lasst Da die Wahl der Darstellungsform gro e Auswirkungen auf die Handhabung einer Modelltransformationssprache hat ist es dennoch sinnvoll diese als Unterscheidungsmerkmal heranzuziehen Auch hier besteht die M glichkeit beide Varianten in einer kombinierten Form zu verwenden 3 3 2 d Auswahlkriterien f r die weiteren Untersuchungen Da es sich bei dem im Rahmen dieser Arbeit zu erarbeitenden Ansatz um eine werkzeug unabh ngige und problemorientierte L sung handeln soll werden im Folgenden nur Arbeiten betrachtet die der dritten Kategorie spezielle Transformationssprache zuzuordnen sind Schwerpunkte der Recherchen sind zum einen die Vorschl ge die im Umfeld von MDA ent standen sind und i d R durch die Industrie getrieben werden Diese m ssen bestimmte An forderungen erf llen die in dem von der OMG lancierten RFP QV7 definiert sind Zum anderen werden aber auch von MDA unabh ngige Ans tze und Projekte betrachtet die eher im akademischen Umfeld entstanden sind 115 3 Stand der Technik 3 3 3 Ans tze aus dem Umfeld der OMG Der MDA Guide der OMG Miller et al 03 beschreibt zu Modelltransformationen nur die Grundidee und ty
126. Reihenfolge ausgef hrt werden m ssen F r den Fall dass ein Element durch eine Transformation seinen Namen ndert wird vorgeschlagen Klassen mit dem Stereotyp lt lt trace gt gt automatisiert anzulegen die Ein und Ausgabeelemente einer Trans formation verlinkt Die Ausf hrung von Regeln kann an Bedingungen gekn pft werden die das Modell abfragen Auf diese Weise kann auch Variabilit t von Transformationsregeln indirekt unterst tzt werden 3 3 4 b Graph Rewriting and Transformation Language GReAT Das in Agrawal 04 pr sentierte System f r Modelltransformationen GReA 7 beinhaltet einen UML basierten Ansatz f r die Spezifikation von Modelltransformationen der sich auf formale Graphgrammatiken und transformationen st tzt Er besteht aus drei Teilen e Einer auf UML Klassendiagramme zugeschnittenen Pattern Specification Language Ein damit spezifiziertes Pattern beschreibt einen Subgraphen und kann Kardinalit ten ent halten Dar ber hinaus sind hierarchisch verschachtelte Patterns m glich e Einer Graphersetzungs Transformationssprache Graph Rewriting Transformation Language mit der sich Transformationsregeln in Form von sogenannten Produktionen formulieren lassen Da auf vorhandene Graphtransformationstechniken zur ckgegriffen wird die nur innerhalb eines Graphen operieren werden Quell und Zielmodell als ein Graph dar gestellt Damit kann eine Produktion als 4 Tupel aus einem Pattern Graph einer Mapping Funkti
127. Signal Bind ClosedLoopController CruiseController Feedback ControlOutputValue Signal Value CurrentS peed ControlOutputValue T hrottleSet ReferenceValueSource Class Value ReferenceValueS ource SpeedAdjustingLever Control ControlOutputValueDrain Class yee OutputValueDrain Throttle FeedbackValueS ource S peed FeedbackValueSource Class CruiseController ee OR TEN VE oP PE en a ClosedLoopControl un SON Br ae a ThrottleSetValue etmeye 1m SpeedAdjustingLever Cuento ee ee gt Throttle SpeedSensor 2 2 Designmodell 1 A Optimierungskriterium Wiederverwendung Reuse Werden die Sensordaten ber einen Datenbus zur Verf gung Ja gestellt DE2Sig Muss der Regelalgorithmus mehrere Zust nde unterscheiden 227 InputRepository CruiseController_Master Throttle lt lt Throttl _InputRepository _ currentState gt 2 setThrottleSetValue AbstractClient 1 setDesiredSpeed getDesiredSpeed pE periodic call_step setCurrentSpeed EnpuNEeD ge getCurrentSpeed ee bus IRA a 0 1 _CurrentSpeed 0 1 _DesiredSpeed CruiseController_AbstractState CurrentSpeed Des
128. Signale werden zu Nachrichten 23 3 Stand der Technik eines Kommunikationssystems zusammengefasst Hierbei m ssen Randbedingungen wie Rechen oder Kommunikationsleistung ber cksichtigt werden e Analyse und Spezifikation zuverl ssiger und sicherer Systeme In der Analysephase werden gef hrliche Situationen analysiert und entsprechende Zuverl ssigkeits und Sicher heitsanforderungen spezifiziert Daraus leiten sich auch bereits grundlegende Sicherheits strategien ab z B notwendige berwachungsfunktionen oder redundante Auslegung von Hard und Software die Abtastraten die Kommunikationssysteme inkl der wichtigsten Nachrichten sowie die grundlegenden An Mit dem Ende dieses Prozessschrittes sind somit die Hardware forderungen und Ma nahmen f r Sicherheit und Zuverl ssigkeit definiert ber die Aus f hrungen von Sch uffele et al 03 hinausgehend werden die m glichen Inhalte der technischen Systemarchitektur f r diese Arbeit wie in Tabelle 3 2 weiter detailliert E E Komponenten EEKomp Interner Steuer ger teaufbau IntSG Kommunikations verbindungen KVerb Buskommunikation BKomm Leistungsver sorgung LeistVers Leitungen Leit Fahrzeugtopologie Topo Liste der vorhandenen Sensoren Sollwertgebern Aktuatoren und Steuerger te sowie einfacher Elektrik Elektroniken Die in einem Steuerger t eingesetzten Rechen und Logikbausteine wie z B Mikroprozessoren ASICs
129. Source AirmassSensor EngineTemperatureSensor Rom i 0 ControllnputValueSource Class Sensor i 0 ControllnputValue AirmassValue Engine i 0 ControllnputValue Signal Temperature RPM ReferenceValueS ource Accelerator ReferenceValueSource Class ___ Pedal ReferenceValue AcceleratorValue OpenLoop ReferenceValue Signal aoe NN ss Controller EngineController en 00 on ro n ne on ro er sssssssesessesseessssseseesssesseesssssesesessesseessessesesessesesoessssseseesesessseesesseseeessssseeesessesesesssssseesesseseeesssssesesesseseeeessen E mae u en Due Opentoopcontrol gt AcceleratorPedal PETET IAEA EER AT EEEIEE LIA EETU STIA TAE LTE gt ControlOutputValue ControllnputValue Fuellnjection ControlOutputValue S ControllnputValue Throttle AirmassSensor PEPPEN EIIE ATEI LEES NOTEER TIERE ET gt ControlOutputValue ControllnputValue IgnitionSystem 2 2 Designmodell CS Optimierungskriterium Wiederverwendung Reuse Werden die Sensordaten ber einen Datenbus zur Verf gung Nein gestellt DE2Sig Muss der Regelalgorithmus mehrere Zustande unterscheiden M ssen alternative Steuerungsstrategien verwendet werden 233 InputValPubSub_EngineTe C refValPubS ub InputValPubSub_Airmass gt _InputValPubSub_RpmSensor gt en an at Bo eco a gt EIER ne EngineTemperatureSensor AcceleratorPedal AirmassSensor RpmSensor notifySubscribers
130. State getNames Namen der konkreten Zust nde 1 i Gonerekestate getNames Namen der konkreten Regelkreise 1 ConcreteControlLoop reacloop Wenn keine zustandbehaftetes Verhalten Template ControlLoop ol OpenLoopController Master IL ConLexe ol OpenLoopController ControlLoop ControlLoop Reuse inputRep Blackboard tinputRep Blackboard Sensor ol ControlInputValueSourcetol ReferenceValueSource ol ControlOutputValueDrain Actuator getData Sensor_getMethod Vace Dar A Actuator_getMethod Neolocp Den Steuerungsalgorithmus austauschbar machen 231 OptimCriteria Reuse AND UserQuestion Mussen alternative Steuerungsstrategien verwendet werden false Strat Template Strategy Reactive reacloop AbstractControlLoop cloop ControlLoop Context ol OpenLoopController Strategy Strategy getNames Namen der alternative Steuerungsalgorithmen 1 Concrete Strategy getNames Interface Name des Steuerungsalgorithmus 1 algorithmInterface PECOnbrolSwraty Heterogene Redundanz unterst tzen OptimCriteria Safety AND UserQuestion Muss heterogene Redundanz unterst tzt werden false Rd Template HeterogeneousRedundancy RedundancyMaster Context Reactive reacloop Sensor cloop Sensor Sensor ol OpenLoopController Channel Channel Reactive reacloop Context cloop Context Controller Reactive reacloop Actuator cloop Actuator Actuator
131. TL In Bottoni P Minas M Hrsg nternational Workshop on Graph Transformation and Visual Modeling Techniques ENTCS 72 3 Elsevier Science B V 2002 URL http www4 in tum de marschal pub entcs bm02 pdf Braun et al 03a Braun P Marschall F BO7L The Bidirectional Object Oriented Transformation Language Ausgabe Technical Report 2003a URL http wwwbib informatik tu muenchen de infberichte 2003 TUM 10307 pdf Braun et al 03b Braun P Marschall F Model Transformations for the MDA with BOTL Proceedings of the Workshop on Model Driven Architecture Foundations and Applications Univeristy of Twente 2003b URL http wwwA4 in tum de publ papers marschall_braun mdafa03 pdf Brown et al 98 Brown W Malveau R McCormick H Mowbray T AntiPatterns Refactoring Software Architectures and Projects in Crisis Wiley Verlag 1998 Buchwald 05 Buchwald Jan Ene Transformationssprache f r musterbasierte Modelltransformationen Diplomarbeit Universtitat Ulm 2005 257 Buschmann 98 Buschmann Frank Pattern orientierte Software Architektur Ein Pattern System Addison Wesley 1998 Coad et al 97 Coad Peter North David Mayfield Mark Object models strategies patterns and applications Yourdon Press computing series Yourdon Press Upper Saddle River N J 1997 S xviii 515 p Compuware Compuware OptimalJ Produktseite URL http www compuware com products optimalj default
132. Transformationsregeln aus dem Analysemodell erzeugt und in geringem Umfang nachbearbeitet Dabei wurde das Optimierungskriterium Sicherheit und Verf gbarkeit gew hlt und alle Fragen bis auf die nach einem Datenbus und alternativen Regelungsstrategien negativ beantwortet Da diese studentischen Arbeiten durchgef hrt wurden als die Entwicklung von POTAD noch nicht abgeschlossen war entsprechen die eingesetzten Regeln und Muster nicht dem in Anhang A und Anhang B dokumentierten Stand Das Analysemodell verwendet zudem nicht die in anderen Analysemodellen dieser Arbeit eingesetzten nformation Flows sondern eine Klassen darstellung mit Assoziationen die der in Abbildung 3 14 gezeigten Modellierungsweise nahe kommt Die Abweichungen bewegen sich aber insgesamt in einem Rahmen der ein Verst ndnis ohne weitere Erlauterungen m glich macht C 1 Kundenanforderungen Das zu entwickelnde System soll folgende Funktionen und Wartungsaufgaben bernehmen Tempomat Speedtronic Tages und Kilometerz hler digitaler Tachometer Wartungsanzeige Fehleranzeige Anzeige des Benzinverbrauchs Anzeige der Durchschnittsgeschwindigkeit Reichweite abfragen a gt 3634 31 1 Benutzerinterface Tempomat Speedtronic Copyright Daimler AG 1 Ein Hebel auf der linken Seite des Lenkrads ist f r die Tempomat bzw Speedtronic Steuerung zust ndig 1 Hebel kann in Pfeilrichtung nach oben bewegt werden 2 Hebel kann in Pfeilricht
133. UilnputValue Signal _ d 0 UiOutputValue Signal T Userlnterface gt EN Deren mn ua UilnputValue UiOutputValue WheelRPMSensor DR ET EP a gt Instrument __ p PRERE ON A VEES gt CruiseController Cluster ControlValue IndicatorValue Lever _ Hessens 000000000 fernen gt Speedindicator 2 2 Designmodell 1 aaa sea Optimierungskriterium Wiederverwendung Reuse Werden die Input Output Daten des User Interfaces ber einen Nein Datenbus zur Verf gung gestellt DE2Sig 235 SL EEE Sollen die angezeigten Werte durch einen Dekorierer aufbereitet Ja werden Namen der konkreten View Dekorierer NumberDecorator Ist die Klasse InstrumentC uster_Controller zustandsbehaftet Observer Observer update i Lever manipulate Lever display u _InstrumentCluster_Controller InstrumentCluster_ Controller initialize handleEvent _InstrumentCluster_Controller _InstrumentCluster_Controller Speedindicator SpeediIndicator manipulate display a N gt _InstrumentCluster_ Model _InstrumentCluster_Model Speedindidator 1 _InstrumentCluster_ Model
134. Valuetui UiOutputValuetui IndicatorValue ConcreteDataHolder modelRep Daten von einem Datenbus lesen und schreiben UserQuestion Werden die Input Output Daten des User Interfaces ber einen Datenbus zur Verf gung gestellt DE2Sig false Bus Template DataBus 234 Reuse modelRep Blackboard ConcreteClient ur SOUrCer lin Drain ui Source remote tui Drain remote ConcreteSubject Bus_ ui UiInputValuet Bus_ ui UiOutputValue ConcreteData ious Modell Darstellung und Steuerung der User Interfaces in separaten Objekten kapseln Template ModelViewContr ui UserInterface Model Model Wi Indieetor ul Ccontreol View Dielserimrerrzee o ler i Coneroliler Sie Daten fiir die Darstellung aufbereiten OptimCriteria Reuse AND UserQuestion Sollen die angezeigten Werte durch einen Dekorierer aufbereitet werden false Decor Template Decorator AbstractView Component mvc View ConcreteComponent ViewDecorator Decorator getNames Namen der konkreten View Dekorierer 1 ConcreteDecorator display Operation viewDecorator Zustandsbehaftetes Verhalten des Controllers unterst tzen makeStates mvc Controller 2 Beispiel 2 1 Analysemodell UserlInterface Class i 0 Indicator Class c 0 Control Class i 0 IndicatorValue Signal c 0 ControlValue Signal s 0 Source Class d 0 Drain Class s 0
135. Werkzeugherstellern nach der Verabschiedung gelingen eine in der Dom ne akzeptierte Darstellung zu finden ist in Zukunft die Nutzung der UML f r die Modellierung der technischen Systemarchitektur denkbar 49 3 Stand der Technik 3 2 2 Die ROPES Methode Rapid Object Oriented Process for Embedded Systems ROPES Douglass 99 Douglass 04 ist eine objektorientierte Entwicklungsmethode die speziell fur eingebettete Systeme mit Echt zeitanforderungen konzipiert ist Sie soll sich auch fur Projekte mit hohem Systementwicklungs anteil eignen bei denen neben der Softwareentwicklung weitere Ingenieurdisziplinen in einen Gesamtprozess integriert werden mussen Als Beispiele werden von dem Autor der Flugzeug und Automobilbau genannt 3 2 2 a Prozessmodell Als Methode umfasst ROPES die Festlegung einer Modellierungssprache und die Beschreibung eines Entwicklungsprozesses der die Verwendung der in der Modellierungssprache enthaltenen Modellelemente beschreibt Als Modellierungssprache kommt die UML zum Einsatz siehe Kapitel 3 2 1 bei dem Entwicklungsprozess handelt es sich im Kern um ein Spiralmodell t Jahre m nn Key Concepts Secondary Concepts Design Concepts Macrocycle Deployment and Optimisation _ 4 6 zen 3 NR R z ys 5 10 60 Minuten Abbildung 3 17 Entwicklungszyklen nach ROPES Douglass 04 Abbildung 3 17 zeigt die drei Zeitachsen des ROPES Standardprozesses Die Makroebene l
136. Zielmodells auf der Basis eines Quellmodells wird allgemein als Modelltransformation bezeichnet siehe Kapitel 3 3 Wenn in allen Entwicklungsphasen Modelle verwendet werden 27 3 Stand der Technik und diese automatisiert Informationen austauschen bzw wiederverwenden spricht man auch von einem durchgangig modellbasierten Entwicklungsprozess Modellbasierte Ans tze gibt es sowohl in der System als auch in der Softwareentwicklung siehe Kapitel 3 1 3 b und 3 1 3 c Wenn es gelingt die Modelle dieser beiden Bereiche zu sammenzuf hren kann von einem durchg ngigen modellbasierten Entwicklungsprozess nach dem oben beschriebenen Verst ndnis gesprochen werden 3 1 3 a Metamodelle Eine wichtige Rolle bei der Herstellung eines durchg ngig modellbasierten Entwicklungs prozesses spielen Metamodelle Ein Metamodell ist eine Definition einer Modellierungssprache also ein Modell das ein Modell beschreibt Um festzulegen wie solche Metamodelle aufgebaut sein d rfen kann f r sie wiederum ein Metamodell entwickelt werden das dann als Metametamode bezeichnet wird Im Allgemeinen wird gefordert dass ein solches Metametamodell sich selbst definiert und nicht wieder auf ein Metamodell zur ckgreift Prinzipiell kann der Vorgang der Metaisierung jedoch beliebig oft wiederholt werden Die hier besprochenen Konzepte und Standards stammen aus dem Umfeld modellbasierter Softwareent wicklung werden aber auch f r Metamodelle der Systemen
137. a Richard Helm Ralph John son und John Vlissides Gamma et al 95 oft als Gang of Four GoF bezeichnet Die 23 Designmuster auch als Entwurfsmuster bezeichnet die in diesem Buch beschrieben sind besitzen heute noch einen hohen Bekanntheitsgrad und sind Grundlage zahlreicher weiterer Arbeiten Der Erfolg der Designmuster hat viele Autoren zur Entwicklung weiterer Musterarten inspiriert H ufig werden die verf gbaren Musterarten in folgende Hauptkategorien unterteilt z B Yacoub et al 04 Douglass 02 e Analysemuster beschreiben f r einen wiederholt anzutreffenden Sachverhalt einer Dom ne eine L sungsvorlage um diesen in einem Analysemodell zu erfassen Fowler beschreibt Ana lysemuster als eine Idee die in einem praktischen Kontext hilfreich war und dies wahr scheinlich auch in einem anderen sein k nnte Fowler 97 Beispielmuster sind Account Accounting Transaction oder Measurement In der ROPES Methode siehe Kapitel 3 2 2 sind Analysemuster nicht explizit Teil der Methode passen aber zur Phase Object Analys s e Architekturmuster beschreiben wiederkehrende grunds tzliche Organisationsprinzipien f r die Architektur einer Softwareanwendung Nach Buschmann et al dr cken sie fundamentale strukturelle Organisationsschemata f r Softwaresysteme aus Sie liefern eine 69 3 Stand der Technik Menge vordefinierter Subsysteme spezifizieren deren Verantwortlichkeiten und beinhalten Regeln und R
138. ackValueSource description The FeedbackvalueSource parameter requires values of type Class Abbildung 3 42 Alternativen f r die Zuweisung der Musterparameter Mit der Best tigung des Dialogs werden die gemachten Zuordnungen als Musterbindung im Modell abgelegt und der Vorgang der Expansion gestartet Darunter wird das Ersetzen der formalen Parameter durch die tats chlichen Parameter in der Musterstruktur und die an schlie ende Verschmelzung mit dem Zielmodell verstanden Abbildung 3 43 zeigt das an gewendete Muster in der Diagramm Darstellung Die Musterinstanz ist als Ellipse dargestellt ClosedLoopControl_CruiseControl Diese ist ber eine spezielle Abh ngigkeitsbeziehung Stereotyp lt lt bind gt gt mit dem Mustertyp verbunden ClosedLoopControl Oberhalb des Pfeils ist die Parameterzuordnung zu sehen Unterhalb der Ellipsen befindet sich die expandierte Struktur des Musters in der die formalen Parameter durch die tats chlichen Parameter ersetzt sind Uber das Kontextmen der Musterinstanz ClosedLoopControl_CruiseControl kann das Muster jederzeit neu expandiert werden Die Dialoge aus Abbildung 3 42 und Abbildung 3 43 sind in diesem Fall mit der alten Bindung vorbelegt und m ssen nicht noch mal neu ausgef llt werden Dies kann z B notwendig werden wenn Elemente aus der Musterinstanz gel scht oder ge ndert wurden oder sich die Musterdefinition selbst ge ndert hat ber den Ve
139. ahrzeugs modellieren lasst Die Hardware Architecture der EAST ADL ist hier wesentlich ausdrucksstarker da sie eigene Metaklassen f r Sensoren Aktuatoren Bussysteme einfache elektrische Verbindungen und vieles mehr definiert Im Rahmen der Analyse der Softwareanforderungen sieht der Kernprozess kein besonderes Artefakt vor Im Falle der EAST ADL k nnen die zu betrachtenden Inhalte der bereits in der Systementwicklung modellierten Functional Analysis Architecture entnommen werden Bei ROPES wird f r diese Phase mit dem Object Analysis Model ein eigenes Modell erstellt Bei der Spezifikation der Softwarearchitektur ist der modellierte Umfang hnlich wobei die Modelle der EAST ADL von der Existenz der EAST Laufzeitumgebung ausgehen und sich auf deren Basis dienste st tzen insbesondere Kommunikationsdienst und Zugriff auf I O der Hardware Einen solch festen Bezug zur Laufzeitumgebung gibt es bei ROPES nicht F r die Modellierung der Struktur des Innenlebens einer Softwarekomponente stellt die EAST ADL keine Artefakte zur Verf gung Die Designoptimierung und Implementierung einer Soft warekomponente ist somit auf Basis der Modelle der EAST ADL nicht m glich Die im Rahmen von ROPES verwendeten Modelle legen hier wiederum einen Schwerpunkt Insgesamt l sst sich festhalten dass ROPES f r die systementwicklungsrelevanten Artefakte keine bestimmten Modelle vorschreibt und auch f r Architekturbeschreibungssprachen wie die EAST ADL off
140. alen Para meter durch tats chliche Parameter ersetzt Da die Modellierung von dynamischen Aspekten aber nicht zu dem Schwerpunkt dieser Arbeit geh rt siehe Kapitel 1 3 wird dieser Teil nicht naher erlautert Instanziierung von Mustern Abbildung 3 41 zeigt den Dialog mit dem eine Bindung des Musters angelegt wird Zu sehen sind unter anderem alle formalen Parameter denen nun tats chliche Parameter zugewiesen werden m ssen Dar ber hinaus m ssen der Root Context Expansion Location und der Zielort f r die Abspeicherung der Bindung Bind Location angegeben werden 4 Apply Closed_LoopControl ClosedLoopControl Pattern aan ata a ee Lo ur Short description of ClosedLoopControl goes here Patte rns 1 8 Pattern Description Detailed description of ClosedLoopControl goes here 4 Parameter Information Argument Values Reference alue Signal DesiredSpeed ee E CruiseController Feedbackv alue Signal CurrentSpeed Lontrolbutpukvalue Signal Throttlevalue ReferenceValueSource Class Lever Controloutput alueDrain Class Throttle P FeedbackValueSource Class SpeedSensor ClosedLoopController Description The ClosedLoopController parameter requires a value of type Class ey Location Information Expansion Location POTAC_PatternLib 4nalysis ClosedLoopControl Example cat Bind Location POTAD Patternlib 4nalysis ClosedLoopControl Example a Apply Cancel Abbildung 3 41 Insta
141. als Klassendiagramm modelliert wird Trotz der Beschr nkung des Ansatzes auf Klassenmodelle ist nach Ansicht der Autoren durch ein Mapping der Klassen auf UML oder MOF Metaklassen auch ein Einsatz f r die MDA m glich Braun et al 03b An einer Werkzeugunterst tzung f r den Ansatz wird momentan noch gearbeitet Ein dezidierter Mechanismus f r Verfolgbarkeit und Variabilit t wird nicht beschrieben 126 Modelltransformationen Nutzung von Attributgrammatiken Der in Dehayni et al 03 vorgestellte Ansatz schl gt f r die Realisierung von Modelltrans formationen die Nutzung von Attributgrammatiken vor In der vorgestellten L sung m ssen alle Modelle bzw Metamodelle in ein textuelles Format berf hrt werden Im Falle von MOF basierten Modellen wird dabei auf die ebenfalls von der OMG standardisierte Sprache HUTN Human Usable Textual Notation zur ckgegriffen die eine textuelle Repr sentation von MOF Modellen bietet Die einzelnen Konzepte aus dem Quell Metamodell werden als Nichtterminale der Attributgrammatik dargestellt die zus tzliche auf das Ziel Metamodell bezogene Attribute enthalten Die eigentliche Transformationslogik wird in den Berechnungsvorschriften semantischen Regeln der Attributgrammatik definiert die f r jede Produktion bei der Traversierung des Quellsyntaxbaumes ausgef hrt werden Das Zielmodell liegt dann ebenfalls in HUTN in einem Attribut des Wurzelknotens dieses Syntaxbaumes vor Als Vorteil
142. angelehnt an IESE c 3 1 3 b Modellbildung in der Systementwicklung Die ersten elektronischen Systeme im Fahrzeug waren relativ autonom und konnten daher auch weitgehend isoliert entwickelt werden Die E E Systementwicklung beschr nkte sich daher auf Fragen wie Bauraum oder Verkabelung Mit der Einf hrung von Bussystemen wie z B CAN erweiterte sich das Aufgabengebiet auf die Festlegung der Netzwerktopologie und die Definition der Kommunikationsmatrix beschreibt f r jeden Netzknoten die ein und ausgehenden Nach richten Aufgrund der noch relativ geringen Bedeutung der Systementwicklung war die Modellbildung im Bereich der Automobilindustrie daher wenig standardisiert abgesehen von einigen wenigen Dateiformaten f r die Kommunikationsmatrix Mit dem in der Einleitung aufgezeigten Trend die einzelnen Funktionen auch funktional ber mehrere Steuerger te hinweg zu vernetzen hat die Notwendigkeit einer formalisierten und standardisierten Modellbildung jedoch zugenommen Es gibt daher einige Initiativen die versuchen die Artefakte der unterschiedlichen Fach disziplinen aus dem Kernprozess zu formalisieren und deren Zusammenhang zu beschreiben Ziel ist ein Metamodell f r den gesamten Kernprozess das f r jedes Artefakt die zul ssigen Modellierungselemente der Fachdisziplin beschreibt und festlegt wie diese mit den Modellierungselementen anderer Fachdisziplinen in Beziehung gebracht werden k nnen Diese als Mappings bezeichneten Verkn
143. angezeigt werden Diese k nnen wiederum die An wendung eines Musters auf der PIM Ebene markieren so dass eine Mapping Regel in diesem Fall die Abbildung zwischen zwei Mustern beschreibt Eine Mapping Spezifikation wird mit Hilfe einer Mapping Sprache Mapping Language spezi fiziert Der MDA Guide beschreibt keine konkrete Mapping Language verweist allerdings auf die oben genannten Konzepte und den lancierten RFP MOF Query View Transformation 111 3 Stand der Technik OMG 02b siehe Kapitel 3 3 3 der eine entsprechende Realisierungstechnologie zum Ziel hat Neben den verschiedenen Mapping Ansatzen werden noch einige Merkmale konzeptionell be schrieben die Transformationsmechanismen grunds tzlich erf llen sollen Ein solches Merkmal ist die Aufzeichnung einer Transformation Record of Transformation Diese Aufzeichnung soll festhalten welche PSM Elemente aus welchen PIM Elementen hervorgegangen sind und auf diese Weise eine Verfolgbarkeit der PIM Elemente in nachgelagerte Modelle unterst tzten Weitere Angaben werden zu m glichen Eingabedaten einer Transformation gemacht Neben dem PIM evtl versehen mit Marks und dem Plattformmodell werden noch Zusatz informationen Additional Information als m gliche Eingabe einer Transformation vor geschlagen Diese k nnen nach der Vorstellung der OMG z B Designentscheidungen Technical Choices des Architekten oder die Angabe von Qualit tsanforderungen Quality Reguriements u
144. angs zwischen Modellen der System und Softwareentwicklung und liefert somit auch eine Grundlage f r den gesuchten Modelltrans formationsmechanismus Auf Basis der bisherigen Erkenntnisse und Festlegungen erscheint nun das in Abbildung 3 50 illustrativ gezeigte Grobkonzept sinnvoll Die Systementwicklung bergibt die logische und technische Systemarchitektur in Form eines wie Kapitel 3 1 3 b beschriebenen Modells an die Softwareentwicklung Die Softwareentwicklung berf hrt die logische Systemarchitektur in das Analysis Object Strutural Model und reichert es auf der Basis von Templates mit Analyse mustern an Eine Modelltransformation berf hrt dieses Modell in ein neues Modell dass ein Ger st f r das Mechanistic Design Object Model darstellt und auf eine Standardarchitektur abgestimmt ist Die ebenfalls erzeugten Verfolgbarkeitslinks verkn pfen Elemente des Quell 106 Softwareentwicklung modells mit resultierenden Elementen im Zielmodell Das Transformationsergebnis ist abhangig von der technischen Systemarchitektur und Designparametern die wahrend der Transformation abgefragt werden Entsprechend der erlauterten Systematik sucht die Transformation nach Analysemustern im Quellmodell in Form von gebundenen Templates und instanziiert mit Hilfe von Regeln Designmuster im Zielmodell durch die Bindung von Templates Logische Systemarchitektur EAST ADL Y Analysis Object Structural Model UML Klassenmodell Analysemus
145. arema nahmen erfordern m ssen sie bereits in der Systementwicklung ber cksichtigt werden Eine berwachungsfunktion untergliedert sich in eine Fehlererkennungs und eine Fehler behandlungsfunktion Dabei kommen z B folgende Verfahren zu Einsatz Schauffele et al 03 e Fehlererkennungsfunktionen e Beobachten von physikalischen Eigenschaften 201 e Referenzwertuberprufung e Uberpriifung anhand redundanter Werte e berpr fung der Datenintegritat z B CRC Hemming Codes e Senden von Bestatigungen e Beobachtung des zeitlichen Ablaufs Watchdog e Fehlerbehandlungsfunktionen e Verwendung redundanter Werte e Fehlerbeseitigung durch Reset e Zustandswechsel z B Notlauf e Fehlerspeicherung Die unterschiedlichen Verfahren f r Fehlererkennung und behandlung k nnen zu unterschied lichen Uberwachungskonzepten kombiniert werden Die Strukturen der entsprechenden Muster unterscheiden sich leicht Das hier beschriebene Muster DetectorCorrector Actuator wurde als ein repr sentatives Beispiel f r eine Uberwachungsfunktion aus dieser Gruppe gew hlt Es berpr ft physikalische Eigenschaften eines Aktuators mit Hilfe eines zus tzlichen Sensors Das berwachungssystem wird durch drei Klassen beschrieben e Detector Die Fehlererkennung e LocalFaultHandler Implementiert die lokale Sicherheitslogik und koordiniert gegebenenfalls die lokale mit einer globalen Fehlerbehandlung siehe Muster Fau tHandler e Corrector Set
146. aschinenlesbare Anfrage an eine externe Informationsquelle gestellt die ein Array aus Strings zur ckliefert Mit dieser Abfrage werden insbesondere die Modelle der technischen Systemarchitektur abgefragt Die Syntax von Anfrage kann implementierungsspezifisch fest gelegt werden F r die kontextabh ngige Formulierung von Fragen bei Benutzerr ckfragen oder bei der Auf forderung zur Namenseingabe ist auch die Konkatenation von Strings sinnvoll Daf r wurde das Zeichen vorgesehen um z B Fragen der Art Name der Zustandsklasse f r lt Variablenname gt zu formulieren 4 3 3 b Grammatik in EBNF Die textuelle Syntax der Transformationssprache wird im Folgenden in EBNF ISO IEC 98 dargestellt Dabei wird die h ufig in der Literatur zu findende Variante der EBNF verwendet in der Terminalsymbole in einfache Hochkommata eingefasst optionale Ausdr cke mit einem nachgestellten Fragezeichen und beliebig oft vorkommende Ausdr cke mit einem nachgestellten Sternsymbol gekennzeichnet werden Die Basissymbole Stringliterale Ganzzahlen und Variablenbezeichner sind hier im Sinne der bersichtlichkeit nur informell beschrieben lt eratoral ee Erler dene Ws rm an ee lt lhs gt Template lt ident gt lt ident gt lt paramlist gt lt paramlist gt lt ident gt lt rhs gt ee ee e e else Selen Sexpnessione I cons i lt condexp gt lt expression gt lt expression gt eendieion a Fender me
147. ateLocalCorrectiveAction an an Handler PowertrainFaultHandler FaultHandler_ChassisPowertrain TE PRI EEI IOI IIIA A NE O DE ER ET TEE BEE LITER TRITT RL SE FaultHandler Re re Be BT ar ee GlobaleFaultld cd i GlobaleFaultid APENRE NTN gt PowertrainFaultHandler PEERI EEE EE ENEE ce PAATI LIOI IEL EF ESEE E ELTETT TEB ON EEES PENRAN OIOI AEL EIIE P EEEE E na se UTTER EEEE eA gt EEE ChangeStateT o 2 2 Designmodell Optimierungskriterium wird in dieser Regel nicht ber cksichtigt Namen der Klassen die einen Fehler erzeugt PowertrainFunction ChassisFunction ExceptionRecord PowertrainFunction a a i i ingExL i lt a ChassisFaultHandler Sala ernten u eepben 9 Erg ExceptionSafeClass ceptionLog get_GlobalExceptionHandl 0 1 uniquelnstance ExceptionLog 0 getUniquelnstance _ ExceptionLog un PowertrainFaultHandler _ExceptionSafeClass _ExdeptionSafeClass PowertrainFaultHandler_ ee one Za CODAE CEHO N ANUE GobalExceptionHandler Exception 0 1 PowertrainFaultHandler uniquelnstance GlobalExce severity String ExceptionHandler _ _GlobalExceptionHandler Exception D Integer 0 1 get_GlobalExceptionHandler _GlobalExceptionHandler 0 1 getUniquelnstance GlobalExceptionHandler
148. atik keine geeignete operationale Semantik definieren nur Uberblicksartig im Kapitel 3 3 5 erwahnt 3 3 4 a J Whittle Framework auf Basis von Maude In Whittle 02 wird ein Ansatz pr sentiert der Elemente eines UML Klassenmodells in einer Faktenbasis hinterlegt und auf dieser Basis mit Hilfe eines Frameworks in der logischen Programmiersprache Maude Modelltransformationen realisiert Bei den Modellelementen be schr nkt sich der Beitrag auf Klassen Assoziationen und Constraints die etwa in der Form class Klassenname Attribute Operationen in der Faktenbasis repr sentiert werden Die Trans formationsregeln bestehen aus einer linken und einer rechten Seite und werden so interpretiert dass jeder Teil eines Modells der mit der linken Seite in Einklang gebracht werden kann unter der entsprechenden Belegung der Variablen durch die rechte Seite ersetzt wird Das in dem Beitrag beschriebene Beispiel besch ftigt sich mit einer Transformation die zeigt dass ein Klassendiagramm ein Refactoring eines anderen Klassendiagramms ist Unter Re factoring wird hierbei eine Struktur nderung des Klassendiagramms aus Designoptimierungs gr nden verstanden wobei das Verhalten nicht ge ndert wird Der Einsatzzweck des Ansatzes ist schwerpunktm ig bei der Optimierung von Modellen und der Konsistenzpr fung zu sehen Die Transformation ist in dem beschriebenen Stand nur teilweise automatisiert da die einzelnen Regeln manuell in einer bestimmten
149. aus dem Analysemodell die Klasse CruiseAlgorithmLong erf llt Zu sehen ist wie ber Musterbindungen und deren Verkn pfung in das Analysemodell navigiert wird und auf diese Weise festgestellt werden kann dass CruiseAlgorithmLong zur Implementierung des Reglers CruiseController beitr gt 103 3 Stand der Technik ReferenceValue Signal ClosedLoopController Class FeedbackValue Signal ControlOutputValue Signal ReferenceValueSource Class ControlOutputValueDrain Class FeedbackValueSource Class E Bee CruiseController A ClosedLoopControl Mc p bind Feedback Value CurrentSpeed ControlOutputValue T hrottleS et Value ReferenceValueS ource S peedAdjustingLever Control OutputValueDrain Throttle FeedbackValueS ource Speed Sensor ReferenceValue DesiredS peed R CruiseController R bind Bind ControlLoop CruiseController_ControlLoop Sensor S peed AdjustingLever SpeedSensor Actuator Throttle Sensor_get Method getDesiredSpeed getCurrentSpeed Actuator_set Meteo setThrottleS etValue Context CruiseController_ Master bind Bind MonitoredChannel CruiseController_ Master Watchdog Watchdog bind Bind AbstractAlgorithm ern Rote ee Concrete Algorithm Long A x Short algorithm R Interface cruise Context t ruiseController _ControlLoop Abbildung 3 49 Verfolgbarkeit durch Verkn pfung
150. awka Thomas Automotive Software Engineering Vieweg 2003 Sendall et al 03a Sendall S Kozaczynski W Model Transformation The Heart and Soul of Model Driven Software Development EEE Software Ausgabe 20 2003a S 42 45 URL http cui unige ch sendall files sendall tech report EPFL model trans pdf Sendall et al 03b Sendall S Perrouin G Guelfi N Biberstein O Supporting Model to Model Transformations The VMT Approach In Rensink A Hrsg Ausgabe CTIT Technical Report University of Twente 2003b S 61 72 URL http trese cs utwente nl mdafa2003 proceedings pdf Stevens et al 98 Stevens Richard Brook Peter Jackson Ken Arnold Stuart Systems Engineering Coping with Complexity Prentince Hall 1998 The Mathworks 04 The Mathworks Simulink 6 Simulation and model based design 2004 URL https tagteamdbserver mathworks com ttserverroot Download 20594_SL_9320v05 pdf W3C 05 World Wide Web Consortium W3C XSL Transformations XSLT Version 2 0 In Kay M Hrsg W3C Working Draft 2005 URL http www w3 org TR xslt20 Welch et al 02 Welch Lonnie R Marinucci Toni Dynamic Resource Management Architecture Patterns PLoP 2002 Proceedings 2002 URL http jerry cs uiuc edu plop plop2002 final RM_patterns pdf Whittle 02 Whittle J Transformations and Software Modeling Languages Automating Transformations in UML n J z quel J M Hussmann H Cook S Hrs
151. ben Ein Muster wird konkret mit folgendem Schema erfasst e Name Ein aus einem Wort bestehender Bezeichner der den Mustertyp innerhalb des Katalogs und der Transformationsregeln eindeutig identifiziert e Zweck Fasst in einem Satz den Inhalt des Musters unter Verwendung fachspezifischer Kernbegriffe zusammen e Motivation Beschreibung des Fachkonzepts das durch das Muster modelliert wird in der dom nenspezifischen Fachsprache blicherweise werden Beispiele genannt und auf weitere Arbeiten und Standards verwiesen e Struktur und Informationsfluss beschreibt die L sung des Musters in Form eines Templates siehe Kapitel 4 2 1 unter Verwendung der in Kapitel 4 2 2 gezeigten Notation Ein Template umfasst bei Analysemustern ein Modell aus Klassen die ber Signale mit einander kommunizieren Einzelne Klassen und oder Signale k nnen als Template Parameter ausgewiesen sein Bei dem dargestellten Diagramm werden die Signal beziehungen entsprechend der in Kapitel 3 2 1 c getroffenen Konvention in Form von Information Flows modelliert F r jedes Template Element werden in einem Satz die Auf gabe und der Informationsaustausch mit anderen Template Elementen erlautert e Beispiel Ein Diagramm mit erlauterndem Text das eine Instanz des Musters f r ein Bei spiel enthalt e Anwendbare Designmuster Eine Liste von Designmustern die bei der Realisierung dieses Analysemusters zum Einsatz kommen k nnen In Klammern wird vermer
152. bene Systematik zu Evaluierungs zwecken auf Basis der Ans tze QVT und EXMOF f r das ebenfalls in diesem Kapitel be schriebene Beispiel zu gro en Teilen umgesetzt Da die Realisierung der fehlenden An forderungen mit Bordmitteln zu sehr umfangreichen und verschachtelten Transformationsregeln f hrt bzw teilweise berhaupt nicht m glich erscheint kommt die Arbeit zu dem Ergebnis dass sich die Systematik aus Kapitel 3 2 4 8 mit diesen Ans tzen f r eine praktische Nutzung nicht geeignet umsetzten l sst 3 3 7 Zwischenergebnis Die Fragestellung dieses Kapitel leitet sich aus der in Kapitel 3 2 5 er ffneten Suche nach einem Modelltransformationsmechanismus ab der die dort gesammelten Anforderungen erf llt Zun chst wurde diesem Thema mit der Untersuchung der Model Driven Architecture MDA in Kapitel 3 3 1 ein Rahmen gesetzt Hierbei handelt es sich um einen Ansatz f r modellgetriebene Softwareentwicklung der viele Konzepte rund um Modelltransformationen skizziert und viele Begriffe in diesem Umfeld gepr gt hat Die Untersuchungen haben ergeben dass die MDA Konzepte zu der hier angestrebten Integration von System und Softwaremodellen passen So lasst sich der Systembegriff der MDA auf elektronische Systeme im Fahrzeug bertragen und die verlangte Formalisierung f r die beteiligten Modelle ist gegeben Mit Verfolgbarkeitsinformationen und den Trans formationsparameter werden hier zudem zwei Punkte ber cksichtigt die bereits in
153. benenfalls der Name eines mengenwertigen Parameters gekennzeichnet ber den iteriert werden soll Bei Belegung des gekennzeichneten Parameters mit einer Menge wird das Muster dann f r jedes Element aus dieser Menge einzeln erzeugt CondParamBinding Conditional Parameter Binding Bezieht sich auf die Erzeugung einer Template Instanz TemplateInstantiation und steht fur eine bedingte Belegung von Parametern Beinhaltet eine Bedingung Condition sowie jeweils ein TemplateParameterSubstitution f r die beiden m glichen F lle ElementInstruction Stellt eine mogliche Variante einer Expression dar und kennzeichnet eine Operation die sich auf eine Menge von Designmodellelementen Element aus dem UML Metamodell bezieht Zu beachten ist dass die ElementInstruction nur Elemente im Designmodell betrifft Somit kommen als m gliche Elemente Klassen Class Operationen Operation Attribute Property Assoziationen Association Vererbungsbeziehungen Generalization und Realisierungs beziehungen Realization in Frage Die Klasse dient als Abstraktion f r die konkreten Operationen CreateElement und DeleteElement CreateElement Steht f r eine Operation die die assoziierte Menge von Modellelementen im Designmodell erzeugt DeleteElement Steht f r eine Operation die die assoziierte Menge von Modellelementen im Designmodell l scht RuleAppliance Stellt eine m gliche Variante einer Expression dar und kennzeichnet den Aufruf ein
154. bereits durch das Template Repository angelegt und wird daher wiederverwendet Allerdings entstehen neue Vererbungs beziehungen zu den abstrakten Klassen Subscriber_ 178 Beispiel Das Muster Strategy wird in Abhangigkeit des Optimierungskriteriums Reuse und einer Be nutzerr ckfrage instanziiert OptimCriteria Reuse AND UserQuestion M ssen alternative Regelstrategien verwendet werden false strat Template Strategy clloop Cont rol oop C Ae OMee ae cl ClosedLoopController Strategy Strategy getNames Namen der alternative Regelalgorithmen 1 ConcreteStrategy getNames Interface Name des Regelalgorithmus 1 AlgorithmInterface I Cont rolserat Das zweite Argument false ist der Default Wert Mit dem dritten Argument strat wird eine Variable deklariert Uber die die Antwort im spateren Verlauf der Regel erneut ausgelesen werden kann Da sich die Parameter ConcreteStrategy und AlgorithmInterface nicht aus dem Analysemodell ableiten mussen Namen fur neu anzulegende Elemente vergeben werden Dies geschieht Uber getNames wobei im ersten Fall beliebig viele Elemente erzeugt werden zweites Argument ist 1 und im zweiten Fall genau ein Element erzeugt wird zweites Argument ist ok Wenn die UserQuestion mit Ja beantwortet wird und bei getNames f r ConcreteStrategy Comfort und Sport und f r AlgorithmInterface cruise eingegeben wird wird die Struktur von Strate
155. binden Hier kann aber offenbar kein Bezug zu ChannetElementen hergestellt werden so dass es z B nicht m glich ist einen Bus sp ter durch Pins und Leitungen detaillierter zu beschreiben Leitungen haben zudem keine Attribute e Platform Model Beschreibt das Betriebssystem OS Funktionen f r die Abstraktion der Hardware HAF und Funktionen der Middleware Diese Ebene ist stark durch die EAST Laufzeitumgebung gepragt siehe unten e Allocation Model Beschreibt die letztendliche Laufzeitarchitektur indem die bisherigen Artefakte verlinkt werden F r Prozessoren aus der Hardware Architecture werden OS Tasks gebildet denen C uster aus dem Function Instance Model zugewiesen werden Fur die Kommunikation zwischen Tasks werden Botschaften definiert die Signalinstanzen aus dem Function Instance Model enthalten Die Botschaften sind wiederum Channels z B vom Typ CAN aus der Hardware Architecture zugeordnet Zu den besonderen Merkmalen der EAST ADL geh rt ein Variantenmanagement mit dem es m glich ist durch das Setzen von Variationspunkten die Variabilit t eines Modellelements in Hinblick auf Variabilit tsdimensionen wie z B Baureihe Aufbau z B Limousine versus Kombi Ausstattungsumfang oder Markt z B USA versus Japan zu beschreiben Mit Hilfe weiterer Mechanismen die im Metamodell definiert sind soll es m glich sein die mit diesen Dimensionen verbundene Variabilit t ausgehend von den Anforderungen Vehicle View
156. bisher weder im In noch im Ausland in gleicher oder hnlicher Form einer Pr fungsbeh rde vorgelegt Ich bin darauf hingewiesen worden dass die Unrichtigkeit der vorstehenden Erkl rung als Tauschungsversuch angesehen wird und den erfolglosen Abbruch des Promotionsverfahrens zur Folge hat Ulm den 17 September 2007 265
157. bstractControlLoop Reuse inputRep RepositorytinputRep Repository Sensor Icl FeedbackValueSourcetcl ReferenceValueSource 225 cl ControlOutputValueDrain get cl FeedbackValuet get cl ReferenceValue set cl ControlOutputValue cl ClosedLoopController AbstractState getNames Namen der konkreten Zust nde 1 getNames Namen der konkreten Regelkreise 1 reacloop Wenn keine zustandbehaftetes Verhalten Template ControlLoop cl ClosedLoopController Master cl ClosedLoopController ControlLoop Reuse inputRep RepositorytinputRep Repository Actuator Sensor_getMethod Actuator_getMethod AbstractState ConcreteState Ju ConcreteControlLoop Context ControlLoop Sensor Icl FeedbackValueSourcetcl ReferenceValueSource cl ControlOutputValueDrain get cl FeedbackValuet get cl ReferenceValue set cl ControlOutputValue choos Den Regelungsalgorithmus austauschbar machen I Betrlabor Sensor_getMethod Actuator_getMethod OptimCriteria Reuse AND UserQuestion M ssen alternative Regelstrategien verwendet werden false Strat Die Struktur des Regelungsalgorithmus vorgeben Template Strategy Reactive reacloop AbstractControlLoop cloop ControlLoop cl ClosedLoopController Strategy getNames Namen der alternative Regelalgorithmen 1 getNames Interface Name des Regelalgorithmus 1 CONO Era Opt
158. ch die Anwendung des Singleton Musters von Gamma et al 95 kann sichergestellt werden dass es von einer Klasse nur eine Instanz gibt Dies wird dadurch erreicht dass die Klasse Singleton nur ber eine statische Klassenoperation getUniqueInstance instanziiert werden kann die die einzige Instanz der Klasse zur ckliefert Beim ersten Aufruf ruft diese Methode den privaten Konstruktor der Klasse auf und belegt das ebenfalls private Klassen attribut uniqueinstance mit der erzeugten Instanz Bei weiteren Aufrufen liefert die Operation getUniqueInstance nur noch die gespeicherte Instanz zur ck Das Muster wird vor allem f r globale Behandlungsmechanismen siehe z B ExceptionMonitor oder Diensten verwendet 15 State 15 1 Zweck Verhalten f r unterschiedliche Zust nde in eigenen Objekten kapseln 15 2 Struktur Context State currentState State 1 call operation operation Context Class State Class 1 ConcreteState 1 Class ConcreteState ___1 operation Operation State en en 2 operation 15 3 Erlauterung Das State Muster von Gamma et al 95 erm glicht die Realisierung einer oder mehrerer Operationen in Abh ngigkeit verschiedener Zust nde eines Objekts Eine Kontextklasse Context assoziiert eine Menge von Zust nden State wobei sie sich den aktuellen Zustand merkt Attribut curren
159. ch die EAST ADL geschlossen werden Bezogen auf die Problemstellung dieser Arbeit ergibt sich damit Folgendes Durch die Kombination aus EAST ADL und ROPES stehen sowohl f r System und Softwareentwicklung detaillierte Modelle zur Verf gung so dass der Kernprozess weitergehend modellbasiert gestaltet werden kann Wie die Modelle methodisch integriert werden k nnen ist noch ungekl rt Insbesondere bei der Frage des Zusammenhangs der Modelle zwischen System und Softwareentwicklung ergeben sich keine neuen Erkenntnisse Die weiteren Untersuchungen dieser Arbeit gehen von einer aus EAST ADL und ROPES UML kombinierten Modelllandschaft aus und fokussieren sich auf die Entwicklungsaktivit ten die zwischen einer vollendeten Functional Analysis Architecture und der Fertigstellung des Design Object Models anzusiedeln sind Das Object Analysis Model soll in einer angepassten Form die Inhalte der functional Analys s Architecture weitgehend bernehmen Die in der Problem stellung angedachte Modelltransformation soll ROPES dahingehend erweitern dass das Design Object Model automatisiert aus dem Object Analysis Model abgeleitet werden kann Dies soll unter einer m glichst breiten Ausnutzung der in den EAST ADL Modellen festgehaltenen Informationen bzgl der technischen Systemarchitektur geschehen Eine Konvertierung der technischen Systemarchitektur in UML Verteilungsdiagramme wird nicht f r sinnvoll erachtet da die hierzu notwendige Festlegung eines P
160. ch realisiert wird Mit diesem Konzept sollen Komponenten wiederverwendbar werden und flexibel im Fahr 32 Systementwicklung zeug auf unterschiedliche Steuergerate verteilt werden konnen Die Spezifikation der dazu notigen Laufzeitumgebung wurde ebenfalls im Projekt EAST EEA begonnen und wird im Projekt Autosar siehe unten fortgef hrt Die Modelle der EAST ADL haben die Entwicklung der E E Architektur des Gesamtfahrzeugs im Blick und passen somit zum Betrachtungsrahmen der Systementwicklung Tabelle 3 5 ordnet einige Elemente aus dem Metamodell der EAST ADL den in Tabelle 3 1 Tabelle 3 3 definierten Inhalten der Systementwicklung zu Die Elemente f r die Inhalte der logischen und technischen Systemarchitektur stammen berwiegend aus den Artefakten Functional Analysis Architecture und Hardware Architecture Inhalt nach Kernprozess M gliche Elemente der EAST ADL siehe Tabelle 3 1 Tabelle 3 3 Funktionsnetzwerk Analys sfunction FunctionalDevice FunctionPort Abstrakte Daten l DesignData Type ConnectorSignal Schnittstellen SignalFunctionPort SignalFunctionPort nterface Attribute Period und TransferTime von FunctionPort E E Komponenten ECU Sensor Actuator 2 mee LEN Processor Memory Peripheral gerateaufbau 3 Kommunikations Fine verbindungen Signallnstance Frame 5 Leistungsver sorgung Ei Tr Pin Wie Fahrzeugtopologie Kette Ana ysisFunction ElementarySoftwareFunction Functioninstance L
161. ch sein k nnen aber unterschiedliche Klassenmodelle als L sung enthalten Der Austausch von Designmusterkatalogen wird z B genutzt um das Design f r unterschiedliche Plattformen zu optimieren siehe Kapitel 6 2 Die Instanziierung eines Designmusters kann durch einen entsprechenden Ausdruck in der Transformationsregel abh ngig von Zusatzinformationen gemacht werden Eine Zusatz information kann ein G obales Optimierungskriterium oder eine Abfrage sein Mit dem globalen Optimierungskriterium wird festgelegt in welche Richtung das Design optimiert werden soll Entsprechend der Festlegung aus Kapitel 3 2 4 8 kann bei dem Start einer Transformation zwischen folgenden Alternativen gew hlt werden 1 Laufzeit 2 Speicherverbrauch 3 Sicherheit und Verf gbarkeit 4 Wartbarkeit Portabilit t Erweiterbarkeit Wiederverwendung Abfragen dienen dagegen zur lokalen Designoptimierung Sie werden bei einzelnen Musterinstanziierungen verwendet um z B die technische Systemarchitektur abzufragen oder sonstige Fragen f r die Instanziierung zu kl ren die durch das globale Optimierungskriterium offen bleiben Abfragen unterteilen sich in maschinelle Abfragen und Benutzerabfragen Maschinelle Abfragen werden durch einen Interpreter ausgef hrt und k nnen z B dazu genutzt werden die EAST ADL Modelle abzufragen Damit k nnte folgende f r das Design relevante Frage beantwortet werden Wird das Signal ber einen diskret angeschlossene
162. che Schnittstelle lesen und schreiben ControlLoop Den Algorithmus einer Regelung Steuerung in einem Objekt kapseln 214 DataBus Den Zugriff auf einen Datenbus in einer ein heitlichen Objektstruktur kapseln Ein Objekt um Zust ndigkeiten erweitern ExceptionMonitor Fehler auf der Ebene einer Objektkollaboration erkennen und behandeln HeterogeneousRedund Heterogene Redundanz in einem Objektmodell abbilden 215 HomogeneousRedund Homogene Redundanz in einem Objektmodell ancy abbilden Model View Modell Darstellung und Steuerung einer Controller interaktiven Anwendung in separaten Objekten ModelViewContr kapseln MonitorActuator Ein Uberwachungskonzept eines Aktuators in einem Objektmodell abbilden Publisher Subscriber Zustandsanderungen eines Objekts PubSubscriber unidirektional an registrierte Abonnenten schicken ReactiveControlLoop Algorithmen f r unterschiedliche Zust nde einer Regelung Steuerung in separaten Objekten kapseln Repository Verteilt erzeugte Daten zentral in einem Objekt kapseln N q Tabelle 4 2 Teil 1 Muster des Designmusterkatalogs 154 C O J Oo Re D gt D C U D Q Y Sicherheit Verftigbarkeit Wart Port Erw Wied Modelltransformationssprache Bewertung hinsichtlich nichtfunktionaler Anforderungen Sicherheit Verfigbarkeit Wart Port Erw Wied Speicherverbrauch SecondGuess Eine Berec
163. chtung in Bezug auf die sog Sub systeme Automobilindustrie intern auch als Dom nen bezeichnet festzulegen Eine m gliche Aufteilung des Gesamtsystems Fahrzeug auf Subsysteme ist die folgende e Antriebstrang engl Powertrain z B Motorsteuerung Getriebesteuerung e Fahrwerk engl Chassis z B Elektronisches Stabilitatsprogramm ESP Fahrwerks regelung e Karosserie engl Body z B Schlie systeme Licht Einparkhilfen e Telematik Multimedia z B Kombiinstrument Audiosysteme Navigation Die Zuordnung der Funktionen zu diesen Dom nen orientiert sich in erster Linie ber den inhaltlichen Zusammenhang in zweiter Linie aber auch an den nichtfunktionalen An forderungen So gelten beispielsweise in der Dom ne Fahrwerk hohe Sicherheits und Verf g barkeitsanforderungen Demgegen ber ist die Karosserie Dom ne eher durch Kostendruck und Ausstattungsvarianten gepr gt Hier m ssen die einzelnen Funktionen m glichst wiederver wendbar und variabel implementiert werden Eine ausf hrlichere Beschreibung der einzelnen Subsysteme und ihrer Anforderungen findet sich bei Sch uffele et al 03 20 Systementwicklung 3 1 2 Der Kernprozess der Systementwicklung In Kapitel 1 1 wurde bereits auf die Einordnung der Softwareentwicklung in eine ubergeordnete Systementwicklung eingegangen In diesem Kapitel soll detaillierter ein ausgew hlter Kernprozess der Systementwicklung vorgestellt werden Systementwicklung engl
164. cklung werden die in Tabelle 3 1 Tabelle 3 3 zusammengefassten Inhalte auf Basis der EAST ADL modelliert w hrend die Softwareentwicklung f r die Modellierung die UML entsprechend der ROPES Methode nutzt Die in Kapitel 3 2 2 g getroffenen Festlegungen beschreiben die Modelllandschaft der Software entwicklung etwas konkreter Demnach bergibt die Systementwicklung ihre Modelle in Form der EAST ADL W hrend die Functional Analysis Architecture f r die Softwareentwicklung in das Analysis Object Model bertragen wird siehe folgendes Unterkapitel werden alle Modelle der technischen Systemarchitektur direkt genutzt Auf eine entsprechende bertragung in UML Diagramme wird verzichtet Im Rahmen der Softwareentwicklung wird jedoch nur ein Ausschnitt der Systementwicklungs modelle genutzt da sich ein Softwareentwicklungsprojekt im Rahmen von POTAD auf die Entwicklung der Software eines Steuerger ts bezieht Der relevante Teil des Funktionsnetz werks wird durch Auswertung des der in Tabelle 3 3 aufgef hrten Mappings 139 4 Eigener L sungsansatz POTAD Funktion Mikroprozessor F2Proz bestimmt Zu ber cksichtigende Schnittstellen ergeben sich aus den Mappings Logischer Sensor Aktuator E E Komponente SA2Komp und Abstraktes Datenelement Bussignal Botschaft DE2Sig Das bereits in Kapitel 3 2 5 skizzierte Grobkonzept wird durch POTAD konkretisiert Der dort in Abbildung 3 50 gezeigte Ablauf wird in Abbildung
165. csctccnecsecceeseeeesseeeesseeeesseesiesneees 119 3 39 Waters ANSatze unseren Dim 126 3 3 6 BEWERHLNB anne nee A E E ET 128 3 3 7 ZWISCHENERBEDNIS 2er near kauen 132 3 4 PRAZISIERTE PROBLEMSTELLUNG aa ua nn e ei E E E 134 4 EIGENER LOSUNGSANSATZ POTAD nuunsanssannsonnnnnnnnnnnnnnnnonnnonnnnnnnnnnnnnnnnnnnnnennnn 137 4 1 ERWEITERUNG DER ENTWICKLUNGSMETHOBE Ei dental cele ea au 138 4 1 1 A Se neun a a a 140 4 1 2 PESTE ee 141 4 2 MUSTER Se ee a a a a a re a E ll 145 4 2 1 TENI EMET 3MOGEelN urn ee ee ee 145 4 2 2 Notation und Werkzeugumsetzung 22u2sunssnessnsenennnnenennnnennnnnnnnnnnennnnenennenenennnenn 148 4 2 3 WAIST CT Kee IOE nee een aad aia aaa ae ne 150 4 3 VIODELLTRANSFORMATIONSSPRA CHE anne is ae een cet 155 4 3 1 VIEL MOG GI a seed saa te a ai east neat ee ci aa nen 156 4 3 2 ONENE T UNK E ne LE Oe IE ERE AE a aE ne Ee 160 4 3 3 Vo OVI OCS VILIN EEEE A hed ane as ae a gaa psd gs ad 160 4 4 VERFOLGBARKEITSMECHANISMUS six tv ee 164 VI 5 PROTOTYPISCHE UMSETZUNG ca ea 167 5 1 VIOBELLTRANSEFORMAT OR et ie Re a ee 167 5 1 1 PW a AKG GHA Re RET Nee Tea RMON Na aE Ieee Pay ASM A SE NMR CLR TTS IOC Cat RD 167 512 Scanner und Parser f r die Transformationsregeln ccccccccc secs cecsneccnecseceeseeseneseneseness 169 51 3 BENUL UIA yeas is TAE A ete hay cee ay A aia TEEN 170 5 2 VERFOUGBARKEIT SNAVIGA TOR es itech terns en an ee 172 5 3 BES PIE En RO ERE ere 175 6 VALIDIERUNG UND BEWERTUNG
166. ctional Analysis Architecture Object Analysis Model Object Analysis Software Anforderungen y Functional Design Architecture Function Instance Software Spezifikation der Software Architektur Model Platform Model Architectural Design Model Software Architectural Design Allocation Model Spezifikation der Software Komponenten Mechanistic N A Mechanistic Design Model Design Design amp Implementierung E E ae der Software Komponenten __Detailed Design Model _ Generated Source Code Detailed Kernprozess der Systementwicklung EAST ADL ROPES Abbildung 3 26 Gegenuberstellung der Artefakte aus Kernprozess EAST ADL und ROPES linke Seite des V Modells Auf der Prozessebene passt seitens ROPES die Variante SemiSpira siehe Abbildung 3 9 zu dem Kernprozess Wie oben erl utert erfolgen hier die Phasen Requirements Analysis und System Engineering nach dem Wasserfallprinzip f r das Gesamtsystem bevor die Softwareent wicklung nach dem Spiralmodell den ersten Mikrozyklus durchl uft Bei der Beschreibung der Benutzeranforderungen ist bei ROPES die Requirements Specification das zentrale Dokument zu dessen Aufbau und Inhalt jedoch wenig formale Vorgaben gemacht werden Es wird jedoch empfohlen das Verhalten des Systems m glich umfassend mit Use 64
167. das dort beschriebene Werkzeug Rational XDE bezogen auf die Anforderungen nach der Darstellung und Expansion von Mustern als die passendste L sung Aus diesem Grund wurde XDE als Werkzeugplattform f r die prototypische Umsetzung von POTAD ge w hlt Einige Elemente aus dem POTAD Metamodell die die Modellierung und insbesondere die Verarbeitung von Mustern betreffen k nnen somit auf existierende Mechanismen der Werk zeugplattform abgebildet werden Die in Kapitel 4 3 3 vorgestellte Transformationssprache wird von einem eigens entwickelten Parser verarbeitet der die Schnittstellen der brigen Komponenten nutzt um Elemente in den beteiligten Modellen zu suchen zu ndern oder hinzuzuf gen und die Interaktion mit dem Benutzer realisiert 5 1 1 Architektur Neben der integrierten Musterunterstutzung bietet XDE als Eclipse basiertes Werkzeug eine Vielzahl von Erweiterungsm glichkeiten in Form von Plug ins Mit der RXE API Rational XDE Extensibility steht eine ffentliche Schnittstelle zur Verf gung mit der allgemeine Operationen auf Modellen wie das Auslesen oder Erzeugen von Elementen ber Java oder NET vor genommen werden k nnen Leider beinhaltet die RXE Schnittstelle keine direkte Unterst tzung der Pattern Engine so dass es in dieser Bibliothek keine Befehle f r die Expansion von Mustern und das Anlegen von Bindungen gibt Diese L cke kann jedoch durch die Verwendung des MDA Toolkit for Rational XDE Java IBM c einer Sammlung
168. dem Schema lt Bedingung gt lt Erf llter Fall gt lt Unerf llter Fall gt 161 4 Eigener Losungsansatz POTAD notiert wobei der unerfullte Fall wie im Metamodell vorgesehen optional ist Bedingungen werden wie folgt realisiert e Durch Bezug zum Optimierungskriterium F r die Angabe des Optimierungskriteriums sind vier Schl sselw rter f r lt Name gt reserviert die die folgende Semantik haben o Performance Performance o Resources Speicherverbrauch o Safety Sicherheit und Verf gbarkeit Reuse Wiederverwendung Wartbarkeit Portabilit t Erweiterbarkeit OptimCriteria lt Name gt e Durch eine Benutzerruckfrage UserQuestion lt Fragetext gt lt Boolescher Standardwert gt lt Ergebnisvariable gt e Durch eine maschinenlesbare Anfrage an eine externe Informationsquelle Mit dieser Ab frage werden insbesondere die Modelle der technischen Systemarchitektur abgefragt Die Syntax von Anfrage kann implementierungsspezifisch festgelegt werden MaschineQuery lt Anfrage gt lt Boolescher Standardwert gt lt Ergebnisvariable gt e Durch logische Operationen zwischen OptimCriteria UserQuestion und MaschineQuery mit den Schl sselw rtern NOT AND OR Die Ergebnisvariable einer Benutzerr ckfrage kann sp ter ebenfalls als Bedingung verwendet werden Hilfsregeln werden ber lt Name der Hilfsregel gt lt Argument_1 gt lt Argument_n gt aufgerufen Einen Ausdruck f r das L schen
169. der alle nicht parametrisierten Elemente des Templates aufnehmen kann Bei der Instanziierung eines Musters muss dem Root Context wie bei einem Template Parameter ein konkretes Element zugewiesen werden Die Zuweisung unterschiedlicher Typen zu dem Root Context z B Class Package oder Component kann als Festlegung einer Template Art in dem oben beschriebenen Sinne interpretiert werden Bei den mitgelieferten GoF Mustern ist der Root Context beispiels weise als Paket definiert Ein XDE Muster mit Root Context Package hat jedoch vermutlich eine leicht andere Semantik als das Paket Template der UML Wie in Kapitel 3 2 4 e erl utert konnte im Rahmen der 96 Softwareentwicklung Arbeit nicht geklart werden ob bei der Bindung eines Paket Templates die tatsachlichen Para meter aus einem anderen Paket kommen k nnen als aus dem bindenden Paket Die vermutete Einschrankung dass dies nicht m glich ist gilt bei XDE nicht Hier m ssen die tatsachlichen Parameter nicht aus dem Paket kommen das dem Root Context zugewiesen ist Die Ellipsen Notation wird in XDE bei jedem Root Context Typ beibehalten Dies gilt z B auch f r ein Template das einen Root Context vom Typ Class und einen Parameter vom Typ Operation deklariert siehe linke H lfte von Abbildung 3 44 Die mit dieser Notation assoziierte Kollaboration ist an dieser Stelle etwas verwirrend da der Root Context graphisch nicht an gezeigt wird und es sich bei solch einem Template
170. derungen und Trends im Bereich Automotive Software Aktuelle Herausforderungen liegen hier in der steigenden Komplexit t durch die zunehmende Vernetzung von Funktionen immer h heren Optimierungsanforderungen bzgl nichtfunktionaler Kriterien und dem zunehmenden Bedarf eine Softwareimplementierung in Bezug auf nderungen in der Systemarchitektur schnell und flexibel anzupassen Die Systemarchitektur wiederum wird im Rahmen neuerer Systement wicklungsans tze zunehmend in formalisierter Weise erfasst und beinhaltet blicherweise eine systematische Beschreibung der Fahrzeugfunktionen und der realisierenden Elektrik Elektronik E E Einige dieser Inhalte werden traditionell auch in der Softwareentwicklung formalisiert erfasst so dass es hier nun zu berlappungen kommen kann Vor diesem Hintergrund sind Bestrebungen zu beobachten die Prozesse der System und Softwareentwicklung st rker zu integrieren und die an den Schnittstellen ausgetauschten Informationen so zu formalisieren dass sie durchg ngig in m glichst vielen Phasen des Entwicklungszyklus nutzbar sind Die Ausgangs situation dieser Versuche erscheint dabei g nstig da die Standardisierungsinitiativen im Bereich der Systementwicklung in letzter Zeit Formalisierungstechniken und Beschreibungsmittel nutzen die im Umfeld der Softwareentwicklung entstanden und etabliert sind Die st rkere prozessuale Verzahnung beider Entwicklungsdisziplinen einerseits und die zu nehmende Formalisierun
171. die aus diesem Analysemuster hervor gehen 2 Kontext Designmuster Zeige das Analysemuster an aus dem dieses Designmuster hervor geht 3 Kontext Klasse Zeige die Muster an an dem diese Klasse beteiligt ist F r die letzte Abfrage reicht die Auswertung der Musterbindung Methodisch relevant werden diese Abfragen z B wenn die Phase Mechanistic Design im Rahmen des Spiralmodells erneut durchlaufen wird Wird hier eine Modelltransformation erneut ausgef hrt wird das Ergebnis grunds tzlich mit dem Designmodell der letzten Iteration entsprechend der im folgenden Unter kapitel genannten Regeln verschmolzen Dies funktioniert uneingeschr nkt wenn f r die Iteration folgende Bedingungen gelten e Das Analysemodell wurde nur erweitert Im Vergleich zur letzten Iteration gibt es neue Modellelemente und Analysemusterinstanzen Bei Analysemusterinstanzen die schon in der letzten Iteration vorhanden waren sind nur neue tats chliche Parameter hinzugekommen e Das Designmodell wurde nur erweitert Im Vergleich zur letzten Iteration sind neue Elemente hinzugekommen Die Namen der durch Modelltransformation erzeugten Elemente wurden nicht ge ndert Die durch Modelltransformation erzeugten Elemente k nnen aber neue Kind Elemente bei einer Klasse z B Attribute oder Operationen und Beziehungen haben Wurde beispielsweise der Name eines tatsachlichen Parameters im Analysemodell oder eines durch Modelltransformation erzeugten Element
172. diese die zuvor gesammelten dom nenspezifischen Anforderungen Die Ergebnisse der Untersuchungen obiger Fragen flie en in eine neue Methode f r den systematisierten bergang zwischen System und Softwaredesignmodellen auf der Basis von Modelltransformationen ein Die Methode ist Gegenstand dieser Arbeit und besteht aus der Erweiterung eines bestehenden Softwareentwicklungsprozesses einem erweiterten Template Mechanismus f r Analyse und Designmuster einer neuen Modelltransformationssprache die den Kernteil dieser Arbeit darstellt und einem Verfolgbarkeitsmodell 1 3 Abgrenzung Die Problemstellung dieser Arbeit umfasst die Entwicklung einer Modelltransformationsl sung die auf Anforderungen einer integrierten System und Softwareentwicklung im Bereich der Automobilindustrie abgestimmt ist Um das Thema im Rahmen einer Dissertation bearbeiten zu k nnen mussten bereits zu Beginn Einschr nkungen getroffen werden von denen im Folgenden einige erlautert sind 1 Einleitung und Motivation Sowohl in der System als auch in der Softwareentwicklung gibt es Ansatze neben der Struktur auch das Verhalten eines Systems zu modellieren Der in dieser Arbeit entwickelte Modelltrans formationsmechanismus ist f r den Umgang mit Strukturmodellen optimiert Modelltrans formationen von Verhaltensmodellen werden nicht betrachtet Da sich der POTAD Ansatz im Wesentlichen auf die Instanziierung von Mustern st tzt werden die M glichkeiten POTAD
173. durch g ngig ber alle Artefakte hinweg konsistent zu beschreiben F r viele Elemente gibt es Typen was die Wiederverwendung von Modellelementen ber mehrere Projekte hinweg f rdert So werden beispielsweise Kommunikationsports von Funktionen Komponenten durch mehrfach referenzierbare Interfaces typisiert Software komponenten in der Functional Design Architecture werden verwendungsunabh ngig be schrieben und erst in dem Function Instance Mode f r ein konkretes Fahrzeugprojekt Instanziiert Ein weiteres Merkmal ist das Konzept den Aufbau und die Kommunikationsbeziehungen von Softwarekomponenten weitgehend unabh ngig von der technischen Plattform zu definieren Diese Vorgehensweise soll durch eine besondere Laufzeitumgebung engl runtime environement m glich werden die auf jedem Steuerger t verf gbar ist Diese stellt umfang reiche standardisierte Basisdienste f r eine Softwarekomponente zur Verf gung z B f r den Zugriff auf Hardware und die Kommunikation mit anderen Softwarekomponenten Aus Sicht einer Softwarekomponente ist die Realisierung der Kommunikation mit einer anderen Software komponente dann weitgehend transparent Es ist nicht direkt ersichtlich ob der Kommunikationspartner auf einem anderen Steuerger t platziert ist und der Datenaustausch ber einen Bus l uft oder ob der Kommunikationspartner auf demselben Steuerger t platziert ist und die Kommunikation intern ber einen gemeinsam benutzten Speicherberei
174. e entwickler sein ingenieurm iges K nnen abverlangt ist die Tatsache dass bei einer Funktion die nichtfunktionalen Anforderungen und die Plattformen variieren k nnen Die nicht funktionalen Anforderungen k nnen au erdem im gegenseitigen Konflikt stehen und eine Ge wichtung notwendig machen Diese Gewichtung sieht beispielsweise bei einer sicherheits relevanten Regelung im Fahrwerksbereich anders aus als bei einer Regelung die eine Komfort funktion im Innenraum realisiert Au erdem kann die aus Sicht der logischen Systemarchitektur gleiche Steuerung oder Regelung bei verschiedenen Fahrzeugmodellen zum Einsatz kommen die mit unterschiedlichen technischen Plattformen ausgestattet sind So k nnen z B die be n tigten Sensoren in dem einen Fall direkt am Steuerger t angeschlossen sein im anderen Fall aber nur indirekt ber den Bus zugreifbar sein In einem Fahrzeug muss die Software als Teil eines fahrzeugweiten Energiemanagements fungieren in einem anderen Fahrzeug besteht diese Anforderung nicht In Abh ngigkeit dieser wechselnden Anforderung m ssen Designent scheidungen getroffen werden die letztendlich zu unterschiedlichen Designl sungen f r dieselbe logische Systemarchitektur f hren k nnen Diese Variabilit t und die damit verbundene Komplexit t beim Design m ssen mit Hilfe entsprechender Methoden effizient beherrscht werden Der Prozess der Softwaredesignentscheidungsfindung st tzt sich bei aktuellen Vorgehensweisen
175. e Die Muster von Homann 04 beschr nken sich dar ber hinaus auf ein bestimmtes Betriebssystem und bei Pont 01 wird der Problembereich weiter auf zeitgesteuerte Systeme eingegrenzt und der L sungsraum umfasst nur einen be stimmten Mikrocontroller Typisch f r alle Musterarten ist dass sie nach einem einheitlichen Schema katalogisiert werden Der Aufbau dieses Schemas variiert nach Musterart und Autor Zu den oft verwendeten Kern elementen geh ren ein eindeutiger Mustername Motivation und Ziel des Musters die Be schreibung der L sung und eine Diskussion von Vor und Nachteilen siehe Kapitel 3 2 4 d Im Folgenden werden die Analyse und Designmuster vertieft da sie im Laufe dieser Arbeit eine besondere Rolle spielen Die Betrachtung beginnt mit den Designmustern da in ihrem Umfeld viele Konzepte entstanden sind die f r die Analysemuster bernommen wurden 3 2 4 b Designmuster Die hier betrachteten Designmuster werden im ROPES Prozess siehe Kapitel 3 2 2 w hrend der Phase Mechanistic Design eingesetzt und liefern als L sung ein Fragment eines Klassen modells Zu den Aufgaben dieser Phase geh rt die Optimierung einzelner Objekt Kollaborationen in Hinblick auf nichtfunktionale Anforderungen Designmuster unterst tzen den Entwickler entsprechend dabei eine ausgew hlte Objektkollaboration in Richtung einer einzel nen oder einer Gruppe von nichtfunktionalen Anforderungen zu optimieren Diese Fokussierung auf bestimmte nicht
176. e SE xXceprnon dc LocalFaultHandler Except Excep Jk G C Ju G ionHandler ion 1onMonitor 237 exMon Sicherstellen dass es nur Instanz von GlobalExceptionMonitor gibt Template Singleton GlobalExceptionHandler Singleton exMon ExceptionMonitortexMon ExceptionHandler Client singGlobExHand Sicherstellen dass es nur eine Instanz von ExceptionLog gibt Template Singleton ExceptionLog MoMo GlobalExceptionHandler exMon ExceptionMonitor Client singExLog 2 Beispiel 2 1 Analysemodell Detector Class Corrector Class LocalFaultHandler Class CorrectiveAction Signal LocalFault Signal Actuator Class bind Bind Corrector FailsafeController LocalFaultHandler Engine FaultHandler CorrectiveAction ChangeT oF ailSafeMode Local Fault UnplausibleS etting Actuator T hrottle Detector Throttle RN MalfunctionDetector lt DetectorCorrector_ Actuator C DetectorCorrector_ Actuator Throttle Sn meas aie 7 EngineFaultHandler ca UnplausibleSetting er W ChangeToFailSafeMode ThrottleMalfunctionDetector Shroti 4 FailsafeController monitors gt 7 lt provides EEA a actions for 2 2 Designmodell C Optimierungskriterium wird in dieser Regel nicht ber cksichtigt Klasse die den Kontext der berwachung darstellt EngineCon
177. e Sollte davon abgewichen werden wird dies bei der Erl uterung des entsprechenden Beispiels erw hnt Der Pfeil am linken oberen Rand der Template Ellipse ist ein Hinweis darauf dass dieses Modellelement aus einem externen Modell kommt in diesem Fall die Musterbibliothek Dieser Hinweis kann f r den Rest dieser Arbeit ignoriert werden Context Class bind Strategy Class Bind Strategy CruiseController_Strategy Concrete ConcreteStrategy Class Be Strategy Comfort Sport algorithm _ algorithminterface Operation Interface cruise Context CruiseController_Controlloop __ controlstrat PENRE IET TERANE TEIR EA EA rece IA ESTE ASE I AR E ENEE O AS AE TE eases gt Sa Strategy gt wm ko nn ee CruiseController_ControlLoop _CruiseController_Strategy OC OUETOR Strategy contextinterface cruise Comfort Sport cruise cruise Abbildung 4 9 eine Template Instanz am Beispiel des Strategy Musters Das Beispiel in Abbildung 4 10 zeigt die Darstellung von Multiplizitaten und Parametergruppen Eine TemplateParameterGroup lasst sich durch die Einf hrung eines Gruppenbezeichners anlegen der als Pr fix dem Template Parameter vorangestellt wird getrennt durch einen Punkt An gaben zur Multiplizitat werden in Klammern hinter dem Parameter oder der Gruppe notiert 149 4 Eigener Losungsansatz POTAD
178. e mindestens einen Parameter besitzen muss und bei Aufruf aus einer anderen Regel immer ausgef hrt wird 2 Die linke Seite verweist auf ein Template aus dem Template Metamodell siehe Kapitel 4 2 1 und eine InstanceVariable Tritt eine TemplateInstance des angegebenen Templates im Analysemodell auf so wird die angegebene InstanceVariable mit dieser belegt und die rechte Seite der Regel ausgef hrt Die Templateinstanz aus dem Analysemodell kann im gesamten rechten Teil der Regel ber die InstanceVariable angesprochen werden um die Belegungen ihrer Parameter aufzul sen RHS Right Hand Side Die rechte Seite dient als Abstraktion f r ein einzelnes Ausf hrungselement einer Regel Sie kann entweder durch einen bedingten Ausdruck CondExpression oder einen unbedingten Aus druck Expression realisiert werden CondExpression Conditional Expression Stellt einen bedingten Ausdruck dar Verweist auf eine Bedingung Condition einen obligatorischen Ausdruck Expression f r den Fall dass die Bedingung erf llt ist sowie einen optionalen Ausdruck f r den Fall dass die Bedingung nicht erf llt ist Expression Dient als Abstraktion der verschiedenen M glichkeiten f r Ausdr cke auf der rechten Seite RuleAppliance TemplateInstantiation und ElementInstruction 157 4 Eigener Losungsansatz POTAD Condition Dient als Abstraktion fur die konkreten Bedingungen OptimCriteria MachineQuery UserQuestion und BoolVariable
179. e parameter uostituto condParamBinding 15 paramSubstitution 1 falsecase actualParameter truecase 1 relates sl Elemente aus dem Elemente aus dem E Elemente der UML2 Metamodell Template Paket von POTAD POT AD Transformationssprache Abbildung 4 11 Metamodell fur die Transformationsregeln 156 Modelltransformationssprache Im Folgenden wird die Semantik der Klassen aus dem Metamodell in nat rlicher Sprache be schrieben TrafoRule Transformation Rule Steht f r eine komplette Transformationsregel Diese hat einen Namen und besteht aus einer linken Seite LHS f r left hand side und einer mindestens ein Element enthaltenden ge ordneten Liste von Elementen der rechten Seite RHS f r right hand side Optional kann die Transformationsregel beliebig viele Transformationsparameter TrafoParameter haben TrafoParameter Transformation Parameter Bezeichnet einen nicht typisierten Parameter f r eine Transformationsregel der ber einen eindeutigen Namen identifiziert wird und ber diesen in der gesamten Regel angesprochen werden kann Wird ein Parameter definiert so muss dieser auch beim Aufruf belegt werden optionale Parameter mit vordefinierten Werten sind nicht vorgesehen LHS Left Hand Side Legt die Ausgangslage f r die Anwendung einer Transformationsregel fest Daf r gibt es zwei M glichkeiten 1 Die linke Seite enth lt kein Element In diesem Fall handelt es sich um eine Hilfsregel di
180. e 131 Tabelle 4 1 Muster des Analysemusterkatalogs 2222022sssseesensnnsennnnnnnnnnnnnnnnnnnnnennennnnnn nenn 152 Tabelle 4 2 Muster des Designmusterkatalogs Teil 1 4442242244444444444400000000000 RR 154 Tabelle 6 1 Abgleich der L sung mit den gestellten Anforderungen aus Kapitel 3 2 5 185 255 Literaturverzeichnis Agrawal 04 Agrawal A A Formal Graph Transformation Based Language for Model to Model Transformations PhD Dissertation Vanderbilt University Dept of EECS 2004 URL http www isis vanderbilt edu publications archive Agrawal_A_8_0_2004_A_Formal_G pdf Akehurst 04 Akehurst D Relations in OCL UML 2004 Workshop OCL and Model Driven Engineering Lisbon Portugal 2004 URL http www cs kent ac uk pubs 2004 2007 Akehurst et al 02 Akehurst D Kent S A Relational Approach to Defining Transformations in a Metamodel In Jezequel J M Hussmann H Hrsg 2002 The Unified Modeling Language Model Engineeing Concepts and Tools Ausgabe 2460 Springer 2002 URL http www cs ukc ac uk pubs 2002 1559 Alexander 77 Alexander Christopher A Pattern Language Oxford University Press 1977 Aquintos Aquintos PREEvision Produktwebseite URL http www aquintos de de products ee php Aquintos 06 Aquintos Benutzerhandbuch PREEvision Release 1 0 2006 Arora et al 98 Arora A Kulkarni S Detectors and correctors
181. e Betriebszust nde ponent unterst tzten da ein vollst ndiger Ausfall des Systems einen hohen Verhaltensmuster Verlust bedeutet In dem Muster Computing Component werden verschiedene Betriebszustande eines eingebetteten Systems definiert wie z B Fai Safe Zustande in die das System nach dem Auftreten eines Fehlers bergeht Controller Das Muster Controller Decompose beschreibt wie ein eingebettetes Decompose System in unterschiedliche Komponenten aufgeteilt werden kann Das Strukturmuster Muster ist die Basis f r alle weiteren Muster Es f hrt eine High Level Sicht eines eingebetteten Systems ein die zur Verfeinerung auf andere Analysemuster verweist Tabelle 3 9 Teil 1 Analysemuster von Konrad et al 04b bersetzt aus dem Englischen 10 Softwareentwicklung Mustername Beschreibung Detector Eingebettete Systeme unterliegen typischerweise Zeit und Betriebs Corrector bedingungen Das Ziel des Musters Detector Corrector ist es einen Verhaltensmuster Mechanismus zu beschreiben der sicherstellt dass eine Komponente in Betrieb ist oder spezifische Bedingungen nicht verletzt sind In dem Muster stellen Detectors Fehlererkennungsfahigkeiten und Correctors Fehlerbehebungsfahigkeiten zur Verf gung wobei die Interaktion zwischen beiden durch einen Loca Fau t Handler gesteuert wird Fault Handler Die Behandlung von Fehlern hat bei eingebetteten Systemen eine Verhaltensmuster besondere Bedeutun
182. e Mangel auf Neben einem fehlenden Standardprofil fur typische Hardwareeinheiten ist vor allem die Um setzung domanentypischer Darstellungsweisen ein Problem Fur die grobe Modellierung der Verteilung von Softwarekomponenten auf Hardwareeinheiten reicht das Verteilungsdiagramm aber aus Ein Modell der logischen Systemarchitektur lasst sich durch ein Profil demnach relativ einfach in die Softwareentwicklung bernehmen und wiederverwenden bei der technischen Systemarchitektur funktioniert dies nur eingeschrankt Fur die weitere Diskussion wird an genommen dass die logische Systemarchitektur im Rahmen der Softwareentwicklung ent sprechend der in Kapitel 3 2 1 c vereinbarten Konvention mit den Mitteln der UML modelliert wird Die technische Systemarchitektur wird dagegen nicht in ein UML Modell berf hrt sondern es werden die in Kapitel 3 1 3 b erlauterten Modelle der Systementwicklung weiterver wendet Im Falle der ROPES Methode siehe Kapitel 3 2 2 muss die Frage nach der Wiederverwend barkeit von Modellen differenziert beantwortet werden So wird zwar im Rahmen der Phase System Engineering die Systementwicklung grundsatzlich berucksichtigt bei den verwendbaren Modellen herrscht jedoch weitgehend Wahlfreiheit insb f r Inhalte der logischen System architektur oder die vorgeschlagenen Modelle haben nur einen geringen Detaillierungsgrad Im weiteren Verlauf des Entwicklungsprozesses ist mit dem Object Analysis Model ein Analyse modell f r
183. e Regelungs bzw Steuerungsverhalten implementiert Dazu werden die Daten der Sensoren Sensor gelesen und nach Ausf hrung der ben tigten Be rechnungen in Aktuatorwerte Actuator umgesetzt 211 3 DataBus 3 1 Zweck Den Zugriff auf einen Datenbus in einer einheitlichen Objektstruktur kapseln 3 2 Struktur ConcreteClient 1 Class ConcreteSubject 1 Class _ ConcreteData 1 Class zu Sa oe Ber 2 DataBus _DataBus update Ol gett DataBus AbstractData AbstractChent AbstractData AbstractSubject AbstractData DatalD 5 AbstractData ConcreteData ConcreteClient ConcreteSubject value 3 3 Erlauterung Das ebenfalls von Douglass Douglass 02 bernommene DataBus Muster stellt einen Daten speicher dar der im Gegensatz zum Blackboard Muster nicht nur lokal zur Verf gung steht sondern ber einen Bus auch Daten mit anderen Komponenten oder Subsystemen austauschen kann Dies wird dadurch verdeutlicht dass die wesentliche Busstruktur in der Musterdefinition nicht parametrisiert ist und somit f r alle Anwendungen des Musters in einem Designmodell gleich ist Diese Struktur beinhaltet eine zentrale Datenbusklasse DataBus die eine Menge von Daten AbstractData verwaltet und auf die lesende AbstractClient und schreibende AbstractS
184. e gt notiert bei den Hilfsregeln bleibt sie bekannterma en leer ber lt Variablenname gt lt Parametername gt k nnen dann auf der rechten Seite die an die einzelnen Para meter gebundenen Elemente aufgel st werden Die Erzeugung einer Template Instanz auf der rechten Seite wird mit dem Ausdruck Template lt Template gt lt Argument_l gt lt Argument_n gt lt Variablenname gt erreicht wobei der Variablenname optional ist Dies setzt voraus dass die vorgegebene Reihen folge der Parameter eingehalten wird Bei der Auswertung wird f r jedes Argument ein Element im Designmodell erzeugt das den Typ des zugeordneten Parameters und den Namen des Argumentes erhalt Existiert ein solches Element bereits so wird das bestehende Element ver wendet Mit diesen Elementen werden dann die Musterexpansion und das Anlegen der Bindungen im Designmodell vorgenommen Einzelne Ausdr cke auf der rechten Seite werden kommasepariert hintereinander aufgelistet F r die brigen Modellelemente gibt es Konstruktoren Class lt Name gt lt Boolescher Wert f r die Eigenschaft abstrakt gt Attribute lt Name der Klasse gt lt Name des Attributs gt lt Typ gt Operation lt Name der Klasse gt lt Name der Operation gt lt R ckgabetyp gt Association lt Name der Quellklasse gt lt Name der Zielklasse gt lt gerichtet gt Inheritance lt Name der Unterklasse gt lt Name der Oberklasse gt Bedingte Verzweigungen werden nach
185. e jeder Unit dokumentiert die Unit Test Procedures die Schritt f r Schritt die Durchf hrung eines Tests inkl der bestanden Kriterien dokumentieren und die Unit Test Results ein Dokument ber die Testergebnisse mit ausf hrlichen Informationen f r jeden Test Datum Name und Version der beteiligten Komponenten Erfolg Misserfolg Die Application Components sind ausf hrbare und getestete Softwarekomponenten die das Endergebnis dieser Phase darstellen 3 2 2 f Test In dieser Phase werden die Entwicklungsergebnisse zu einem Prototyp zusammengef hrt ge testet und entdeckte Fehler f r die n chste Iteration des Mikrozykluses gesammelt Das esting unterteilt sich in die Subphasen ntegration Test Design Integration Testing und Validation Test Design Validation Testing siehe Abbildung 3 25 62 Softwareentwicklung Translation Detects Design Detects Analysis Defects Defects Test Vectors Test Vectors Validation Test Results Integration Test Validation Test Plan Plan Integration Tested Components Integration Testing Integration Test Design Validation Test Design Validation Testing Integration Test Validation Test Procedures Procedures Integration Test Results Application Tested Components RE Application Abbildung 3 25 Artefakte der Phase Testing Douglass 99 Zu den
186. e und Relationen verwendet Diese werden zun chst in UML modelliert spezifische Eigenschaften der Relationen m ssen jedoch ebenfalls mit Hilfe von OCL Ausdr cken be schrieben werden In dem Beitrag geht es primar um Transformationen zwischen Elementen ein und derselben Sprache abstrakte Syntax Semantik Domane konkrete Syntax die Autoren schlie en aber nicht aus dass der Ansatz auch fur Modelltransformationen zwischen ver schiedenen Modellen geeignet ist Allerdings bezieht sich der Ansatz nur auf Relationen und lasst die genaue Spezifikation der operationalen Semantik offen 3 3 6 Bewertung Die untersuchten Ans tze f r Modelltransformationen werden im Folgenden anhand der bisher gesammelten dom nenspezifischen Anforderungen bewertet Abschlie end soll die Frage be antwortet werden ob eine Modelltransformation auf Basis der in Kapitel 3 2 4 8 skizzierten Systematik mit Hilfe der untersuchten Ans tze m glich ist 3 3 6 a Vorauswahl anhand grober Unterscheidungsmerkmale Die in Kapitel 3 2 5 gesammelten Anforderungen sind so detailliert dass eine volle Unter stutzung von existierenden Ans tzen nicht erwartet werden kann Insbesondere die adaquate Umsetzung von Templates Anforderung TEM und der Expansionsmechanismus Anforderung EXP erscheinen als zu speziell um sie als bereits vorhandene Merkmale bestehender Ans tze vorauszusetzen Deshalb wird bei der Bewertung nicht verlangt dass jede Anforderung in der formulierten Form
187. eSetValue Context CruiseController_Master gt Sensor_getMethod Operation __ Actuator_setMethod Operation _CruiseController_ControlLoop ControlLoop D secondaryCalc ane p CruiseController_ControlLoop 1 initialize secondaryCalc step 1 shutDown bind Bind AbstractAlgorithm ControlAlgorithm Concrete Algorithm Long Short Algorithm a Interface cruise Context CruseConroler ControlLoop Gonels6 Abbildung 3 47 Ein auf Sicherheit und Robustheit optimiertes Design des Tempomaten Die Muster zur Entkopplung der Sensorik wurden in diesem Fall weggelassen Stattdessen wurde durch den Einsatz des Musters SecondGuess bei der die Berechnung der Drosselklappen stellung eine Diversifikation auf der Softwareebene erreicht Die kritische Berechnung wird durch zwei unterschiedliche Algorithmen vorgenommen In einem ersten Schritt wird mit einem genauen und laufzeitintensiven Algorithmus ein Ergebnis berechnet Dieses wird dann mit Hilfe eines weniger laufzeitintensiven Algorithmus dessen Ergebnis ungenauer sein kann verifiziert Eine Ma nahme zur Erh hung der Robustheit ist der Einsatz des Watchdog Musters Mit Hilfe des Watchdogs wird berpr ft ob der Regler entsprechend der vorgegebenen Zykluszeit aktiv ist Dazu sendet der Regler periodisch eine Nachricht an den Watchdog Bleibt diese f r eine bestimmte Zeitspanne aus werden vom Watchdog korrigierende Ma nahmen ergriffe
188. echnican Panu L Comfort S pot FE D Fei Wartung E Enine Reparatur Wechsel zwischen a Tempomatmodus und Speedlimiter Tempomamsaus Tempomatmodus Wahl des Schaltprogramms ranzeug 1km h Fahrzeug abbremsen os Tempomat fortsetzen Beschleunigungsverhalten Speedlimiter a beschleunigen Speedlimiter 10 km h 1 km h Abbildung 2 3 Softwaresimulator f r das KFS 2 2 Design der Softwarefunktionen In einem ersten Schritt wurde im Rahmen einer Diplomarbeit siehe Kapitel 6 2 ein Software design f r das KFS mit einer herk mmlichen modellbasierten Entwicklungsmethode ROPES siehe Kapitel 3 entwickelt Dazu wurde die logische und technische Systemarchitektur in den entsprechenden Modellen der ROPES Methode nachmodelliert und anschlie end der vor geschriebene Prozess durchlaufen Viele Funktionen des KFS haben Steuerungs Regelungs oder berwachungsaufgaben die nach einem hnlichen logischen Schema aufgebaut sind zyklisch werden aktuelle Sensor und Sollwertgeberdaten eingelesen mit denen eine Berechnung durchgef hrt wird deren Ergebnis an Aktuatoren gesendet wird die dieses in physikalische Arbeit umsetzen Aufgrund dieser hnlichkeit l sst sich vermuten dass sich auch ein einheitliches Design f r Softwarefunktionen mit Steuerungs Regelungs oder berwachungsaufgaben finden l sst Am Beispiel der ersten Umsetzung des KFS wurde jedoch deutlich dass das Design dieser Funktionen stark variieren kann Der Grund
189. edes redundante Element gibt 215 7 HomogeneousRedundancy 7 1 Zweck Homogene Redundanz in einem Objektmodell abbilden 7 2 Struktur Context Context Class Sensor Class Channel Class useSecondChannel Boolean periodic call getChannelState Ra oe ctuator Class ao lt Channel gt a 1 MOEN EOUSHEOUnOaTCY 2 eee Channel lt Channel gt il channelState Boolean lt Channel gt setChannelState getChannelState _ lt InputDataValidation gt InputDataValidation 1 _ lt Sensor gt call setChannelState Zu _ lt Sensor gt 1 1 5 of 0 _ lt Actuator gt Actuator ayi 1 1 _ lt ActuationValidation gt 0 z 102o 0 lt Actuator gt _ lt ActuationValidation gt SEAT en i ActuationValidation 1 _ lt Sensor gt _ lt Controller gt Controller call setChannelState 7 3 Erl uterung Das von Douglass 02 bernommene HomogeneousRedundancy Muster beschreibt ein Design modell f r ein System in dem die Verf gbarkeit durch die redundante Auslegung der Sensorik Aktuatorik und der Steuerung Regelung erh ht wird Charakteristisch ist dabei dass es sich bei den redundanten Elementen um dieselbe Implementierung handelt Auf diese Weise kann zwar z B der Ausfall ein
190. eeeeneeaes 172 Abbildung 5 5 Aufruf des Verfolgbarkeitsnavigators ber das Kontextmenu 2 cceseesneeeeeennnn 173 Abbildung 5 6 Ergebnis einer Abfrage f r den Kontext Analysemuster 2ussssssenseeneensenenenennnnenn 174 Abbildung 5 7 Ergebnis einer Abfrage f r den Kontext Designmuster eunseeneensennsensnnneenennenennnnnn 174 Abbildung 5 8 Ergebnis einer Abfrage f r den Kontext Klasse ucuussessennnnnnnnnnnnnnnnneneeeneenenen 175 Figure 7 1 UML class diagram of the Detector Corrector Pattern ccccccc ccc cccc nce eceeeec eee eeeneeseeen canes 205 Figure 7 2 UML state diagram of the LocalFaultHandler in the Detector Corrector Pattern 206 Figure 7 3 UML state diagram of a timeout detector in the Detector Corrector Pattern 206 Figure 7 4 UML state diagram of a constraint violation detector in the Detector Corrector Pattern 206 Figure 7 5 UML state diagram for the Corrector in the Detector Corrector Pattern 207 Figure 7 6 UML sequence diagram example of a timeout detector in the Detector Corrector Pattern 208 254 Tabellenverzeichnis Tabelle 3 1 M gliche Inhalte der logischen Systemarchitektur 220022022essesseneeeseneeeennnenn 23 Tabelle 3 2 M gliche Inhalte der technischen Systemarchitektur ccccccc cece nccee cece eeeneeeeeeeeeeaeeeaeeas 24 Tabelle 3 3 F r die Softwa
191. eelementen und den Steuerungs und Regelungsfunktionen e Indicator Anzeigeelement das den von UserInterface empfangenen Wert IndicatorValue anzeigt 198 e Control Bedienelement das den vom Benutzer eingestellten Wert ControlValue an UserInterface sendet 3 4 Beispiel Das Beispiel zeigt eine Erweiterung des Tempomaten Beispiel zu Muster ClosedLoopControl um ein Kombiinstrument UserInterface InstrumentCluster Dieses umfasst einen Hebel f r die Einstellung der Sollgeschwindigkeit Control Lever und eine Anzeige der aktuellen Ge schwindigkeit Indicator SpeedIndicator Die Funktion InstrumentCluster bersetzt die Be wegungen des Hebels hoch runter vor zur ck in eine Sollgeschwindigkeit DesiredRPM f r CruiseController um InstrumentCluster ist dar ber hinaus auch f r die Umrechnung Radrehzahl CurrentRPM in km h CurrentSpeed verantwortlich Auf diese Weise wird der von WheelRPMSensor erfasste Wert ber SpeedIndicator digitale Anzeige in der vom Fahrer ge w nschten Gr e angezeigt bind UserInterface Class Bind Indicator Speed Indicator Class Indicator Control Lever Indicator Control Class Value CurrentS peed Control IndicatorValue Signal Value Lever ControlValue Signal Movement Source Wheel Source Class RPMSensor Drain CruiseController Ui Drain Class InputValue
192. eint Mit Hilfe der konkreten Notationen die sich aus einem Metamodell ableiten k nnen Modelle erstellt werden Im Falle einer Modellierungssprache f r Softwareentwicklung beschreibt ein solches Modell z B ein bestimmtes Softwaresystem Die zur Laufzeit existierenden Daten oder Objekte dieses Systems k nnen als Instanz dieses Modells betrachtet werden Die in Kapitel 3 2 1 beschriebene Modellierungssprache UML ist in die in Tabelle 3 4 gezeigte Vier Schichten Metamodellarchitektur eingebettet die ein Beispiel f r das Konzept der sich 28 Systementwicklung selbst definierender Metametamodelle liefert Die einzelnen Ebenen werden hier mit MO bis M3 abgekurzt Im Rahmen von Kapitel 3 1 3 a wird noch auf diverse OMG Standards zu diesen Ebenen eingegangen Beschreibung Beispielelement Metametamodell Definiert die Sprache f r die Spezi MetaClass fikation von Metamodellen und sich MetaAttribute Metamodell M2 selbst Met aOperation Instanz eines Metametamodells Class Attribute definiert die Sprache fiir die Spezi Operation Component fikation von Modellen Instanzen des Modells Beschreiben geschwindigkeit 80 Systeme zur Laufzeit oder Aus pragungen einer bestimmten Dom ne Modell M1 Instanz eines Metamodells definiert Class Fahrzeug die Sprache f r die Beschreibung Attribute geschwindig eines Systems oder Dom ne keit I Tabelle 3 4 Vier Schichten Metamodellarchitektur Darstellung
193. en 3 Ein Modelltransformationsansatz muss den Zusammenhang zwischen den Modellen der System und Softwareentwicklung durch geeignete Verlinkung dauerhaft verfolgbar machen so dass Designentscheidungen bei Variabilitat im Zielmodell nachvollziehbar bleiben Diese drei Kernforderungen sind eine Zusammenfassung der in Kapitel 3 2 5 aufgestellten Liste mit Anforderungen an einen Modelltransformationsansatz In Kapitel 4 wurde ausf hrlich ein Modelltransformationsansatz beschrieben dessen Grundidee eine Neuerung im Bereich der Modelltransformationen darstellt Den Zusammenhang zwischen formalisiert beschriebenen Analyse und Designmustern zu systematisieren und daraus Transformationsregeln abzuleiten die f r eine Analysemusterinstanz Designmuster instanziieren F r einen selbst erstellten Katalog aus 5 Analysemustern wurden mit der eigenen Transformationssprache Regeln erstellt 183 6 Validierung und Bewertung die insgesamt 18 Designmuster aus einem ebenfalls im Rahmen dieser Arbeit zusammen gestellten Katalog instanziieren Durch diese Transformationsregeln und die entsprechenden Werkzeuge die im letzten Kapitel vorgestellt wurden ist die automatisierte Erstellung eines Designmodells auf der Basis von Mustern m glich Daher sind die unter Punkt 1 aufgef hrten Anforderungen erf llt Die in Kapitel 4 3 vorgestellte Transformationssprache sieht zwei Arten von Variabilit t vor In Bezug auf nichtfunktionale Anforderungen kann ein
194. en Bei der Untersuchung aktueller Softwareentwicklungsmethoden in dem folgenden Kapitel soll ber die Fragen aus der Problemstellung hinaus berpr ft werden inwiefern diesen methodischen Ver nderungen im Bereich der Systementwicklung auf der Seite der Software entwicklung Rechnung getragen wird Ein Schwerpunkt bildet dabei die Frage wie sich die Modelle der Systementwicklung im Rahmen der Softwareentwicklung wiederverwenden lassen 42 Softwareentwicklung 3 2 Softwareentwicklung Dieses Kapitel erlautert den Stand der Technik zu den fur die Problemstellung relevanten Themen aus dem Bereich Softwareentwicklung Die bereits in Kapitel 3 1 3 begonnene Schwer punktbildung auf modellbasierter Entwicklung wird an dieser Stelle fortgefuhrt In dem folgenden Unterkapitel wird mit der UML zunachst eine etablierte Modellierungssprache fur die modellbasierte Softwareentwicklung vorgestellt Die in dem darauf folgenden Unter kapitel zusammengefasste ROPES Methode pr zisiert deren Einsatz f r die Entwicklung von eingebetteten Echtzeitsystemen und beschreibt daruber hinaus auch eine konkrete Vorgehens weise In Kapitel 3 2 4 wird mit den Mustern ein verbreitetes Konzept fur eine systematisierte Erstellung von Modellen vorgestellt 3 2 1 Die Unified Modeling Language Die Unified Modeling Language UML ist eine Sprache f r die Modellierung von software intensiven Systemen im Sinne der in Kapitel 3 1 3 referenzierten Definition Die verf
195. en Mit der Zusammenstellung soll lediglich gezeigt werden dass es fur die hier betrachtete Domane ausreichend anwendbare Muster gibt Auf Basis der Zusammenstellung kann als Ergebnis festgehalten werden dass es durchaus zahlreiche Designmuster mit Anwendungsmoglichkeit im Bereich Automotive Software gibt Es gibt allerdings auch viele publizierte Designmuster fur die sich kein Anwendungsfall finden lieB oder die in einigen Projekten geltenden Richtlinien widersprechen Beispielsweise gibt es Systeme bei denen eine Speicherallokation nach der Initialisierungsphase aus Sicherheits und oder Verf gbarkeitsgr nden verboten ist Bei Designmustern die dynamisch Objekte anlegen muss entsprechend darauf geachtet werden dass dies nur zur Initialisierungsphase geschieht oder die Verwendung ganz ausgeschlossen wird Insgesamt muss bei dieser Diskussion auch nach den in Kapitel 3 1 1 f erlauterten Subdom nen differenziert werden da deren Charakteristika mitentscheidend bei der Frage nach der Verwendungsm glichkeit einzelner Muster sind Durch die vielen Publikationen gibt es viele Muster die sich inhaltlich berlappen oder sogar das gleiche Konzept beschreiben aber unterschiedlich benannt sind Es gibt leider keine zentrale Instanz die alle Muster in einem Namensraum nach einer festen Systematik verwaltet und nach einem einheitlichen Schema beschreibt Die L sung eines Musters wird bei den meisten Ver ffentlichungen relativ grob und beispie
196. en Objektstruktur gekapselt ReactiveControlLoop F r den Fall dass die Steuerung zustandsbehaftet ist werden die Steuerungsalgorithmen f r die unterschiedlichen Zust nde in separaten Objekten gekapselt ControlLoop Der Steuerungsalgorithmus wird in einem separaten Objekt gekapselt PublisherSubscriber Wiederverwendung M gliche zuk nftige Datenkonsumenten der Sensoren k nnen einfach durch Registrierung als Abonnent hinzugef gt werden Strategy Wiederverwendung Der Steuerungsalgorithmus kann leicht ausgetauscht werden HeterogeneousRedundancy Sicherheit Heterogene Redundanz der Sensorik Aktuatorik und des Reglers unterst tzen SecondGuess Sicherheit Den in der Steuerung verwendeten Algorithmus durch einen k rzeren Algorithmus absichern und beide Algorithmen in separaten Objekten kapseln Watchdog Sicherheit Periodisch pr fen ob die Steuerung noch aktiv ist 197 3 Userlnterface 3 1 Zweck Abstrakte Beschreibung einer Benutzerschnittstelle 3 2 Motivation Einige Steuerungs und Regelungssysteme benotigen Interaktion mit dem Fahrer oder anderen Insassen So muss z B der Sollwert f r eine Regelung eingestellt oder aktuelle Sensorwerte angezeigt werden Eine weitere wichtige Aufgabe der Benutzerschnittstelle ist das Anzeigen von Fehlern Bei sehr einfachen Benutzerschnittstellen k nnen die Bedien und Anzeigeelemente als Sensoren bzw Aktuatoren modelliert werden Bei komplexeren Benutzerschni
197. en ist Bei der Softwareentwicklung sind die zu verwendenden Modelle dagegen enger gefasst und genauer beschrieben System und Softwareentwicklung sind nur lose ge koppelt Da bei den Modellarten in der Systementwicklung weitgehend Wahlfreiheit herrscht ist es mit den im Rahmen der Methode zu Verf gung stehenden Mitteln auch nicht m glich den Zusammenhang zwischen Modellen der System und Softwareentwicklung systematisch zu 65 3 Stand der Technik beschreiben Die Softwareentwicklung beginnt konsequenterweise mit der Erstellung eines eigenen Analysemodells dem Object Analysis Model Hier herrscht ein gewisser Bruch in der Durchg ngigkeit da der Bezug dieses Modells zu den Modellen der Systementwicklungen ungekl rt ist Die EAST ADL liefert f r alle systementwicklungsrelevanten Artefakte detaillierte Metamodelle Die Modellierung geht bis zur Spezifikation der Softwarearchitektur und der darin enthaltenen Softwarekomponenten mit ihren Schnittstellen Modelle f r das interne Design der Komponenten stehen dagegen nicht zur Verf gung Zusammenfassend kann festgestellt werden dass die EAST ADL konkrete Modelle f r die Artefakte bezogen auf den Kernprozess der Systementwicklung liefert ROPES liefert dies f r die Softwareentwicklung Im Bereich der Softwarearchitektur gibt es inhaltliche berlappungen Die Formalisierungsl cke die bei ROPES in der Systementwicklung durch die Wahlfreiheit bei den Modellen herrscht kann dur
198. enhaft die Steuerger te und ihre Vernetzung eines Fahrzeugs Copyright Daimler AG Abbildung 1 1 Vernetzte Steuerger te in einem Oberklassenfahrzeug In diesem Umfeld besch ftigt sich ein Softwareprojekt typischerweise mit der Software eines Steuerger ts Die in der Systemarchitektur erfassten Informationen beantworten f r die Soft wareentwicklung viele entscheidende Fragen Welche Funktionen m ssen implementiert werden zu welchen Funktionen gibt es Schnittstellen wie ist der Aufbau des verwendeten Steuerger ts und welche Kommunikationssysteme stehen zur Deckung des Kommunikationsbedarfs zur Verf gung Die f r diese Fragen relevanten Entscheidungen werden blicherweise im Rahmen der E E Systementwicklung gef llt und von der Softwareentwicklung als Anforderungen bzw Randbedingungen bernommen Durch verschiedene Trends hat der hierbei entstehende Ab stimmungsbedarf in letzter Zeit zugenommen Dazu geh rt z B die steigende Zahl von ver teilten Funktionen die sich inhaltlich oft querschnittlich zu der an Steuerger ten orientierten 2 Umfeld Projektorganisation verhalten Ein weiteres hier zu nennendes Themenfeld sind die neuen Assistenzsysteme Da diese teilweise aktiv Einfluss auf das Fahrzeug nehmen unterliegen sie oft Sicherheits und Verf gbarkeitsanforderungen die eng koordinierte Hardware und Software ma nahmen f r die Fehlererkennung und behandlung erfordern Auf der Ebene der Hardware kann dies z B die
199. enmanagement F r die Repr sentation von Dom nen auf UML Ebene werden Pakete verwendet Um zu kennzeichnen dass in dem Paket nur Elemente der Dom ne platziert werden sollen wird der Stereotyp lt lt domain gt gt verwendet Die Physical Architecture bezieht sich auf die Organisation der Elemente des Systems die zur Laufzeit existieren Typische Elemente sind Subsysteme Komponenten und aktive Objekte ROPES sieht f r die Betrachtung dieser Architektur unterschiedliche Abstraktionsebenen vor die in Abbildung 3 21 gezeigt werden IN x Ebene 0 lt lt system gt gt Systemebene Ebene 1 System entwicklungs ebene Ebene 2 Disziplinen lt lt subsystem gt gt Ebene 3 Software komponenten Ebene 4 Thread Ebene lt lt active gt gt lt lt active gt gt Abbildung 3 21 Abstraktionsebenen der Architektur Douglass 02 Die oberste Ebene Ebene 0 umfasst das gesamte System wie z B ein Fahrzeug oder Flug zeug Die darunter liegende Ebene Ebene 1 betrachtet Subsysteme und Ihre Schnittstellen M gliche Subsysteme im Falle eines Fahrzeugs w ren z B Antriebstrang oder Fahrwerk Subsysteme k nnen beliebig verschachtelt sein z B Antriebstrang in Motorsteuerung und 54 Softwareentwicklung Getriebe und trennen i d R noch nicht nach Hard und Softwareaspekten Diese Auf trennung in unterschiedliche Disziplinen erfolgt auf Ebene 2 In der Beschreibung zu ROPES werden hi
200. ente einer Parameterbelegung zu einer Menge ver einigt Dadurch wird beispielsweise das Muster Blackboard nur einmal instanziiert der Para meter ConcreteDataHolder jedoch mit drei Elementen f r diese Instanz belegt Vorraussetzung daf r ist dass der Zielparameter eine Multiplizitat gr er als Eins hat Parameter die keine eingehenden Pfeile haben m ssen bei der Instanziierung entweder mit Standardwerten belegt oder vom Nutzer spezifiziert werden Das Beispiel des Strategy Musters zeigt dass die Instanziierung eines Musters an Bedingungen gekn pft werden kann Eine solche Bedingung kann sich auf eine nichtfunktionale Anforderung oder die Implementierungsplattform Abfrage der technischen Systemarchitektur beziehen womit der oben angesprochenen Variabilit t Rechnung getragen wird Verfolgbarkeit ber die beschriebene Unterst tzung bei der Erstellung von Designmodellen hinaus konnte ein weiterer Mehrwert der Systematik beobachtet werden Werden f r alle Muster die Bindungen und zus tzlich f r die Designmusterinstanzen die Abh ngigkeit zur Analysemusterinstanz ge speichert so ergibt sich eine Grundlage f r einen Verfolgbarkeitsmechanismus Dieser erlaubt es entlang der verkn pften Musterinstanzen und deren Parameter durch die Modelle zu navigieren Abbildung 3 49 zeigt einen solchen Pfad f r das Designmodell aus Abbildung 3 47 Exemplarisch ist die Situation geschildert in der ein Entwickler ermitteln m chte welche Funktion
201. epr sentiert ein Grundger st aus mehreren Klassen das nach dem Schema des MDA Toolkits bei der Definition der Transformation als Plug in ben tigt wird Dazu geh ren Klassen f r die Anpassung der Parameter des Men s und der vor der Transformation angezeigten Dialoge Die Klasse POTAD Transformation selbst enth lt eine Methode die von dem MDA Toolkit aufgerufen wird wenn der Benutzer die Transformation startet In dieser Methode werden die Parameter ausgelesen und verarbeitet sowie anschlie end ber eine Methode der Klasse RuleCoordinator die Ausf hrung der Regeln gestartet Diese Klasse enth lt eine Reihe von statischen Feldern in denen die Werte der Transformationsparameter Stacks f r Variablen und Argumente aus den Transformationsregeln sowie Flags f r verschiedene Modi im gesamten Paket zugreifbar gemacht werden Im operationalen Teil liest die Klasse alle Regeln in dem als 168 Modelltransformator Parameter angegebenen Verzeichnis fur die Regeldateien aus und koordiniert jeweils die Initialisierung und den Aufruf von Scanner und Parser Die Klasse Parser ist Ergebnis der Generierung mittels CUP und beinhaltet in den semantischen Regeln die Aktionen die bei Erkennung eines bestimmten Teilworts durch den Parser aus gef hrt werden siehe folgendes Unterkapitel Diese Aktionen bestehen darin den Inhalt der Stacks oder die Modi zu ver ndern sowie ber die beiden Klassen XDEHandler und Dialogs Muster im Analysemodell zu
202. er S peedAdj ustingLever _Subscriber eE Subscriber Bind ConcreteSubscriber InputRepository updateMethode set CurrentS peed Publisher S peedSensor DesiredSpeed CurrentSpeed bind Bind Repository InputRepository Data DesiredSpeed Current C nutren Speed Client CruiseController_Master g _Throttle 0 1 _InputRepository bind Bind ControlLoop CruiseController_ControlLoop Sensor Inputr Repository Actuator Throttle Sensor_getMethod getDesired Speed getCurrentSpeed Actuator_setMethod setThrottleSet op Value Context CruiseController_ Master _CruiseController_ControlLoop bind Bind Strategy CruiseController_Strategy Concrete Strategy Comfort Sport Algorithm const Interface cruise Context CruiseController_Co nalen CruiseController_Strategy Abbildung 3 45 Analysemuster ClosedLoopControl am Beispiel eines Tempomaten und einem auf Wartbarkeit und Wiederverwendbarkeit optimierten Design 99 3 Stand der Technik N ReferenceValue Signal bind ClosedLoopController Class Bind ClosedLoopController ClimateController Feedback FeedbackValue Signal Value CurrentT emperature ControlOutputValue Compressor ControlOutputValue Signal SetValue ReferenceValueS ource T emperatureDirector Control ReferenceValueSo
203. er Auswertungslogik bereits in den semantischen Regeln der Parserspezifikation zu integrieren Zunachst wurde eine Scannerspezifikation auf Basis einer an Java orientierten Vorlage verfasst die Konstrukte wie die Berucksichtigung von Kommentaren der Aufbau von Bezeichnern und die Erkennung von Strings bereits enthalt Dementsprechend erlaubt das Plug in in den Trans formationsregeln die Verwendung von Kommentaren Bezeichnern und Strings nach dem Vor bild von Java Auf Basis dieser Spezifikation wurde der Java Code fur den Scanner erzeugt der nur aus einer Klasse besteht Bei der Spezifikation des Parsers im nachsten Schritt wurden die vom Scanner zuruckgelieferten Symbole als Terminale verwendet sowie in Anlehnung an die Grammatik in EBNF siehe Kapitel 4 3 3 b verschiedene Nichtterminale definiert Die Grammatik in EBNF Darstellung konnte als Grundlage dienen musste allerdings an CUP spezifischen Vorgaben angepasst werden Innerhalb der semantischen Regeln wurde die Auswertungslogik fur die Trans formationsregeln implementiert AbschlieBend wurde der Parser generiert der aus einer Klasse f r die Symboltabelle und einer weiteren f r die Parserlogik besteht 5 1 3 Benutzung Im Folgenden soll ein typisches Anwendungsszenario des Plug ins mit Hilfe einiger Screenshots erlautert werden Vor dem Start der Transformation muss der Benutzer ein Analysemodell unter Verwendung von Analysemustern erstellt haben und die zu verwendenden Trans fo
204. er Hardware behandelt werden indem auf die redundanten Elemente um geschaltet wird systematische Implementierungsfehler werden damit jedoch nicht adressiert Ein Channel fasst in dem Muster die Klassen Controller Sensor Actuator InputDataValidation und ActuationValidtion zusammen Dieses Gespann wird zweimal instanziiert so dass die Klasse Context Zugriff auf zwei Channel hat Grunds tzlich wird der zuerst instanziierte Channel verwendet Erkennen die Klassen InputDataValidation oder ActuationValidation einen Fehler wird das Attribut channelState auf false gesetzt Die Klasse Context fragt dieses Attribut periodisch ab und setzt im Falle von false das Attribut useSecondChannel auf true womit auf den zweiten Channel umgeschaltet wird 216 8 Model View Controller ModelViewContr 8 1 Zweck Modell Darstellung und Steuerung einer interaktiven Anwendung in separaten Objekten kapseln 8 2 Struktur Observer Model Class View 1 Class ar eee Controller 1 oe i update Observer ModelViewContr _ View Controller lt Controller gt manipulate lt View gt initialize display handleEvent lt View gt 1 lt Controller gt 1 2 o 0 _ lt Model gt Model 1 lt Model gt attach detach getData 8 3 Erl uterung Das
205. er Hilfsregel Sie enth lt einen Verweis auf die aufzurufende Regel TrafoRule sowie eine Menge von TrafoParamBindings die alle Parameter der aufzurufenden Regel mit Mengen von Modell elementen belegen 159 4 Eigener Losungsansatz POTAD TrafoParamBinding Transformation Rule Parameter Binding Bezieht sich auf den Aufruf einer Transformationsregel RuleAppliance und stellt eine Ver kn pfung zwischen einem TrafoParameter aus der zugeh rigen Regel TrafoRule und einer Menge von Modellelementen Element her Bei Verwendung des TrafoParameters auf der rechten Seite einer Regel wird dieser durch die ber das TrafoParamBinding angegebene Menge ersetzt Mit dem Attribut iterate wird festgelegt ob bei einer Belegung des Parameters mit einer Menge von Elementen ber diese iteriert also die zugeh rige Hilfsregel f r alle Elemente aus der Menge ausgef hrt werden soll 4 3 2 Offene Punkte Das Metamodell der Transformationssprache regelt nicht jedes Detail So bleibt die Frage offen wie die Erzeugung von Elementen im Detail formuliert werden soll Hier ist zum einen entscheidend ob man nur das Element an sich z B nur eine Klasse oder auch bereits ab h ngige Elemente z B eine Klasse inklusive aller ihrer Attribute und Operationen erzeugen will Zum anderen ergibt sich das Problem dass f r neu erzeugte Elemente im Designmodell die keine Grundlage im Analysemodell haben Namen gefunden werden m ssen Daf r gibt es ver
206. er beteiligten Technologien und die z T noch fehlende Standardisierung Speziell im Bereich der Modelltransformationen gibt es momentan noch sehr viele unterschiedliche Ans tze die i d R noch experimentellen Status besitzen Auch gibt es nur wenig Arbeiten die sich umfassend mit der konkreten inhaltlichen Ausgestaltung von Modelltransformationen in einer bestimmten Dom ne besch ftigen Entsprechend gibt es auch kaum fundierte Daten um welchen Umfang sich der Auto matisierungsgrad tats chlich erh hen l sst 1 2 Problemstellung Die modellgetriebene Entwicklung verspricht Informationen unterschiedlicher Entwicklungs phasen durchg ngig in formalisierten Modellen zu erfassen und berg nge zwischen Modellen teilweise automatisieren zu k nnen Aufgrund dieser Eigenschaften scheint sich dieser Ansatz auch f r die Integration von System und Softwareentwicklung bei der Entwicklung von Automotive Software anzubieten Zum einen sind die geforderten Modelle f r beide Ebenen vorhanden zum anderen werden viele aktuelle Herausforderungen im angesprochenen Bereich der Komplexitatsbeherrschung adressiert 6 Abgrenzung Im Vergleich zu vielen anderen IT Anwendungsdom nen existieren in der Form der System modelle zu Beginn der Softwareentwicklung umfangreiche Informationen zu den Anforderungen mit hohem Formalisierungsgrad Hier lasst sich vermuten dass sich diese systematisch in der Softwareanalyse wiederverwenden lassen und dass mit Hi
207. er die Disziplinen Elektrik Elektronik Mechanik Software und Chemie genannt Die oben erw hnte Motorsteuerung kann z B in Elektrik Elektronik Aspekte Sensoren f r z B Luftmasse oder druck Steuerger t Aktuatoren wie z B Z ndkerze oder Einspritzpumpe Mechanik Aspekte Kolben Nockenwelle Ventil etc Chemie Aspekte Mischverh ltnisse katalytische Abgasreinigung und Software Steuerungs und Regelungsprogramm das mit Hilfe der beteiligten Elektrik Elektronik Einfluss auf die Mechanik nimmt die wiederum Wechsel wirkung mit den chemischen Prozessen hat aufgeteilt werden Die Software eines Subsystems kann auf der darunter liegenden Ebene 3 in Software Komponenten untergliedert werden Dabei handelt es sich um austauschbare Softwareteile auf hoher Ebene die das Subsystem ausmachen Im Falle des Motorsteuerger ts k nnten das die unterschiedlichen Steuerungs und Regelungsfunktionen Regelung der Aufladung Leerlaufdreh zahlregelung Lambdaregelung eine Komponente f r den Umgang mit dem CAN Bus und eine Diagnosekomponente sein Auf der untersten Ebene werden Prozesse bzw Threads und ihre Nebenlaufigkeit betrachtet Mindestens eine Komponente im System erzeugt einen Thread in der UML durch den Stereo typ lt lt acitve gt gt gekennzeichnet andere k nnen sich in dem Sinne passiv verhalten dass sie nur auf Aufrufe von aktiven Komponenten reagieren Threads enthalten die Laufzeitobjekte die in dieser Abstraktionshie
208. er eine prozedurale Sprache Der letzte Fall ist aufwendiger da die objektorientierten Mechanismen der UML in der Programmier sprache nachgebildet werden m ssen und hierf r ein entsprechender Translation Style Guide erarbeitet bzw vereinbart werden muss 61 3 Stand der Technik Real Time Framework 3rd Party Components ek Compilation Compiled Object Code Generated Source Code Translation Style Guide Legacy Code Automatic Code Generation Manual Code Generation Unit Test Plan Linked Components Translation Defects Unit Test Procedures Unit Test Results Design Object Model Application Components Abbildung 3 24 Artefakte der Phase Translation Douglass 99 ROPES sieht bereits in der dieser Phase Unit Testing vor Hierbei werden Teile des Codes mit Hilfe einer Anzahl von White Box Tests durchlaufen die sicherstellen dass die Units Ein heiten intern korrekt sind und dem Design entsprechen Dies soll eine h here Qualit t und die Verringerung der Entwicklungszeit durch fr hes Erkennen von Fehlern bewirken Zu den resultierenden Artefakten dieser Phase geh ren neben dem Generated Source Code erzeugter Quellcode und den blichen Ergebnissen eines Compiler Linker Laufs die Ergebnisse die aus dem Unit Testing resultieren Dazu geh ren der Unit Test Plan der Testtiefe und breit
209. erden die bei der Transformation verwendeten globalen Optimierungskriterien des Transformationsvorgangs die entsprechenden Designmuster sowie ggf die Antworten auf gestellte Benutzerr ckfragen angezeigt POTAD Traceability Navigator Designpattern i Traceability Information Gewahltes Designpattern losedLoop_D3 PubSubscriber Gefundenes Analyse Pattern ClosedLoop_4 CruiseClosedLoop Globale Aspekte des Transformationsyorgangs Portability False Performance False Resources False Security true Betreffende Benutzerr ckfragen Userquestion Werden die Sensordaten ber einen Datenbus zur Verf gung gestellt gt False Abbildung 5 7 Ergebnis einer Abfrage f r den Kontext Designmuster 3 Die Abfrage Pattern Role Finder kann ber das Kontextmen einer Klasse im Model Ex plorer oder einem Diagramm aufgerufen werden Ziel der Abfrage ist es zu ermitteln an welchen Musterinstanzen diese Klasse beteiligt ist Wie in Abbildung 5 8 zu sehen ist ent h lt das Ergebnis die entsprechenden Muster und die Parameter die die Klasse jeweils be legt 174 Beispiel POTAD Traceability Navigator Pattern Role Fin x Traceability Information an gew hlte Klasse Fallstudie_D1 Lruiselonkrol Beteiligung an Patterns Fallstudie_D1 cloop ControlLoop Fallstudie D1 strat Context Abbildung 5 8 Ergebnis einer Abfrage f r den Kontext l asse 5 3 Beispiel Im Folgenden wird eine Transfo
210. erfolgbarkeitsinformati onen TRC Zugriff auf bereits er zeugte Elemente im Zielmodell ZBE lterationsmechanismus fur Mengen von Modellelementen IT Historie der Losung Realisiert in POTAD durch Die Metamodelle POTAD Templates POTAD Traceability und POTAD Transformations sind in das UML2 Metamodell integriert Quell sind UML Klassendiagramme und Zielmodell einer Transformation Template und TemplateBinding Semantik von TemplateInstantiation Variante der LHS die ein Template und eine InstanceVariable enth lt matched auf ein Analysemuster Festlegung der globalen Optimierungsrichtung der Trans formation mit OptimCriteria Subtypen von Query f r lokale Designentscheidungen z B bzgl der technischen System architektur Formulierung von bedingten Ausdr cken CondExpression und bedingten Parameterbelegungen CondParamBinding Anlegen der DesignTrace Beziehung durch TemplateInstantiation und Speicherung der Designentscheidungen entsprechend des XML Schemas im Attribut traceInfo Geordnete Reihenfolge der RHS und die M glichkeit erzeugte Template Instanzen ber InstanceVariable anzusprechen Attribute iterateFor in TemplateInstantiation und iterate in TrafoParamBinding Tabelle 6 1 Abgleich der L sung mit den gestellten Anforderungen aus Kapitel 3 2 5 6 2 Historie der L sung Die im L sungsansatz dieser Arbeit vorgestellten Konzepte wurden durch drei Diplomarbeiten berpr
211. ernimmt den Wert des Musterelements Demnach k nnen mit der Option Merge die Merkmale im Zielelement nicht auf ihre Default Werte zur ckgesetzt werden Ein solcher Effekt kann mit der Option Replace erreicht werden Beispiel Klasse mit f int x im Muster und f float x im Zielmodell Im Verschmelzungsergebnis hat die Klasse die Operationen f int x Preserve Bei einer Kollision wird das existierende Merkmal im Zielelement nicht ge andert Stattdessen wird ein neues Merkmal im Zielelement angelegt Beispiel Klasse mit f int x im Muster und float x im Zielmodell Im Verschmelzungsergebnis verf gt die Klasse ber beide Operationen ber ladung Bei Attributen mit unterschiedlichen Typen wird wegen des ent stehenden Namenkonflikts an das Attribut aus dem Muster ein Postfix an geh ngt _1 Replace Bei einer Kollision wird das Zielelement gel scht und durch das Musterelement ersetzt Diese Einstellung kann dazu verwendet werden um das Zielelement auf Default Werte zur ckzusetzen Beispiel Klasse mit im Muster und f float x im Zielmodell Im Ver schmelzungsergebnis hat die Klasse die Operationen No Copy Das Musterelement wird nicht in das Zielmodell bernommen Es werden alle im Muster definierten Referenzen zu diesem Element normal weiterverarbeitet Beispiel Eine als Parameter ausgewiesene Klasse in einem Muster verf gt ber Attribute und hat eine Assoziation zu einer anderen Klasse Beim Ver schme
212. estellte Regel kann das in Abbildung 3 45 und Abbildung 3 47 gezeigte Klassenmodell bis auf das graphische Layout zu 100 erzeugen Die Regel erzeugt auch keine berfl ssigen Elemente die wieder gel scht werden m ssen Zu den notwendigen manuellen Nacharbeiten einer Transformation geh rt die Verfeinerung der Beziehungen So m ssen beispielsweise ein fache Assoziationen in Kompositionen umgewandelt werden oder die Multiplizitaten angepasst werden Im B 1 ist eine umfangreichere Regel f r das Analysemuster ClosedLoopControl enthalten die unter anderem die Muster ReactiveControlloop f r zustandsbehaftete Regelungen und HeterogeneousRedundancy f r redundant erfasste Sensorwerte verwendet Dar ber hinaus sind im Anhang B weitere Transformationsregeln f r weitere Muster zu finden 182 6 Validierung und Bewertung In diesem Kapitel wird der vorgestellte Losungsansatz den gesteckten Zielen gegenubergestellt und bewertet Zunachst wird gepruft ob die gestellten Anforderungen durch den vorgestellten Losungsansatz erfullt werden die Anforderungen werden validiert Danach wird der Losungsan satz ausgehend von diversen studentischen Projekten und eigenen Erfahrungen bewertet Dabei werden die Erfahrungen mit POTAD im Rahmen der Fallstudie KFS zur Bewertung heran gezogen Abschlie end werden derzeitige Grenzen der L sung aufgezeigt 6 1 berpr fung des eigenen Ansatzes Anhand der Problemstellung aus Kapitel 1 2 und der prazisierte
213. euerung verf gt z B ber weitaus mehr Sensoren und Aktuatoren als der hier gezeigte Motordrehzahlsensor und die Drosselklappe siehe z B BOSCH 03 Die ge zeigte technische Systemarchitektur passt zu einem in der Automobilindustrie angestrebten Zukunftsszenario indem die Reduzierung der Steuerger te durch die Integration von Software funktionen weiter fortgeschritten ist 12 Ubersicht Steuergerat MMI und Kfz Management Anzeige Lenkradtasten Ruckstellknopf as Gaspedal Bremspedal Umschalter Sport Comfort i Z ndschloss 3 go s Drosselklappe Motordrehzahlsensor Steuerger t Antriebstrang und Fahrwerk Bremse Raddrehzahlsensor Sa Abbildung 2 2 Skizze der technischen Systemarchitektur der Fallstudie informell Der fur den Losungsansatz dieser Arbeit relevante Aufgabenbereich bei der Entwicklung des KFS umfasst die Abbildung der Funktionen Kfz Management Fahrfunktionen etc aus der logischen Systemarchitektur auf ein Softwaredesign das zu der in Abbildung 2 2 gezeigten technischen Systemarchitektur passt Um sich auf diese Aufgabe konzentrieren zu k nnen wurde f r die technische Systemarchitektur und die Umgebung Regelstrecke ein Software simulator entwickelt der auf einem PC ausgef hrt werden kann Abbildung 2 3 Zu dem Funktionsumfang des Softwaresimulators geh rt die Bereitstellung der Ein und Aus gabeelemente in einem GUI mit dem der Benut
214. ever Validation Validation V V FirstSpeedA djustingLever _InputDataValidation V InputData Validation om 1 SpeedAdjustingLever SpeedAdiustingle call setChannelState a Re SIRERIIEEVEN SpeedAdjustingLever CruiseController_ Master GruiseController Master i gerDesiiedspeean 1 First_ Cruise bake SpeedSensor ee periodic call step SpeedSensor Se _SpeedSensdr en tSpeed SSR UENO PES SpeedSensor Second_Cruise 1 oe Controller_ Master a l FirstSpeedSensor wer _CruiseController_ControlLoop tes CruiseController_ControlLoop SecondSpeedSensor initialize step Watchdog shutDown call alogrithminterface stroke periodic call_stroke correctivAction nn 1 primaryCalc 1 secondaryCalc Ke ControlAlgorith ntro rithm zZ Second pee aah Actuation controlSG SecondThrottle Validation ma i cle N A FirstThrottle First Actuation Long Short Validation 1l Throttle cruise cruise ae Throttle ActuationValidation i ActuationValidation Throttle Throttle a R 2 SS z B 2 OpenLoopControl 1 Transformationsregel Rule OpenLoop Template OpenLoopControl ol gt Sensorwerte in einem Repository kapseln OptimCriteria Reuse Template Blackboard ol OpenLoopController Master Client InputRepository Blackboard 230 ol ControlInputValuetol ReferenceValue ConcreteDataHolder inputRep Sensorwerte von ei
215. f Basis dieser Erkenntnisse k nnen auch erste Feststellungen bzgl der in der Problemstellung Kapitel 1 2 gestellten Frage nach dom nenspezifischen Anforderungen an einen m glichen Modelltransformationsmechanismus zwischen Modellen der System und Softwareentwicklung gemacht werden So m ssen als Eingabemodelle die besprochenen Modelle der logischen und technischen Systemarchitektur verarbeitet werden k nnen Welche Informationen im Detail f r die Softwareentwicklung relevant und somit enthalten sein m ssen wird noch im weiteren Verlauf der Untersuchungen gekl rt Aus den gesammelten grundlegenden Anforderungen und Trends der Dom ne l sst sich weiterhin ablesen dass der Modelltransformationsmechanismus das Ausgabemodell in Hinblick auf die variierende Gewichtung der oben genannten An forderungen optimieren muss Dar ber hinaus m ssen die erzeugten Ausgabemodelle mit den Eingabemodellen verkn pft werden um so der allgemeinen Forderung in der Dom ne nach Verfolgbarkeitsmechanismen gerecht zu werden Zusammenfassend kann festgehalten werden dass seitens der Systementwicklung wesentliche Voraussetzungen erf llt sind um die Softwareentwicklung durch den Austausch von Modellen starker mit der Systementwicklung zu integrieren Durch die gestiegene Verbreitung modell basierter Methoden in der Systementwicklung kann zu Beginn der Softwareentwicklung in dieser Dom ne auf vergleichsweise stark formalisierte Informationen zur ckgegriffen werd
216. fasst ein Funktionsnettz aus drei logischen Sensoren Sollwertgebern zwei Steuerungs Regelungseinheiten sowie zwei logischen 3 1 Einleitung und Motivation Aktuatoren Zwischen diesen logischen Einheiten sind die abstrakten Signale S1 56 definiert In der technischen Systemarchitektur ist im unteren Teil ein Steuerger tenetzwerk mit einem Bus und drei Steuerger ten beschrieben die zwei Busnachrichten austauschen Dar ber ist beispiel haft f r Steuerger t 2 der Aufbau eines Steuerger ts mit seinen angeschlossenen Sensoren Sollwertgebern und Aktuatoren dargestellt Die gestichelten Linien repr sentieren die Abbildung zwischen logischer und technischer Systemarchitektur So werden beispielsweise Steuerungs und Regelungseinheiten CPUs zugeordnet sofern sie durch Software implementiert werden logische Sensoren und Aktuatoren werden den entsprechenden Sensoren und Aktuatoren auf der Hardwareebene zugeordnet und die abstrakten Signale aus der logischen Systemarchitektur werden Busnachrichten zugeordnet sofern die kommunizierenden Funktionen nicht demselben Steuerger t zugeordnet sind N amp S4 S5 if Teen Senai Steuerung 1 gt Aktuator 2 Eo ee Sollwert S6 geber 1 m O D Q y 0 lt 7 r D 3 D O y D x r
217. fi et al 03a und Sendall et al 03a werden im Folgenden einige Beitr ge zusammengefasst und eingeordnet ber die in Kapitel 3 3 2 c vorgestellten Kategorien von Realisierungsans tzen hinaus lassen sich die Ans tze noch anhand der folgenden grundlegenden L sungsideen unter scheiden e Ans tze mit formaler Fundierung Den Modellierungssprachen der OMG wird oft ein geringer Grad an Formalisierung vorgeworfen da Teile der Semantik oft in nat rlicher Sprache definiert sind Sofern Modellierungssprachen der OMG verwendet werden ber tragt sich dieser Mangel auch auf Modelltransformationen Einige Ans tze versuchen daher das Problem Modelltransformation durch bertragung auf bereits existierende formale Konzepte wie Attributgrammatiken oder logische Programmiersprachen zu l sen Dar ber hinaus werden spezifische formale Grundlagen f r eine Transformationssprache entwickelt Zu dieser Kategorie geh ren z B die Attributgrammatiken das Framework auf Basis von Maude und BOTL siehe Kapitel 3 3 5 e Anlehnung an Graphtransformationen Da sich objektorientierte Modelle auch als Graphen interpretieren lassen liegt der Gedanke nahe sich an Techniken f r Graphtransformationen zu orientieren f r die es eine umfangreiche Theorie und zahlreiche Implementierungen gibt Betrachtet man ein UML Modell als Graph so lassen sich Modell transformationen ber Graphersetzungsregeln realisieren Jede solche Regel wird ber ein linksse
218. folgung von Designentscheidungen genutzt werden Anhand eines dem POTAD Entwicklungsprozess folgenden Prototyps der die in der POTAD Transformationssprache formulierten Regeln ausf hren kann und die Verfolgbarkeit werkzeug seitig unterst tzt wird die Realisierbarkeit des L sungsansatzes gezeigt POTAD wurde durch studentische Arbeiten anhand einer Fallstudie berpr ft die typische Eigenschaften der betrachteten Dom ne abdeckt Die Ergebnisse dieser Arbeiten haben die Tauglichkeit von POTAD gezeigt die Methodik und die Transformationssprache verbessert und Grenzen aufgezeigt Abstract One answer to many current challenges in the electronic domain of automotive development is a continuous model based engineering process that integrates models of system and software development A system model describes by the use of the logical system architecture the func tions of a vehicle and through the technical system architecture the realising electronics such as control units sensors actuators and data busses During software development a software design model for selected functions of the logical system architecture must be constructed with consideration of the technical architecture and further requirements Current model based development approaches claim to automate the transition between different development phases by the concept of model transformations This concept lends itself to generate a skele ton of the software design model f
219. funktionale Anforderungen wird notwendig weil viele nichtfunktionale Anforderungen in einem konflikt ren Verh ltnis stehen siehe Kapitel 3 2 2 d Es ist die Auf gabe des Entwicklers bei der Auswahl von Mustern einen Kompromiss zu finden der alle nicht funktionalen Anforderungen des Systems im richtigen Verh ltnis adressiert Bei diesem Auswahlprozess und der Anwendung des Musters st tzt sich der Entwickler auf folgende wichtige Kernelemente einer Musterbeschreibung Das Problem beschreibt die Design aufgabe zu der das Muster passt bei Designmustern i d R die Optimierung einer Kollaboration in Richtung einer nichtfunktionalen Anforderung Im Kontext wird die Situation beschrieben in dem das Muster anwendbar ist Die Losung beschreibt die Struktur des Musters in der Form eines Klassendiagramms und evtl das Verhalten mit Hilfe von Sequenz oder Zustandsdiagrammen Da die Optimierung des Designs f r eine nichtfunktionale Anforderung oft zu Lasten anderer nichtfunktionaler Anforderungen erfolgt wird mit den Konsequenzen die Auswirkung der Musteranwendung auf andere nichtfunktionale Anforderungen erl utert Diese Kernelemente finden sich direkt oder indirekt auch in den bekannten Schemata f r die Be schreibung von Mustern wieder Im Rahmen dieser Arbeit ging es unter anderem darum aus dem vielf ltigen Angebot von Designmustern eine geeignete Auswahl f r die Dom ne Automotive Software zu finden Dazu wurde zun chst eine ber
220. g UML 2002 The Unitied Modeling Language Model Engineering Languages Concepts and Tools 5th International Conference Dresden Germany September October 2002 Ausgabe LNCS Springer 2002 261 Willink 03a Willink E D A concrete UML based graphical transformation syntax The UML to RDBMS example in UMLX Eclipse Foundation Whitepaper 2003a URL http dev eclipse org viewcvs indextech cgi gmt home doc umlx M4M03 pdf rev 1 2 Willink 03b Willink E D UMLX A graphical transformation language for MDA 2nd OOPSLA Workshop on Generative Techniques in the context of Model Driven Architecture Anaheim California USA 2003b URL http se2c uni lu tiki se2c bib_download php id 799 Yacoub et al 04 Yacoub Sherif M Ammar Hany H Pattern oriented analysis and design composing patterns to design software systems Addison Wesley Boston u a 2004 S XXIV 385 S 262 Thesen 1 Die logische Systemarchitektur der Systementwicklung lasst sich bei einem durchgangig modellbasierten Entwicklungsprozess im Rahmen der Softwareentwicklungsmethode ROPES als Analysemodell wiederverwenden 2 Sowohl in solchen Analysemodellen als auch in den nachgelagerten Designmodellen lassen sich wiederverwendbare Muster finden 3 Zwischen den Analyse und Designmustern lassen sich wiederverwendbare Realisierungs beziehungen finden 4 Diese Beziehungen zwischen den Analyse und Designmustern variieren mit den nicht funktionalen A
221. g In diesem Muster wird ein globaler und mehrere lokale Fault Handlers definiert Der Global Fault Handler sammelt Nachrichten der Loca Fault Handler und agiert als zentraler Ko ordinator f r Systemwiederherstellungs und Sicherheitsma nahmen User Interface Benutzerinteraktion ist ein wichtiger Aspekt eingebetteter Systeme In Strukturmuster dem Muster User Interface Benutzerschnittstelle interagiert das System mit dem Benutzer ber Contro amp Bedienelement und Indicators Anzeigeelement Im Gegensatz zu Aktuatoren und Sensoren unterliegt diese Interaktion blicherweise weniger harten Anforderungen z B Zeitanforderungen Das Muster User Interface beschreibt wie ein Objektmodell f r eine Benutzerschnittstelle spezi fiziert werden kann das erweiterbar und wiederverwendbar ist Tabelle 3 9 Teil 2 Analysemuster von Konrad et al 04b bersetzt aus dem Englischen Das Beschreibungsschema orientiert sich an Gamma et al 95 Hinzugef gt wurden die Felder Constraints Verhalten und Anwendbare Designmuster Die Felder Implementierung und Beispielcode wurden dagegen entfernt und das Feld Verwandte Designmuster in Verwandte Analysemuster umbenannt Das Feld Constraints stellt im Vergleich zu anderen Arbeiten eine Besonderheit dar Hier k nnen in formaler Weise Bedingungen in temporaler Logik spezifiziert werden die f r jede Instanz des Musters gelten m ssen Hie
222. g der Interfaces st rker verwoben Im n chsten Schritt erfolgt die Aufl sung der Komponenten in dem sie durch die Struktur des Musters Innenansicht der Komponente ersetzt werden Ergeb nis ist ein Klassenmodell mit verwobenen Musterinstanzen Im letzten Schritt wird dieses Klassenmodell durch die Entfernung redundanter Strukturen und der Anwendung weiterer Optimierungstechniken verfeinert und f hrt schlie lich zum letztendlichen Designmodell 80 Softwareentwicklung 3 2 4 e Muster in der UML Im letzten Unterkapitel wurde auf Arbeiten hingewiesen die sich mit der formalisierten Be schreibung der Struktur und Verhaltensmodelle eines Musters befassen Eine Zielsetzung hier bei ist den Zusammenhang zwischen dem Modell der Vorlage und dem Anwendungsmodell in dem das Muster verwendet ist so zu beschreiben dass auch im Nachhinein erkennbar ist an welcher Stelle im Modell ein Muster eingesetzt ist und welche Elemente die in der Vorlage definierten Rollen aus ben Der UML2 Standard OMG 05c liefert hierzu L sungen die im Folgenden erlautert werden Der Mustergedanke wird innerhalb des UML Standards durch zwei unterschiedliche Konstrukte adressiert Collaboration Kollaboration und Template Vorlage Die Beschreibungen sind in Kapitel 9 3 3 bzw 17 5 in OMG 05c zu finden Eine Collaboration ist in der UML2 ein Subtyp des neu eingef hrten Structured Classifier Sie beschreibt in Form von Rollen wie Elemente f r die Erf
223. g der Entwicklungsinformationen auf Basis gemeinsam genutzter Be schreibungsmittel andererseits wirft die Frage auf ob sich Software in diesem neuen Umfeld nicht systematischer entwickeln l sst als bisher Konkret stellt sich folgende Frage Ist es f r einzelne Funktionen einer formalisiert beschriebenen Systemarchitektur m glich automatisiert einen Teil des Softwaredesigns abzuleiten Moderne modellbasierte Ans tze aus dem Umfeld der Softwareentwicklung scheinen in Bezug auf diese Frage eine L sung anbieten zu k nnen F r die Integration und Wiederverwendung von formalisierten Informationen benachbarter Fachdisziplinen werden dom nenspezifische und plattformunabhangige Modelle vorgeschlagen die ein Softwaresystem problemorientiert und designunabh ngig beschreiben Mit dem Konzept der Modelltransformation scheint auch die angesprochene Automatisierung bei der Ableitung eines Softwaredesigns realisierbar zu ein Sie versprechen die p attformunabhangigen Modelle weitgehend maschinell in p attformspezifische Modelle beschreiben eine Designl sung berf hren zu k nnen Die hierbei anzuwendende Systematik spiegelt sich in Form von Transformationsregeln wider Das folgende Unterkapitel erl utert das Umfeld der Automotive Softwareentwicklung etwas genauer und wirft einige Fragen auf die sich stellen wenn man diese modellbasierten Ans tze im Kontext von Automotive Software f r die Integration von System und Softwareentwicklung nutzen
224. gement Bus CAN Sensor ECU Actuator Motordrehzahlsensor ________ Antriebstrang und Fahrwerk Drosselklappe discrete discrete ROM 512KFlash RAM 128KMemory Sensor CPU Actuator Raddrehzahlsensor 850 7 Bremse discrete discrete A deploy artifact Tempomat Abbildung 3 16 Ausschnitt eines m glichen Verteilungsdiagramms f r das KFS Bei der Modellierung weiterer Aspekte der technischen Systemarchitektur wie z B Bus kommunikation insbesondere Nachrichten Leistungsversorgung Leitungen oder die Fahrzeug topologie st t die Stereotypisierung jedoch an ihre Grenzen da eine in der Dom ne bliche Darstellungsweise auf diesem Weg kaum zu erreichen ist Die reine UML eignet sich aufgrund der wenigen Modellelemente nur sehr begrenzt zur Spezi fikation von Hardware Jeckle et al 03 Sie stellt zur Beschreibung der Hardware nur die Mittel zur Verf gung um die Verteilung von Software spezifizieren zu k nnen Ein standardisiertes und etabliertes UML Profi wurde die Situation verbessern ist aber zurzeit nicht verf gbar Wie bereits in Kapitel 3 1 3 b erwahnt wird aktuell im Rahmen des Projekts ATESST ATESST an einer neuen Version der EAST ADL gearbeitet die als UML2 Profil ver ffentlicht werden soll Sollte es den
225. gnmusterkatalog enthaltenen Muster sind in Tabelle 4 2 aufgelistet In den rechten Spalten ist eine Bewertung der Muster hinsichtlich der in POTAD betrachteten nichtfunktionalen Anforderungen zu sehen Diese Bewertung wurde als Grundlage f r die Erstellung der Transformationsregeln verwendet ist jedoch nicht das Ergebnis einer systematischen Evaluierung Sie st tzt sich haupts chlich auf Erfahrungen und Einsch tzungen die im Rahmen einer an POTAD beteiligten Diplomarbeit gewonnen wurden siehe Kapitel 6 2 Grunds tzlich wurde bei der Bewertung eines Kriteriums als Referenz ein Design mit m glichst wenigen Objekten herangezogen in dem Kommunikation zwischen Objekten ber ffentliche Attribute realisiert wird und komplexe Algorithmen in einer Operation unter intensiver Nutzung von Kontrollstrukturen implementiert sind Entstehen durch die Anwendung eines Design musters redundante oder aus funktionaler Sicht berfl ssige Daten wird der Speicherverbrauch mit bewertet Die Laufzeit wird mit bewertet wenn neue Iterationen oder Suchaktivi taten notwendig werden Kommen durch das Muster nur wenige Anweisungen ohne Schleifen hinzu wird dies mit 0 bewertet Diese Regeln k nnen jedoch nur als grobe Orientierung verstanden werden 153 4 Eigener Losungsansatz POTAD Bewertung hinsichtlich nichtfunktionaler Anforderungen Blackboard Verteilt erzeugte Daten zentral in einem Objekt kapseln und ber eine generis
226. gram ming Ausgabe March 1995 Kolodziejczyk 05 Kolodziejczyk Gregor Der Einsatz von Mustern bei Analyse und Design von eingebetteten Echtzeitsystemen Diplomarbeit Fachhochschule Bochum 2005 Konrad et al 04a Konrad Sascha H C Cheng Betty Campbell Laura A Object Analysis Patterns for Embedded Systems Department of Computer Science Michigan State University East Lansing Michigan 2004a Konrad et al 04b Konrad Sascha Cheng Betty H C Campbell Laura A Object Analysis Patterns for Embedded Systems EEE Transactions on Software Engineering Ausgabe 30 IEEE 2004b S 970 992 Kruchten 04 Kruchten Philippe The Rational Unified Process An Introduction An Introduction Addison Wesley Object Technology Series Addison Wesley Longman Amsterdam 2004 Lalanda 98 Lalanda Philippe Shared repository pattern Proceedings of Pattern Languages of Programs 98 1998 URL jerry cs uiuc edu plop plop98 final_submissions P24 pdf Lea et al 94 Lea D Alexander Christopher An ntroduction for Object Oriented Designers ACM Software Engineering Notes 1994 URL http g oswego edu dl ca ca ca html Ledeczi et al Ledeczi A Maroti M Bakay A Karsai G Garrett J Thomason C Nordstrom G Sprinkel J Volgyesi P 7he Generic Modeling Environment URL http www isis vanderbilt edu Projects gme GME20000Overview pdf L nn et al 04 L nn et al Henrik Report Definition of lang
227. gy Context lt Strategy gt Strategy u contextinterface AlgorithmInterface Context Class Strategy Class ConcreteStrategy 1 Class _ AlgorithmInterface Operation ConcreteStrategy a un gt Algorithminterface ee mit dem bisher erzeugten Modell Ausschnitt wie folgt verschmolzen x CruiseController_ControlLoop initialize step shutDown X contextinterface bind Bind Strategy CruiseController Strategy Concrete Strategy Comfort Sport algorithm eontlsrat Interface cruise Context SE ONONE coer _CruiseController_Strategy X Konflikt Element erg nzt bestehendes Element X Konflikt Element wird nicht neu angelegt Da der Parameter Context mit der existierenden ControlLoop Instanz verwoben ist gibt es hier einen Konflikt und die Klasse CruiseController_ControlLoop wird nicht neu angelegt Im 179 5 Prototypische Umsetzung Rahmen der Verschmelzung wird jedoch der existierenden Klasse die Operation contextInterface hinzugef gt gr nes Kreuz die in der Template Struktur von Strategy f r Context vorgesehen ist Nach der Instanziierung des Musters Strategy ist das in Abbildung 3 45 gezeigte Design erzeugt und die Regel f r das Optimierungskriterium Reuse abgeschlossen Die folgenden Template Instanziierungen werde
228. h die Ansatze die viele Kriterien bereits erfullen entsprechend er weitern lassen fuhrte zu einem negativen Ergebnis 133 3 Stand der Technik 3 4 Prazisierte Problemstellung Die Untersuchungen dieses Kapitels haben die Moglichkeiten und Mangel existierender Ansatze fur Modelltransformationen in Bezug auf erarbeitete Anforderungen der Domane Automotive Software aufgezeigt Die hier betrachteten Modelltransformationen sollen im Kontext einer stark integrierten System und Softwareentwicklung eingesetzt werden Sie verfolgen das Ziel ein als Analyse modell erfasstes Funktionsnetzwerk automatisiert in ein Grundger st eines Software Designmodells zu berf hren Neben der M glichkeit die von der Entwicklungsmethode vor gesehenen Analyse und Designmodelle verarbeiten zu k nnen wird eine zentrale Heraus forderung darin gesehen bei der Formulierung von Transformationsregeln die in der Dom ne bliche Entwicklungssystematik auf einfache Weise abbilden zu k nnen W hrend die Verarbeitung der relevanten Modelle von vielen der untersuchten Ans tze unter st tzt wird ergeben sich aus dem zweiten Punkt folgend Problemfelder 1 F r die betrachtete Dom ne wurden die in der Referenzmethode ROPES verankerten Muster als Grundlage einer Systematik f r den bergang von Analyse zu Designmodellen identifiziert Mit Hilfe einer Ad hoc Notation wurde anhand einzelner Beispiele aufgezeigt wie sich eine Modelltransformation als I
229. he Kapitel 3 2 4 Das resultierende Artefakt ist das Architectural Design Model das im Wesentlichen die Dia gramme aus dem System Engineering und der Object Analysis um architekturspezifische Inhalte erg nzt Dies umfasst z B das Hinzuf gen von Protokollklassen f r die Kommunikation in Multiprozessorumgebungen und das Markieren aktiver Klassen durch den Stereotyp lt lt active gt gt bei der Festlegung von Threads Mechanistic Design Das Mechanistic Design dient der Verfeinerung der Zusammenarbeit zwischen den Objekten Die Aktivitat ist die Erarbeitung von einzelnen Kollaborationen durch Hinzuf gen von Glue 60 Softwareentwicklung Objekten wie z B Container oder Iteratoren G ue Objekte sorgen fur einen Zusammenhalt von bestimmten im System existierenden Objekten Falls z B ein Controller viele eintreffende Nachrichten verwalten soll so ist es notwendig dass ein Container FIFO angelegt wird und zus tzlich ein Iterator der es erm glicht die Eintr ge des G ue Objekts zu manipulieren Durch die intensive Nutzung von Mechanistic Design Patterns siehe Kapitel 3 2 4 werden auch in dieser Phase Muster als zentrales Hilfsmittel genutzt Als Artefakt entsteht das Mechanistic Design Model das eine Weiterentwicklung der Klassen Sequenz Zustands und Aktivit ts diagramme aus der vorgelagerten Phase ist Detailed Design Das Detailed Design optimiert die interne Struktur und das Verhalten einzelner Klassen Zu den Ak
230. he Systemarchitektur des KFS Das KFS deckt die Fahrzeugdom nen Antriebstrang Fahrwerk Fahrfunktionen und Telematik Kombiinstrumentfunktionen ab siehe Kapitel 3 1 1 f Damit sind zwei Subdom nen mit recht unterschiedlichen Eigenschaften vertreten So handelt es sich bei den Fahrfunktionen 11 2 Fallbeispiel Kombiinstrument und Fahrfunktionen berwiegend um kontinuierliche Funktionen die Kfz Managementfunktionen und das Kombi instrument haben reaktiven Charakter Im Rahmen der Fallstudie wurde von der in Abbildung 2 2 grob und informell skizzierten technischen Systemarchitektur ausgegangen Es gibt zwei Steuerger te die ber einen Feldbus wie z B CAN verbunden sind e Mensch Maschine Interaktion MMI und Kfz Management An dieses Steuerger t sind alle f r die Benutzerinteraktion notwendigen Bedien und Anzeigeelemente an geschlossen Im Steuerger t werden die Eingaben ausgewertet verarbeitet und ggf die An zeigeelemente aktualisiert Einige Eingaben Brems und Gaspedalstellung eingestelltes Fahrprogramm Stellung des Z ndschl ssels werden ber den Bus an das zweite Steuer ger t weitergeleitet Zu den auf dem Steuerger t lokal ausgef hrten Softwarefunktionen ge h ren neben der Berechnung der Anzeigewerte die Kfz Managementfunktionen Kapitel 4 in Anhang C Um diese Funktionen ausf hren zu k nnen m ssen ber den Bus der Wert des Raddrehzahlsensors und auftretende Fehlermeldungen des Steuerger ts
231. heitlicht F r einzelne Use Cases werden Objekt kollaborationen gebildet Im weiteren Schritt k nnen an dieser Stelle bereits Schl sselmethoden und attribute der Klassen definiert werden Im Rahmen der parallel durchgef hrten Objekt Verhaltensanalyse Object Behavioral Analysis wird das Verhalten modelliert das f r eine korrekte Funktion des Systems essentiell ist Idealisierweise erfolgt dies in einer Umgebung in der die Modelle ausf hrbar sind und somit gegen die Use Case Beschreibungen validiert werden k nnen Das Object Structural Model ist das resultierende Artefakt der Strukturanalyse Es besteht aus Klassen und Objektdiagrammen die unter anderem die Vererbungshierarchie und die Kollaborationen der Schl sselklassen und Objekte zeigen Das Object Behavioral Model besteht als resultierendes Artefakt der Objekt Vehaltensanalyse aus einer Auswahl aus Zustands Aktivit ts Sequenz Kollaborations und Zeitdiagrammen 3 2 2 d Design Die Designphase definiert eine spezielle auf die Projektziele hin optimierte L sung die konsistent mit dem Analysemodell ist Die Optimierung ist durch nichtfunktionale An forderungen getrieben z B in den Bereichen Vorhersagbarkeit Datendurchsatz Zuverl ssig keit Sicherheit Wiederverwendbarkeit Portierbarkeit Wartbarkeit Skalierbarkeit Komplexi tat Ressourcenverbrauch Energieverbrauch und Entwicklungsaufwand Die Herausforderung liegt in der Tatsache dass einige dieser Anforderunge
232. hender Transformationsregeln wurde mit Hilfe des Modelltransformators unter Ver wendung desselben Analysemodells und derselben Anforderungen wie in der ersten Arbeit ein Designmodell erzeugt Der Vergleich mit dem Referenzmodell ergab dass das erzeugt Modell in gro en Teilen mit dem Referenzmodell bereinstimmt Der Modellierer des Referenzmodells stufte das erzeugte Modell als ein verwendbares Grundger st ein Es wurde jedoch beobachtet dass in dem manuell erzeugten Referenzmodell zus tzliche Designmuster vorkommen die sich nicht direkt mit einem Analysemuster in Verbindung bringen lassen im Zusammenspiel mit den brigen Designmustern aber sinnvoll erscheinen Au erdem wurden manche Designmuster durch Regeln unterschiedlicher Analysemuster mehrfach angelegt Hier war ein Optimierungsschritt notwendig der einzelne Instanzen desselben Mustertyps zu einer Instanz vereinigte Diese beiden Punkte sind Grenzen von POTAD die in Kapitel 6 3 vertieft werden Die dritte Arbeit Fischer 05 besch ftigte sich neben der Evaluation unterschiedlicher Werk zeugumgebungen und der Implementierung des Verfolgbarkeitsnavigators auch mit der Nutzung von POTAD in der Detailed Design Phase Die bisherigen Arbeiten hatten Designmusterbiblio theken verwendet deren Muster zwar die Verwendung einer objektorientierten Programmier sprache voraussetzten programmiersprachenspezifische Details aber offen lassen Als Beispiele seien hier Unterschiede bei Java und C i
233. her Subscriber PubSubscriber 10 1 Zweck Zustandsanderungen eines Objekts unidirektional an registrierte Abonnenten schicken 10 2 Struktur Publisher Subscriber lt Publisher gt Subscriber notifySubscribers F updateMethod atach detach Publisher Class ConcreteSubscriber 1 Class ConcreteSubscriber updateMethod Operation updateMethod PubSubscriber 5 a ubSu i we SS 10 3 Erlauterung Das Publisher Subscriber Muster stammt urspr nglich von Buschmann Buschmann 98 wurde in der hier gezeigten Form jedoch f r die Darstellung als UML Klassendiagramm angepasst Es stellt einen Benachrichtigungsmechanismus zwischen einem Herausgeber Publisher und mehreren Abonnenten ConcreteSubscriber die ber eine abstrakte Schnittstelle Subscriber definiert sind dar ndern sich Daten bei dem Herausgeber so schickt dieser den neuen Daten stand an alle registrierten Abonnenten Operationen notifySubscribers und updateMethod Das Muster kann berall dort eingesetzt werden wo Signale nur in eine Richtung aber an mehrere Empf nger kommuniziert werden Im Gegensatz zum Muster Oberserver von Gamma et al 95 handelt es sich um reine Push Kommunikation 11 ReactiveControlLoop 11 1 Zweck Algorithmen fur unterschiedliche Zustande einer Regelung Steuerung in separaten Objekten kapseln 11 2 Struktur
234. hnung durch unterschiedliche Algorithmen absichern und diese in separaten Objekten kapseln Singleton Sicherstellen dass es von einer Klasse nur eine Instanz gibt und diese global zur Verf gung stellen State Verhalten f r unterschiedliche Zust nde in eigenen Objekten kapseln Strategy Eine Familie von austauschbaren Algorithmen definieren und in separaten Objekten kapseln TemplateMethod Das Skelett eines Algorithmus definieren und einzelne Rechenschritte in separate Objekte auslagern Watchdog Eine Zeit berwachung in einem Objekt kapseln Muster wirkt positiv auf diese Anforderung Wartbarkeit Portabilit t Erweiterbar Muster wirkt neutral auf diese Anforderung keit Wiederverwendung Muster wirkt negativ auf diese Anforderung ee N q J oO Tabelle 4 2 Teil 2 Muster des Designmusterkatalogs Teil 2 4 3 Modelltransformationssprache Ziel der in diesem Kapitel beschriebenen Transformationsregeln ist es fur ein Analysemuster in Abh ngigkeit von nichtfunktionalen Anforderungen und der technischen Systemarchitektur durch die Instanziierung von Designmustern eine Designvorlage zu erzeugen Grundlage der L sung ist die bereits in Kapitel 3 2 4 8 beschriebene Systematik und das in Kapitel 3 2 5 skizzierte Grobkonzept mit den dort ebenfalls gesammelten Anforderungen Der im Folgenden vorgestellte Ansatz f r Transformationsregeln greift die in Abbildung 3 48 skizzierte Grundidee auf die Parameterabhang
235. hrt eine Software aus die das Steuerungs und Regelungsverhalten implementiert Ein solches Steuerger t ist f r den Fahrer oft unsichtbar und verf gt ber keine direkte Benutzerschnitt stelle Es bildet mit den Sensoren und Aktuatoren oft eine integrierte elektronische Komponente die eng mit der Software verzahnt ist Ein Steuerger t wird in diesem Kontext daher auch als eine funktionale Einheit aus Hard und Software betrachtet Aufgrund dieser Merkmale spricht man bei Automotive Software auch von eingebetteten Systemen Viele dieser Funktionen m ssen zyklisch in festen Abst nden aufgerufen werden um ihre Regelungs oder Steuerungsaufgabe zuverl ssig und stabil zu erf llen Au erdem muss bei manchen Funktionen aus Sicherheitsgr nden sichergestellt werden dass auf das Auftreten eines Ereignisses innerhalb einer vordefinierten Zeitschranke reagiert wird Aus diesen Gr nden unter liegt Automotive Software oft auch Echtzeitanforderungen 18 Systementwicklung 3 1 1 b Zuverlassige und sichere Systeme Bei vielen Softwarefunktionen im Fahrzeug kann ein Ausfall im Extremfall f r den Fahrer zu einem t dlichen Risiko werden Aus diesem Grund haben die Analyse der Funktionssicherheit und die Spezifikation geeigneter Konzepte die dieses Risiko mindert einen hohen Stellenwert F r ein fehlertolerantes Verhalten sind z B geeignete Ma nahmen f r die Fehlererkennung und die Fehlerbehandlung zu implementieren Viele Sicherheitsmechanisme
236. ichnet eine bestimmte TemplateInstance aus dem Template Metamodell siehe Kapitel 4 2 1 so dass diese innerhalb einer Regel ber den Namen angesprochen werden kann Templatelnstantiation Stellt eine m gliche Variante einer Expression dar und kennzeichnet die Erzeugung einer neuen Template Instanz Dazu wird das Template sowie eine Menge von TemplateParameterSubstiutions beide aus dem Template Metamodell siehe Kapitel 4 2 1 angegeben wobei die TemplateParameterSubstiutions sich auf alle notwendigen Parameter des angegeben Templates beziehen und mit diesen bez glich Typ und Multiplizitat vereinbar sein m ssen Einzelne Para meter k nnen auch mit bedingter Verzweigung belegt werden siehe ConcdParamBinding Bei der Erzeugung wird eine TemplateInstance des angegebenen Templates expandiert indem die Para 158 Modelltransformationssprache meterersetzung getreu der Bindung vorgenommen und die Struktur mit dem Zielmodell ver schmolzen wird Zusatzlich wird eine Verfolgbarkeitsbeziehung von der neuen Instanz zur Instanz des Analysemusters auf der linken Seite erzeugt f r die die Regel ausgef hrt wird Falls es sich um einen bedingten Ausdruck handelt werden mit dieser Beziehung auch die Be dingungen festgehalten Optional kann mit der TemplateInstantiation auch eine InstanceVariable definiert werden die f r den restlichen Teil der Regel als Kennzeichner der neu angelegten Template Instanz dient Mit dem Attribut iterateFor wird gege
237. ichtlinien f r deren Beziehungen untereinander Buschmann 98 Beispiel muster sind Layers Broker und Mikrokernel In der ROPES Methode siehe Kapitel 3 2 2 werden Architekturmuster in der Phase Architectural Design verwendet e Designmuster liefern f r wiederkehrende Designprobleme eine L sungsvorlage f r das Designmodell in der Form von Klassen bzw Objektkollaborationen F r die GoF be schreiben Designmuster eine allgemein wiederkehrende Struktur aus kommunizierenden Komponenten die ein generelles Designproblem f r einen bestimmten Kontext l sen Gamma et al 95 Buschmann et al definieren ein Designmuster als ein Schema f r die Verfeinerung von Subsystemen oder Komponenten eines Softwaresystems oder die Be ziehungen zwischen ihnen Buschmann 98 Beispielmuster sind Strategy State und Proxy In der ROPES Methode siehe Kapitel 3 2 2 werden Designmuster in der Phase Mechanistic Design verwendet weswegen sie hier auch als Mechanistic Design Patterns be zeichnet werden e Idioms liefern f r wiederkehrende Designprobleme ein Codeger st in einer bestimmten Programmiersprache Es wird beschrieben wie bestimmte Aspekte von Komponenten oder Beziehungen zwischen ihnen unter Ausnutzung besondere Eigenschaften der Programmier sprache implementiert werden k nnen Beispiele sind Singleton in C Buschmann 98 und Counted Pointer Coplien 91 In der ROPES Methode siehe Kapitel 3 2 2 passen Idioms zur Phase
238. ie Softwareentwicklung ein gebettet ist Dieses Kapitel erlautert die Dom ne in Hinblick auf diese Merkmale Die Ausf hrungen st tzen sich dabei im Wesentlichen auf Schauffele et al 03 Nach den derzeitigen Recherchen ist dies einige der wenigen Arbeiten die Automotive Software Engineering f r die Verwertung im Kontext einer wissenschaftlichen Arbeit ausreichend systematisch und umfassend beschreibt 3 1 1 Grundlegende Anforderungen der Dom ne Die folgenden Unterkapitel gehen auf grundlegende Anforderungen die im Automobilbereich an softwareintensive Systeme gestellt werden ein 3 1 1 a Eingebettete Regelungs und Steuerungssysteme Die meisten Softwarefunktionen im Fahrzeug haben steuerungs oder regelungstechnischen Charakter Regelungs und Steuerungssysteme habe die Aufgabe mit Hilfe von Sensoren Soll wertgebern und Aktuatoren eine Strecke zu beeinflussen oder zu berwachen Abbildung 3 2 zeigt wie sich der grundlegende logische Aufbau solcher Systeme bei einem Fahrzeug darstellt ar Sollwertgeber suey bine Aktuatoren Strecke Sensoren Reglung Ll De 4 Fahrzeug Abbildung 3 2 Das System Fahrer Fahrzeug Umwelt Schauffele et al 03 Im Kontext von Automotive Software Engineering werden solche Systeme betrachtet bei denen die Steuerungs bzw Regelungseinheit durch ein sog elektronisches Steuerger t engl Electronic Control Unit realisiert ist das ber einen Mikrocontroller verf gt Die CPU f
239. iese Muster schon vor der bergabe durch die Systementwicklung eingebracht werden Ein Mustereinsatz auf dem hier notwendigen Formalisierungsniveau entspricht in diesem Bereich zurzeit jedoch nicht dem Stand der Technik 4 1 2 Design Die Designphase startet entsprechend der ROPES Vorgabe mit dem Architectural Design In bereinstimmung mit Douglass 04 wird der Einsatz von Modelltransformationen in dieser Phase nicht f r sinnvoll gehalten F r die weitere Diskussion wird eine Standardarchitektur auf der Basis des Architekturmusters Cyclic Execution Douglass 02 angenommen Dieses Muster beschreibt einen Scheduler der zyklisch hintereinander die zugewiesenen Methoden von Objekten aufruft die sich alle in demselben Adressraum befinden Da es bei diesem in der Automobilindustrie sehr verbreiteten Verfahren keine echte Nebenl ufigkeit gibt m ssen auch keine Synchronisierungsmechanismen f r den konkurrierenden Zugriff auf Ressourcen vorhanden sein Die Behandlung von Nebenlaufigkeit wird bei der folgenden Diskussion von Design l sungen daher nicht diskutiert entsprechend der Abgrenzung aus Kapitel 1 3 Bei variierenden L sungen im Architectural Design m ssen die nachfolgend erlauterten Trans formationsregeln erweitert werden Die entscheidende Erweiterung der ROPES Methode durch POTAD erfolgt bei der Erstellung des Mechanistic Design Model In dieser Phase geht es um die Optimierung einzelner Objekt 141 4 Eigener Losungsansatz
240. igkeiten zwischen Analyse und Designmustern zu beschreiben In Anlehnung an die Vorgehensweise vieler Vorschl ge zu QVT siehe Kapitel 3 3 3 wurde die entwickelte Transformationssprache ber ein Metamodell definiert das die abstrakte Syntax der Transformationsregeln beschreibt In den Erl uterungen zu den einzelnen Klassen aus diesem 155 4 Eigener Losungsansatz POTAD Metamodell wird dann die statische und prozedurale Semantik in nat rlicher Sprache be schrieben Die prozedurale Semantik liefert somit eine informelle Beschreibung des Mechanis mus der umgesetzt werden muss um die Transformationsregeln auszuwerten 4 3 1 Metamodell Abbildung 4 11 zeigt das Metamodell der POTAD Transformationssprache Es ist in dem Paket POTAD_Transformations enthalten das durch die in Abbildung 4 5 gezeigten Beziehungen mit dem UML2 Metamodell integriert ist avo OR 0 1 Condition p NOT result condition 1 paramBinding formalParameter _TrafoParameter 0 1 truecase 0 1 falsecase lt gt trafoParameter V rhs ordered template designFor templateTrac templatelnstance 1 boundElement templateBinding templateTrace 1 0 1 instance templateBindingf 1 0 1 ordered instance ti parameter titution e
241. ign mdx l Durchsuchen Datei der Desigamusterbibliothek Ci Entwicklung xDE workspace POTADNPatternLib POTAD_PatterriLib mdx Durchsuchen Besen Verzeichnis f r die Transformationsregeln C YEntwicklung xDE Workspace POT AD TestTransformationen Regelr Durchsuchen Optinierungskriteriurn Performance Speicherverbrauch Sicherheit und Verf gbarkeit Wiederverwendung Wartbarkeit Portabilitat Erweiterbarkeit Benutzerr ckfragen unterdr cken Auszuf hrende Aktionen i Yalidierung der Parameter Ausf hrung der Transformation M verifikation des Ergebnisses Abbildung 5 3 Dialog mit Einstellungen f r die Transformation 171 5 Prototypische Umsetzung Mit OK wird die Transformation gestartet Nach dem Einlesen der Modelle erscheint bei Erkennung eines Musters im Analysemodell und dem Vorhandensein einer zu dem Template passenden Transformationsregel eine Meldung Nach Best tigung wird der zugeh rige rechte Teil der Regel ausgef hrt Wird in der Transformationsregel eine Benutzerr ckfrage gestellt so erscheint sofern nicht unterdr ckt ein Fenster mit dem Fragetext und den zwei m glichen Antworten oberer Dialog in Abbildung 5 3 Die Transformation wird unterbrochen bis die Frage beantwortet wird Bei der Abfrage von Namen erscheint ebenfalls ein Dialog der den Fragetext ausgibt und eine Zeichenkette als Eingabe verlangt Der untere Dialog in Abbildung 5
242. ilfe von UML Verteilungsdiagrammen engl deployment diagram bei denen Hardwareeinheiten als Modes dargestellt werden die mit einander verkn pft sind Durch die Platzierung zuvor modellierter Komponenten innerhalb der Nodes wird die Software der Hardware zugeordnet Das Architekturmodell und die erw hnten Sichten werden in unterschiedlichen Phasen ver wendet Im Folgenden werden die Mikrophasen nach ROPES genauer erl utert und der Bezug zu den Architekturaspekten hergestellt 3 2 2 c Analyse Die Analysephase identifiziert die essentiellen Eigenschaften die jede technische Umsetzung des zu entwickelnden Systems erf llen muss Das Analysemodell soll keine Angaben zu einer technischen L sung enthalten und keine Optimierungsentscheidungen treffen Die Analyse wird nochmals in drei Subphasen unterteilt Requirements Analys s System Engineering und Object Analysis siehe Abbildung 3 22 56 Softwareentwicklung Architectural Test Vectors Model Hardware Specification System Engineering Software Specification Requirements Executable Hazard Analysis Specification Specification otic Use Cases Application Requirements Requirements IN G Analysis Tested Application Object Scenarios Structural Analysis Test Vectors Requirements Specification Object Behavioral Analysis C N Object Behavioral Model Analysis Defects
243. imCriteria Reuse AND Strat Template TemplateMethod controlStrat Strategy controlStrat ConcreteStrategy controlStrat algorithmInterface calcControlDeviation calcControlValue template OptimCriteria Reuse AND NOT Strat Template TemplateMethod Reactive reacloop AbstractControlLoop cloop ControlLoop cl ClosedLoopController ConrolAlgoImpl closedLoopAlgorithm calcControlDeviation calcControlValue template Heterogene Redundanz unterst tzen Context Strategy Concrete Strategy algorithmInterface AbstractClass ConcreteClass templateMethod primitiveOperation AbstractClass ConcreteClass templateMethod primitiveOperation OptimCriteria Safety AND UserQuestion Muss heterogene Redundanz unterst tzt werden false Rd 226 Template HeterogeneousRedundancy RedundancyMaster Reactive reacloop Sensor cloop Sensor cl ClosedLoopController Channel Reactive reacloop Context cloop Context an Context Sensor Channel Controller Reactive reacloop Actuator cloop Actuator Actuator heteroRed Typische Sicherheitsmechanismen ber Hilfsregel einbringen OptimCriteria Safety makeStandardSafety Reactive reacloop AbstractControlLoop cloop ControlLoop 2 Beispiel 2 1 Analysemodell ReferenceValue Signal ClosedLoopController Class bind FeedbackValue
244. in Abbildung 4 1 dar gestellt Kapitel 4 1 stellt eine Erweiterung der Softwareentwicklungsmethode ROPES vor die einerseits auf den Kernprozess der Systementwicklung abgestimmt ist und andererseits die brigen POTAD Bausteine in den Entwicklungsprozess integriert Das darauf folgende Kapitel 4 2 umfasst eine Beschreibung des verwendeten Template Metamodells eine eigene Systematik zur Erfassung von Analyse und Designmustern und einen entsprechenden Musterkatalog der als Beispiel im Rahmen dieser Arbeit verwendet wird Die in Kapitel 4 3 beschriebene Modell transformationssprache ist der Kernteil dieser Arbeit und stellt einen neuen Ansatz f r Modell transformationen dar Dieser st tzt sich auf die zuvor beschriebenen Templates und bildet gleichzeitig die Grundlage f r den Mechanismus zur Verfolgung von Designentscheidungen aus Kapitel 4 4 Abbildung 4 2 gibt in der Form eines semiformalen UML Klassendiagramms einen berblick ber den Zusammenhang der einzelnen POTAD Artefakte und soll als Orientierungs hilfe f r die folgenden Unterkapitel dienen 137 4 Eigener L sungsansatz POTAD enth lt Logische Systemarchitektur gt EigeneMuster Funktionsnetzwer A a modelliert Ausschnitt aus Analysemustertyp PPIE PEIEE EEIT TERTE IEEE OIEI IIO EPET EPERE ETTR hat Struktur von M Analysis Object Structural Model lt T Analysemodell 1 dokumentiert De
245. in doc formal 05 07 05 OMG 05c Object Management Group OMG Unified Modeling Language Superstructure Version 2 0 2005c URL http www omg org cgi bin doc formal 05 07 04 OMG 06 Object Management Group OMG Object Constraint Language Version 2 0 2006 URL http www omg org cgi bin doc formal 2006 05 01 OMG 07 Object Management Group OMG MOF QVT Final Adopted Specification 2007 URL http www omg org cgi bin doc ptc 2005 11 01 OMG a Object Management Group OMG a Systems Modeling Language Webseite URL http www omgsysml org OMG b Object Management Group OMG b Model Driven Architecture Webseite URL http www omg org mda OMG c Object Management Group OMG c Unified Modeling Language Webseite URL http www uml org OSEK VDX 05 Offene Systeme und deren Schnittstellen f r die Elektronik im Kraftfahrzeug OSEK VDX Operating System Specification 2 2 3 2005 Pollet et al 02 Pollet D Vojtisek D Jezequel J M OCL as a core UML transformation language WITUML 2002 Position paper Malaga Spain 2002 URL http www irisa fr triskell publis 2002 Pollet02a pdf Pont 01 Pont Michael J Patterns for Time Triggered Embedded Systems Addison Wesley 2001 QVTMG 04 QVT Merge Group QVTMG Revised submission for MOF 2 0 Query Views Transformations version 1 8 2004 URL http www omg org docs ad 04 10 04 pdf Schauffele et al 03 Sch uffele Jorg Zur
246. ird dann innerhalb der Klassen in Zuweisungsregeln Assignment Rules definiert in denen die Eigenschaften mit Werten 117 3 Stand der Technik belegt werden Durch den Einsatz von OCL Ausdr cken k nnen dabei auch Bedingungen formuliert werden Als konkrete Notation f r dieses Konzept wird eine Erweiterung von UML Klassendiagrammen vorgeschlagen in denen Directions als Doppelstriche mit Namen dargestellt werden Das in Abbildung 3 53 gezeigte Beispiel vermittelt einen groben Einblick in diese Notation Es zeigt eine Transformation zwischen einem UML Klassenmodell und einem relationalen Datenbank schema Die Doppelstriche stehen f r die Directions die Klassen in der Mitte stehen f r die Transformationsklassen Sie enthalten die Mappings die Directions schneidende Assoziationen zwischen den Elementen auf der linken und rechten Seite die jeweils aus dem der Direction zugeordneten Metamodell stammen Die Kompositionsbeziehung zwischen den Trans formationsklassen impliziert dass die Ausf hrung der Transformation AttributeToColumn immer mit der Ausf hrung von ClassToT able verkn pft ist uml relational table Table from SimpleRDEMS class E class 1 F ClasstToTable from SimpleUML 1 elassToTable atrsTo Col mns k E AtributeTo Column attribute E Attribute 1 from Simple UML column 1 Column from SimpleRDEMS 1 Key pri maryKey trom SimpleROBMS Abbildung 3 53
247. ird die Sollgeschwindigkeit auch bei Steigungen oder gr erem Windwiderstand nahezu gehalten 194 bind Bind ClosedLoopController Cruise ReferenceValue Signal Controller FeedbackValue Current ClosedLoopController Class Speed ControlOutputValue Throttle FeedbackValue Signal Value ReferenceValue ControlOutputValue Signal Source Lever ControlOutputValue ReferenceValueSource Class Drain Throttle FeedbackValue ControlOutputValueDrain Class BD er Source SpeedSensor Reference Pe FeedbackValueSource Class ClosedLoopControl_CruiseControl Dane se DesiredS peed ene ere gt Se ClosedLoopControl ec SE a rn SS et a DesiredS peed becca aa Rn EES acon k anand tetera N ThrottleValue J CruiseController PEE A EE PIENI AE ASEO EIN E EA EEIN gt Throttle Lever CurrentS peed SpeedSensor Weitere Beispiele f r Regelungen im Kfz sind BOSCH 03 Lambda Regelung Drehzahl regelung bei Dieselmotoren Anti Blokier System ABS und Klimaanlage 1 5 Anwendbare Designmuster Repository Wiederverwendung Die Sensorwerte in einer Klasse kapseln und so die eigent liche Regelung von der Datenbeschaffung entkoppeln DataBus F r den Fall dass die Sensordaten ber einen Datenbus empfangen werden wird der Zugriff auf diesen in einer einheitlichen Objektstruktur gekapselt ReactiveControlLoop Fur den Fall dass die Regelung zustandsbehaftet is
248. iredSpeed get u AbstractData getCurrentSpeed CruiseController_ControlLoop CruiseController_ControlLoop AbstractData AbstractData x AbstractData initialize step shutDown DatalD i i Bus_CurrentSpeed Bus_DesiredSpeed value value 2 4 Designmodell 3 Optimierungskriterium Sicherheit und Verf g barkeit Safety Werden die Sensordaten ber einen Datenbus zur Verf gung Nein gestellt DE2Sig Muss der Regelalgorithmus mehrere Zustande unterscheiden Muss heterogene Redundanz unterst tzt werden Interface Name des redundanten Regelalgorithmus 229 RedundancyMaster First_CruiseController_Channel useSecondChannel Boolean Second CruiseController Channel periodic call getChannelState a lu heteroRed ee CruiseController_Channel i Cannel channelState Boolean CruiseController Channel setChannelState 1 getChannelState Arstinput Secondinput Data Data SecondSpeedAdjustingL
249. iredSpeed CruiseController_ AbstractState 0 1 _DataBus ses DataBuS o i 7 BR AbstractSubject Nes ee eae N LowSpeed HighSpeed SpeedSensor_ 1 _CruiseController_AbstractControlLoop remote CruiseController_AbstractControlLoop initialize step Speed AbstractDat _AbstractDat a shutDown PS Lever remote contextinterface template C controstrat Sl HSLoop LSLoop m CruiseController Strategy Comfort CrutseController_ Strategy Sport Bus_DesiredSpeed Bus_CurrentSpeed cruise L cruise q cruise talie ee calcControlValue calcControlValue calcControlValue calcControlDeviation calcControlDeviation calcControlDeviation 2 3 Designmodell 2 Optimierungskriterium Werden die Sensordaten ber einen Datenbus zur Verf gung Ja gestellt DE2Sig Muss der Regelalgorithmus mehrere Zustande unterscheiden 228 SpeedSensor _ SpeedAdjusting Throttle remote Lever_remote setThrottleSetValue SpeedSensor AbstractSubject CruiseController_ Master getDesiredSpeed lt ______ getCurrentSpeed _SpeedSensor periodic call_step eo a bus cloop 0 1 ee 7_SpeedAdjustingLever DataBus SpeedAdjustingLever 1 AbstractClient 4 update 2 DataBus getDes
250. isieren zu k nnen F r die Mapping Spezifikation die die Abbildungsregeln zwischen PIM und PSM Elementen be schreibt schlagt die OMG unterschiedliche Kategorien vor Modeltypen Mapping Model Type Mappings Es wird beschrieben wie Typen aus dem PIM Modell auf Typen des PSM Modells abgebildet werden Handelt es sich um Typen die in einem MOF Metamodell spezifiziert sind wird auch von Metamode l Mapping ge sprochen Modelinstanz Mapping Model Instance Mappings Durch das zus tzliche Anbringen von Markierungen Marks an Elemente aus dem PIM Modell wird f r jedes Element un abh ngig vom Typ entschieden wie es auf die PSM Ebene abgebildet wird Marks repr sentieren nach Vorstellung der OMG z B plattformspezifische Realisierungskonzepte oder Quality of Service Anforderungen und k nnen unter anderem in Form von Stereotypen eines UML Profils oder Rollen eines Musters realisiert sein Muster und Templates Ein Mapping kann auch mit Hilfe von Mustern und Templates beschrieben werden Unter einem Template wird in diesem Kontext ein parametrisierbares Modell verstanden das mit einem Designmuster vgl Kapitel 3 2 4 vergleichbar ist jedoch einen h heren Spezifikationsgrad besitzt Die Abbildungsregel beschreibt hierbei wie f r die Anwendung eines Templates in der PSM Ebene die Template Parameter mit Elementen aus PIM belegt werden Welche Elemente aus dem PIM f r die Parameterbelegung verwendet werden kann wieder durch Marks
251. iteln Anforderungen der Dom ne gesammelt wurden be schaftigt sich dieses Kapitel nun mit dem Stand der Technik des eigentlichen Schwerpunkt themas dieser Arbeit den Modelltransformationen Durch die im ersten Unterkapitel behandelte Model Driven Architecture MDA wird diesem Thema zun chst in Bezug auf Konzepte und Technologien ein Rahmen gesetzt Anschlie end wird das in der MDA eingef hrte Konzept der Modelltransformation vertieft Zun chst werden einige Grundlagen und Grundbegriffe zu dieser Idee erl utert und eine Reihe konzeptioneller und technischer Unterscheidungsmerkmale auf gef hrt Anschlie end werden einige konkrete Ans tze vergleichend vorgestellt Die ab schlie ende Bewertung erfolgt auf der Basis ausgew hlter Anforderungen die sich aus Unter suchungen der vorangegangenen Kapitel ergeben 3 3 1 Model Driven Architecture Engineering Die Model Driven Architecture MDA der OMG OMG b ist ein Ansatz f r modellgetriebene Softwareentwicklung siehe Kapitel 3 1 3 Die im MDA Guide Miller et al 03 beschriebene Vision umfasst die Ziele Portierbarkeit Interoperabilitat und Wiederverwendbarkeit die vor allem durch architektonische Trennung unterschiedlicher Belange architectural separation of concerns erreicht werden sollen Da der Ansatz im Umfeld von modellgetriebener Softwareent wicklung viele Begriffe pr gt und h ufig zitiert wird werden im Folgenden einige f r diese Arbeit wichtigen Begriffe und Konzep
252. itiateLocalCorrectiveAction 1 Signal e FaultHandler_ChassisPowertrain REN Handler PowertrainFaultHandler N s FaultHandler gt See nn Dr ER a ChangeStateT o z GlobaleFaultld Z O ess PowertrainFaultHandler gt CentralFaultManagement 7 GlobaleFaultld PD ChassisFaultHandler _ ee eeeeeeeeeeeeeeeteneneeeeetnnnneetetnnneetttnneeettennneeetttnn gt ChangeStateTo 4 5 Quelle Verwandte Muster Das hier gezeigte Muster geht zur ck auf das Analysemuster Fau tHandler von Konrad et al 04a Die hier gezeigte Fassung ist hinsichtlich der Signale und Musterparameter erweitert worden 4 6 Anwendbare Designmuster e ExceptionMonitor Fehler auf der Ebene einer Objektkollaboration erkennen und behandeln e Singleton Sicherstellen dass es nur eine Instanz der globalen Fehler berwachung und des globalen Logging Mechanismus gibt 5 DetectorCorrector 5 1 Zweck Beschreibt ein generisches berwachungskonzept das korrigierende Ma nahmen initiiert wenn sich das System oder einzelne Komponenten nicht mehr in einem g ltigen Zustand befinden 5 2 Motivation Viele Softwarefunktionen im Fahrzeug unterliegen besonderen Sicherheits und Zuverlassigkeits anforderungen Erf llt eine solche Funktion ihre Aufgabe nicht mehr sicher oder zuverl ssig muss eine Reaktion nach einer festgelegten Sicherheitslogik erfolgen Sch uffele et al 03 Da viele berwachungskonzepte den kombinierten Einsatz von Hard und Softw
253. itiges und ein rechtsseitiges Graph Muster dargestellt Wird eine Transformation aus gef hrt so f hrt jedes Vorkommen eines linksseitigen Graph Musters einer Regel dazu dass dieses Vorkommen durch das rechtsseitige Graph Muster ersetzt wird F r dieses allgemeine Prinzip gibt es eine Vielzahl von Methoden aus der Graphentheorie Agrawal 04 weist jedoch auf viele Unzul nglichkeiten dieser Ans tze in Bezug auf diesen Anwendungskontext hin So muss beispielsweise mit typisierten attributierten und gelabelten Graphen gearbeitet werden um UML Modelle als Graph darzustellen Da es sich bei Graphtransformationen um Ersetzungsregeln handelt ist es zudem meist erforderlich auf Kopien der Quellmodelle zu arbeiten Deshalb werden Graphtransformationen f r viele Ans tze nur als formale Grund lage oder als Inspirationsquelle f r eigene erweiterte Mechanismen verwendet Zu dieser Kategorie geh ren z B GReAT die Story Diagramms VMT und die Ans tze von Khriss und Judson Die Kategorien stellen keine disjunkten Klassen im Sinne einer vollst ndigen Klassifikation dar sondern dienen lediglich der Einordnung nach wesentlichen Charakteristiken der jeweiligen Ans tze Die in Kapitel 3 2 4 g skizzierte Systematik impliziert dass Muster in einer festen Reihenfolge instanziiert werden m ssen Anforderung ZBE Um die Untersuchung der zahl 119 3 Stand der Technik reichen Beitrage zu fokussieren werden einige Ansatze die fur diese System
254. k Die TemplateSignature wird an der Ellipse rechts oben als Kasten dargestellt Es enthalt eine geordnete Liste der TemplateParameter in der Form Name Typ Die Multiplizitat eines Parameters wird in Klammern angegeben sofern sie nicht Eins ist Unterhalb der Ellipse ist die Klassenstruktur des Templates zu sehen In dem Beispiel ist jede Klasse als Parameter ausgewiesen es waren aber auch weitere statische Klassen m glich Bei der Expansion wird die hier gezeigte Struktur der Para meterklasse mit der Struktur der tats chlichen Klassen verschmolzen Die Notation lt Parametername gt ist ein Beispiel f r StringExpression der in diesem Fall den Namen des tatsachlichen Template Parameters zur ckgibt Abbildung 4 9 zeigt eine m gliche Instanz des Strategy Musters Eine TemplateInstance wird ebenfalls als Ellipse dargestellt und hat einen eigenen Namen Das TemplateBinding wird als Abh ngigkeitsbeziehung zwischen den Ellipsen von Template und TemplateInstace modelliert Das Bind Kommando repr sentiert die ParameterSubstitution durch eine Liste von Parameter Zuweisungen in der Form formal actual Bei der Instanziierung wird die Template Struktur entsprechend der Verschmelzungseinstellung mit dem Zielmodell verschmolzen Das Attribut mergeBehavior kann im Werkzeug editiert werden ist in Diagrammen aber nicht sichtbar Dies gilt auch f r die Eigenschaft rootContext in einem TemplateBinding Die Standardeinstellung von mergeBehavior ist merg
255. ket Templates die tatsachlichen Parameter aus einem anderen Paket kommen Im Beispiel aus Abbildung 3 37 k nnte z B die Klassen Thermometer und Hygrometer aus einem Paket Sensorik stammen Bei der Behandlung dieses sehr realistischen Falls w re es aus Sicht der Musterinstanziierung w nschenswert wenn zwischen den Paketen Messung_Wetterstation und Sensorik eine Import Beziehung angelegt wird und die Klassen Thermometer und Hygrometer innerhalb von Messung Wetterstation verwendet werden Vermutlich d rfen die tats chlichen Parameter aber nur aus dem gebundenen Paket kommen was dann ein Nachteil der Paket Templates w re Eine berpr fung anhand von Werkzeugumsetzungen war nicht m glich da im Rahmen der Untersuchung kein UML2 Werkzeug gefunden werden konnte das bei der Instanziierung von Templates eine Modellverschmelzung nach den Regeln der UML durchfuhrt Ein weiterer Mangel kann in den Paket Verschmelzungsregeln gesehen werden die bei der Instanziierung von Paket Templates zum Einsatz kommen Sie sind fur die Modellierung von Metamodellen optimiert und passen bei einigen Details nicht zu den Anforderungen die man bei der Instanziierung von Mustern haben kann W rde z B die Klassen Thermometer und Wetterstation bereits vor der Instanziierung Abbildung 3 35 ber eine gerichtete Assoziation mit Namen Temperatur bertragung verf gen so w rde das Paket nach der Instanziierung Abbildung 3 36 entsprechend der Verschmelzungsregeln von
256. kt zu welchem Optimierungskriterium das Designmuster passt 151 4 Eigener Losungsansatz POTAD Der mit diesem Schema beschriebene Umfang wird fur den Umgang mit Transformationssregeln als ausreichend betrachtet Fur eine noch ausfuhrlichere Beschreibung eines Analysemusters wird das erweiterte Schema von Konrad et al 04b empfohlen Der Analysemusterkatalog findet sich in Anhang A 1 Tabelle 4 1 gibt einen berblick ber die im Katalog befindlichen Muster beschreiben OpenLoopControl Eine Steuerkette engl feedforward contro beschreiben 195 Abstrakte Beschreibung einer Benutzerschnittstelle 198 FaultHandler Beschreibt eine hierarchische Fehlerbehandlung bei der eine globale Fehlerbehandlungskomponente mehrere lokale Fehlerbehandlungskomponenten koordiniert DetectorCorrector Beschreibt ein generisches berwachungskonzept das korrigierende Ma nahmen initiiert wenn sich das System oder einzelne Komponenten nicht mehr in einem g ltigen Zustand befinden Tabelle 4 1 Muster des Analysemusterkatalogs Die beiden Muster C osedLoopControl und OpenLoopContro finden in der Fallstudie die haufigste Verwendung Sie beschreiben den charakteristischen Aufbau einer Regelung und einer Steuerung so wie er auf der Ebene der Systementwicklung betrachtet wird Beide Muster wurden auf Basis der Beschreibung DIN 19226 1 DIN 94 selbst definiert Die Muster User nterface FaultHandler und DetectorCorrector spiegeln ebenfa
257. kte Verbindung 199 3 6 Anwendbare Designmuster e Blackboard Wiederverwendung Die f r das User Interface relevanten Daten in einem Objekt kapseln und so das User Interface von der Datenbeschaffung entkoppeln e DataBus F r den Fall dass die Daten ber einen Datenbus empfangen oder gesendet werden wird der Zugriff auf diesen in einer einheitlichen Objektstruktur gekapselt e ModelViewController Modell Darstellung und Steuerung des User Interfaces in separaten Objekten kapseln e Decorator Wiederverwendung Daten f r die Darstellung aufbereiten e State Zustandsbehaftetes Verhalten der User Interface Steuerung unterst tzen 4 FaultHandler 4 1 Zweck Beschreibt eine hierarchische Fehlerbehandlung bei der eine globale Fehlerbehandlungs komponente mehrere lokale Fehlerbehandlungskomponenten koordiniert 4 2 Motivation Ein Fehler in einer Funktion kann in manchen F llen nicht durch lokale Ma nahmen behandelt werden Die Sicherheitslogik sieht f r solche Fehler Reaktionen vor die die gesamte Fahrzeug elektronik betreffen k nnen Beispielsweise ist f r manche Fehler ein Zustandswechsel in den sog Notlauf vorgesehen bei der nur noch die absolut notwendigen Funktionen aktiv sind Diese Art der Fehlerbehandlung muss zentral koordiniert werden 4 3 Struktur i LocalFaultHandler 1 Class GlobalFaultHandler Class GlobalFaultindication Signal InitiateLocalCorrectiveAction 1
258. kte aus Douglass 99 mit den durch POTAD hinzugekommenen Erg nzungen farblich markiert Die neuen Artefakte wurden nur mit den hier betrachteten Analyse und Designphasen in Verbindung gebracht Pfeile zu den anderen Phasen sind nicht ausgeschlossen 138 Erweiterung der Entwicklungsmethode Application De 7 SN Hazard Analysis Analysis Defects Analysis Object Model Tested Application Scenarios Use Cases Test Vectors N Design Defects Be Design Patterns Testing Translation Defects Design Object Model Application Components Translation X 3rd Party Legacy Code Components Real Time Framework Abbildung 4 3 Die durch POTAD erganzten Artefakte in der ROPES Methode Auf der Ebene der Systementwicklung wird der in Kapitel 3 1 2 erlauterte Kernprozess an genommen der auf dem V Modell basiert und weitgehend nach dem Wasserfallprinzip organisiert ist Im Rahmen der Softwareentwicklung kommt die in Kapitel 3 2 2 a behandelte Variante SemiSpiral der ROPES Methode zum Einsatz die eine am Spiralmodell orientierte Softwareentwicklung in einen solchen Systementwicklungsprozess einbettet Es wird von einem ber System und Softwareentwicklung hinweg durchg ngig modellbasierten Entwicklungs prozess ausgegangen der die in Kapitel 3 2 2 g skizzierte Modelllandschaft nutzt Im Rahmen der Systementwi
259. l DIDI erden lt eenecilelon 1 NOT lt eokarition UserQueskion semg be Hoolesn Te idene a Machmne uery 724 string lt boolean ident OptimCriteria lt ident gt lt ident gt lt expression gt Template lt ident gt lt argumentlist gt lt ident gt dene ih zomentelase v2 Class lt argument gt lt boolean gt Attribute lt argument gt lt argument gt lt argument gt Operation lt argument gt lt argument gt lt argument gt Association lt argument gt lt argument gt lt boolean gt Inheritance lt argument gt lt argument gt lt argumentlist gt lt argumentlist gt lt argument gt 163 4 Eigener Losungsansatz POTAD lt argument gt lt ident gt lt ident gt elements lt ident gt lt ident gt lt argument gt lt ccondition gt lt argument gt lt argument gt lt string gt lt argument gt getNames lt string gt lt int gt getNamesByMachineQuery lt string gt lt boolean gt true talse Seen IP emo Kring gt lt ident gt U lt idene gt 2 eter mop Jaye lt string_lit gt in Hochkommata eingefasster Text lt int gt Ganzzahl lt ident gt 98 Bezeichner tur eine Variable 4 4 Verfolgbarkeitsmechanismus Der Verfolgbarkeitsmechanismus von POTAD basiert auf der bereits in Kapitel 3 2
260. l f r relationale Daten banken berf hrt werden Table ET Hable or eee cl name j Sas primary ___ __ ars pk Key I name cl name ID ee eee Ss kCol Column int SQLDataType or name cl name ID nee nteger ied ee v Abbildung 3 56 Ausschnitt aus einer MOLA Transformationsregel Kalnins et al 04 125 3 Stand der Technik Eine Schleife enthalt einen Schleifenkopf der durch ein Muster mit einem Element realisiert wird und kann als einer der beiden Typen FOREACH oder WHILE deklariert werden der den Schleifenkopf entweder als Platzhalter f r ein Element bei FOREACH oder als Bedingung bei WHILE verwendet Bei der Ausf hrung der Transformation werden dann f r ein Quellmodell das eine Instanz des Quellmetamodells ist alle definierten Statements ausgef hrt In einer Erweiterung dieser basic MOLA k nnen zus tzlich noch Kardinalitatsbeschrankungen und verschachtelte Muster verwendet werden Die mit diesen Erweiterungen versehene Sprache wurde nach Angaben der Autoren anhand verschiedener typischer Beispiele aus dem MDA Umfeld erfolgreich getestet Als Vorteil wird insbesondere die intuitive Verst ndlichkeit durch die graphische Repr sentation hervorgehoben Die in den Beispielen verwendeten Muster und Regeln sind allerdings sehr einfach und beziehen sich auf separierbare Teilaspekte einer Transformation Damit bleibt offen ob sich der Ansatz auch
261. lass 99 222244444444444424220000000 00000 57 Abbildung 3 23 Artefakte der Phase Design Douglass 99 2224444444442422444420000 000000 gt 60 Abbildung 3 24 Artefakte der Phase Translation Douglass 99 22244444444222222222000 gt 62 Abbildung 3 25 Artefakte der Phase Testing Douglass 99 2224444444444444400000 02er 63 Abbildung 3 26 Gegen berstellung der Artefakte aus Kernprozess EAST ADL und ROPES linke Seite des V Models een I ale 64 Abbildung 3 27 kategorisierte und bewertete Designmuster cuesesesssesessensnnnnnnnnnnnnennennennenneennen 13 Abbildung 3 28 Analysemuster Accounting Transaction nach Fowler 97 75 Abbildung 3 29 Paketbeziehungen im Umfeld von Templates ccccccccccce seca eee eee seen eeeeeeneeeseeneeaeenneeaees 82 Abbildung 3 30 Metamodell f r die Template Definition 0 0 0 0 cocci cc cece ccc cc cece eeee een eeee een eese een eeseeeneees 83 Abbildung 3 31 Elemente die als Template deklariert werden k nnen ccccccccceccecen eee eeeeeeeeeeeenes 83 Abbildung 3 32 Elemente die als Parameter deklariert werden d rfen eeeeeeneenen 84 AbBild ng 3 33 emi lakes Bindung 2 hens se ie A oe ones 84 Abbildung 3 34 Das Template Messner ru sgnosbensuctdonemeniscaraanel 85 Abbildung 3 35
262. lche der Sichten Struktur Interaktion und Verhalten sie sich besonders eignen Konzeptuelle ber 44 Softwareentwicklung lappungen verschiedener Diagrammarten erlauben die alternative Darstellung bestimmter Sach verhalte mit Hilfe verschiedener Diagramme IESE al Use Case Analyse Diagramm Interaktions ee Kompositions bersicht a Design struktur lt diagramm u Klassen x N diagramm diagramm Objekt a Implemen dern kations Zustands tierung diagramm diagramm l Komponenten logische diagramm l Verteilungs Zeit Struktur Verhalten Interaktion intern Abbildung 3 11 Methodische Einordnung der UML Diagramme angepasst nach IESE a Welche Diagramme in einem Entwicklungsprojekt zum Einsatz kommen h ngt stark von der verwendeten Methode und weiteren Randbedingungen des Projekts ab In der Praxis hat sich gezeigt dass besonders die Klassendiagramme zur Strukturdarstellung Use Case Diagramme zur Darstellung von Anwendungsfallen Zustandsdiagramme zur Verhaltensbeschreibung und Sequenzdiagramme zur Darstellung von Interaktion zum Einsatz kommen IESE a Im Rahmen dieser Arbeit kommen ausschlie lich Klassendiagramme entsprechend der in Kapitel 1 3 be schriebenen Fokussierung auf Strukturmodelle zum Einsatz die in Kapitel 3 2 1 c n her er lautert werden 3 2 1 b UML Metamodell und Profile Die Definition der UML
263. le Meta modellierung UML Meta modellierung MOF Meta modellierung UML Beziehung Quelle Ziel alles moglich alles moglich nur innerhalb Modell nur ver schiedene Modelle alles moglich nur innerhalb Modell nur innerhalb Modell nur ver schiedene Modelle nur ver schiedene Modelle nur ver schiedene Modelle Richtung plete isle fa fafa e a bidirektional Relationen bidirektional Mappings unidirektional unidirektional unidirektional unidirektional unidirektional unidirektional unidirektional unidirektional unidirektional je Kompatibel zu Variabilitat Vorgaben indirekt Uber OCL Bed ied Trans formations parameter je indirekt ber Bedingungen indirekt ber OCL Bed am eb indirekt Kontrollfluss zwischen Regeln Benutzer wahlt Ver feinerungs schema eb Tabelle 3 12 Charakterisierung der Ans tze ber Unterscheidungsmerkmale 130 Modelltransformationen 3 3 6 b Bewertung anhand der Anforderungen Tabelle 3 13 zeigt die Ergebnisse einer Analyse in der die Erfullung der Anforderungen aus Kapitel 3 2 5 durch die noch verbleibenden Ansatze ermittelt wurden Im Falle von QVT und EXMOF konnte bei der Bewertung auf Transformationsregeln zur ck gegriffen werden die im Rahmen einer Diplomarbeit erstellt wurden siehe unten Fur die anderen beiden Ansatze konnte auf Basis de
264. le ClosedLoop Template ClosedLoopControl cl gt Sensorwerte in einem Repository kapseln OptimCriteria Reuse Template Repository cl ClosedLoopController Master Vo iG lite ite InputRepository Repository cl FeedbackValuetcl ReferenceValue Data inputRep Sensorwerte von einem Datenbus lesen UserQuestion Werden die Sensordaten ber einen Datenbus zur Verf gung gestellt DE2Sig false Bus Template DataBus Reuse inputRep RepositorytinputRep Repository ConcreteClient Icl FeedbackValueSourcetcl ReferenceValueSource cl FeedbackValueSource remote cl ReferenceValueSource remote ConcreteSubject Bus cl ReferenceValue Bus_ cl FeedbackValue Jy Coneretelara BUS Sensorwerte f r m gliche neue Konsumenten zugreifbar machen OptimCriteria Reuse AND NOT Bus Template PubSubscriber cl ReferenceValueSource Publisher inputRep Repository ConcreteSubscriber set cl ReferenceValue updateMethode refValPubSub OptimCriteria Reuse AND NOT Bus Template PubSubscriber cl FeedbackValueSource Publisher inputRep Repository ConcreteSubscriber set cl FeedbackValue updateMethode feedValPubSub Unterschiedliche Klassen f r Zust nde UserQuestion Muss der Regelalgorithmus mehrere Zust nde unterscheiden false Reactive Template ReactiveControlLoop cl ClosedLoopController Master Le OMbext cl ClosedLoopController AbstractControlLoop A
265. le Design Patterns e Watchdog Design Pattern Douglass 99 Describes more implementation specific details about the watchdog such as implementation strategies Also Known As To be determined Known Uses To be determined Related Object Analysis Patterns e Fault Handler Object Analysis Pattern Stores and handles fault messages from the watch dog 209 A 2 Designmuster 1 Blackboard 1 1 Zweck Verteilt erzeugte Daten zentral in einem Objekt kapseln und uber eine generische Schnittstelle lesen und schreiben 1 2 Struktur Client lt Blackboard gt Blackboard setData getData Client 1 Class Blackboard Class DataHolder ConcreteDataHolder 1 Class DataHolder u Blackboard B IR gt N ConcreteDataHolder 1 3 Erl uterung Das Blackboard Designmuster in der gezeigten Form stammt von Yacoub et al 04 und stellt eine stark abgewandelte Version des urspr nglichen Musters von Buschmann Buschmann 98 dar Es dient in dieser Fassung als abstrakter Datenspeichermechanismus Die Blackboard Klasse selbst verwaltet eine Reihe von Datenklassen DataHolder die jeweils als konkrete Datenklasse ConcreteDataHolder spezialisiert werden m ssen Uber den Client wird der Benutzer des Datenspeichers festgelegt der ber die Operationen setData und getData der Klasse Blackboard Daten setzen
266. le Wirkungsketten des Gesamtsystems Fahrzeug Fahrer Umwelt modelliert Das PIM kann als ein Funktionsnetz der logischen Systemarchitektur interpretiert werden das die durch Software zu realisierenden Funktionen enth lt Das PSM kann wiederum ein Softwaredesignmodell repr sentieren das auf die technische Systemarchitektur abgestimmt ist 112 Modelltransformationen 3 3 2 Grundlagen 3 3 2 a Begriffsklarung Das Konzept der Modelltransformation ist als wesentlicher Baustein des MDA Ansatzes in Bezug auf Anforderungen und Grundidee von der OMG relativ ausf hrlich beschrieben siehe Kapitel 3 3 1 Der Begriff ist jedoch schon lter und kann allgemeiner gefasst werden In der Literatur z B Czarnecki et al 03 wird zun chst zwischen mode to mode und model to text unterschieden Letztere beschr nken sich dabei auf die Generierung von Text z B f r Dokumentationszwecke oder Datenaustausch oder Programmcode was im Deutschen meist mit Codegenerierung bezeichnet wird Genau genommen stellen diese Textformen jedoch auch ein Modell eines Systems dar so dass keine klare Trennung vorgenommen werden kann Im Rahmen dieser Arbeit wird der Fokus auf Transformationen zwischen solchen Modellen gelegt die ber ein MOF basiertes Metamodell und eine graphische Repr sentation verf gen Bei der Literaturrecherche wurden deshalb generische Ans tze die allgemeine Modelle zulassen inkludiert w hrend Besonderheiten der Codegenerier
267. legt X Konflikt Element wird nicht neu angelegt 181 5 Prototypische Umsetzung Die dem Parameter MonitoredChannel zugewiesene Klasse CruiseController Master existiert schon und wird daher nicht neu angelegt Allerdings kommt die in dem Template definierte Operation call_step hinzu Am Ende der Transformation sind die Musterinstanzen zu Verfolgbarkeitszwecken wie folgt verlinkt lt trace gt lt designmodel id 2819C5E1 path C Design mdx gt lt optimCriteriaSetting name Performance value false gt lt optimCriteriaSetting name Resources value false gt lt optimCriteriaSetting name Security value null gt lt optimCriteriaSetting name Portability value null gt lt designpattern id F6C82ADF gt lt optimCriteria name Reuse gt lt designpattern gt lt designpattern id EDBOE89B gt lt designpattern id 818C251D gt lt optimCriteria name Reuse gt lt designpattern gt lt designpattern id B57BCFAF gt lt optimCriteria name Reuse gt lt designpattern gt lt designpattern id EEE29F 2E gt lt optimCriteria name Reuse gt lt userquestion text Mussen alternative Regelstrategien verwendet werden answer true gt lt designpattern gt lt designmodel gt lt trace gt R een ander CruiseController es el ig Design For Design For we Design For Design For Design For uns a Die vorg
268. lfe des Konzepts der Modelltrans formationen automatisiert Softwaredesignmodelle abgeleitet werden k nnen Im Rahmen dieser Arbeit werden Modelltransformationen f r diesen Kontext untersucht M ngel existierender Ans tze die sich in diesem konkreten Anwendungsumfeld ergeben werden identifiziert Folgende Fragestellungen liegen den Untersuchungen bestehender Methoden und Technologien im n chsten Kapitel zugrunde e Was sind die zentralen Anforderungen und Trends bei softwareintensiven Systemen im Kraftfahrzeug die durch Modelltransformationen in diesem Bereich adressiert werden sollten e Inwiefern unterst tzten herk mmliche Methoden die integrierte System und Softwareent wicklung durch den Austausch von Modellen Wie sieht der Entwicklungsprozess aus und welche Modelle werden konkret an den Schnittstellen zwischen System und Softwareent wicklung ausgetauscht e Welche Anforderungen an Modelltransformationsmechanismen m ssen gestellt werden wenn diese dazu genutzt werden sollen Modelle der Systementwicklung automatisiert in Modelle der Softwareentwicklung zu berf hren e Wie l sst sich der Zusammenhang zwischen Modellen der System und Softwareentwicklung derart systematisieren dass dieser formalisiert beschrieben werden kann Wie lassen sich auf dieser Grundlage Abbildungsregeln f r einen Modelltransformationsmechanismus formulieren e Welche Ans tze zu Modelltransformationen gibt es und inwiefern erf llen
269. lhaft beschrieben Oft ist z B nicht dezidiert ausgewiesen welche Teile des Musters durch eigene Elemente ausgetauscht werden k nnen also Parameter des Musters darstellen und welche Bedingungen dabei eingehalten werden m ssen Dies lasst sich damit begr nden dass Muster nach Definition nur eine L sungsidee bzw ein abstraktes L sungskonzept beschreiben das individuell ausgestaltet werden kann siehe oben In Bezug auf die klassischen Ziele von Designmustern lasst sich hier daher auch kein Mangel ableiten Wenn Muster aber dar ber hinaus im Kontext von Modelltransformationen zur automatisierten Erstellung von Modellen genutzt werden sollen reicht diese Art der L sungsbeschreibung nicht aus Im weiteren Verlauf dieses Kapitels werden formalisierte Musterbeschreibungen noch adressiert insb in Kapitel 3 2 4 e Bei einer automatisierten Verarbeitung von Mustern zeigen die berwiegend textuellen Muster Beschreibungen weitere Schw chen So sind die nichtfunktionalen Eigenschaften des Musters bzw die Kr fte bei den Standardwerken in Prosaform beschrieben Eine systematische Auswertung die z B die Frage beantwortet ob ein Muster die Laufzeit oder den Speicherverbrauch positiv neutral oder negativ beeinflusst ist daher schwierig Vorgreifend sei auf die erarbeitete Tabelle 4 2 verwiesen in der die Eigenschaften eines Designmusters einheit lich bewertet werden 3 2 4 c Analysemuster Bezogen auf die ROPES Methode passen Anal
270. liche Funktionalitat Dazu wird zunachst eine abstrakte Dekoriererklasse Decorator definiert die eine Referenz auf eine abstrakte Komponente Component halt diese aber zugleich beerbt und somit eine identische Schnittstelle Operation liefert Ein konkreter Dekorierer ConcreteDecorator kann somit einer Konkretisierung der Komponente ConcreteComponent zus tzliche Funktionalit t in diesem Fall in Form einer weiteren Operation addedBehavior hinzuf gen Das Muster kann zum Beispiel eingesetzt werden wenn in Objekten verwaltete Werte auf verschiedene Arten aufbereitet werden sollen 213 5 ExceptionMonitor 5 1 Zweck Fehler auf der Ebene einer Objektkollaboration erkennen und behandeln 5 2 Struktur Client Class ExceptionSafeClass Class ExceptionHandler Class Exception 1 Class Be ExceptionMonitor Class C ExceptionMonitor D Pete oo Client ExceptionRecord _ExceptionRecord ExceptionLog 1 _ExceptionLog _ExceptionLog 1 ExceptionSafedass lt ExceptionSafeClass gt lt ExceptionMonitor gt ExceptionMonitor lt ExceptionSafeClass gt _GlobalExceptionHandler GobalException 1 Handler Exception severity String _GlobalExceptionHandler 1 ExceptionID Integer _ lt ExceptionHandler gt ExceptionHandler
271. lichen Komponentennetzwerk Architektur f r das KFS 39 Abbildung 3 10 Die UML Diagramme im berblick angepasst nach Oestereich 04 44 Abbildung 3 11 Methodische Einordnung der UML Diagramme angepasst nach IESE al 45 Abbildung 3 12 Blockdiapramme ns ee oo 47 Abbildung 3 13 Beispiel eines m glichen UML2 Profils f r die Modellierung der Functional Analysis Arche A gen el dp EA EADE ae aeg T A 47 Abbildung 3 14 Funktionsnetzwerk als Klassendiagramm ccccccceececceeeee seen eeeeeee eee eeee ceases enaeeeenaeees 48 Abbildung 3 15 Modellierung von Signalen mit Hilfe von nformation FIOWS 0ccccccc cece cece eee tec ee ee eens 48 Abbildung 3 16 Ausschnitt eines m glichen Verteilungsdiagramms f r das KFS 49 Abbildung 3 17 Entwicklungszyklen nach ROPES Douglass 04 sssseeeennnnen 50 Abbildung 3 18 Entwicklungszyklen nach ROPES Variante Sem Spira Douglass 04 51 Abbildung 3 19 Mikrozyklus der Softwareentwicklung Douglass 04 222222222222222220 gt 52 Abbildung 3 20 Phasen und Artefakte des Gesamtprozesses Douglass 99 22220 gt 53 Abbildung 3 21 Abstraktionsebenen der Architektur Douglass 02 2 22 54 Abbildung 3 22 Artefakte der Phase Analysis Doug
272. liegt zum einen in der Platzierung der Softwarefunktion in der technischen 14 Design der Softwarefunktionen Systemarchitektur und zum anderen in den unterschiedlichen nicht funktionalen Anforderungen an die Funktion Im Folgenden sind ein paar Beispiele aus dem KFS genannt die zeigen wie sich unterschiedliche Rahmenbedingungen auf das Design auswirken konnen e Wenn die Tempomatfunktion als sicherheitsrelevant eingestuft wird mussen die Ein und Ausgangswerte plausibilisiert werden und evtl redundant mit unterschiedlichen Verfahren berechnet werden Bei der Berechnung der aktuellen Geschwindigkeit fur die Anzeige mit Hilfe des Raddrehzahlsensors ist dies nicht notwendig e Das Steuerger t MMI und Kfz Management ist mit relativ umfangreichen Ressourcen bzgl Rechenleistung und Speicher ausgestattet Da die auf diesem Steuerger t laufenden Funktionen in jeder Baureihe vorkommen soll das Softwaredesign m glichst wiederver wendbar sein Die Optimierung des Designs in Richtung Wiederverwendung darf bei diesen Rahmenbedingungen auch etwas zu Lasten des Ressourcenverbrauchs gehen Bei dem Steuerger t Antriebstrang und Fahrwerk ist dagegen der Ressourcenverbrauch kritischer Die Motorsteuerung muss in sehr kurzen Zeitabst nden die Werte f r die Aktuatorik be rechnen k nnen Echtzeitanforderungen Da die Algorithmen au erdem stark auf einen be stimmten Motor optimiert sind und sich dadurch nicht viele Wiederverwendungsm glich keiten e
273. ll nachvollziehen Durch eine Neuexpansion des Musters wird das Designmodell aktualisiert Der im folgenden Unterkapitel beschriebene Muster Expansionsmechanismus gew hrleistet dabei dass Musterinstanzen bei ge nderter Parameterbelegung neu expandiert werden k nnen und dabei bereits erzeugte Modellfragmente wiederverwendet und mit neu hinzukommenden Modellelementen verschmolzen werden Weitere Nutzungsm glichkeiten der Verfolgbarkeitsinformation werden f r die Phasen Detailed Design siehe unten und Analysis gesehen Das Ermitteln von realisierenden Klassen f r einzel ne Elemente des Funktionsnetzwerks kann z B interessant sein wenn nderungen im Funktionsnetzwerk diskutiert werden und die Auswirkungen auf das Design analysiert werden sollen Evtl gibt es auch Anwendungsm glichkeiten f r das Testen und weitere hier nicht betrachtete Phasen Das Detailed Design Model wird grunds tzlich manuell erstellt wie urspr nglich bei ROPES vorgesehen In seltenen F llen kann auch hier das Instrument der Neuexpansion von bereits instanziierten Mustern genutzt werden um das Design weiter zu verfeinern Vereinfachungs potenzial bietet POTAD in der Detailed Design Phase durch die erw hnte M glichkeit Design musterkataloge die w hrend der Transformation verwendet werden auszutauschen So kann beispielsweise ein Katalog gew hlt werden dessen Muster bereits sehr stark auf eine Plattform optimiert sind oder eine Alternative die viele Details
274. lls Konzepte wieder die auf der Ebene der Systementwicklung festgelegt werden Diese drei Muster sind eigene Weiterentwicklungen bzw Pr zisierungen von Konrad et al 04b 4 2 3 b Muster f r das Design Designmuster beschreiben L sungsschablonen f r wiederkehrende Designprobleme Der im Rahmen dieser Arbeiten verwendete Musterbegriff f r das Design lehnt sich an Gamma et al 95 an Designmuster sind im Gegensatz zu Analysemustern umfangreich publiziert Die im Anhang A 2 erfasst Designmuster verwenden folgendes Schema e Name Ein aus einem Wort bestehender Bezeichner der den Mustertyp innerhalb des Katalogs und der Transformationsregeln eindeutig identifiziert e Zweck Fasst in einem Satz das Designziel des Musters zusammen 152 Muster e Struktur Beschreibt die L sung des Musters in Form eines Templates siehe Kapitel 4 2 1 unter Verwendung der in Kapitel 4 2 2 gezeigten Notation Ein Template bei Design mustern umfasst ein Klassenmodell das einzelne Klassen Operationen oder Attribute als Parameter ausweisen kann e Erl uterung Beschreibung des Musters in Textform im Kontext der Dom ne Dieses im Vergleich zu Gamma et al 95 reduzierte Schema wurde gew hlt da diese Muster in ausf hrlicher Form publiziert sind und daher im Rahmen dieser Arbeit nicht detailliert dokumentiert werden m ssen Der Schwerpunkt des Schemas liegt somit in der formalisierten Beschreibung der Klassenstruktur als Template Die im Desi
275. llung einer bestimmten Aufgabe zu sammenarbeiten In dem Modell eines konkreten Systems kann mit dem Element CollaborationUse markiert werden wo diese Struktur verwendet wird und mit Hilfe von RoleBindings gezeigt werden welche Elemente die definierten Rollen aus ben Laut UML Standard dienen Collaboration und CollaborationUse haupts chlich Verst ndnis und Dokumentationszwecken Ein Element das eine in einer Collaboration definierte Rolle aus bt muss manuell angelegt werden und dann mit einem Ao eBinding versehen werden Eine auto matische Instanziierung die die Struktur der Collaboration automatisch bernimmt wird im UML Standard nicht erw hnt Ein weiterer Nachteil ist dass nur sehr wenige UML Typen in einer Co laboration als Rolle definiert werden k nnen Au erdem gibt es keine M glichkeit Teile einer Collaboration als statisch auszuweisen Alle Elemente einer Collaboration werden als Rolle interpretiert Es ist somit nicht m glich festzulegen dass z B eine Klasse genau in dieser Form gleicher Name und gleiche Features in jeder Anwendung der Collaboration vorkommen Muss Die UML Templates realisieren dagegen ein weiter formalisiertes Vorlagenkonzept dessen Grundprinzip von den schon l nger bekannten C Templates bernommen wurde Grund legende Idee dieses Konzepts ist es den Typ eines Elements zur Modellierungszeit offen zu lassen und als sog formalen Template Parameter engl formal template parameter auszu weisen
276. ln definiert Bei Paket Templates gelten hierbei dieselben Verschmelzungs regeln wie bei einer Paket Verschmelzung Abh ngigkeitsbeziehung zwischen Paketen mit Stereotyp lt lt merge gt gt 86 Softwareentwicklung Kritik lm Rahmen der Modellierung der Fallstudie fiel auf dass sich ein in der Domane haufig auf tretender Sachverhalt mit UML Templates nicht adaquat abbilden lasst Bezogen auf das Beispiel wird dies an der Tatsache deutlich dass eine Messeinheit haufig Uber mehrere Sensoren verfugt In diesem Fall bietet es sich an den Parametern Sensor und sensorValue entsprechend mehrere Objekte zuzuweisen Dies ist laut UML Metamodell erlaubt die Eigenschaft actual von TemplateParameterSubstitution hat die Multiplizit t wird aber im Standard nicht n her beschrieben Es ist auch nicht m glich einem Parameter bei der Definition eines Templates eine Multiplizit t zuzuweisen TemplateParameter ist kein Subtyp von MultiplicityElement womit eine Festlegung getroffen werden k nnte wie viele Elemente bei der Instanziierung zugewiesen werden d rfen bzw m ssen Abbildung 3 37 zeigt eine Instanz des Musters in der einzelnen Parametern mehrere Elemente zugewiesen wurden Dem Parameter Sensor sind die Klassen Thermometer und Hygrometer und dem Parameter sensorWert die Signale Temperatur und Luftfeuchtigkeit zugewiesen Messeinheit Class sensorWert Signal Sensor Class Messung
277. lung Die Subtypen von TemplateableElement sind in der Template Spezifikation ausf hrlicher be schrieben Hier finden sich f r jede Template Art spezifische Angaben zur Instanziierung des Templates SchwerpunktmaBig wird dabei beschrieben wie Template Elemente mit bereits existierenden Elmenten verschmolzen engl merging werden Der UML Standard OMG 05c definiert den Begriff der Verschmlezung z B bei der Erlauterung der mit lt lt merge gt gt stereo typisierte gerichtete Beziehung zwischen Paketen Durch solch eine Beziehung wird angezeigt dass die Inhalte zweier Pakete kombiniert werden Dies ist laut UML Standard in dem Sinne mit einer Generalisierung vergleichbar dass einem Element konzeptionell die Charakterisitk eines anderen Elements hinzugef gt wird Das Ergebnis ist ein neues Element dass die Charakteristika dieser beiden Elemente kombiniert Bei einer Template Instanziierung werden entsprechend die Template Elemente mit den Elementen des Zielmodells verschmolzen Nach der Instanziierung enth lt das Zielmodell eine Kombination der zuvor existierten Elemente und der Template Elemente Modellierung von Mustern Eine M glichkeit die Klassenstruktur eines Musters zu modellieren und die parametrisierbaren Anteile auszuweisen bieten die Paket Templates Abbildung 3 34 zeigt die Definition eines Musters Messung in dieser Form Messeinheit Class sensorValue Signal Sensor Class
278. lysemuster Accounting Transaction nach Fowler 97 Das Muster beschreibt einen buchhaltungstechnischen Geschaftsvorgang nach dem Prinzip der doppelten Buchfuhrung Wie den Kardinalitaten in dem UML Diagramm zu entnehmen ist kann ein Objekt der Klasse Account Konto mehreren Objekten der Klasse Entry Buchung zugeordnet werden Aus diesen m ssen genau zwei Entry Objekte genau einem Objekt der Klasse Accounting Transaction zugeordnet werden Entsprechend des Prinzips der doppelten Buchfuhrung muss die Summe beider Buchungseintrage Null ergeben Das dargestellte Muster zeigt einen wiederholt anzutreffenden Sachverhalt der bei der Ent wicklung von Buchhaltungssystemen in der Analysephase modelliert werden muss Es bildet einen komplexen Zusammenhang aus der Realwelt modellhaft nach und verwendet die Sprache des Domanenexperten Das gezeigte UML Modell ist rein konzeptuell und enthalt keine Design aspekte Zu den ersten Arbeiten zu Analysemustern gehort auch Coad et al 97 Der Beitrag von Fernandez et al 00 f hrt Semantic Analysis Pattern ein die auf der Problemseite Use Cases oder eine Sammlung von Anforderungen enthalten und auf der Losungsseite Verhaltens beschreibungen in Form von Zustands und Sequenzdiagrammen liefern Im Gegensatz zu Fowler der seine Muster informell beschreibt wird hier ein festes Beschreibungsschema ver wendet Geyer Schulz et al 01 benutzen f r die Beschreibung ihrer Analysemuster f r Groupware P
279. lzen werden die Attribute aus dem Muster nicht in die Klasse ber nommen die im Modell als tats chlicher Parameter fungiert wohl aber die Assoziation Tabelle 3 10 Verschmelzungshinweise in Rational XDE 95 3 Stand der Technik Fur jedes Element im Muster kann der Verschmelzungshinweis individuell gesetzt werden Allerdings muss das Vaterelement in der Kompositionshierarchie auf Merge gesetzt sein damit die Kindelemente mit Elementen im Zielmodell kollidieren k nnen und eine Verschmelzung stattfindet Ein Beispiel ist eine auf Preserve oder No Copy gesetzte Klasse die in einem Muster als Parameter ausgewiesen ist und ber eine auf Merge gesetzt Operation verf gt Die Einstellung Merge bei der Operation bleibt dann ohne Effekt da durch die Einstellung Preserve oder No Copy der bergeordneten Klasse nie eine Kollision auftreten kann die eine Ver schmelzung der Operation ausl sen w rde Kollisionen bei Beziehungen k nnen auch erkannt werden und eine entsprechende Ver schmelzung ausl sen Die hierbei verwendeten Regeln vergleichen unter anderem die an der Beziehung teilnehmenden Partner die Namen der Beziehungs Endpunkte und deren Eigen schaften Auf detaillierte Erl uterungen der dabei angewendeten Regeln wird hier verzichtet Gleiches gilt f r den Mechanismus mit dem Code Templates f r die Muster Elemente hinter legt werden die dann bei der Musterinstanziierung ins Zielmodell mit bertragen werden Zusammenfas
280. m chte Diese Betrachtungen f hren schlie lich im darauf folgenden Unterkapitel zu der Formulierung einer Problemstellung f r die im Rahmen dieser Arbeit ein L sungsansatz er arbeitet wird 1 Einleitung und Motivation 1 1 Umfeld Die hier betrachtete Automotive Software lauft auf dem Mikrocontroller eines Steuergerats das mit Hilfe von angeschlossenen Sensoren Sollwertgebern und Aktuatoren Steuerungs und Regelungsfunktionen realisiert In heutigen Fahrzeugen gibt es bis zu 70 solcher Steuergerate von denen die meisten mehrere Funktionen ausuben Da sich mittlerweile viele Funktionen aus Teilfunktionen unterschiedlicher Steuerger te zusammensetzen sind die Steuerger te zur Deckung des Kommunikationsbedarfs ber bis zu f nf Bussysteme miteinander vernetzt auf denen wiederum ca 8000 Signale ausgetauscht werden Ein Beispiel f r solch eine verteilte Funktion ist der Tempomat Dieser versucht das Fahrzeug so zu beschleunigen dass eine eingestellte Geschwindigkeit erreicht bzw gehalten wird Dazu wird der Fahrerwunsch ber ein Bedienelement des Mantelrohrschaltermoduls in der Nahe des Lenkrads eingelesen und die aktuelle Geschwindigkeit ber das ESP Steuerger t ermittelt Sollte sich eine Abweichung zwischen Soll und Ist Geschwindigkeit ergeben kann das Motormoment ber das Motorsteuer ger t das Getriebe ber das Getriebesteuergerat und das Bremsmoment ber das ESP Steuerger t beeinflusst werden Abbildung 1 1 zeigt skizz
281. m Rahmen der Softwareentwicklung gesehen k nnen jedoch Auswirkung auf die Wahl des Prozessortyps und der Busvernetzung haben 55 3 Stand der Technik Die Darstellung dieser Sicht erfolgt mit UML Klassendiagrammen in denen f r Klassen die Stereotypen lt lt active gt gt lt lt task gt gt und lt lt resource gt gt verwendet werden Distribution View Identifiziert Objekte die in unterschiedlichen Adressraumen erzeugt werden und zeigt wie diese ber Adressraumgrenzen hinweg kommunizieren Zu den dar gestellten Sachverhalten geh ren die verwendeten Protokoll Stacks und eingesetzte Kommunikations Designmuster siehe Kapitel 3 2 4 b Die Darstellung erfolgt durch Klassendiagramme in denen die relevanten Klassen und ihre Beziehungen hervorgehoben werden In Abh ngigkeit der verwendeten Kommunikationstechnologie k nnen Stereotypen zum Einsatz kommen Safety and Reliability View Zeigt wie Fehler im System zur Laufzeit identifiziert isoliert und behandelt werden Zu den Inhalten dieser Sicht geh ren das Aufzeigen von redundanten Strukturen und berwachungsmechanismen sowie die Beschreibung des Ver haltens im Fehlerfall Dies erfolgt mit UML Klassendiagrammen in denen manche Elemente mit Stereotypen ausgezeichnet sind z B werden redundante Subsysteme mit lt lt channel gt gt markiert Deployment View Zeigt wie sich die Elemente der Softwarearchitektur auf die Hardware einheiten verteilen Dies erfolgt mit H
282. men werden 9 Sobald der Fahrer das Gaspedal ber den Druckpunkt Kick down hinaustritt und gleich zeitig die aktuelle Geschwindigkeit nicht mehr als 20 km h von der begrenzten abweicht schaltet sich die Speedtronic ab 10 Bei berschreiten der Geschwindigkeit ert nt ein akustisches Signal und es erscheint eine Meldung 11 Die Geschwindigkeitsbegrenzung wird beim Speichern angezeigt 4 Benutzerinterface Bordcomputer 1 Der Bordcomputer wird ber die Tasten am Multifunktionslenkrad gesteuert und die An zeige erfolgt ber ein Multifunktions Display Punkte 2 und 3 nicht relevant 1 Multifunktionsdisplay 2 Untermen ausw hlen aufw rts abw rts 3 Telefonieren Gespr ch annehmen Gespr ch beenden 4 Von Men zu Men springen vor zur ck 5 Im Men springen vor zur ck 2 Das Multifunktions Display verf gt ber eine Men f hrung 244 i Ab Start 3 135 km Keine 1 30 h Storung 90 kmh Einstellungen Zur cksetzen lag ll nop Copyright Daimler AG am 1 Betriebsmen Standardanzeige mit Tages und Kilometerz hler Digitaler Tachometer Wartungsanzeige 2 Fehleranzeige Storungen abfragen 3 Einstellungen Auf Werkseinstellungen zurucksetzen Schaltprogramm wahlen 4 Reiserechner Verbrauchs und Geschwindigkeitsstatistiken ab Start Verbrauchs und Geschwindigkeitsstatistiken ab Reset Reichweite abfragen Uber den R
283. mfassen Die genannten Konzepte werden in dem MDA Guide berwiegend anhand von Modelltrans formationen zwischen PIM und PSM erl utert Es wird jedoch darauf hingewiesen dass sowohl f r das PIM als auch f r das PSM Zwischenstufen m glich sind So kann ein PIM zun chst in ein verfeinertes PIM transformiert werden genauso wie das entstehende PSM durch weitere Modelltransformationen verfeinert werden kann 3 3 1 c Die MDA Artefakte im Kontext der Systementwicklung Die in den MDA Dokumenten enthaltenen Beispiele stammen aus Bereichen wie Verwaltung Betriebswirtschaft oder Finanzwesen Dies wirft die Frage auf welche Bedeutung die MDA Artefakte in einem Systementwicklungsprozess wie dem in dieser Arbeit betrachteten Bereich der softwareintensiven Steuerungs und Regelungssysteme im Kraftfahrzeug haben Im Folgenden wird untersucht wie sich de MDA Artefakte mit dem bereits beschriebenen System entwicklungsprozess abgleichen lassen Der Betrachtungsrahmen von MDA umfasst explizit ein System inkl der Nicht Softwareanteile was sich mit der Perspektive des Kernprozesses der Systementwicklung deckt Ein pragendes Merkmal des MDA Ansatzes ist die Abstraktion von der Plattform die sich in den beschriebenen Viewpoints mit ihren zugeh rigen Modellen C M P M und PSM u ert Diese Unterteilung passt auch zu den durch den Kernprozess propagierten Abstraktionsebenen So l sst sich das CIM als ein Modell der Anforderungsphase auffassen das al
284. mme der UML erlauben zwar bereits eine relativ umfangreiche Be schreibung eines Softwaresystems k nnen allerdings durch verschiedene Technologien noch erweitert werden Ein in der UML integrierter Mechanismus f r Erweiterungen mittels Spezialisierungen ist durch die M glichkeit der Definition von UML Profilen gegeben die als Zusammenfassung von Adaptionen von Konstrukten mit einer bestimmten Zielstellung be schrieben werden k nnen In UML Profilen k nnen f r jeden Typ von Elementen in einem Modell spezialisierte Versionen definiert werden die durch Stereotypen gekennzeichnet sind Die Kennzeichnung ist entweder mit Text in Guillemets gefasste Namen also etwa lt lt stereotyp gt gt oder mit vom Benutzer vorzugebenden Icons m glich In der Definition eines solchen Stereotyps k nnen spezifische Name Wert Paare sog Tagged Values in der Form Eigenschaft Wert als Attribute des Stereotyps und zus tzliche Bedingungen formuliert werden um ein spezielles Konzept auszudr cken Ein Profil b ndelt dann eine Sammlung von Stereotypen zu einem Paket Bei der Erstellung von Profilen ist zu beachten dass grunds tzlich nur die Spezialisie rung existierender Elementtypen gestattet ist und die beschriebenen Konzepte nicht in Wider spruch mit den sonstigen Konzepten der UML stehen d rfen F r g ngige Einsatzgebiete gibt es auch bereits vordefinierte bzw standardisierte Profile OMG c Ankn pfungspunkte zum UML Metamodell und der UML Metam
285. modelliert werden Funktional Analysis Architecture Beschreibt ein Netz aus logischen Funktionen AnalysisFunctions und logischen Sensoren Aktuatoren unctionalDevices Diese Elemente k nnen ber Ports die wiederum ber Connectors verbunden sind kommunizieren Ein Port ist ber ein Interface getypt das wiederum Signale ConnectorSignal spezifiziert die einen abstrakten Typ DesignDataType haben In der FunctionalDesignArchitecture wird ein Implementierungstyp mp ementationData Type hinzugef gt Mit einem Objekt vom Typ 7ypeAssoziation wird die Abbildung zwischen beiden Typen beschrieben z B Skalierung und Offset F r Ports k nnen Zeitangaben z B Zykluszeit gemacht werden die als Anforderung zu verstehen sind Eine AnalysisFunction kann eine Komposition aus weiteren Ana ysisFunctions sein Auf diese Weise kann das Funktionsnetz in einer Hierarchie organisiert werden Functional Design Architecture Beschreibt Softwarekomponenten und ihre Sub funktionen Es wird zwischen Kompositionen CompositeSoftwareFunction und elementaren Softwarefunktionen ZlementarySoftwareFunction differenziert CompositeSoftwareFunctions k nnen weitere CompositeSoftwareFunctions oder ElementarySoftwareFunctions enthalten E ementarySoftwareFunctions k nnen nicht weiter unterteilt werden und lassen sich somit sp ter einem Steuerger t zuordnen Bei der Kommunikationsmodellierung greift die Functional Design Architecture auf die aus der Functi
286. n Dabei kann es sich z B um den Reset des Mikrocontrollers handeln Variabilit t Das Beispiel der beiden Designmodelle f r den Tempomaten zeigt dass die Zuordnung von Designmustern zu einem Analysemuster mit unterschiedlichen nichtfunktionalen Anforderungen variieren kann Dies ist angesichts der Tatsache dass Designmuster explizit f r die Umsetzung einer bestimmten nichtfunktionalen Eigenschaft entwickelt werden auch nicht berraschend Die Untersuchung weiterer Beispiele hat gezeigt dass eine solche Variabilitat auch von der 101 3 Stand der Technik technischen Systemarchitektur ausgeht So konnen z B in Abhangigkeit von der Frage ob die Sensoren und Sollwertgeber Uber ein Bussystem mit dem Regler kommunizieren oder direkt an den Mikrokontroller des Reglers angebunden sind unterschiedliche Muster fur die Datenbereit stellung zum Einsatz kommen Die nichtfunktionalen Anforderungen und die technische Systemarchitektur spannen somit einen zweidimensionalen Losungsraum fur Designmusterkonstellationen eines Analysemusters auf Da die Erfassung aller moglichen Kombinationen zwischen einer nichtfunktionalen Anforderung und einer technischen Systemarchitektur nicht praktikabel ist wurde die erste Dimension auf eine Auswahl exklusives ODER der folgenden vier h ufig vorkommenden Anforderungen be schrankt 1 Laufzeit 2 Speicherverbrauch 3 Sicherheit und Verf gbarkeit 4 Wartbarkeit Portabilitat Erweiterbarkeit
287. n Modellen teilweise auch als horizontale Transformationen bezeichnet Konsistenz pr fungen von Modellen zur Automatisierung des Softwareentwicklungsprozesses auch vertikale Transformationen genannt oder f r Reverse Engineering Zwecke eingesetzt werden F r die horizontalen Transformationen die eine Art Modellevo ution darstellen kann man zus tzlich drei verschiedene Arten unterscheiden perfektionierend im Sinne von 113 3 Stand der Technik Refactoring oder Optimierung korrigierend im Sinne der automatischen Korrektur von unerw nschten Strukturen im Modell und adaptiv f r die Anpassung an andere Gegeben heiten e Generizitat Ans tze k nnen auf bestimmte Typen von Modellen beschr nkt sein oder durch den Einsatz von Metamodellierung f r unterschiedliche Modelltypen offen sein e Beziehung Quelle Ziel Hier wir festgelegt ob Quell und Zielmodelle identisch sein d rfen Au erdem spielt es eine Rolle ob Zielmodelle neu generiert werden oder bereits existierende Zielmodelle eventuell aktualisiert werden mussen e Richtung F r konkrete Ans tze ist es von Bedeutung ob die Transformation immer nur in einer festgelegten Richtung unidirektional erfolgen kann oder ob eine definierte Trans formation auch in Gegenrichtung also von Zielmodellen zu Quellmodellen durchf hrbar ist bidirektional e Unterst tzung von Nachverfolgbarkeit Traceability F r dieses Merkmal ist es in erster Linie entscheidend
288. n Unter anderem kann die Instanziierung eines Musters von einer Bedingung abh ngig gemacht werden Soll dieses Muster sp ter mit einem weiteren Muster verwoben werden muss ge pr ft werden ob das Muster instanziiert wurde oder nicht Bei sehr viel Variabilit t werden die Regeln durch die vielen Fallunterscheidungen daher un bersichtlich und schlecht wartbar Mit dem Konzept der Hilfsregeln wurde eine erste Ma nahme getroffen Trans formationsregeln in konsistente und wiederverwendbare Einheiten zu zerlegen Das Problem wird damit jedoch nicht vollst ndig beseitigt Mit der prototypischen Implementierung lassen sich die Transformationsregeln nur ein geschrankt im Kontext einer iterativen Vorgehensweise nutzen Ein durch Modelltrans formation erzeugtes Designelement dessen Name nachtr glich manuell ge ndert wird wird bei erneuter Ausf hrung der Transformation nicht wieder gefunden und daher neu erzeugt Hierbei handelt es sich jedoch nur um eine Schw che des Prototyps eine Ausbaustufe k nnte die angelegten Verfolgbarkeitsinformationen auswerten und so das erzeugte Element finden und wiederverwenden 7 Zusammenfassung und Ausblick Diese Arbeit bewegt sich im Umfeld von modellgetriebenen System und Softwareentwicklungs ans tzen deren grundlegende Idee eine durchg ngige Nutzung von formalisierten Modellen in den Entwicklungsphasen ist Auf dieser Basis werden mit Hilfe von Modelltransformationen Modelle unterschiedlicher En
289. n die ber das Signal ControlInputValue Umgebungsinformationen zur Verf gung stellen e OQOpenLoopController Berechnet auf der Grundlage von ReferenceValue und ControlInputValue das Signal ControlOutputValue e ControlOutputValueDrain Empf ngt ControlOutputValue 2 4 Beispiel Ein Beispiel f r eine Steuerung ist ein elektronisches Motormanagement Der Fahrer kann ber das Gaspedal ReferenceValueSource AcceleratorPedal dem System den gew nschten Vortrieb anzeigen Die Motor Steuerung muss dazu die Aktuatoren f r die Einspritzung die Drossel klappe und das Z ndsystem ControlOutputDrain Fuellnjection Throttle IgnitionSystem entsprechend steuern Dazu ben tigt sie Informationen bzgl des aktuellen Betriebspunktes des Motors die ber Sensoren f r die Luftmasse die Motortemperatur und die aktuelle Drehzahl beschafft werden ControlInputSource EngineTemperatureSensor AirmassSensor RpmSensor 196 Das hier gezeigte Modell ist unvollst ndig eine detaillierte Beschreibung aller Sensoren Soll wertgebern und Aktuatoren einer Motorsteuerung findet sich bei BOSCH 03 bind Bind ControlOutputDrain F uel Injection IgnitionSystem Throttle ControlOutputV alue Fuel InjectionValue IgnitionValue Throttle Value ControllnputValue Source AirmassSensor Engine OpenLoopController Class TemperatureSensor Rpm ControlOutput
290. n die festlegt wie die Begriffe und Beziehungen eines Modells graphisch in einem Diagramm zu visualisieren sind Dabei wird versucht die graphische Symbolik so zu w hlen dass sie von der Zielgruppe m g lichst intuitiv verwendbar ist Ein Diagramm kann bei einigen Modellierungssprachen auch nur Ausschnitte des Modells enthalten was dazu genutzt wird f r unterschiedliche Fragestellungen unterschiedliche Diagramme zu erstellen die jeweils nur die relevanten Modellelemente ent halten Modelle und ihre Diagramme k nnen auf unterschiedliche Fragestellungen fokussieren und dabei von anderen Details abstrahieren und somit zu einem gemeinsamen Problem und L sungsver st ndnis zwischen verschiedenen Fachdisziplinen beitragen Sch uffele et al 03 Weitere Mehrwerte von formalisierten Modellen liegen z B in den M glichkeiten der Simulation Code Generierung und Rapid Prototyping Bertram et al 01 Die konsequente Weiterentwicklung der modellbasierten Entwicklung f hrte schlie lich zu dem Ansatz von modellgetriebener Entwicklung Hier wird in jeder Entwicklungsphase ein hoch formalisiertes Modell als das zentrale Entwicklungsartefakt verwendet Aufgrund des hohen Formalisierungsgrades ist es teilweise m glich die Beziehungen zwischen den Modellen zu beschreiben und dies f r die automatische Gewinnung von Systembestandteilen bzw weiteren Modellsichten auf das System auszunutzen Dieser Vorgang der automatisierten Konstruktion eines
291. n Bezug auf Destruktoren und Interface Konzepte genannt Im Rahmen dieser Diplomarbeit wurde nun jeweils eine spezifische Variante der Designmusterbibliothek f r Java und C erstellt Es wurde au erdem die M glichkeit von XDE genutzt ber den integrierten Code Template Mechanismus Code Ger ste f r die Muster zu erstellen Neben der Erzeugung von Methodenrumpfen der richtigen Typdefinition bei Klassen Attribute und Parametern konnte f r einzelne Beispiele auch aufgezeigt werden dass sich auch Code f r das charakteristische Verhalten des Musters erzeugen l sst Bei der Verwendung dieser programmiersprachenspezifischen Designmusterbibliotheken werden bereits einzelne Aktivit ten der Detailed Design Phase adressiert Die im Rahmen des Detailed Design zu leistende genaue Auslegung von Algorithmen und Auswahl geeigneter Daten 186 Grenzen des Ansatzes strukturen ist aber in Abh ngigkeit unterschiedlicher Anforderungen wieder variabel so dass hier unterschiedliche Varianten des Musters notwendig waren Hier wurde nun der Ansatz untersucht denselben Transformationsmechanismus der bisher fur eine Transformation zwischen Modellen der Object Analysis und dem Mechanistic Design verwendet wurde nun f r eine Transformation zwischen Modellen des Mechanistic Design und des Detailed Design zu verwenden Dies wurde anhand des Designmusters ControlLoop_Open untersucht bei dem der Steuerungsalgorithmus Methode step h ufig mit Kennlinien a
292. n Entwicklerteams Es handelt sich aber weiterhin um eine funktionale Sicht in der keine Objektorientierung verwendet wird Subsysteme werden als Black Box betrachtet ihr interner Aufbau ist somit unbekannt Zu den weiteren Aktivit ten geh rt e Die Definition der Subsystem Architektur e Die Definition der Interfaces and Interaktionsprotokolle zwischen den Subsystemen e Die Zusammenarbeit zwischen den Subsystemen f r unterschiedlichen Use Cases be schreiben e Use Cases in Anforderungen an Subsysteme zu zerlegen e Analyse und Festlegung der Schl sselalgorithmen insb kontinuierliches Verhalten e Zerlegung der Subsysteme in ihre technischen Disziplinen Zu den m glichen resultierenden Artefakten geh rt das Architectural Model Architektur model das in Form von Klassen bzw Komponentendiagrammen vorgelegt wird Die Inhalte dieser Diagramme entsprechen den Erl uterungen zu den Sichten Subsystem and Component und Deployment siehe vorheriges Unterkapitel Die Executable Specification ausf hrbare Spezifikation beschreibt das Verhalten auf Subsystem bzw Komponentenebene und kann in der Form von Zustandsdiagrammen f r reaktives Verhalten Aktivit tsdiagrammen Skizzierung nebenl ufiger Algorithmen Sequenzdiagrammen f r ausgesuchte Pfade innerhalb der Zustandsdiagramme und mathematischen Modellen f r kontinuierliches Verhalten z B PID Regler vorliegen Bei der Software und Hardware Specification Software und Hardware
293. n Problemstellung aus Kapitel 3 4 wird hier der eigene L sungsansatz aus Kapitel 4 berpr ft Basierend auf der Untersuchung von neuen modellbasierten Methoden im Umfeld der System und Softwareentwicklung wurden Modelltransformationen als ein m gliches Instrument identifiziert um einzelne Aufgaben der Softwareentwicklung durch die Wiederverwendung von Modellen aus der Systementwicklung zu automatisieren In Kapitel 3 wurden nach der Aufarbeitung der dom nenspezifischen An forderungen existierende Modelltransformationsans tze auf ihre Eignung in diesem An wendungskontext hin untersucht Bei diesen Untersuchungen wurden Unzul nglichkeiten der existierenden Ans tze entdeckt die in der pr zisierten Problemstellung zu folgenden drei Kern forderungen als Ergebnis der Analyse des Stands der Technik gef hrt haben 1 Ein Modelltransformationsansatz muss das in der Methode bereits etablierte Musterkonzept wiederverwenden und weiterentwickeln Die Umsetzung einer darauf basierenden Systematik verlangt von einem Modelltransformationsmechanismus die M glichkeit parametrisierbare Mustertypen und ihre Instanzen beschreiben zu k nnen sowie die f r die Musterinstanziierung notwendige Parameter Bindung und die Musterexpansion durchzu f hren 2 Ein Modelltransformationsansatz muss die mit wechselnden nichtfunktionalen An forderungen und unterschiedlichen technischen Systemarchitekturen einhergehende Vari abilitat im Designmodell unterst tz
294. n Sensor oder ber den Bus empfangen 142 Erweiterung der Entwicklungsmethode Liegen die Informationen nicht maschinenlesbar vor kann alternativ der Benutzer wahrend der Transformation durch einen Fragedialog zur Klarung der Frage aufgefordert werden Die in dieser Arbeit gezeigten Transformationsregeln st tzen sich ausschlie lich auf Benutzerr ck fragen da f r die Implementierung der maschinellen Abfrage in der prototypischen Umsetzung siehe Kapitel 1 der Zeitrahmen nicht ausreichte Der Aufbau der Transformationsregeln und m glichen Parameter sind ausf hrlich in Kapitel 4 3 beschrieben Nach dem alle Benutzerr ckfragen beantwortet sind erzeugt der Transformator ein aus Designmusterinstanzen bestehendes Grundger st des Mechanistic Design Models Dieses muss i d R nachbearbeitet und um Klassen erg nzt werden die sich nicht aus dem Analysemodell ableiten lassen Ein weiteres Ergebnis der Modelltransformation sind die Verfolgbarkeitsinformationen Dieser in Unterkapitel 4 4 genauer beschriebene Mechanismus verbindet die Designmusterinstanzen w hrend der Transformation mit den Analysemusterinstanzen aus denen sie hervorgegangen sind Um die nachfolgende Designaktivitat zu unterst tzen muss das eingesetzte Modellierungswerkzeug Abfragen dieser Links f r unterschiedliche Kontexte implementieren Folgende Abfragen der Verfolgbarkeitsinformation sind vorgesehen 1 Kontext Analysemuster Zeige alle Designmuster an
295. n im Konflikt stehen und Designent scheidungen verlangen Optimierungsm glichkeiten ergeben sich z B bei der Behandlung folgender Fragestellungen e Festlegung aktiver Objekte e Scheduling Strategien 59 3 Stand der Technik e Fehlerbehandlungsstrategien e Kommunikationsmedien und Protokolle e Speicherverwaltungsstrategien e Implementierungsstrategien Pointer Referenzen TCP IP sockets Wie in Abbildung 3 23 zu sehen wird die Designphase in drei Subphasen unterteilt Architectural Design betrachtet das gesamte Softwaresystem Mechanistic Design betrachtet Kollaborationen und Detailed Design betrachtet Klassen Analysis Object Model Architectural Model Scenarios Mechanistic Design Design Detects Design Detects Use Cases Architectural Design Detailed Design Hazard Analysis Design Patterns N S Architectural Design Mechanistic Design l l Model Model Detailed Design Model Design Object Model Abbildung 3 23 Artefakte der Phase Design Douglass 99 Architectural Design Das Architectural Design trifft strategische Designentscheidungen die die meisten oder alle Softwarekomponenten im System betreffen wie beispielsweise die Verteilung der Komponenten auf Prozessoren die Bestimmung von Threads und die Behandlung von Nebenl ufigkeitsfragen Zentrales Designinstrument ist die Anwendung von Architectural Patterns sie
296. n in Tools f r Trans formationen wiederverwendet werden k nnten Letzteres wird allerdings nur mit einem ein fachen theoretischen Architekturmodell f r ein Tool zur Manipulation von Modellen belegt Das mitgelieferte Beispiel beschreibt leider nur eine sehr einfache Transformation Generierung von getter und sette Methoden f r Klassen was eine Beurteilung des Ansatzes hinsichtlich komplexerer Transformationen schwierig macht In einem weiteren Vorschlag Akehurst 04 wird dagegen die Erweiterung der OCL um das Konzept der Aelationen vorgeschlagen Da sowohl die OCL als auch die mathematische Relationentheorie auf der Mengentheorie basieren sind nach Ansicht des Autors nur wenige Erweiterungen der OCL n tig von denen die wichtigsten aufgef hrt werden Diese in OCL 127 3 Stand der Technik ausgedruckten Relationen werden als mogliche Notation fur die re ations aus dem Ansatz der QVT Merge Group siehe Kapitel 3 3 3 a vorgeschlagen Eine operationale Semantik die z B in Form von Actions definiert werden k nnte wird explizit ausgeklammert Eine hnliche Idee wird etwas ausf hrlicher in einem fr heren Beitrag ber einen relationalen Ansatz f r Modell transformationen beschrieben Akehurst et al 02 Basis ist hier die Idee Elemente der Relationentheorie als Objektmodell zu modellieren und auf dieser Basis Transformations beziehungen zwischen Modellen zu beschreiben F r die Modellierung von Transformationen werden Paar
297. n mit dem Ziel entwickelt kompatibel mit den in der Branche blichen Entwicklungsprozessen zu sein Die EAST ADL zeigt in welch gro em Umfang formalisierte Informationen bei einer intensiven Systementwicklung zur Verf gung stehen k nnen die f r die Softwareentwicklung relevant sind Im Bereich der mit der technischen Systemarchitektur verwandten Artefakte wird die EAST ADL im Projekt Autosar AUTOSAR bereits weiterentwickelt und standardisiert Bei den Artefakten die der logischen Systemarchitektur hinzugerechnet werden k nnen Functional Analysis Architecture verharrte das Metamodell auf dem Stand des Forschungsprojekts EAST EEA Im Rahmen des Projekts ATESST ATESST wird aktuell eine Version 2 der EAST ADL 34 Systementwicklung in der Form eines UML2 Profils siehe Kapitel 3 2 1 b entwickelt In dieser Version sollen die durch Autosar standardisierten Inhalte bernommen und mit den brigen Artefakten harmonisiert werden Dennoch liefert die EAST ADL eine pr zise und umfassende Beschreibung der Konzepte in der Systementwicklung der Automobilindustrie und kann als Referenz f r aufbauende Arbeiten wie der hier vorliegenden herangezogen werden In Kapitel 3 2 2 8 werden die einzelnen Modelle der EAST ADL zusammen mit Modellen der Softwareent wicklungsmethode ROPES den Artefakten des Kernprozesses aus Kapitel 3 1 2 zugeordnet Anzeige lt lt electrical gt gt Lenkradtasten lt lt electrical gt gt Umschalter I
298. n nicht betrachtet werden gilt die Forderung nach einer einheit lichen Beschreibung derselbigen nur fur Designmuster 3 2 4 d Weiterfuhrende Themen Neben der Konzeption des Musterbegriffs der Beschreibung von Mustern und der Abgrenzung unterschiedlicher Musterarten gibt es noch zahlreiche weitere Arbeiten die sich im Umfeld von Mustern bewegen Im Folgenden wird auf einige dieser Themen eingegangen Musterkataloge und systeme Unter einem Musterkatalog versteht man eine Sammlung mehr oder weniger zusammen hangender Muster die diese in eine Reihe von Kategorien einteilt und Beziehungen zwischen den Mustern dokumentiert Der Katalog stellt eine blo e Aufz hlung von Muster dar die mit minimalen Mitteln strukturiert wurde Ein Mustersystem Buschmann 98 dagegen ist weitaus zusammenh ngender hierarchisch gegliedert und spricht ein definiertes Problemumfeld an Es beschreibt wie bergeordnete Muster mit Hilfe von untergeordneten Mustern realisiert werden k nnen und stellt Abh ngig keiten und Zusammenh nge zwischen den Mustern bezogen auf das Zielgebiet umfassend dar Von der Pattern Language unterscheidet es sich darin dass die Abdeckung des Umfeldes weit aus geringer ist und Mustersysteme somit als Teil einer umfassenderen Mustersprache ein gesetzt werden k nnen Um den Anwender bei der Auswahl eines passenden Musters zu unterst tzen k nnen Kataloge oder Systeme eine Suchfunktion bzw Suchmethoden anbieten die es e
299. n nur ausgef hrt wenn das Optimierungs kriterium Safety gew hlt wurde In diesem Fall wurden bis auf ControlLoop alle bisher er w hnten Template Instanziierungen nicht ausgef hrt Ausgehend von einer ControlLoop Instanz wird dann das SecondGuess Template instanziiert OptimCriteria Safety Template SecondGuess Coop COMEMOMAGOU wy one ControlAlgorithm AbstractAlgorithm SORO rT orale Concrete getNames Interface Name des redundanten Regelalgorithmus 1 AlgorithmInterface controlSG Uber den Parameter Context wird diese Instanz mit der Instanz von ControlLoop verwoben Die tatsachlichen Parameter fur AbstractAlgorithm und ControlAlgorithm werden in diesem Fall durch konstante Strings vorgegeben Der Name des Algorithmus kann ahnlich wie bei der Instanziierung von Strategy durch den Benutzer eingegeben werden Die Struktur des Templates SecondGuess Context Class AbstractAlgorithm Class ConcreteAlgorithm 2 Class _ AlgorithmInterface Operation SecondGuess E E eee primaryCalc ra z o gt __ ___ AbstractAlgorithm Context 1 Ig secondaryCalc Algorithminterface ConcreteAlgorithm AlgorithmInterface 180 Beispiel wird mit dem bisher erzeugten Modell wie folgt verschmolzen Throttle R _SpeedSensor SpeedAdjustingLever bind Bind ControlLo
300. n werden dabei durch eine Kombination aus Hardware und Softwarema nahmen realisiert wodurch sich besondere Anforderungen an das Softwareengineering ableiten Eine weitere Voraussetzung f r zuver lassige Systeme die Auswirkung auf die Softwareentwicklung hat ist die Anforderung Funktionen und Schnittstellen f r die Diagnose bereitzustellen 3 1 1 c Verteilte Systeme Viele neue Funktionen basieren auf dem Zusammenspiel mehrerer Teilfunktionen die auf unter schiedlichen Steuerger ten realisiert sind Ein modernes Oberklassenfahrzeug verf gt mittler weile ber ca 70 Steuerger te die ber ca f nf Bussysteme mehrere tausend Signale aus tauschen Die sich daraus ergebende Komplexit t durch Abh ngigkeiten verschiedener Ent wicklungsprojekte muss in der Entwicklungsmethode ber cksichtigt werden 3 1 1 d Wechselnde Plattformen Der Markt bietet vergleichsweise viele Mikrocontrollerarchitekturen die f r ein Steuerger t genutzt werden k nnen Die Entscheidung f r eine bestimmte Plattform ist stark durch den Einkauf und die Systementwicklung bestimmt F r die Softwareentwicklung relevante Platt formaspekte der Hardware sind z B der verwendete Prozessor bestimmt die m glichen Compiler und Programmiersprachen oder die angeschlossenen Bussysteme haben Auswirkung auf das Kommunikationsmodell und das Zeitverhalten Auch auf der Ebene der Software spielen Plattformaspekte eine Rolle So gibt es Standardkomponenten Basissoftware f
301. nDetector eine unplausible Stellung UnplausibleSetting erkannt aktiviert die Funktion EngineFaultHandler einen Notlauf FailSafeController Detector Class Corrector Class LocalFaultHandler Class CorrectiveAction Signal LocalFault Signal Actuator Class bind Bind Corrector FailsafeController LocalFaultHandler Engine FaultHandler CorrectiveAction ChangeT oFailSafeMode Local Fault UnplausibleS etting Actuator Throttle Detector Throttle ge a es MalfunctionDetector _ Detecto rCorrector Actuator _DetectorCorrector_Actuator_Throttle ee en r gt Fr a e SSS UnplausibleS etting er nn ChangeT oF ailSafeMode ThrottleMalfunctionDetector Throttle A FailsafeController monitors gt gt lt provides corrective 7 actions for 5 6 Anwendbare Designmuster e MonitorActuator berwachungskonzept des Aktuators in einem Objektmodell auf Design ebene abbilden e ExceptionMonitor Fehler auf der Ebene einer Objektkollaboration erkennen und behandeln e Singleton Sicherstellen dass es nur eine Instanz der globalen Fehler berwachung und des globalen Logging Mechanismus gibt 203 6 Detector Corrector Originalauszug aus Konrad et al 04a Im Folgenden ist die Originalbeschreibung des Musters Detector Corrector aus Konrad et al 04a wiedergeben Damit soll ein Beispiel f r die in Kapitel 3
302. nal ReferenceValueSource Class ControlOutputValueDrain Class FeedbackValueSource Class ae se A ClosedLoopControl e p eng ee aa lt ReferenceValue gt ReferenceValueSource ee lt ControlOutputValue gt ClosedLoopController ee gt ControlOutputValueDrain FeedbackValueSource e ReferenceValueSource Sendet die SollgroBe ReferenceValueSource an ClosedLoopController e FeedbackValueSource Sendet die R ckf hrgr e ControlInputValue an ClosedLoopController e ClosedLoopController Vergleicht fortlaufend ReferenceValue sowie FeedbackValue und be rechnet f r die Angleichung einen entsprechenden Wert f r ControlOutputValue e ControlOutputValueDrain Empfangt ControlOutputValue 1 4 Beispiel Ein Beispiel f r eine Regelung ist ein klassischer Tempomat Der Fahrer gibt ber ein Bedien element ReferenceValueSource Lever eine Sollgeschwindigkeit ReferenceValue DesiredSpeed vor Die Istgeschwindigkeit FeedbackValue CurrentSpeed wird laufend ber den Drehzahlsensor der R der FeedbackValueSource SpeedSensor ermittelt und mit dem der Sollgeschwindigkeit verglichen Wird eine Abweichung festgestellt wird ein neuer Wert ControlOutputValue ThrottleValue f r die Ansteuerung der Drosselklappe ControlOutputValueDrain Throttle berechnet der mit einem konkreten ffnungswinkel korrespondiert Durch die R ckkopplung ber den Drehzahlsensor w
303. nden Idealerweise sind diese schon bekannt und dokumentiert 3 Damit sich die Erstellung der Transformationsregeln lohnt muss die Entwicklung mehrerer Systeme geplant sein die im Fachmodell immer wieder dieselben Muster nutzen Die Variabilitat des Designs wird bei POTAD durch einfache Bedingungen und Fallunter scheidungen in den Transformationsregeln realisiert Bei umfangreicher Variabilit t f hrt dies zu schwer lesbaren und schwer wartbaren Transformationsregeln Hier ist zu pr fen wie Transformationsregeln besser in konsistente und wiederverwendbare Einheiten zerlegt werden k nnen Evtl k nnten dabei Konzepte aus dem Umfeld der Generativen Programmierung Czarnecki et al 00 eine Verbesserung bringen Die maschinelle Abfrage der technischen Systemarchitektur wurde zwar im Metamodell ber cksichtigt in der prototypischen Umsetzung jedoch nicht implementiert Stattdessen werden die ben tigten Informationen durch Benutzerr ckfragen erfragt Es ist zu vermuten dass sich diese Benutzerr ckfragen durch die systematische Auswertung der technischen Systemarchitektur reduzieren lassen Arbeiten zu den entsprechenden Abfragen und Aus wertungsmechanismen stehen noch aus POTAD wurde zu einem Zeitpunkt entwickelt zu dem noch kein Standard f r eine Trans formationssprache absehbar war Mittlerweile steht Query Views Transformations QVT kurz vor der finalen Verabschiedung als OMG Standard Eine Untersuchung der beiden letzten
304. ne Technologie zu l sen f r die es bereits ausgereifte Transformations mechanismen gibt Die Modelle werden entsprechend vor der Transformation in eine Zwischen darstellung konvertiert und danach wieder in das Ausgangsformat zur ckkonvertiert Die am h ufigsten f r diese Zwischendarstellung verwendete Technologie ist XML da es hier mit XSLT Extensible Stylesheet Language Transformations W3C 05 bereits einen sehr etablierten Transformationsmechanismus gibt Die Nutzung von XML bietet sich hierbei auch deswegen an weil es mit XM XML Metadata Interchange OMG 05a einen Standard gibt der be schreibt wie ber MOF definierte Modelle in XML repr sentiert werden Die meisten Ans tze f r Modelltransformationen schlagen eine spezielle Transformationssprache vor die in einer problemorientierten Syntax Konstrukte und Mechanismen f r die Formulierung von Transformationsregeln bereitstellt Bei den hierzu verf gbaren Arbeiten lassen sich folgende Unterscheidungsmerkmale feststellen e Paradigma Dabei wird haupts chlich in dek arative und imperative Ans tze getrennt In einer deklarativen Sprache werden zun chst nur Beziehungen zwischen Variablen be schrieben die anhand einer festgelegten Semantik ausgewertet werden um ein Ergebnis zu erzeugen Beispiele hierf r sind logische und funktionale Programmiersprachen Im Gegen satz dazu werden in imperativen Sprachen die einzelnen Schritte zur Erzeugung eines Er gebnisses explizit im
305. ne Template Instanz im Analysemodell festgehalten werden welche Designmuster unter welchen Bedingungen in einer bestimmten Transformation aus ihr hervorgingen und welche Randbedingungen in Form der Optimierungskriterien bei dieser Trans formation galten 166 5 Prototypische Umsetzung In diesem Kapitel wird der Nachweis der Anwendbarkeit fur den in Kapitel 4 beschriebenen Losungsansatz durch eine prototypische Implementierung erbracht Die Hintergrunde und die Architektur der prototypischen Implementierung werden vorgestellt und erlautert Die L sung ist eine Erweiterung des Werkzeugs Aationa XDE und besteht aus zwei Teilen Dem Modelltransformator der die in Kapitel 4 beschriebene Modelltransformation durchf hrt und dem Verfolgbarkeitsnavigator der die w hrend der Transformation angelegten Verfolgbar keitsinformationen auswertet und den Benutzer bei Verfolgung von Designentscheidungen unterst tzt Die Benutzung des so erweiterten Modellierungswerkzeugs ist an die in Kapitel 4 1 dargestellte POTAD Methode angelehnt An der Implementierung waren die in Kapitel 6 2 erw hnten studentischen Arbeiten in gro em Umfang beteiligt 5 1 Modelltransformator Zun chst werden die Werkzeugplattform sowie die an der prototypischen Umsetzung beteiligten Komponenten und deren Zusammenhang in Form einer Grobarchitektur skizziert Im Rahmen der bereits in Kapitel 3 2 4 f erw hnten Evaluierung von Werkzeugen mit Musterunterst tzung erwies sich
306. nem Datenbus lesen UserQuestion Werden die Sensordaten ber einen Datenbus zur Verf gung gestellt DE2Sig false Bus Template DataBus Reuse inputRep Repositoryt inputRep Repository ConcreteClient ol ControlInputValueSourcetol ReferenceValueSource ol ControlInputValueSource _ remote ol ReferenceValueSource remote ConcreteSubject Bus_ ol ReferenceValue Bus_ ol ControlInputValue ConcreteData N s hlsy Sensorwerte f r m gliche neue Konsumenten zugreifbar machen OptimCriteria Reuse AND NOT Bus Template PubSubscriber ol ReferenceValueSource Publisher inputRep Blackboard ConcreteSubscriber setData updateMethode refValPubSub OptimCriteria Reuse AND NOT Bus Template PubSubscriber ol ControlInputValueSource elements Publisher inputRep Blackboard ConcreteSubscriber setData updateMethode InputValPubSub Unterschiedliche Klassen f r Zust nde UserQuestion Muss der Regelalgorithmus mehrere Zust nde unterscheiden false Reactive Template ReactiveControlLoop ol OpenLoopController Master Context ol OQpenLoopController AbstractControlLoop AbstractControlLoop Reuse inputRep Blackboard tinputRep Blackboard Sensor ol ControlInputValueSourcetol ReferenceValueSource ol ControlOutputValueDrain Actuator getData Sensor_getMethod setData Actuator_getMethod ol OpenLoopController AbstractState Abstract
307. neuen Elementes e Entfernung Remova Entfernen des Quellelementes hnlich wie bei Graphtransformationen wird jedes Auftreten einer Struktur das der linken Seite einer Transformation entspricht durch deren rechte Seite gem der zus tzlichen Notation ersetzt Abbildung 3 55 zeigt einige Elemente der Notation anhand eines einfachen Beispiels bei dem UML Klassen in ein Modell f r relationale Datenbanken berf hrt werden Die be schrifteten Rauten mit den Pfeilen verdeutlichen dass die Zielelemente auf Basis des Quell elementes neu erzeugt werden sollen F r Attributwerte der neu erzeugten Elemente kann dazu auch auf Attribute der Quellelemente zugegriffen werden Die gro e Raute in der Mitte be deutet den verschachtelten Aufruf einer weiteren Transformation die analog der abgebildeten Transformation definiert ist Die halben Rauten links und rechts am Rand verdeutlichen den Input und Output der Transformation Package Database Bae belie rom Simei lit fom Simpie R DBMS tlass Class table Tanle rom Seel a fon Sider OBS Kind persistent name prefie class name Key _ Key fiom Simmer DEM name k_ classname primitive r preis prefix Sting PEETA a SSUES ee aes from Simtel Abbildung 3 55 Beispiel Definition einer Transformationsregeln in UMLX Willink 03a Als prototypische Realisierung des Ansatzes wird auf einen Editor fur das Me
308. nforderungen und der technischen Systemarchitektur 5 Werden f r den Mustereinsatz formalisierte Templates mit Parametern verwendet lassen sich die Beziehungen zwischen den Analyse und Designmustern systematisch beschreiben Kernelement ist hier die Zuweisung von Analysemusterparametern zu Designmusterpara metern 6 Auf Basis dieser Systematik lassen sich Modelltransformationen definieren mit denen der halbautomatische bergang zwischen Analyse und Designmodellen m glich ist 7 Durch Verlinkung der angelegten Designmusterinstanzen mit der Instanz des entsprechenden Analysemusters lasst sich die Verfolgbarkeit von Designentscheidungen unterst tzen Ulm den 17 September 2007 263 Eidesstattliche Erklarung Ich versichere dass ich die vorliegende Arbeit ohne unzulassige Hilfe Dritter und ohne Be nutzung anderer als der angegebenen Hilfsmittel angefertigt habe Die aus anderen Quellen direkt oder indirekt Ubernommenen Daten und Konzepte sind unter Angabe der Quelle gekenn zeichnet Weitere Personen waren an der inhaltlich materiellen Erstellung der vorliegenden Arbeit nicht beteiligt Insbesondere habe ich hierfur nicht die entgeltliche Hilfe von Vermittlungs bzw Beratungsdiensten Promotionsberater oder anderer Personen in Anspruch genommen Niemand hat von mir unmittelbar oder mittelbar geldwerte Leistungen fur Arbeiten erhalten die im Zusammenhang mit dem Inhalt der vorgelegten Dissertation stehen Die Arbeit wurde
309. ng 3 47 Ein auf Sicherheit und Robustheit optimiertes Design des Tempomaten 101 Abbildung 3 48 Parameterabh ngigkeiten zwischen Analyse und Designmustern e 103 Abbildung 3 49 Verfolgbarkeit durch Verkn pfung von Mustern ccccc cece ccc cce cece eee eeeneeeeeeneeneeaes 104 Abbildung 3 50 Illustration der angestrebten Transformation u2ssssseesenenensnnenenennen nennen nennen 107 Abbildung 3 51 Schematischer berblick zu MDA Modelltransformationen ccccccccccereeecseeeseeerevenes 111 Abbildung 3 52 Kategorien der technischen Realisierung von Modelltransformationen 114 Abbildung 3 53 Notation von EXMOF anhand eines Beispiels Compuware et al 04b 118 Abbildung 3 54 Beispiel eines Transformation Pattern Judson et al 03 123 Abbildung 3 55 Beispiel Definition einer Transformationsregeln in UMLX Willink 03a 124 Abbildung 3 56 Ausschnitt aus einer MOLA Transformationsregel Kalnins et al 04 125 Abbildung 4 1 Die POTAD Bausteine u una u 137 Abbildung 252 Die POTAB Arteiskte ana ura n eee coin R 138 Abbildung 4 3 Die durch POTAD erg nzten Artefakte in der ROPES Methode 139 Abbildung 4 4 Typischer Ablauf von Aktivit ten in POTAD eneeneneennnnnenennnenn
310. ng wird immer eingeleitet durch das Wurzelelement lt trace gt das beliebig viele Elemente vom Typ lt designmodel gt enth lt so dass die Information auch f r mehrere Trans formationen mit unterschiedlichen Zielmodellen festgehalten werden kann in der bisherigen Implementierung wurde allerdings die Beschr nkung auf ein Designmodell vorgenommen F r das Designmodell wird jeweils die ID innerhalb von Rational XDE und der Pfad angegeben Daraufhin folgt eine Reihe von Elementen lt optimCriteriaSetting gt mit Name und Wert die f r die Wahl der einzelnen Optimierungskriterien stehen Obwohl diese f r eine bestimmte Trans formation jeweils identisch sind werden sie f r jedes Analysemuster erneut protokolliert Anschlie end werden die erzeugten Designmuster mit dem Tag lt designpattern gt und dem Attribut id der Reihe nach aufgef hrt ber die IDs sind die Muster innerhalb eines Namens raumes eindeutig identifizierbar Falls die Erzeugung des Musters an Bedingungen gekn pft war werden diese innerhalb des lt designpattern gt Tags mit Hilfe der Elemente lt userquestion gt und lt OptimCriteriaSetting gt abgelegt F r die Benutzerr ckfragen wird dabei der Text Attribut 165 4 Eigener Losungsansatz POTAD text und die Antwort Attribut answer sowie f r Optimierungskriterien der Name Attribut name festgehalten Ist die Bedingung negiert so wird sie zusatzlich von einem Tag lt negated gt umrahmt Insgesamt kann so f r ei
311. ngen bzgl der verwendeten Entwicklungsmethode sowie den verwendeten Modellen und Mustern wird ein Formalismus f r die Beschreibung musterbasierter Transformationsregeln vorgestellt der durch die Einbeziehung von Zusatzinformationen bzgl unterschiedlicher nichtfunktionaler Anforderungen und der technischen Systemarchitektur das Zielmodell variieren kann Eine prototypische Implementierung des Ansatzes auf Basis des Werkzeugs Rational XDE wird in Kapitel 5 vorgestellt Hier wurde ein Plug in geschrieben das die entwickelten Trans formationsregeln ausf hren kann Abschlie end wird eine Beispielregel detailliert erl utert Eine kritische Reflexion des eigenen Ansatzes erfolgt in Kapitel 6 Die Ergebnisse werden be wertet und den eingangs formulierten Anforderungen gegen bergestellt Im anschlie enden Kapitel 7 wird die Arbeit zusammengefasst die Anwendbarkeit in anderen Dom nen diskutiert und ein Ausblick auf m gliche zuk nftige Themen gegeben 2 Fallbeispiel Kombiinstrument und Fahrfunktionen Am Beispiel eines kleineren Systems aus Kombiinstrument und Fahrfunktionen wurde die Problemstellung dieser Arbeit entwickelt der L sungsansatz siehe Kapitel 4 berpr ft weiter entwickelt und bewertet Dieses Kapitel stellt das System vor und erl utert dessen wichtigsten Eigenschaften F r beispielhafte Erl uterungen im weiteren Verlauf dieser Arbeit wird das Kombiinstrument und Fahrfunktionen System KFS zugrunde gelegt
312. ngungen f r die in den Kernprozess ein gebettete Softwareentwicklung ab In dem darauf folgenden Unterkapitel 3 2 wird untersucht inwiefern aktuelle modellbasierte Softwareentwicklungsmethoden diesen Rahmenbedingungen gerecht werden und ob den neuen Herausforderungen die sich aus aktuellen Trends der Dom ne ableiten siehe Kapitel 1 2 geeignet begegnet werden kann Mit den in Kapitel 3 3 besprochenen Modelltransformationen wird ein erster Schritt in Richtung eines Ansatzes voll zogen der System und Softwareentwicklung durch automatisiertes berf hren der Modelle starker integriert Dazu werden verf gbare Techniken zum Thema Modelltransformationen zusammengetragen und speziell hinsichtlich der in den vorherigen Unterkapiteln gesammelten Anforderungen untersucht Probleme und M ngel der existierenden Ans tze werden aufgezeigt und am Ende des Kapitels zu einer Problemstellung pr zisiert 3 1 Systementwicklung Anforderungen an Automotive Software folgen oft einer bestimmten Charakteristik Die Ent wicklung der Software ist eine Teilaktivitat einer bergeordneten Systementwicklung Aus diesen Tatsachen leiten sich einige Rahmenbedingungen f r die Softwareentwicklungsmethode ab die im Rahmen der Gesamtentwicklung von elektronischen Systemen im Fahrzeug zum 17 3 Stand der Technik Einsatz kommt Dies umfasst zum einen grundlegende Anforderungen an die zu entwickelnde Software selber zum anderen aber auch an den Prozess in den d
313. notigt werden Wurzel element fur eine Bindung ist die Klasse TemplateBinding Hierbei handelt es sich um eine ge richtete Beziehung erbt von DirectedRelationship zwischen einer Template Instanz TemplateableElement mit Aggregation boundklemnt und dem Template Typ TemplateSignature Uber die enthaltenen Elemente TemplateParameterSubstituion verf gt eine Bindung ferner ber Informationen bzgl der Zuordnung von tats chlichen zu formalen Template Parametern Diese Zuordnung wird dadurch realisiert dass TemplateParameterSubstitution jeweils eine gerichtete Assoziation zu einem formalen Template Parameter Rolle formal und zu mindestens einem konkreten Modellelement das von Paramterableklement erbt besitzt Rolle actual Die Bedingung dass der tats chliche Template Parameter und der formale Template Parameter typkompatibel sein m ssen ist im Standard durch ein entsprechendes OCL Constraint spezifiziert Kernel Element Templates Template 1 A rarameter formal Templates Template 1 ParameterSubstitution A Templates Parameterable actual owningSubstitution Element ownedActual 0 1 parameterSubstitution Kernel Directed Relationship tempais boundElement Templates Template TemplateableElemeni Binding Templates TemplateSignature signature Abbildung 3 33 Template Bindung 84 Softwareentwick
314. nsatzen pflegen teilweise ergeben sie sich jedoch erst indirekt durch eine Kette von verlinkten Objekten Die Mangel der EAST ADL sind in Themenbereichen angesiedelt deren Relevanz fur die weitere Diskussion bereits ausgeschlossen wurde Da das Metamodell des E E Konzept Tools nur eingeschrankt offentlich verfugbar ist wird im Folgenden die EAST ADL als Referenz Modellierungssprache fur die Systementwicklung verwendet 3 1 3 c Modellbildung in der Softwareentwicklung Im Bereich der Softwareentwicklung ist die Standardisierung der Modellbildung im Vergleich zur Systementwicklung relativ weit fortgeschritten Mit der Unified Modeling Language UML gibt es eine standardisierte und weithin akzeptierte Modellierungssprache mit der sich Modelle f r ein breites Spektrum von Softwareentwicklungsaufgaben erstellen lassen Hier gibt es auch einen relativ gut entwickelten Markt von Modellierungswerkzeugen und der Austausch von Modellen ist prinzipiell m glich Die UML wird ausf hrlicher in Kapitel 3 2 1 behandelt 3 1 4 Zwischenergebnis Das zur ckliegende Kapitel adressiert aus der Sicht der Systementwicklung die in der Problem stellung Kapitel 1 2 formulierten Fragen nach den grundlegenden Anforderungen und Trends der Dom ne und die Integration von System und Softwareentwicklung durch einen Gesamt prozess sowie den Austausch von Modellen Kapitel 3 1 1 hat gezeigt dass viele Softwarefunktionen im Fahrzeug dadurch charakterisiert werden
315. nstanziierung von Designmustern beschreiben l sst und somit ein etabliertes Instrument der Entwicklungsmethode wiederverwendet wird Die Umsetzung dieser Systematik verlangt von dem Modelltransformationsmechanismus die Klassenstruktur eines Musters in Form eines Templates mit Parametern beschreiben zu k nnen und eine Musterinstanziierung durch Bindung der Parameter und Expansion der Klassenstruktur im Zielmodell durchf hren zu k nnen Diese Grundfunktionalit t wird zwar von einigen Entwicklungswerkzeugen unterst tzt kann im Rahmen der betrachteten Modelltransformationsans tze aber nicht in dem notwendigen Umfang genutzt werden Um eine Modelltransformation nach der oben beschriebenen Systematik zu realisieren muss daher ein neuer Ansatz konzipiert werden 1 Die Analyse der Anwendungsdom ne hat gezeigt dass das Softwaredesign und damit auch die Auswahl der verwendeten Designmuster stark mit den unterschiedlichen nicht funktionalen Anforderungen und der technischen Systemarchitektur variiert Ein Modell transformationsmechanismus muss diese Variabilit t im Zielmodell entsprechend erm g lichen Viele der untersuchten Ans tze unterst tzen dies indirekt ber die M glichkeit die relevanten Informationen in einem zus tzlichen Eingabemodell abzulegen und die Aus f hrung einer Transformationsregel dann von einer Bedingung abh ngig zu machen die dieses Modell abfragt Hier w re ein noch feinerer Mechanismus w nschenswert der e
316. nt Abbildung 3 30 Metamodell f r die Template Definition Das Wurzelelement des Metamodells f r die Template Definition ist die abstrakte Klasse TemplateableElement Alle Spezialisierungen dieser Metaklasse k nnen als Template definiert werden Wie Abbildung 3 31 zu entnehmen ist handelt es sich dabei neben Classifier damit auch jede Spezialisierung wie z B Komponenten Datentypen Schnittstellen oder Signale unter anderem auch um Operationen oder Attribute bzw Properties Element TemplateableElement Package Operation Cassifier StringExpression Property Abbildung 3 31 Elemente die als Template deklariert werden konnen Wie Abbildung 3 30 weiter zu entnehmen ist enthalt ein Template eine Signatur TemplateSignature die wiederum Parameter TemplateParameter enth lt Ein Parameter verweist auf eine abstrakte Klasse ParameterableElement ber diese Beziehung wird unter 83 3 Stand der Technik anderem der Typ des Parameters festgelegt Um welchen Typ es sich dabei konkret handeln kann ist in Abbildung 3 32 zu sehen Element ParameterableElement ValueSpecification PackageableElement Operation Classifier ConnectableHement Property Abbildung 3 32 Elemente die als Parameter deklariert werden durfen Abbildung 3 33 zeigt die Elemente die fur eine Template Bindung be
317. ntik hat wird der Stereotyp in den Diagrammen nicht angezeigt Wenn im Folgenden Diagramme mit nformation Flows wie in Abbildung 3 15 gezeigt werden wird implizit angenommen dass entsprechend der beschriebenen Konvention die Signalbeziehung auch nach dem Muster aus Abbildung 3 14 modelliert wurde 3 2 1 d Modellierung der technischen Systemarchitektur mit Verteilungsdiagrammen Fur die Modellierung der Hardware Topologie und der Verteilung der Software des Systems auf die Hardware ist in der UML das Verteilungsdiagramm engl Deployment Diagram vor gesehen Hardware Einheiten werden als Knoten engl Nodes modelliert die ber Kommunikationsverbindungen und Abh ngigkeiten miteinander verkn pft werden k nnen Eine auf einen Knoten verteilbare Einheit wird als Artefakt engl Artifact bezeichnet und kann f r 48 Softwareentwicklung den Code einer Softwarekomponente stehen oder eine andere Form von verteilbarer Information z B Dateien Abbildung 3 16 zeigt eine Modellierung der technischen Systemarchitektur des KFS mit einem Verteilungsdiagramm das inhaltlich mit Abbildung 3 6 und Abbildung 3 9 vergleichbar ist Um eine ahnliche Aussagekraft wie die in Kapitel 3 1 3 b erlauterten Modelle der Systementwicklung zu erreichen wurde die UML in diesem Beispiel um ein ad hoc Profil mit Stereotypen f r die Beschreibung von Steuerger ten Sensoren Aktuatoren und Kommunikationsverbindungen erweitert ECU MMI_Kfz Mana
318. nziierung eines Musters 92 Softwareentwicklung Fur die Zuweisung der Musterparameter bietet XDE zwei Moglichkeiten Zum einen konnen bereits existierende Elemente aus dem Modellbaum ausgew hlt werden linker Dialog in Abbildung 3 42 Sollten f r die Parameterbelegung des Musters neue Elemente angelegt werden so kann dies zum anderen direkt in dem Dialog geschehen Dazu muss dem Element ein Name gegeben werden Hierbei kann der Benutzer alternativ direkt einen Namen angeben oder den Namen per String Ausdruck in der XDE eigenen Script Sprache generieren lassen rechter Dialog in Abbildung 3 42 Letzteres ist vor allem hilfreich wenn das Muster ver schachtelt in einem weiteren Muster verwendet wird oder wenn das Muster wiederholt an gewendet wird Select Argument Values Select Argument Values Available value sources 3 Available value sources C Generated C Collection Generated Collection Be Specify a value For the ClosedLoopController parameter q Be Specify values for the FeedbackValueSource parameter Select an available class Selected Class Enter name for a Class Selected Classis F Example i CruiseController Simple value Select gt gt i ClosedLoopControl_ Speedsensr 7 JSensor Bg ClosedLoopControl_ lt lt Remove CruiseController C Script value Lever F SpeedSensor Throttle GCruiseController l GSpeedSensorif cri gt Feedb
319. ob inhaltliche Verbindungen zwischen Elementen aus Quell und Ziel modellen im Rahmen der Transformation festgehalten werden k nnen und somit ein spezieller Mechanismus f r eine sp tere Auswertung zur Verf gung gestellt werden kann e Variabilit t Ansatze k nnen die Formulierung verschiedener Varianten einer Trans formation erlauben die von gewissen vorgegebenen oder sich aus den Quellmodellen er gebenden Bedingungen abh ngen 3 3 2 c Kategorien f r Realisierungsans tze Unabh ngig von der im vorherigen Abschnitt vorgenommenen Differenzierung hinsichtlich unterschiedlicher Anforderungsmerkmale lassen sich auch bei den Realisierungsans tzen Kate gorien bilden siehe Abbildung 3 52 kombiniert Abbildung 3 52 Kategorien der technischen Realisierung von Modelltransformationen Viele Hersteller von UML Werkzeugen bieten die M glichkeit Modelltransformationen durch direkte Manipulation des Modells mit Hilfe von Programmierschnittstellen APIs zu realisieren 114 Modelltransformationen In diesem Fall werden einzelne Transformationen direkt in einer i d R objektorientierten Programmiersprache implementiert Dazu steht i d R eine spezielle Bibliothek zur Verf gung die haufig verwendete Operationen wie z B das Lesen vorhandener oder das Erzeugen neuer Modelle und Modellelemente bereitstellt Eine weitere Kategorie von Ans tzen versucht Modelltransformationen durch eine bertragung des Problems auf ei
320. odellierungssprache gibt es im Rahmen dieser Arbeit bei der Untersuchung von Modelltransformationssprachen Kapitel 3 3 der Untersuchung der UML Templates Kapitel 3 2 4 e sowie der Spezifikation der eigenen Transformationssprache in Kapitel 4 Der UML Profilmechanismus wird im Rahmen dieser Arbeit genutzt um neu definierte Metaelemente die die Semantik der UML erweitern in herk mmlichen UML Diagrammen darstellen zu k nnen siehe Kapitel 4 4 Es gibt zudem modellbasierte Ans tze aus dem Bereich der Systementwicklung die Inhalte der Systement wicklung mit Hilfe eines Profils aus Basis der UML modellieren siehe Kapitel 3 1 3 b 3 2 1 c Modellierung der logischen Systemarchitektur mit Klassendiagrammen Ein Klassendiagramm ist eine graphische Darstellung von Klassen Objekttypen und ihren Beziehungen zu anderen Klassen Ein durch solch ein Diagramm visualisiertes Klassenmodell wird in objektorientierten Softwareentwicklungsmethoden blicherweise sowohl in der Analyse als auch in der Designphase verwendet siehe Kapitel 3 2 2 Im Folgenden soll die in der Problemstellung aufgeworfene Frage diskutiert werden wie sich die Modelle der Systement wicklung in der UML darstellen lassen Dazu geh rt insbesondere auch die Modellierung der logischen Systemarchitektur in der Analysephase der Softwareentwicklung Die hier zu modellierenden Inhalte sind in Tabelle 3 1 zusammengefasst 46 Softwareentwicklung Das im Rahmen dieser Arbeit betrach
321. oder mehrere Gr en als Ein gangsgr en andere Gr en als Ausgangsgr en aufgrund der dem System eigent mlichen Gesetzma igkeiten beeinflussen Kennzeichen fur das Steuern ist der offene Wirkungsweg bei dem die durch die Eingangsgr en beeinflussten Ausgangsgr en nicht fortlaufend und nicht wieder ber dieselben Eingangsgr en auf sich selbst wirken Im Gegensatz zum Muster ClosedLoopControl kann es hier mehrere Ein und Ausgangsgr en geben wobei es sich bei den Eingangsgr en definitionsgemaB nicht um eine R ckf hrgr e handeln darf Somit werden bei der Steuerung auch nicht alle St rgr en ber cksichtigt bliche Ans tze bei der Steuerungsfunktion sind einfache Zookup Tabellen oder mathematische Funktionen Pont 01 2 3 Struktur und Informationsfluss OpenLoopController Class o 1 ControlOutputValueDrain Class o 1 ControlOutputValue Signal i 0 ControllnputValueSource Class i 0 ControllnputValue Signal ReferenceValueSource Class ReferenceValue Signal a OpenLoopControl gt St ne Eee of 0 ec P A REIEIENCEVA ICH lt ControlOutputValue gt ReferenceValueSource OpenLoopController ET E TE EE E E D ControlOut putVa lueDra in e ReferenceValueSource Sendet die Sollgr e ReferenceValueSource an OpenLoopCont roller e ControllnputValueSource Weitere f r die Steuerung relevante Informationsquelle
322. ogicalCluster OS Task Processor Logische architektur Sen C x Q i O Sm E Q de VY gt 7 eb z Q E Q gt Funktion Mikroprozessor Logischer Sen 2 Kette FunctionalDevice LocalDeviceManager m sor Aktuator Sensor Actuator Peripheral E E Komponente element Channel Bussignal bzw Zus tzlich DesignData Type TypeAssociation 1 Abstraktes Daten Kette ConnectorSignal Signallnstance Frame 3 Botschaft mplementationData I ype Tabelle 3 5 Mogliche Elemente der EAST ADL fir die logische und technische System architektur sowie fur die Mappings 33 3 Stand der Technik Die logische Systemarchitektur kann auf der Seite der EAST ADL durch die Functional Ana lysis Architecture abgebildet werden In Abbildung 3 5 ist ein kleiner Ausschnitt einer moglichen Functional Analysis Architecture fur das KFS aus Kapitel 2 dargestellt der inhaltlich aus Abbildung 2 1 abgleitet ist Ein Functional Device mit Namen Tempomathebel verfugt Uber einen Sender Port mit dem Namen Benutzerkommando Der Port ist durch das Interface IF_Benutzerkommando getypt das die Beschreibung eines abstrakten Signals f r die bermittlung von Benutzerkommandos enth lt die Interface Definition ist nicht abgebildet Die Analys s Function mit dem Namen Tempomat Speedtronic verf gt ber einen entsprechenden Empf nger Port der ber einen Connector mit dem Sender Port verb
323. omains werden als Output im Rumpf erzeugt Der Rumpf kann optional eine einf hrende n t Section und eine abschlie ende endSection enthalten Innerhalb des Rumpfes stehen eine Reihe aus imperativen Programmiersprachen bekannte Anweisungen zur Verf gung wie z B Schleifen oder bedingte Verzweigungen In der textuellen Syntax hat ein Mapping die folgende Struktur mapping lt Name des Mappings gt lt Input Parameter gt lt Output gt quard lt Optionale Bedingungen oder Matchings gt init lt Optionale Init Section gt lt Ausdrucke zur Generierung des Outputs gt end lt Optionale End Section gt Sowohl Ae ations als auch Mappings k nnen auf verschiedene Arten komponiert und redefiniert werden Als Erg nzung der textuellen Notation wird auch eine graphische Notation auf Basis von UML Objektdiagrammen vorgeschlagen die die Transformationen allerdings nur auf Ebene der Patterns beschreibt Die Formulierung von Bedingungen und die Implementierung der Transformation sind daher nur mit Hilfe der textuellen Syntax m glich Unter dem Namen QVT Interoperabilit t wird die Einbettung in ein Framework ber eine Abstraktionsschicht f r Modell und Metamodell Repositories vorgeschlagen das auch die Ausf hrung von manuell programmierten Transformationen in verschiedenen Programmiersprachen und eine Wechsel wirkung mit diesen unterst tzen soll Verfolgbarkeit wird im Metamodell von QVT durch ein eigenes Paket adressiert
324. on einem Guard Ausdruck und einer Attributbelegung dargestellt werden Der Pattern Graph wird ber die Pattern Specification Language ausgedr ckt und enth lt im 120 Modelltransformationen Gegensatz zu der g ngigen zweiseitigen Notation bei Graphtransformationen ein Pattern mit Elementen aus dem Quell und Zielmodell Die Mapping Funktion definiert fur jedes Element aus dem Pattern ob es bei Anwendung der Regel im Graph gematched geloscht oder neu erzeugt werden soll In dem Guard k nnen uber OCL Ausdr cke zus tzliche Be dingungen f r die Ausf hrung der Regel formuliert werden die Attributbelegung weist den neu erzeugten Elementen Werte zu e Kontrollstrukturen f r die Graphersetzung und transformation die ber Konzepte wie Sequenzierung parallele Ausf hrung hierarchische und rekursive Definitionen oder bedingte Verzweigungen eine Steuerung der Ausf hrungsreihenfolge der Produktionen erlauben Im Rahmen der Recherchen konnte nicht gekl rt werden ob und wie Verfolgbarkeit unterst tzt wird Anhand einer selbst entwickelten Werkzeugkette wurde der Ansatz evaluiert In einem anderen Beitrag Karsai et al 03 diskutieren die Autoren auch den Zusammenhang von GReAT und QVT und listen eine Reihe von Herausforderungen und M glichkeiten der Ver wendung von Graphtransformationen f r die MDA auf die vor allem die intuitive Darstellung und den R ckgriff auf bew hrte Technologien als Vorteile hervorheben 3 3
325. onal Analysis Architecture bekannten Ports Connectors und nterfaces zur ck Ein ConnectorSignal kann hier aber mit dem Implementierungstyp mp ementationData Type getypt sein Zwischen DesignData Type und mplementationData Type kann eine Abbildung beschrieben werden Ports und Funktionen verf gen ber Attribute mit denen das zeitliche Verhalten spezifiziert werden kann z B Zykluszeit ber einen Loca DeviceManager kann mit der Hardware kommuniziert werden Function Instance Model Beschreibt die Instanziierung von Funktionen f r ein konkretes Fahrzeug Dazu werden F ementarySoftwareFunctions mit gleichen zeitlichen An forderungen f r die sp tere Zuordnung zu Tasks zu Clustern zusammengefasst und somit die logische Hierarchie und die Variabilit t aufgel st F r Funktionen die ber Cluster Grenzen hinweg kommunizieren m ssen werden Signalinstanzen zwischen den ent sprechenden Clustern angelegt Hardware Architecture Beschreibt die Hardware f r Steuerger te ECU Sensoren und Aktuatoren sowie die Kommunikationskan le Channel die diese verbinden Ein Channel kann vom Typ electrical CAN oder weiteren Bustechnologien sein Der interne Aufbau 31 3 Stand der Technik eines Steuergerats kann mit Elementen wie Processor Memory und Peripheral Peripherie z B auch Bus Transceiver beschrieben werden Au erdem ist es m glich f r Steuerger te Pins anzulegen und diese mit Leitungen Wires zu ver
326. op CruiseController_ControlLoop Sensor Speed AdjustingLever SpeedSensor Actuator Throttle Sensor_get Method getDesiredSpeed getCurrentSpeed Actuator_set Method setT hrottleS etValue Context CruiseController_ Master _CruiseController_ControlLoop secondaryCalc 1 tan secondaryCalc 1 bind Bind AbstractAlgorithm ControlAlgorithm Concrete Algorithm Long Short algorithm P nterface cruise Context CruiseController_ControlLoop ons gt X Konflikt Element wird nicht neu angelegt Ein Konflikt tritt bei dieser Instanziierung nur bei dem tats chlichen Parameter f r Context auf Hier wird die bereits bestehende Klasse CruiseController_ControlLoop wiederverwendet Abschlie end wird das Template Watchdog instanzilert OptimCriteria Safety Template Watchdog Watchdog Watchdog cloop Context MonitoredChannel watchDog Die Struktur des Templates Watchdog Watchdog Class MonitoredChannel 1 Class Watchdog gt en me m eee Watchdog _ lt MonitoredChannel gt MonitoredChannel _ lt Watchdog gt stroke correctivAction periodic call_stroke wird wie folgt mit dem existierenden Modell Ausschnitt verschmolzen bind Bind MonitoredChannel CruiseController_ Watchdog _CruiseController_ Master X Konflikt Element wird nicht neu ange
327. osedLoopController Class FeedbackValue Signal ControlOutputValue Signal ReferenceValueSource Class ControlOutputValueDrain Class FeedbackValueSource Class E oe ren osedLoopContro a p ua io 2 ie lt ReferenceValue gt ReferenceValueSource E E E E lt ControlOutputValue gt FeedbackValueSource Abbildung 3 39 Darstellung des Musters im Diagramm Uber diese grundlegende Musterdefinition hinaus k nnen in dem Pattern Explorer noch detailliertere Einstellungen vorgenommen werden siehe Abbildung 3 40 Dazu geh rt ein Feld f r jedes Element des Musters in dem das Verhalten beim Verschmelzen eingestellt werden 90 Softwareentwicklung kann siehe folgendes Unterkapitel Des Weiteren k nnen im Pattern Explorer spezielle Dialoge f r die Anwendung des Musters Constraints f r die tats chlichen Musterparameter zus tz lichen Script Code f r die Anwendung des Musters und vieles mehr spezifiziert werden Zu den definierbaren Constraints geh rt auch die Multiplizitat des Parameters womit die bei der Er lauterung der UML bem ngelte L cke an dieser Stelle geschlossen wird Li e Kr I ein es a ri LI cree eeu ri ri Misc Patterns Ji ClosedLoopContral 5 Pattern Applications al Advanced Properties Default Expansion Location ce Default Bind Location X Stereotype Application GA Toolbox Application E Custom
328. pansion EXP Die Klassenstruktur eines Templates muss nach der Bindung wie in Kapitel 3 2 4 f erlautert expandiert und mit dem Zielmodell verschmolzen werden konnen Template Instanz als Ausf hrungskriterium einer Regel AKR Template Instanzen im Quellmodell m ssen auffindbar und ihre Parameterbelegung aufl sbar sein Das Vor kommen einer Template Instanz eines bestimmten Templates muss als Kriterium fur die Ausfuhrung einer bestimmten Transformationsregel definiert werden konnen Zusatzinformation ZI Neben dem eigentlichen Quellmodell muss eine Transformation auch Zusatzinformationen entsprechend Kapitel 3 3 1 b verarbeiten k nnen in Abh ngigkeit derer die Transformation das Zielmodell variiert Konkret sollen Modelle der technischen Systemarchitektur und Designparameter abgefragt werden k nnen Hierbei ist es akzeptabel wenn diese Informationen f r die Transformation in eine bestimmte Form ge bracht werden m ssen Bedingungen BED Das Anlegen von Template Instanzen muss mit Bedingungen ver kn pft werden k nnen Eine Bedingung kann die an einer Transformation beteiligten Modelle und die spezifizierten Zusatzinformationen ZI abfragen Verfolgbarkeitsinformationen TRC Es muss m glich sein im Rahmen einer Trans formation spezielle Abh ngigkeitsbeziehungen zwischen Template Instanzen aus dem Ziel modell und solchen aus dem Quellmodell anzulegen Diese k nnen entweder als direkte Ver kn pfungen zwischen den
329. pische Einsatzszenarien ohne eine genaue Aussage bzgl einer konkreten L sung zu machen Um auch f r diesen elementaren Bestandteil der MDA eine standardisierte und damit austauschbare L sung zur Verf gung zu haben lancierte die OMG im April 2002 den Request for Proposal RFP f r einen neuen Standard namens MOF 20 Query Views Transformations RFP QVT Die zahlreichen ersten Einreichungen zu diesem RFP verdichteten sich nach und nach auf zwei Ans tze EXMOF von den Firmen Compuware und Sun und QVT von der QV7 Merge Group einem Zusammenschluss zahlreicher Firmen Mittlerweile ist unter dem Titel MOF QVT eine Version des letzten Vorschlags verf gbar die als Final Adopted Specification bezeichnet wird OMG 07 Damit ist zu erwarten dass dieser Vorschlag ohne gr ere nderungen als offizieller OMG Standard verabschiedet wird Im Folgenden werden die letzen beiden konkurrierenden Ans tze im Standardisierungsprozess n her analysiert 3 3 3 a QVT Merge Group QVT In QVTMG 04 werden fiir Queries eine Erweiterung der OCL 2 0 vorgeschlagen und Views werden als Ergebnisse spezieller Transformationen nicht separat behandelt Bei den Trans formationen wird in rein deklarative Ae ations als Spezifikation und operationale Mappings als Implementierung einer Transformation differenziert Mit Hilfe einer speziellen Pattern Matching Language k nnen beliebigen Strukturen aus Elementen des f r den jeweiligen Kontext g ltigen Metamodells
330. plate Parameter nur einen dieser vier Typen haben In den Beispielen dieser Arbeit werden die Parametertypen Property in der Form als Klassenattribut und Operation nur fur Templates der Designebene verwendet der Parametertyp Signal kommt hingegen nur bei Templates der Analyseebene zum Einsatz Durch Einf hrung einer neuen Vererbungsbeziehung ist nun auch TemplateParameter Subtyp von MultiplicityElement Damit kann einem Parameter eine Multiplizitat zugewiesen werden und die in Kapitel 3 2 4 e identifizierte L cke geschlossen werden Das Element TemplateParameterGroup wurde neu hinzugef gt Es realisiert die in Kapitel 3 2 4 e als L cke identifizierte Gruppierung von Parametern Eine Gruppe besitzt eine Multiplizitat und kann keine weiteren Untergruppen enthalten Letzteres ist eine komplexi tatsreduzierende Einschr nkung die f r die hier betrachteten Beispiele keine Nachteile hat in zuk nftigen Arbeiten aber beseitigt werden sollte Die Klasse StringExpression wird ber eine Kompositionsbeziehung von NamedElement ein gebunden Von NamedElement erben wiederum viele Elemente die in einem Template ent halten sein k nnen Da TemplateableElement entfernt wurde siehe oben existiert auch die Vererbungsbeziehung zu StringExpresseion nicht mehr Das neue Element Template hat die Vererbungsbeziehung nicht bernommen Es ist somit m glich Stringausdr cke innerhalb eines Templates zu verwenden ein String Ausdruck selber kann aber nicht
331. prache enth lt bereits einige wesentliche Konzepte die in VMT mit eingeflossen sind 3 3 4 d I Khriss Design Unterst tzung durch Muster basierte Transformationen In Khriss et al 99a wird ein Ansatz beschrieben in dem mit Hilfe von Modelltrans formationen ein UML Designmodell schrittweise verfeinert wird Transformationsregeln werden in Form von Verfeinerungsschemata in einer Bibliothek zusammengefasst die jeweils ein 121 3 Stand der Technik abstraktes und ein detailliertes Modell umfassen Das detaillierte Modell verfeinert das abstrakte Modell durch die Anwendung eines Designmuster das fur diese Verfeinerung charakteristisch ist Neben Klassenmodellen sind auch Zustands und oder Kollaborationsmodelle moglich Die Verfeinerungsschemata werden aus einzelnen elementaren Verfeinerungen aufgebaut sog Micro Refinements f r die Korrektheitsbeweise im Sinne formaler Verifikation angegeben werden diese werden in Khriss et al 99b genauer beschrieben Damit ist nach Ansicht der Autoren auch das gesamte Verfeinerungsschema verifizierbar Eine Transformation eines Modells erfolgt schrittweise durch Anwendung ausgew hlter Verfeinerungsschemata auf aus gew hlte Teile des Modells Als Vorteil der Verfeinerung auf Basis von Mustern wird die Ver folgbarkeit von Designentscheidungen angef hrt Ein Konzept das den Einsatz der Ver feinerungsschemata dauerhaft verfolgbar macht wird jedoch nicht beschrieben sondern stich punktartig
332. r instanzilert OptimCriteria Reuse Template PubSubscriber cl ReferenceValueSource Publisher inputRep Repository ConcreteSubscriber set cl ReferenceValue updateMethode refValPubSub OptimCriteria Reuse Template PubSubscriber cl FeedbackValueSource Publisher inputRep Repository ConcreteSubscriber set cl FeedbackValue updateMethode feedValPubSub zweimal Bei der Parameterzuweisung findet eine Verwebung mit dem zuvor angelegten Repository Muster statt Dar ber hinaus gibt es bei dieser Instanziierung keine Besonderheiten Die Struktur des Musters PubSubscriber Publisher Subscriber lt Publisher gt Subscriber notifySubscribers x updateMethode Publisher Class ConcreteSubscriber 1 Class ConcreteSubscriber updateMethode Operation updateMethode PubSubscrib gt nn u upscriper Be Per wird mit dem Zielmodell Ausschnitt wie folgt verschmolzen bind Bind ConcreteSubscriber InputRepository updateMethod set DesiredS peed Publisher S peedAdj ustingLever R _Subscriber aT Bind ConcreteS ubscriber InputRepository updateMethod set CurrentS peed Publisher S peedSensor DesiredSpeed E CurrentSpeed X Konflikt Element wird nicht neu angelegt Die dem Parameter ConcreteSubscriber zugewiesene Klasse wurde
333. r FeedbackSensor_ value rpmValue Actuator_ value EGAS_value Director_reference Value desiredS peed bind LocalFaultHandler LocalCCFault Handler GlobalFaultHandler Global PowertrainF aultHandler LocalFault Handler_FaultThrowingEntity Engine Controller LocalFaultHandler_error Code EngineContr_errorCode Global FaultHandler_errorCode Global_ error bind Detector Engine RPMDetector Corrector Engine ThrottleCorrector Detector_error Code EngineDet_errorCode Local FaultHandler LocalEngineRPMF ault Handler Corrector_recoveryAction Code recoveryAction Monitored Entity EngineRPMSensor Corrective Entity EngineController bind Director SpeedController OpenLoop Controller Engine Controller Actuator Throttle Actuator Actuator_value Throttle_ value Director_referenceValue EGAS _ value 249 C 3 Designmodell Strategy x _AbstractData _DataBus 0 1 0 1 _DataBus lt p _Blackt WWW V _AbstractThread lt gt _ExceptionHaindler _ExceptionSafeClass im 250 ckboard 0 1 _DataHolder Zee x _Actuator 1 _Actuator L _ExceptionHandler _ExceptionSafeClass 1 _Strateg _ExceptionSafeClass 1 1 _ExceptionHandler _ExceptionLog 1 _ExceptionLog _Bcepionecorg EcaptionRecord
334. r einer Probleml sung die in einer nachteiligen Situation resultiert abschrecken Der Begriff Anti Muster wurde urspr nglich 1995 von Koenig 95 vorgeschlagen und ist eventuell etwas missverst ndlich da es abgesehen von den Anti Mustern mit negativer Vorbildfunktion auf die das Pr fix Anti sicherlich passt noch eine weitere Gruppe von Anti Muster gibt die zus tzlich beschreiben wie man ausgehend von einer unvorteilhaften Aus gangssituation den Sprung zu einer rettenden L sung schaffen kann Zu Anti Mustern sind in den vergangenen Jahren zahlreiche Werke entstanden z B Brown et al 98 Qualitative Eigenschaften eines Designmuster In Kapitel 3 2 4 b wurden einige grunds tzliche Anforderungen an Designmuster genannt wie z B Wiederverwendbarkeit der L sung oder das wiederholte Auftreten eines Problems In Lea et al 94 werden weitere Eigenschaften beschrieben anhand dessen sich die Qualit t eines Musters beurteilen lasst e Kapselung und Abstraktion Ein Muster kapselt ein wohldefiniertes Problem in einem festgelegten Anwendungsfeld und stellt eine Abstraktion von empirisch erarbeitetem Wissen und praktischer Erfahrung best practice dar e Offenheit und Variabilit t Jedes Muster sollte Erweiterungen durch andere Muster er lauben und eine Abh ngigkeit seiner Auspr gung bzw Implementierung von bestimmten Gegebenheiten erm glichen e Generativitat und Zusammensetzbarkeit Der Vorgang der Erstellung einer Mus
335. r vorhandenen Dokumentation keine konkrete Implementierung vorgenommen werden weshalb die Einsch tzungen hier nur auf konzeptionellen berlegungen beruhen ing alalla EXMOF GReAT Wird bereits im vollen Umfang unterst tzt Kann indirekt oder mit Hilfe kleinerer Erweiterungen unterst tzt werden Kann mit Hilfe gr erer Erweiterungen unterst tzt werden O Wird nicht unterst tzt ae ww CAE Eanes SE EES IEEE Tabelle 3 13 Erf llungsgrad der verbliebenen Ans tze in Bezug auf die Anforderungen aus Kapitel 3 2 5 Zwei Kriterien werden von allen Ans tzen voll erf llt So unterst tzen alle Kandidaten UML Klassendiagramme Anforderung UML und bieten in unterschiedlicher Form M glichkeiten Template Instanzen aufzufinden und diese als Ausf hrungskriterium f r eine Transformations regel zu formulieren Anforderung AKR Die Wiederverwendung von Templates ber Trans formationen hinaus Anforderung TEM ist bei keinem Ansatz m glich es bestehen lediglich verschieden ausgepr gte M glichkeiten innerhalb von Transformationen durch eigene Implementierung eine vergleichbare Definition vorzunehmen Einen expliziten Bindungs und Expansionsmechanismus Anforderung EXP bietet keiner der Ans tze lediglich bei dem Vor schlag der QVT Merge Group l sst sich dieser in Ans tzen durch spezielle Transformations regeln nachbilden Die Abh ngigkeit von Zusatzinformationen ZI kann bei ebendiesem Ansatz ber Transforma
336. r_ Model attach detach getData B 4 DetectorCorrector 1 Transformationsregel Rule DetectorCorrector Actuator Template DetectorCorrector_Actuator dc gt _InstrumentCluster_ Controller _InstrumentCluster_Controller _InstrumentCluster_ Model InstrumentCluster_Controller currentState State initialize handleEvent call operation 3 p _ State CarState _ fae handleEvent u a EngineOff EngineRunning handleEvent handleEvent berwachungskonzept des Aktuators in einem Objektmodell abbilden Template MonitorActuator getNames Klasse die den Kontext der berwachung darstellt 1 Context getNames Name des berwachungssensors 1 dc Detector dc Actuator ser de Aellaror Value getNames Klasse die den Sollwert liefert 1 ActuatorMonitorSensor Monitor Actuator Actuator_setMethode ReferenceValueSource getNames Methode fiir die Abfrage des Sollwerts 1 ReferenceValueSource_getMethod dc CorrectiveAction monAct correctiveActionMethod Fehler auf der Ebene einer Objektkollaboration erkennen und behandeln Template ExceptionMonitor monAct Monitor UEXeCowmlon ar las len Ju G ExceptionSafeClass monAct Monitor ExceptionHandler Excep dc Local rav
337. rache beschrieben F r eine Umsetzung in die Praxis bedarf es allerdings einer konkreten Schreibweise in der die in 160 Modelltransformationssprache der abstrakten Syntax beschriebenen Konzepte ausgedr ckt werden k nnen Wie schon in Kapitel 3 3 gesehen gibt es hierf r verschiedene M glichkeiten die sich in erster Linie auf graphische und textuelle Notationen aufteilen Im Folgenden wird eine textuelle Notation vor gestellt die im weiteren Verlauf dieser Arbeit verwendet wird Die erarbeitete textuelle Notation versucht die Konzepte aus dem Metamodell m glichst direkt in Schl sselw rter oder konstrukte einer Art Programmiersprache umzusetzen Die in den offenen Punkten ausgef hrten Gestaltungsm glichkeiten bei Konstruktoren f r Elemente und bei der Namenswahl wurden dabei bereits konkretisiert Die entstandene Sprache wird nach folgend zun chst informell beschrieben um einen Bezug zur abstrakten Syntax und damit zur Semantik herzustellen Anschlie end wird die Grammatik der Sprache in der bei kontextfreien Sprachen blichen EBNF xtended Backus Naur Form dargestellt 4 3 3 a Informelle Erl uterung Transformationsregeln bestehen in der textuellen Syntax aus folgendem Schema Regelname Regelparameter Linke Seite gt Rechte Seite Bei Regeln ohne Parameter die bei Vorkommen einer Template Instanz eines bestimmten Typs ausgef hrt werden wird die linke Seite mit Template lt Template gt lt Variablennam
338. rammierte Plug in wertet den XML String aus der einer Analysmusterinstanz als Tagged Value TraceInfo des Stereotyps AnalysisCollaboration aus dem Profil Traceability w hrend des Transformationsvorgangs hinzugef gt wurde Eingebunden in das Werkzeug 172 Verfolgbarkeitsnavigator werden die Abfragen uber den XDE Menu Extender Mechanismus Dieser erlaubt es eigene Software in das XDE Menusystem einzubinden auch in die Kontextmenus Dem Werkzeug bekannt gemacht wird solch eine menu extension mit einem menu specification file das in einem entsprechenden Verzeichnis liegen muss Auf diese Weise konnen die Abfragen uber Kontextmenus genau fur die Kontexte gestartet werden die in Kapitel 4 1 2 vorgesehen sind Abbildung 5 5 zeigt den Aufruf uber das Kontextmenu einer Analysemusterinstanz Abfragen die nicht zu dem Kontext passen sind deaktiviert oe d He T Collection Editor FS Properties Window Analysiscollaboration Cruiseclosedloop Code Templates Extensions POTAD Traceability Navigator Analyse Abbildung 5 5 Aufruf des Verfolgbarkeitsnavigators uber das Kontextmenu lm Folgenden sind die drei Abfragen noch einmal implementierungsspezifisch beschrieben 1 Die Abfrage Ana yse kann uber das Kontextmen einer Musterinstanz im Model Explorer oder einem Diagramm aufgerufen werden die ber einen Stereotyp lt lt AnalysisCollaboration gt gt verf gt und au erdem eine lt lt design for g
339. rans ation in einem gewissen Umfang auch zum Detailed Design Eine weitere Differenzierung in Musterarten ist nach der Dom ne m glich Tabelle 3 8 listet f r die Hauptkategorien Musterkataloge verschiedener Autoren auf und ordnet sie einer Dom ne zu Die Auswahl ist ungeordnet und beispielhaft Entsprechend dem Schwerpunkt dieser Arbeit sind aber vor allem Muster aus dem Bereich der eingebetteten Steuerungs und Regelungs systeme gew hlt worden Weitere hier nicht aufgef hrte Muster aus diesem Bereich finden sich z B bei Kircher et al 02 Kircher et al 01 Tendenziell nehmen die Designmuster in ihrer Beschreibung wenig Bezug auf eine Dom ne Eine Dom ne bedient sich zwar oft einer bestimmten Auswahl von Designmustern diese k nnen jedoch in mehreren Dom nen verwendet werden und sind entsprechend auch dom nen neutral beschrieben So spielen Muster die z B Zuverl ssigkeitsaspekte adressieren im Bereich der Steuerungs und Regelungssysteme genauso eine Rolle wie bei Systemen aus dem Bank bereich 70 Softwareentwicklung Kate Musterkatalog Domane gorie Fowler Analysis Patterns Fowler 97 Balzert Analysemuster Balzert 99 Konrad et al Object Analysis Patterns for Embedded Eingebettete Steuerungs Systems Konrad et al 04b Coad et al Patterns Coad et al 97 Fernandez Yuan Semantic Analysis Patterns Verwaltung allgemein Fernandez et al 00 und Regelungssysteme Geyer Sch
340. rarchie die kleinste Einheit darstellen Nicht in allen Projekten m ssen alle Abstraktionsebenen betrachtet und modelliert werden In reinen Softwareprojekten die existierende Standardhardware verwenden k nnen beispielsweise die Ebenen f r Softwarekomponenten und Threads ausreichen Parallel zu der in Abbildung 3 21 dargestellten Zerlegung der Architektur existieren in ROPES fest definierte Sichten Views die die Architektur in Hinblick auf eine ganz bestimmte Frage stellung hin betrachten Sichten basieren in einem Projekt immer auf demselben Modell filtern jedoch nur die Anteile heraus die f r die Fragestellung relevant sind ROPES verwendet die folgenden f nf Sichten e Subsystem and Component View Zeigt wie das System auf oberste Ebene in Sub systeme und Komponenten unterteilt wird Diese Unterteilung erfolgt vor der Trennung in Disziplinen so dass z B ein Subsystem sowohl Hard als auch Softwareaspekte umfassen kann Bei reinen Softwareprojekten kann sich diese Unterteilung auf Softwarekomponenten beziehen Diese Sicht korrespondiert mit den gleichnamigen Abstraktionsebenen aus Abbildung 3 21 und ist die Grundlage f r alle weiteren Sichten Die Darstellung erfolgt in UML Klassen und Komponentendiagramme e Concurrency and Resource View identifiziert nebenlaufige Tasks zeigt den grunds tz lichen Ansatz f r das Scheduling und Regeln f r die Synchronisierung und das Ressourcen management Diese Themen werden primar i
341. rbeitet In einer Kennlinie werden Ansteuerungswerte f r Aktuatoren in Abh ngigkeit von gemessenen Sensorwerten abgelegt Die abgespeicherten Werte werden St tzstellen genannt dazwischenliegende Werte m ssen interpoliert werden Je nachdem ob die Steuerung eine Interpolation ben tigt ob die St tzstellen feste Abst nde haben und wie das zu erwartende Abfrageverhalten ist z B ob aufeinander folgende Abfragen h ufig nah beieinanderliegende Sensorwerte enthalten werden unterschiedliche Suchalgorithmen zum Auffinden von Stutzstellen und unterschiedliche Daten strukturen zur Ablage der Kennlinie verwendet Diese Alternativen wurden als Muster erfasst wobei diese haupts chlich aus Code Templates bestehen und kaum UML Elemente enthalten Auch f r diese Muster konnte eine Transformationsregel spezifiziert werden die diese Muster in Abh ngigkeit von Designentscheidungen instanziiert Somit konnte mit dieser Arbeit zum einen gezeigt werden dass bei der Formulierung der Transformationssregeln von der Programmiersprache abstrahiert werden kann da programmier sprachenspezifische Details ber die austauschbaren Muster eingebracht werden k nnen Zum anderen wurde f r ein Beispiel gezeigt dass sich der Transformationsmechanismus auch f r die Detailed Design Phase eignet 6 3 Grenzen des Ansatzes Der in dieser Arbeit vorgestellte Ansatz POTAD hat sich in den beschriebenen studentischen Projekten siehe Kapitel 6 2 und im Umfeld der Fallst
342. rchitektur durch Treffen konkreter Realisierungsentscheidungen in eine technische Systemarchitektur berf hrt Hierzu m ssen die Funktionen und logischen Sensoren Aktuatoren aus der logischen Systemarchitektur Komponenten aus der technischen Systemarchitektur zugeordnet werden Dieser Vorgang wird auch Fartitionierung oder Mapping genannt Damit verbunden ist auch die Identifikation und Bewertung unterschiedlicher Realisierungsalternativen f r die logische Systemarchitektur Dabei m ssen auch die erw hnten Randbedingungen siehe Kapitel 3 1 1 ber cksichtigt werden Da es zwischen diesen Randbedingungen zu Zielkonflikten kommen kann m ssen diese evtl durch das Treffen von Designentscheidungen aufgel st werden siehe Kapitel 3 1 1 Im Einzelnen werden folgende Aktivit ten durchgef hrt e Analyse und Spezifikation der steuerungs und regelungstechnischen Systeme Die Sensoren Sollwertgeber Aktuatoren und Steuerungs bzw Regelungseinheiten der logischen Systemarchitektur werden auf die realisierende Hardware abgebildet e Analyse und Spezifikation von Echtzeitsystemen F r die unterschiedlichen Steuerungs und Regelungsfunktionen werden die Abtastraten festgelegt Aus diesen Abtastraten leiten sich sowohl die Echtzeitforderungen f r die Software als auch f r das Kommunikations system ab e Analyse und Spezifikation verteilter und vernetzter Systeme Die logischen Software funktionen werden Mikrocontrollern zugeordnet und die
343. rd deaktiviert wenn das Bremspedal bet tigt wird oder durch Dr cken des Hebels um in den Speedtronic Modus zu wechseln 3 Speedtronic 1 2 3 4 Speedtronic sorgt daf r dass eine bestimmte Geschwindigkeit nicht berschritten wird Nur bei laufendem Motor aktiv Jede Geschwindigkeit ber 30 km h begrenzbar Eingaben des Fahrers Hebel nach oben um aktuelle oder h here Geschwindigkeit zu speichern ge rundet auf den n chstgr eren Zehnerwert Hebel nach unten um aktuelle oder niedrigere Geschwindigkeit zu speichern gerundet auf den n chstkleineren Zehnerwert Hebel nach vorne um die Geschwindigkeitsbegrenzung zu deaktivieren 243 Hebel nach hinten um die zuletzt gespeicherte Geschwindigkeitsbegrenzung ab zurufen oder eine Feineinstellung in 1 km h Schritten vorzunehmen Hebel nach innen drucken um zwischen Tempomat und Speedtronic zu wechseln 5 Durch kurzzeitiges Betatigen des Hebels nach oben bzw nach unten wird die gegenwartige Geschwindigkeitsbegrenzung aufgerundet und gespeichert 6 Der Fahrer hat nun die Moglichkeit durch Antippen des Hebels nach oben bzw nach unten die Geschwindigkeit um jeweils 10 km h zu erhohen bzw zu verringern 7 Ein langeres Betatigen des Hebels nach oben bzw nach unten hat zur Folge dass die Be grenzung kontinuierlich erhoht bzw verringert wird 8 Mit dem Bet tigen des Hebels nach hinten kann eine Feineinstellung in 1 km h Schritten vorgenom
344. rdert Zum einen l sst sich eine sehr simple Form von Verfolgbarkeitslinks zwischen den Quell und Zielelementen bei jedem Ansatz realisieren hierbei handelt es sich schwerpunktm ig um eine Werkzeugfrage Zum anderen bietet nur ein untersuchter Ansatz einen dezidierten Mechanismus Um bei der weiteren Analyse noch mehrere Ans tze vergleichen zu k nnen wird der Verfolgbarkeitsmechanismus als ein Merkmal betrachtet das im Zweifelsfall durch eine eigene Erweiterung des Ansatzes erf llt werden muss In Tabelle 3 12 werden die untersuchten Ans tze f r Modelltransformationen in Bezug auf die vorgegebenen Merkmale bewertet Die Einsch tzungen lehnen sich an eine Diplomarbeit Buchwald 05 an die im Umfeld dieser Arbeit durchgef hrt wurde siehe Kapitel 6 2 Wie aus der Tabelle hervorgeht sind die Ans tze EXMOF GReAT VMT und der Vorschlag der QV 7 Merge Group mit den Vorgaben kompatibel Nur der letztgenannte Vorschlag erf llt auch das optionale Verfolgbarkeitskriterium durch einen dezidierten Mechanismus 129 3 Stand der Technik Ziel Einsatz zweck perfektion ierend Konsistenz pr fung perfektion ierend perfektion ierend Zwischen modell f r Code generierung Milicev allgemein UMLX MOLA allgemein Generizitat Meta modellierung MOF Meta modellierung MOF Elemente in Faktenbasis Meta modellierung UML UML Modelle UML Modelle UML Model
345. redundante Auslegung der Kommunikationskanale und der Energiever sorgung notwendig machen Auf der Ebene der Software muss dies z B durch eine Voting Funktion bei Abweichung der redundanten Werte oder ein Energiemanagement ber cksichtigt werden Die oben geschilderten Tendenzen wie z B die zunehmende Vernetzung der Funktionen oder die eng zu koordinierenden Ma nahmen bei sicherheitsrelevanten Systemen f hren zu einer komplexen Abh ngigkeit zwischen System und Softwareentwicklung die mit den herk mm lichen Methoden immer schwieriger zu beherrschen ist Es zeigt sich jedoch ein Trend bei den Entwicklungsmethoden bei dem sich der Fokus weg von der isolierten Entwicklung von Einzel modulen hin zu einer funktionsorientierten Entwicklung des Gesamtsystems bzw dessen Sub systemen bewegt In diesem Kontext wird die Softwareentwicklung immer st rker als eine Teilaktivitat einer bergeordneten Systementwicklung betrachtet in der viele Fachdisziplinen eng miteinander verzahnt sind Um die Abh ngigkeiten der Entwicklungsartefakte aus unter schiedlichen Bereichen zu beherrschen werden diese auf m glichst feingranularer Ebene mit einander verkn pft Auf diese Weise soll eine durchg ngige Verfolgbarkeit engl Traceability hergestellt werden um z B leicht ermitteln zu k nnen welche Softwarekomponenten welche Funktionen aus der Systemarchitektur realisieren Bei der Formalisierung und Verkn pfung der Informationen verfolgen die meis
346. reiben enthalten nicht funktionale Anforderungen Randbedingungen wie Varianten und Skalierbarkeitsanforderungen gesetzliche Bestimmungen z B Sicherheitsanforderungen oder auch Anforderungen bzgl Wartbarkeit siehe auch Kapitel 3 1 1 Im Rahmen dieses Prozessschrittes werden diese unstrukturierten Informationen in ein erstes formalisiertes und funktionales Modell berf hrt in der die Anforderungen eindeutig strukturiert und vollst ndig erfasst sind Das resultierende Artefakt ist die logische System architektur Diese hat sich als Zwischenschritt bei der Abbildung der Benutzeranforderungen auf eine technische Systemarchitektur insbesondere bei komplexen Systemen bew hrt Stevens et al 98 Bei der ogischen Systemarchitektur handelt es sich um ein abstraktes logisches Modell des Systems und seiner Funktionen das unabh ngig von einer m glichen technischen Realisierung ist Es dient als Bindeglied zwischen Benutzeranforderungen und der technischen System architektur und ist in der Sprache der Systementwicklung verfasst Es handelt sich bei diesem Prozessschritt somit um einen kreativen Entwurfs und Strukturierungsprozess in dem das System schrittweise in logische Komponenten und Schnittstellen zerlegt wird ber die Aus f hrungen von Sch uffele et al 03 hinausgehend werden die m glichen Inhalte der logischen Systemarchitektur f r diese Arbeit in Tabelle 3 1 weiter detailliert Zeitangaben werden in dem Kernprozess von
347. reibung eines abstrakten Signals f r die bermittlung von Benutzerkommandos enth lt die Interface Definition ist nicht abgebildet Der function Block mit dem Namen Tempomat Speedtronic verf gt ber einen entsprechenden Empf nger Port der ber einen Assemb y Connector mit dem Sender Port verbunden ist Auf diese Weise wird der abstrakte Signalfluss zwischen den beiden logischen Einheiten Tempomathebel und Tempomat Speedtronic ausgedr ckt 37 3 Stand der Technik Fur die Darstellung der Inhalte aus der technischen Systemarchitektur bietet sich vor allem die Komponentennetzwerk Architektur an Abbildung 3 9 zeigt einen Ausschnitt eines moglichen Modells fur das KFS die aus Abbildung 2 2 abgleitet ist Inhalt nach Kernprozess Mogliche Elemente aus dem Metamodell des siehe Tabelle 3 1 Tabelle 3 3 E E Konzepttools Funktionsnetzwerk FunctionBlock ActuatorBlock SensorBlock Composition 2 En Steuerger teauf CPU ASIC FPGA RAM ROM EEPROM 3 Kommunikationsver BusSystem KonventionelleVerbindung bindungen BusAnbindung KonventionelleAnbindung Signal SignalGroup Bus Transmission Frame 5 Leistungsversorgung Batterie Generator LVVerbindung LVAnbindung 6 Leitungen 00 Leitung Ader Pin Stuetzpunkt Trennstelle Pin 7 Fahrzeugtopologie Bauraum EinbauOrt TopologieSegment Ausbindung Trennstelle 1 Funktion Logischer Sen sor Aktuator SensorBlockMapping ActuatorBlockMapping E E Komponente 3
348. rgeben liegt in diesem Fall der Schwerpunkt des Designs eher auf der Performance Optimierung e Die Motorsteuerung empf ngt die aktuelle Gaspedalstellung als digitalisierten Wert ber den Bus in zyklischen Abst nden von 10 ms die Motordrehzahl wird uber eine diskrete Leitung bezogen W hrend die Gaspedalstellung direkt verwendet werden kann ist bei der Motordrehzahl eine Vorverarbeitung des Wertes notwendig Am Beispiel der ersten Umsetzung des KFS wird deutlich dass Funktionen die sich auf einer logischen Ebene mit einem einheitlichen Schema beschreiben lassen auf der Designebene stark variieren k nnen Bei der Erstellung des Designs m ssen Anforderungen ber cksichtigt werden von denen vorher abstrahiert wurde Das KFS Design zeigt aber auch dass es auch f r die Umsetzung dieser Anforderungen Designschemata gibt vgl Kapitel 3 2 4 die wiederum un abh ngig von der logischen Funktion sind So gibt es beispielsweise f r die Anforderungen im Bereich Wiederverwendung Designtechniken die bei eingebetteter Regelungssoftware genauso eingesetzt werden wie bei betriebswirtschaftlicher Software f r Gro rechner Letztendlich sucht der Entwickler bei der Designerstellung in der logischen Systemarchitektur nach gewissen Mustern F r die Designumsetzung dieser Muster nutzt er in Abh ngigkeit von den Randbedingungen technische Systemarchitektur nichtfunktionale Anforderungen ebenfalls wieder gewisse Muster Bei der Erstellung des er
349. rithm Interface cooling Context Sea oreo ClimateController_ Strategy Abbildung 3 46 Analysemuster ClosedLoopControl am Beispiel einer Klimaanlage und einem auf Wartbarkeit und Wiederverwendbarkeit optimierten Design 100 Softwareentwicklung Im Rahmen der Analysen konnte der beobachtete Zusammenhang zwischen Analyse und Designmuster f r weitere Beispiele best tigt werden Die feste Zuordnung von Design zu Analysemustern gilt aber offenbar nur wenn die nichtfunktionalen Anforderungen und die Plattform gleich bleiben ndern sich diese Randbedingungen k nnen auf der Designebene andere Muster zum Einsatz kommen Abbildung 3 47 zeigt ein Design f r den Tempomaten das in Richtung Sicherheit und Robustheit optimiert wurde bind S Bind MonitoredChannel CruiseController_ Watchdog CruiseController Master i Throttle SpeedSensor lt TETEE CruiseController_Master _ Throttle getCurrentSpeed en periodic call_ step setThrottleSetValue periodic call_stroke A A I SpeedAdjustinglever sneedAdjustingLever getDesiredSpeed bind 5 Context Class Bind ControlLoop CruiseController_ControlLoop Sensor Speed ControlLoop Class AdjustingLever SpeedSensor Actuator Throttle Sensor_get Sensor Class Method getDesiredSpeed getCurrentSpeed Actuator_set Actuator Class Method setT hrottl
350. rlauben ausgehend von der Fachdom ne und konkreten Problemstellung passende Muster zu finden Formalisierung der L sungsbeschreibung Viele Autoren z B Gamma et al 95 und Buschmann 98 verstehen die in den Mustern enthaltenen Diagramme als eine reine Konzeptillustration die mit dem Modell eines an gewendeten Musters in keiner formalisierten Beziehung steht Manche Autoren z B Douglass 02 sehen jedoch die M glichkeit die Beziehung zwischen der Strukturbeschreibung eines Musters und dem Modell in der dieses Muster angewendet wird formaler zu fassen Ein haufig anzutreffender Ansatz ist die Beschreibung eines Musters als parametrisierbare Kollaboration 18 Softwareentwicklung siehe Kapitel 3 2 4 e Eine Kollaboration besteht in diesem Kontext aus Rollen modelliert als Classifier die zusammenarbeiten z B durch Assoziationen Viele dieser Rollen k nnen als parametrisierbar ausgewiesen werden und somit bei der Anwendung des Musters mit konkreten Modellelementen belegt werden Prozess der Bindung Auf diese Weise wird festgelegt welche Teile eines Musters statisch kommen bei jeder Anwendung vor sind und welche Teile durch eigene Elemente ausgetauscht werden k nnen ber die bei der Anwendung des Musters mit gepflegten Rollen bleibt der Bezug zu der Musterbeschreibung erhalten Anti Muster W hrend Muster eine vorbildliche L sung einer Problemstellung beschreiben sollen Ant Muster als negatives Beispiel vo
351. rmationsregel f r das Muster C osedLoopContro detaillierter erl utert das unter anderem die in Abbildung 3 45 und Abbildung 3 47 gezeigten Design modelle erzeugen kann Die hierbei angestellten Design berlegungen sind in Kapitel 3 2 4 g geschildert Die Auswirkung der Regel wird anhand des ebenfalls dort verwendeten Beispiels CruiseController erkl rt Bei der Diskussion des Verschmelzungsverhaltens wird angenommen das das Attribut mergeBehavior bei jedem Musterelement die Einstellung merge hat Der Kopf der Regel ClosedLoopControl sieht wie folgt aus Rule ClosedLoopControl Template ClosedLoopControl cl gt Zun chst wird eine parameterlose Regel mit dem Namen ClosedLoopControl angelegt Auf der linken Seite der Regel ist das Template ClosedLoopControl mit der Variable cl angegeben Damit wird die rechte Seite der Regel ausgef hrt wenn im Modell eine Bindung des Templates ClosedLoopControl gefunden wird ber die Variable cl k nnen Anweisungen auf der rechten Seite auf die gefundene Template Bindung zugreifen Die rechte Seite der Regel beginnt mit Template Instanziierung die abh ngig von einer Be dingung ist OptimCriteria Reuse Template Repository cl ClosedLoopController Master He llikan c InputRepository Repository cl FeedbackValuetcl ReferenceValue Data inputRep Wenn das Optimierungskriterium Reuse wahr ist wird das Template Repository instanziiert Der Template Parameter Client wird mit
352. rmationsregeln als separate Dateien mit der Dateiendung tra in einem gemeinsamen Ver zeichnis abgelegt haben Au erdem m ssen in einem nicht notwendigerweise separaten Modell alle Designmuster die im Rahmen der Transformationsregeln instanziiert werden als Pattern Asset definiert sein Mit diesen Voraussetzungen kann die Transformation ber einen Men eintrag aufgerufen werden Abbildung 5 2 Daraufhin erscheint zun chst der Dialog mit den Transformations parametern Abbildung 5 3 die ber die Benutzervorgaben auch mit Standardwerten versehen werden k nnen Hier m ssen die Dateien mit dem Analysemodell dem Designmodell und der Musterbibliothek sowie das Verzeichnis mit den Transformationsregeln angegeben werden Au erdem kann hier eines der vier Optimierungskriterien ausgew hlt und bei Bedarf die Be nutzerr ckfragen unterdr ckt werden Die Wahl der auszuf hrenden Aktionen ist vom MDA Toolkit vorgegeben und kann nicht unterdr ckt werden F r den Prototyp ist diese Wahl un n tig da die Validierung der Parameter sowie die Verifikation des Ergebnisses nicht implementiert sind 170 Modelltransformator Modeling Fallstudie_A Main Rational Workbench Sele Tools Format Diagram Modeling PurifwPlus ClearCase Ausf hren Fenster Hilfe a l el e sy UX to ISF Design r Pad Refresh Profile 3 gt oo o2 aS
353. rodukte ebenfalls eine strukturierte Form 15 3 Stand der Technik In Konrad et al 04b werden unter dem Titel Object Analysis Pattern Analysemuster f r die Dom ne der eingebetteten Systeme vorgestellt Die Muster sind ihrem Namen entsprechend f r die Phase Object Analysis im ROPES Prozess siehe Kapitel 3 2 2 vorgesehen und erweitern die Methode an dieser Stelle Der Beitrag umfasst die Definition eines Beschreibungsschemas und die Katalogisierung von 7 Mustern detailliert beschrieben in Konrad et al 04a die in Tabelle 3 9 zusammengefasst sind Actuator Sensor Das Muster Actuator Sensor spezifiziert Basistypen f r Sensoren und Strukturmuster Aktuatoren in einem eingebetteten System Zu den Hauptverantwort lichkeiten eines eingebetteten Systems geh rt die Interaktion mit der Umgebung ber Sensoren und Aktuatoren Aus diesem Grund be schreibt das Muster wie Beziehungen zwischen Aktuatoren und Sensoren und anderen Komponenten im System erfasst werden k n nen Communication Durch die steigende Nachfrage nach verteilten eingebetteten Echtzeit Link systemen werden Kommunikationsf higkeiten immer wichtiger Das Verhaltensmuster Muster Communication Link beschreibt wie auf einer abstrakten Ebene die angebotenen Kommunikationsf higkeiten eines eingebetteten Systems erfasst werden k nnen wie z B periodische Nachrichten zu anderen Systemen Computing Com Eingebettete Systeme m ssen h ufig unterschiedlich
354. rofils den Rahmen dieser Arbeit sprengen w rde zumal es hier das erw hnte ATESST Projekt mit dieser Zielstellung gibt Es wird vielmehr davon ausgegangen dass die EAST ADL Modelle im Rahmen der Softwareentwicklung in ihrer urspr nglichen Form verwendet werden 3 2 3 Weitere UML basierte Methoden Neben ROPES gibt es zahlreiche weitere Softwareentwicklungsmethoden die UML Modelle verwenden Sehr bekannt ist der Rational Unified Process RUP Kruchten 04 Er ist eine konkrete Umsetzung des Unified Process Jacobson et al 99 der parallel zur UML entwickelt und ver ffentlicht wurde und dessen Autoren Ivar Jacobson Grady Booch und James Rumbaugh auch zu den Protagonisten der UML Standardisierung geh rten RUP wurde durch 66 Softwareentwicklung die Firma ational die heute zu der Firma 5M geh rt kommerzialisiert und wird bis heute mit speziellen Werkzeugen unterstutzt Zu den Kernprinzipien des Unified Process gehoren eine iterative und inkrementelle Vorgehens weise die Beschreibung und Ausrichtung vieler Aktivitaten auf Anwendungsfalle und objekt orientierte Analyse und Design Hier gibt es somit eine gro e hnlichkeit zu ROPES Ein Unterschied ergibt sich aber durch die Tatsache dass ROPES speziell f r die Entwicklung eingebetteter Software mit Echtzeitanforderungen konzipiert wurde und dadurch verst rkt z B Hardware Sicherheits und Verf gbarkeitsaspekte betrachtet Bei den Systemen die in Publikationen zu RUP
355. rojektspezi fisch festgelegt werden Die UML besitzt schon aufgrund dieser Tatsache keine formale Semantik und verhindert per se auch nicht widerspr chliche Modelle Jeckle et al 03 Das folgende Unterkapitel gibt einen berblick ber die vorhandenen Diagramme Aufgrund des hohen Bekanntheitsgrades der UML wird auf eine ausf hrliche Darstellung der Modellierungs sprache verzichtet und an dieser Stelle auf den Standard OMG 05c und die umfangreich 43 3 Stand der Technik vorhandene Sekundarliteratur verwiesen z B Jeckle et al 03 und Born et al 05 Statt dessen konzentrieren sich die beiden weiteren Unterkapitel auf Aspekte die im Rahmen dieser Arbeit von besonderer Bedeutung sind Dazu gehoren das UML Metamodell und der Profil mechanismus sowie der Einsatz von UML Modellen fur die Darstellung von Ergebnissen der Systementwicklung 3 2 1 a Diagramme Die bersicht in Abbildung 3 10 zeigt alle in der UML2 vorhandenen Diagrammarten und charakterisiert deren Inhalt mit Stichworten UML Diagramm Struktur lt diagramm Klassendiagramm Objektdiagramm Paketdiagramm Kollaborations Diagramm diagramm Mi Zeigt Klassen und Zeigt Objekte mit Zeigt Akteure Use Zeigt Ablagestruktur Zusammenarbeit und ihre Beziehungen beispielhaften Wer Cases und ihre Be und Abh ngigkeiten Rollen von Klassen untereinander ten ziehungen unter der Modellelemente einander Architektur lt diagramm Kompositions
356. rom the system architecture model thereby automating a part of the software engineering activities The analysis of this work shows that the collected domain specific requirements which must be made on a model transformation mechanism for such a scenario are not fulfilled by current approaches The approach taken in this work the Pattern Oriented Transformations between Analysis and Designmodels POTAD uses the system architecture as an analysis model within software development and systemizes the connection with the design model on the basis of analysis and design patterns By means of this systematisation a POTAD transformation rule instantiates for an analysis pattern different design patterns under consideration of non functional requirements and the technical system architecture At the same time links between an analysis and design pattern are created which are used to trace design decision later The feasibility of the solution is shown by a prototype which follows the POTAD development process and executes the transformation rules formulated in the POTAD transformation lan guage POTAD was verified by several student works based on a case study which covers typical characteristics of the examined domain The results of these works showed the suitability and improved the methodology as well as the transformation language and pointed out the limits of the approach taken Inhaltsverzeichnis 1 EINLELTUNG UND MOTIVATION 2 2 2
357. rschmelzungs mechanismus siehe n chstes Unterkapitel kann dabei sichergestellt werden dass durch die 93 3 Stand der Technik wiederholte Expandierung Elemente des Musters nicht doppelt im Zielmodell angelegt werden Beispielsweise f hrt eine Neuexpansion direkt im Anschluss auf die erste Instanziierung zu keinen nderungen im Modell In dem einer Musterbindung ber einen l ngeren Zeitraum hin Schritt f r Schritt immer neue tats chliche Parameter zugewiesen werden kann die Muster instanz auf diese Weise sukzessive ausgebaut werden bind Bind ClosedLoopController Cruise ReferenceValue Signal Controller FeedbackValue Current ClosedLoopController Class Speed ControlOutputValue Throttle FeedbackValue Signal Value ReferenceValue ControlOutputValue Signal Source Lever ControlOutputValue ReferenceValueSource Class Drain Throttle FeedbackValue ControlOutputValueDrain Class aes e Source SpeedSensor Reference Ber FeedbackValueSource Class Value DesiredS peed ossalsoreontrei CrulseControl ween ne ETRE A ClosedLoopControl ma a SOE wee anne ee DesiredS peed lever a ThrottleValue CruiseController EPEIROSE A TIA TTT AE ATENENT D Throttle CurrentS peed SpeedSensor Abbildung 3 43 Das angewendete Muster in der Diagramm Darstellung Verschmelzungsregeln ber die sog merge hints Verschmelzungshinweise kann f r jedes Element des M
358. rteentwicklung relevante Mappings der Systementwicklung 25 Tabelle 3 4 Vier Schichten Metamodellarchitektur Darstellung angelehnt an IESE c 29 Tabelle 3 5 M gliche Elemente der EAST ADL f r die logische und technische Systemarchitektur sowie f r die Mappe S edn a TI RR ERER RENERLERLBERELAER HERR SEHEEER TIER PRINT SUEDEELRENESLTRTERPRTSBEREN 33 Tabelle 3 6 M gliche Elemente aus dem Metamodell des E E Konzept Tools f r die logische und technische Systemarchitektur sowie f r die Mappings usuunseeseensensnensensnnnennnnnnnnnnnenennnnennnnn 38 Tabelle 3 7 Vergleich der unterschiedlichen Modellierungsans tze in Bezug auf die Inhalte des PSO ZS SSCS en ei An nen engeren ee een einher 40 TF belle 3 8 M sterkategorlen nee ee ea ucrandyeremaateereesalueuanes 71 Tabelle 3 9 Analysemuster von Konrad et al 04b bersetzt aus dem Englischen 76 Tabelle 3 10 Verschmelzungshinweise in Rational XDE ccccc ccc ccc cece cece cece beeen eed ee ceed ees eeneenneen ens 95 Tabelle 3 11 Vorgegebene Merkmale entsprechend des Schemas von Czarnecki et al 03 129 Tabelle 3 12 Charakterisierung der Ans tze uber Unterscheidungsmerkmale 0 c0ccceeeeeneeeeeeeeen es 130 Tabelle 3 13 Erfullungsgrad der verbliebenen Ans tze in Bezug auf die Anforderungen aus Kapitel 3 2 5 Re a ea Ma a Er Rear Bee STD lea BN Be LEERE eo Bus Eee Br B
359. rzu wurde eine eigene Syntax entwickelt mit der z B die Beziehung zwischen Ereignissen und erwarteten Reaktionen beschrieben werden kann Die Autoren verf gen ber eine Werkzeugkette innerhalb derer UML Analysemodelle mit einer formalen Semantik erstellt werden k nnen Wurden in ein Modell die Analysemuster ein gebracht kann mit Hilfe eines Model Checkers berpr ft werden ob die f r das Muster definierten Constraints in diesem Modell erf llt werden Im Anhang A 16 ist das Muster Detector Corrector in Form eines Originalauszugs aus dem in Konrad et al 04a vorgestellten Musterkatalog beschrieben 3 Stand der Technik Die hier besprochenen Analysemuster sind noch relativ jung und nicht breit etabliert Sie leisten fur diese Arbeit vor allem einen konzeptionellen Beitrag Nach eigener Einschatzung gibt es auf dieser Ebene noch zahlreiche Konzepte die sich durch Muster beschreiben lassen Der in An hang A 1 zusammengestellte Analysemusterkatalog enthalt einige selbst erstellte Muster die im weiteren Verlauf dieser Arbeit verwendet werden Die bei den Designmustern angebrachte Kritik gilt eingeschrankt auch fur die Analysemuster Ein Muster wird bei Konrad et al 04b zwar aufgrund der Constraints wesentlich formaler beschrieben bei der Beschreibung der Losungsstruktur werden aber auch hier die austausch baren Elemente und deren Anforderungen nicht dezidiert ausgewiesen Da bei Analysemustern nichtfunktionale Eigenschafte
360. s ReferenceValueSource_getMethod Operation correctiveActionMethod Operation MonitorActuator gt Bee Ae hn re en Context call ReferenceValueSource_getMethod _ lt ReferenceValueSo urce gt ReferenceValueSource ReferenceValueSource_getMethod _ lt ReferenceValueSo urce gt _ lt Monitor gt Monitor MonitorState Boolean Actuator_setMethod correctiveActionMethod call_get lt Actuator gt Value call_ ReferenceValueSource_getMethod periodic check 9 3 Erl uterung Das von Douglass 02 adaptierte MonitorActuator Muster beschreibt ein Objektmodell f r die berwachung eines Aktuators Actuator auf Designebene Dies erfolgt ber einen speziellen Sensor ActuatorMonitorSensor der durch ein Objekt vom Typ Monitor ausgelesen wird Der gemessene Wert wird _ lt ActuatorMonitorSensor gt 1 _ lt Actuator gt Actuator Actuator_setMethod ActuatorMonitorSensor get lt Actuator gt Value im Rahmen der periodischen Methode check mit dem Sollwert ReferenceValueSource_getMethod und der Stellgr e des Aktuators Actuator_setMethod ver glichen Wird hier ein kritischer Zusammenhang festgestellt werden ber die Methode correctiveActionMethod korrigierende Ma nahmen eingeleitet 218 10 Publis
361. s Redundancy 8 Chain of Responsibility Sicherheit a cca Wartbarkeit Zuverlassigkeit und Master Slave Portabilitat Korrektheit JL Monitor Actuator Pattern L Model View Controller Erweiterbarkeit A Memento Wiederverwendung dL Pipes and Filters 3 Bridge 2 Decorator W Observer Publisher Subscriber A Composite er Proxy Di iterator Lb Control Loop 2 Safety Executive Pattern 2 Sanity Check Pattern 2 Channel Architecture Pattern Lb Watchdog Pattern 4 Reactive Control Loop 2 State Table 3 Critical Section Pattern 8 Garbage Collection Pattern 2 State 3 Garbage Compactor Pattern Verhalten 3 Remote Method Call Pattern 4 Pool Allocation Pattern Ressourcenmanagement interrupt Pattern 2 Flyweight a Static Allocation Pattern 4 Control Pattern 4 Generic Assessment Pattern 4 Initiation Pattern 8 Static Priority Pattern W Resource Instrumentation 1 sehr geeignet 4 nur sehr eingeschrankt geeignet Abbildung 3 27 kategorisierte und bewertete Designmuster Die Zusammenstellung und Bewertung der Muster ist nicht das Ergebnis einer systematischen Untersuchung Ein Muster wurde in die Auswahl mit aufgenommen wenn eine Anwendungs moglichkeit im Rahmen der Fallstudie oder einem anderen dem Autor bekannten System als 13 3 Stand der Technik realistisch erschi
362. s er laubt auf einfache Weise die Instanziierung von Mustern von nichtfunktionalen Eigen schaften oder der technischen Systemarchitektur abh ngig zu machen 2 Das Eingabemodell leitet sich in dem hier betrachteten Kontext aus dem Modell der Systementwicklung ab Die beschriebene Verzahnung von System und Softwareentwicklung 134 Prazisierte Problemstellung in der Domane macht es notwendig dass der Zusammenhang zwischen den Modellen der System und Softwareentwicklung dauerhaft verfolgbar ist Entsprechend muss ein Modell transformationsmechanismus Elemente der Ein und Ausgabemodelle geeignet verlinken konnen Die wenigen in den untersuchten Ansatzen enthaltenen Verfolgbarkeitskonzepte be ruhen im Wesentlichen auf einer simplen Verlinkung von Elementen aus dem Quell und Zielmodell oder dem persistenten Festhalten einer Regelanwendung Hier ware ein ver feinerter Mechanismus wunschenswert der auch Designentscheidungen bei Variabilitat im Zielmodell verfolgbar und nachvollziehbar macht Die Untersuchung der existierenden Ansatze ergab dass es zurzeit keine Losung gibt die die domanenspezifischen Anforderungen und die beschriebene Systematik praxistauglich unter stutzt Aus diesem Grund wird in dem folgenden Kapitel ein eigener Ansatz fur Modelltrans formationen entwickelt der die genannten Problemfelder adressiert und insbesondere die in Kapitel 3 2 5 gesammelten Anforderungen erfullt 135 4 Eigener Losungsansatz POTAD
363. s im Designmodell ge ndert k nnen mit dem in Kapitel 5 vorgestellten Prototyp bei erneuter Ausf hrung der Transformation redundante 143 4 Eigener Losungsansatz POTAD Elemente entstehen Im Beispiel aus Abbildung 3 45 wird mit der ersten Modelltransformation aus der Klasse CruiseController im Analysemodell die Klasse CruiseController_Master im Designmodell erzeugt Wird die Klasse des Analysemodells dann in CC unbenannt entsteht im Designmodell bei einer erneuten Transformation zusatzlich zu der schon existierenden Klasse CruiseController Master die Klasse CC Master Um zu erreichen dass die Klasse CruiseController Master in CC_Master unbenannt wird m ssen die Verfolgbarkeitsinformationen ausgewertet werden Dies kann vermutlich mit Hilfe der Verfolgbarkeitslinks im Rahmen einer Transformation automatisch geschehen ist in dem Prototyp aus Kapitel 5 aber nicht implementiert und daher ein Thema f r zuk nftige Arbeiten siehe Kapitel 7 1 K nnen die oben genannten Bedingungen bei einer Iteration nicht eingehalten werden ist in der hier vorliegenden Fassung von POTAD die manuelle Neuexpansion der betroffenen Design muster vorgesehen wie in Kapitel 3 2 4 f beschrieben Der Entwickler kann ber die bei der letzten Transformation angelegten Verfolgbarkeitsinformationen ermitteln welche Design musterinstanzen aus der betreffenden Analysemusterinstanz hervorgegangen sind und Namens anderungen in den Designmuster Bindungen manue
364. s nur noch eine Template Art Template ist das Wurzelelement eines Templates und nimmt alle statischen und parametrisierbaren Elemente eines Templates auf Die M glichkeit Elemente aufzunehmen erh lt die Klasse durch die Vererbungsbeziehung zu Package Die Eigenschaft dass parametrisierbare Elemente eine Kompositionsbeziehung zu TemplateParameter haben wurde entfernt Demgegen ber wird TemplateParameter immer als Kompositionselement von TemplateSignature eingebunden e Durch die Einf hrung der abstrakten Klasse TemplateMergeableElement kann f r jedes Template Element das Verschmelzungsverhalten gesteuert werden und somit die in Kapitel 3 2 4 e identifizierte L cke der UML Templates geschlossen werden F r die Semantik der vier m glichen Einstellungen merge preserve replace und noCopy gelten die Erlauterungen in Tabelle 3 10 Die L sung TemplateMergeableElement als Superklasse von NamedElement zu modellieren l st das Problem auf einfache aber radikale Weise da somit fast alle UML Elemente ber diese Eigenschaft verf gen auch wenn sie nicht im Kontext von Templates verwendet werden Bei einer etwaigen Weiterentwicklung sollte hier nach einer L sung ge sucht werden bei der die Verschmelzungseigenschaft nur bei Template Elementen vor handen ist 146 Muster Von ParameterableElement wurden alle Vererbungsbeziehungen zu Subtypen bis auf die zu Signal Class Property und Operation entfernt Somit kann im Rahmen von POTAD ein Tem
365. schiedene M glichkeiten die je nach Anwendungsfall Vor und Nachteile haben e Namen f r erzeugte Elemente werden grunds tzlich in den Transformationsregeln fest vorgegeben Dies f hrt zwar meist zu passenden Bezeichnungen kann bei mehrfacher An wendung derselben Regel oder bei Iterationen aber zu Problemen f hren wenn mehrmals Elemente gleichen Namens erzeugt werden die eigentlich unterschiedliche Identit ten be sitzen m ssten e Namen f r erzeugte Elemente werden auf Basis eines automatischen Schemas generiert z B Name der Template Instanz gt _ lt Parametername gt Sofern jede Template Instanz ber einen Namespacing Mechanismus einen eigenen Namen erhalt vermeidet dies Widerspr che macht es aber in den meisten F llen notwendig die Namen der Elemente sp ter anzu passen e Der Benutzer der Transformation erh lt die M glichkeit Namen f r neu erzeugte Elemente ber die Benutzeroberflache einzugeben Dies erm glicht sinnvolle Namen kann aber bei missbrauchlicher Nutzung oder Fehlern durch den Benutzer zu Widerspr chen f hren wenn dieser z B den Namen eines Elementes eingibt das in einem anderen Kontext bereits existiert Das Metamodell beschreibt in diesem Punkt also nur das abstrakte Konzept der Erzeugung eines Elements und berl sst die konkrete Ausgestaltung der praktischen Realisierung des Mechanismus 4 3 3 Konkrete Syntax Im vorigen Abschnitt wurde das abstrakte Konzept der Transformationssp
366. se um den Einsatz von Analysemustern er ganzt AuBerdem werden das Konzept der Modelltransformation als Designschritt und die Nutzung der Verfolgbarkeitsinformationen im Prozess verankert Das Template Metamodell der UML2 ist in der Weise erganzt dass die Beschreibung und Instanziierung von Mustern fur eine Transformation ausreichend formalisiert ist Damit kann nun z B das Verschmelzungsverhalten fur jedes Template Element festgelegt werden Parameter gruppiert und hinsichtlich Multiplizi tat genauer spezifiziert werden Die Transformationssprache basiert auf der zuvor grob skizzierten Systematik In einer textuellen Syntax kann f r eine gefundene Analysemuster instanz in Abh ngigkeit von nichtfunktionalen Anforderungen und der Zielplattform die Instanziierung von Designmustern angesto en werden Die dabei angelegten Verfolgbarkeits informationen verkn pfen die Analyse und Designmusterinstanzen und dokumentieren eine getroffene Auswahl zwischen Designalternativen Eine prototypische Implementierung wurde als Erweiterung der UML Entwicklungsumgebung Rational XDE realisiert Ein eigener Interpreter kann POTAD Transformationsregeln ver arbeiten in dem er im Analysemodell nach Analysemusterinstanzen sucht und entsprechend der Regel Anweisungen Designmuster instanziiert Im Rahmen von studentischen Arbeiten wurden einige Transformationsregeln entwickelt und erfolgreich anhand einer Fallstudie erprobt 7 1 Zuk nftige Arbeiten Der in die
367. sed Transformations Proceedings of the Second International Workshop on Strategic Knowledge and Concept Formation wate Japan 1999a S 157 167 URL http se2c uni lu tiki se2c bib_download php id 612 Khriss et al 99b Khriss Ismail Keller Rudolf K Hamid Issam A Supporting Design by Pattern based Transformations Proceedings of the International Workshop on Software Transformation Systems STS 99 Los Angeles CA USA 1999b S 50 58 URL http www iro umontreal ca keller Publications Papers sts99 pdf Kircher et al 01 Kircher Michael Jain Prashant Schmidt Douglas Corsaro Angelo Proceedigns of th Wokshop Towards Patterns and Pattern Languages for OO Distributed Real time and Embedded Systems OOPSLA Workshop Tampa 2001 URL http www posa3 org workshops RealTimePatterns OOPSLA2001 Kircher et al 02 Kircher Michael Jain Prashant Schmidt Douglas Gokhale Andy Proceedigns of th Wokshop on Patterns in Distributed Real Time and Embedded Systems OOPSLA Workshop Washington USA 2002 URL http www posa3 org workshops RealTimePatterns OOPSLA2002 Klein Klein Gerwin JF lex The Fast Scanner Generator for Java URL http www jflex de Kleppe et al 03 Kleppe Anneke Warmer Jos Bast Wim MDA Explained The Model Driven Architecture Practice and Promise Addison Wesley Professional 2003 Koenig 95 Koenig A Patterns and Antipatterns Journal of Object Oriented Pro
368. send kann festgestellt werden dass der Verschmelzungsmechanismus die im letzten Unterkapitel beschriebenen M ngel der Paket Templates aus der UML beheben kann Es k nnen auch Elemente verschmolzen werden die sich strukturell st rker unterscheiden z B Operationen mit unterschiedlichen Parameterlisten und das Verschmelzungsverhalten kann f r jedes Musterelement individuell gesteuert werden Es k nnen mehr Beziehungen als bei den Paket Templates wiederverwendet werden und bei kollidierenden Operationen ist sowohl eine Verschmelzung als auch eine Uberladung in unterschiedlichen Auspr gungen m glich Einordnung und Vergleich mit den UML Templates Wesentliche Konzepte der UML Templates wie z B Template Parameter und eine Template Bindung mit Parameterersetzung sind in Rational XDE mit dem als Pattern bezeichneten Konstrukt umgesetzt Im Folgenden werden die entdeckten Unterschiede erlautert In der UML wird ein Template deklariert indem ein herk mmlicher UML Typ wie z B Class Package oder Component muss Subtyp von TemplateableElement sein um eine Signatur mit einer Parameterliste erg nzt wird Auf diese Weise k nnen unterschiedliche Template Arten ent stehen z B Klassen Paket oder Komponenten Templates Bei Rational XDE gibt es f r das Template nur einen Metatyp der graphisch als gestichelte Ellipse dargestellt wird Mit dem nicht in den UML Templates vorhandenen Root Context wird ein UML Typ festgelegt
369. ser Konstruktor im Template mit dem deutlich gemacht wird dass mindestens ein Konstruktor im Verschmelzungsergebnis vorhanden sein muss dieser aber ber beliebige Parameter verf gen kann Sowohl das gezielte berladen als auch das Verschmelzen von Operationen kann bei einer Musterinstanziierung Sinn machen Daher w re es w nschenswert wenn f r jedes Element im 88 Softwareentwicklung Template das Verschmelzungsverhalten feiner spezifiziert werden konnte Das im folgenden Unterkapitel vorgestellte Werkzeug verf gt ber entsprechende Einstellungsm glichkeiten wohingegen die UML immer dieselben Standardregeln vorsieht 3 2 4 f Werkzeugunterstutzung f r Muster In Fischer 05 wurden als Vorarbeit zu der Entwicklung von POTAD die Musterunterst tzung in den Werkzeugen Rational XDE IBM b BM Software Architect IBM a und Compuware Optimal Compuware vergleichend evaluiert Die Musterunterst tzung dieser Werkzeuge unterscheidet sich von anderen UML Werkzeugen dahingehend dass zwischen Mustertypen und instanzen differenziert wird und die von der UML beschriebene Parameter Bindung vom Grundsatz her unterst tzt wird Bezogen auf die Umsetzung der Templates aus dem UML Metamodell Kapitel 3 2 4 e erwies sich das Produkt XDE als das m chtigste Werkzeug Als stellvertretendes Beispiel daf r was an Werkzeugunterst tzung f r Muster zurzeit verf gbar ist wird die Musterunterst tzung von XDE im Folgenden ausf hrlicher erl u
370. ser Arbeit vorgestellte Ansatz POTAD wurde in einer Fallstudie eingesetzt und hat Grenzen die in Kapitel 6 3 aufgezeigt wurden Zur Erweiterung dieser Grenzen und Ver besserung von POTAD sind weitere Arbeiten notwendig e Bei der Entwicklung von POTAD wurde davon ausgegangen dass die betrachteten Systeme auf der gr nen Wiese nach Top down Vorgehensweise neu entwickelt werden Es ist zu pr fen wie POTAD genutzt werden kann wenn ein bestehendes System zu dem Modelle nur unvollst ndig vorliegen nach Bottom up Vorgehensweise erweitert werden soll Evtl ist es m glich die Transformationsregeln so zu erweitern dass sie das Design anhand der Frage variieren ob f r eine bestimmte Teilfunktionalitat eine existierende Implementierung eingebunden werden muss oder nicht Im ersten Fall w rden dann entsprechende Design muster f r die Adaptierung und die Integration in das Gesamtdesign in der Trans formationsregel instanziiert e POTAD wurde anhand einer Fallstudie aus der Dom ne Automotive Software berpr ft Eine breitere Evaluierung vor allem auch in anderen Dom nen steht noch aus Die An wendbarkeit in einer anderen Dom ne wird grunds tzlich als positiv eingesch tzt wenn folgende Bedingungen erf llt sind 1 In der Dom ne wird bereits ein formalisiertes Fachmodell erstellt Dieses lasst sich mit den Mitteln der UML modellieren 190 Zukunftige Arbeiten 2 In diesem Fachmodell lassen sich wiederkehrende Muster fi
371. ses besteht und teilweise auch Varianten abh ngig von bestimmten Einflussfaktoren beinhaltet e Beispiele die exemplarisch Kontext Problemstellung und L sung illustrieren und so dem Leser ein besseres Verst ndnis des Musters erm glichen e Eine Beschreibung des Ergebnisses der Musteranwendung also der positiven als auch negativen Konsequenzen der Folgen f r den Zustand des Systems der gel sten sowie noch ausstehenden Probleme und der M glichkeiten des weiteren Vorgehens e Eine Begr ndung die die einzelnen Vorgehensschritte und das Muster als Ganzes erl utert und erkl rt warum das Muster auf die gegebene Problemstellung anwendbar ist und wie es das Problem l st e Eine Auflistung weiterer Muster die alternativ oder in Erg nzung zu dem gegebenen Muster eingesetzt werden k nnen Muster als Komponenten Mit dem Ansatz Pattern oriented Analysis and Design POAD pr sentiert Yacoub et al 04 eine Methode zur Erstellung von Designmodellen durch die Komposition von Mustern Muster werden als Komponenten mit Interfaces betrachtet f r die es eine Au en die Komponente und ihre Interfaces und Innensicht Struktur des Musters gibt Es wird ein Entwicklungs prozess beschrieben bei dem ausgehend von Use Cases zun chst lose Kompositionen von Mustern auf Basis der Au enansicht zusammengestellt wird Diese im ersten Schritt nur durch Abh ngigkeiten verbundenen Komponenten werden im n chsten Schritt durch die Verbindun
372. sicht der Arbeiten aus Gamma et al 95 Buschmann 98 12 Softwareentwicklung Douglass 99 Douglass 02 sowie weiterer Einzelpublikationen aus diversen Muster konferenzen zusammengestellt In einem ersten Schritt wurde diese Liste dahingehend ver dichtet dass hnliche bzw konzeptgleiche Muster von unterschiedlichen Autoren verkn pft wurden In einem zweiten Schritt wurde jedes einzelne Muster auf die Verwendbarkeit in der Dom ne und insbesondere in der Fallstudie gepr ft Die in Frage kommenden Kandidaten wurden auf einer Skala von 1 sehr geeignet bis 4 nur sehr eingeschr nkt geeignet bewertet und in 4 Kategorien eingeteilt siehe Abbildung 3 27 Ein wichtiges Selektionskriterium war dabei die Granularit tsebene des Musters Muster f r das Mechanistic Design siehe Kapitel 4 2 3 besch ftigen sich mit Kollaborationen zwischen Objekten Architekturmuster oder Idiome wurden daher aussortiert Insbesondere bei Archi tekturmustern ist die Abgrenzung zu Mustern des Mechanistic Design aber oft flie end Einige der Muster aus Abbildung 3 27 haben Architekturcharakter k nnen aber auch f r Objekt Kollaborationen verwendet werden Die Bewertung erfolgt jedoch in Hinblick auf die Ver wendung f r das Mechanistic Design da dies die von den Transformationsregeln adressierte Abstraktionsebene ist WD Mediator A Template Method WD Exception Monitor W Strategy pi Second Guess 2 visitor Homogeneou
373. sign f r lt ______ Entwicklungsmethode gt _ UML2 Template Binding UML2 Template Mechanistic Design 1 Object Model Designmodell ai 1 hat Mustertyp zn Katalog Gamma et al enth lt Auswahl aus Designmusterkatalog Dt Katalog Douglass gt Katalog Buschmann et al erzeugt Vorlage liest ein f hrt aus beschreibt Design fur as Zu hat Struktur von wendet Regel an f r variiert anhand von eer erfragt een l fragt ab Technische Systemarchitektur K E E iin Kapitel 4 1 m Kapitel 4 2 E Kapitel 4 3 E Kapitel 4 4 Stand der Technik Kapitel 3 Abbildung 4 2 Die POTAD Artefakte 4 1 Erweiterung der Entwicklungsmethode POTAD verwendet eine angepasste Form der in Kapitel 3 2 beschriebenen Softwareent wicklungsmethode ROPES im Bereich Analyse und Design Die Anpassungen umfassen einer seits die Modifikation bzw Konkretisierung einiger Aktivit ten und Artefakte um die Methode in den Kernprozess und die Modelllandschaft der Systementwicklung siehe Kapitel 3 1 2 zu integrieren Andererseits werden aber mit den Analysemustern den im Rahmen des Designs von einem Modelltransformator genutzten Transformationsregeln und den Verfolgbarkeits informationen auch v llig neue Artefakte eingef hrt Abbildung 4 3 zeigt die urspr ngliche bersicht der ROPES Artefa
374. sist of client source model elements that are deleted by characterized classes with create operations that are associated transformations are marked by X with product classes The create operations create The elements in the dashed box are new elements instances of the Product classes added by characterized transformations Source Pattern Transformation Schema ClientProductRelationship theFactory Factory Each create operation ina client determines a factory class in the target model Abbildung 3 54 Beispiel eines Transformation Pattern Judson et al 03 3 3 4 f D Milicev Erweiterte UML Objektdiagramme In Milicev 02 wird eine auf UML Objektdiagrammen basierende Notation f r die Be schreibung von Mappings zwischen Modellen vorgeschlagen Ziel ist dabei die Erzeugung eines Zwischenmodells ntermediate Model zur einfacheren Codegenerierung Zun chst m ssen Metamodelle f r Quell und Zwischenmodell definiert werden deren Elemente dann in dem erweiterten Objektdiagramm verwendet werden k nnen Instanzen der zu erzeugenden Elemente aus dem Zwischenmodell als Objekte die eigentliche Logik der Transformation in stereo typisierten UML Paketen die Bedingungen Schleifen Parametrisierung u A ausdr cken In diesen Paketen k nnen alle Elemente aus dem Quellmetamodell als Werte bestimmter vor definierter Tagged Values verwendet werden Mit dieser Modellierungsweise lasst sich nach Ansicht des Autors effektiv automatisch
375. sorValue int tags period 10 Abbildung 3 13 Beispiel eines m glichen UML2 Profils f r die Modellierung der Functional Analysis Architecture der EAST ADL Sofern bei der Softwareentwicklung die UML2 zum Einsatz kommt lasst sich somit im Falle der EAST ADL das Funktionsnetzwerk direkt f r die Analyse bernehmen Im Rahmen der Arbeit wurde jedoch auch nach einer sehr einfachen Darstellung gesucht die sich m glichst auch mit UML 1 4 Werkzeugen modellieren l sst Eine in Abbildung 3 14 gezeigte M glichkeit das Beispiel mit diesen Mitteln zu modellieren ist die Verwendung von zwei Klassen Sensor und ControlFunction die ber eine Assoziation verbunden sind und zur Laufzeit ein Signal aus tauschen k nnen Mit Signal ist dabei der im UML Metamodell definierte Typ gemeint der als Klasse mit dem Stereotyp lt lt signal gt gt deklariert wird Die Empfangbarkeit des Signals wird bei ControlFunction in einem zus tzlichen Compartment durch den Eintrag des Signals model liert Durch die private Methode send_sensorValue wird angezeigt welche Klasse ein Signal sendet f r gr ere Modelle wichtig In Anlehnung an Douglass 99 k nnen mit dem Stereo typ lt lt periodic gt gt und dem tagged value period Angaben zum Zeitverhalten beim Senden des 47 3 Stand der Technik Signals gemacht werden Der Wert von period gibt die Zykluszeit in Millisekunden an Ist kein Stereotyp angegeben wird das Signal episodisch versendet
376. specific system constraints Structure The class diagram for the Detector Corrector Pattern can be seen in Figure 7 1 A Local FaultHandler interacts with its Detectors and Correctors which provide fault detection and correction capabilities for a Device The LocalFaultHandler also reports occurring faults to the GlobalFaultHandler which can override the LocalFaultHandler 204 Global FaultHandler collaborate Local FaultHandler provides corrective actions for monitors 0 Detector Device Corrector Figure 7 1 UML class diagram of the Detector Corrector Pattern Behavior Figure 7 2 shows the behavioral diagram for the LocalFaultHandler The LocalFaultHandler receives fault reports from Detectors and initiates recovery actions in the Correctors Addition ally the LocalFaultHandler can be overridden by the GlobalFaultHandler and be returned to normal behavior on a Reset Figure 7 3 and Figure 7 4 show state diagrams for the Detector class Figure 7 3 represents a state diagram for a detector that is waiting for a periodic service denoted by an Update message by a Device Figure 7 4 represents a state diagram for a detector that periodically checks if certain system conditions are violated Additionally Figure 7 5 shows a state diagram for the Corrector component in which the Corrector initiates corresponding recovery actions Figure 7 6 shows a sequence diagram where a detector of
377. stehung und Verwendung im Kontext eines Entwicklungsprozesses zu beschreiben Das CIM wird manuell erstellt und dient primar dazu Anforderungen zu beschreiben und durch die Etablierung eines einheitlichen Vokabulars ein gemeinsames Problemverst ndnis zu er reichen Die im CIM gesammelten Anforderungen sollen in Bezug auf die nachgelagerten PIM und PSM Konstrukte nachverfolgbar traceable sein D h es soll durch geeignete Mechanis men m glich sein zu ermitteln welcher Teil des Systems welche Anforderung realisiert Das PIM stellt eine konkrete Beschreibung des Systems ohne Details der Plattform dar und wird laut Vorgabe erstellt d h es geht nicht unmittelbar aus dem CIM hervor Anders verh lt es sich bei dem PSM das durch ein festgelegtes Mapping unter Ber ck sichtigung des Plattform Modells ber eine Modelltransformation aus dem PIM entsteht Dabei handelt es sich um den Vorgang bei dem zwei Modelle desselben Systems ineinander berf hrt werden F r den bergang von PIM zu PSM beschreibt die OMG einige Konzepte wie dieser Vorgang m glichst formalisiert und automatisiert durchgef hrt werden k nnte Abbildung 3 51 zeigt diese in einem schematischen berblick 110 Modelltransformationen Abbildung 3 51 Schematischer Uberblick zu MDA Modelltransformationen Modelltransformationen sind in der MDA das Schl sselkonzept um das oben beschriebene Konzept von architectural separation of concerns effizient real
378. sten KFS Designs gab es zahlreiche Anhalts punkte die vermuten lie en dass sich dieser Zusammenhang weit aus mehr systematisieren lasst als in den herk mmlichen Methoden vorgesehen Die Problemstellung der Arbeit leitet sich aus der Frage ab ob diese Systematisierung so weitgehend m glich ist dass sie im Rahmen einer Modelltransformation f r einen automatisierten bergang von Analyse zu Designmodellen genutzt werden kann 15 3 Stand der Technik Im Folgenden sollen die f r diese Arbeit relevanten Technologien und Methoden vorgestellt erlautert und in einen Gesamtzusammenhang gebracht werden Zun chst werden die Methoden der System und Softwareentwicklung vorgestellt um damit einen Rahmen f r die Unter suchung der Modelltransformationen zu schaffen i Systementwicklung A Kapitel 3 1 I Definiert Anforderungen fur I N Beschreibt Rahmen f r pe Modelltransformationen Prazisierte Problemstellung 7 5 Kapitel 3 3 Kapitel 3 4 4 l l i i Definiert Anforderungen f r i N I Softwareentwicklung Kapitel 3 2 Abbildung 3 1 Uberblick der Themen Abbildung 3 1 zeigt den Aufbau der folgenden Unterkapitel im Uberblick Wegen der groBen Wechselwirkung mit der Softwareentwicklung werden zunachst die grundlegenden Merkmale der Kernprozess und die zu ber cksichtigenden Methoden der Systementwicklung vorgestellt Aus diesen Betrachtungen leiten sich Rahmenbedi
379. streben eine enge Verzahnung mit der Softwareentwicklung an In der Softwareentwicklung haben sich seit einiger Zeit Modelle etabliert die technisch gro e hnlichkeiten mit den Modellen der Systementwicklung haben Ans tze im Umfeld modellgetriebener Softwareentwicklung versprechen Modelle aus unter schiedlichen Bereichen integrieren zu k nnen F r den bergang zwischen solchen Modellen wird das Konzept der Modelltransformationen angeboten das diesen Vorgang weitgehend automatisieren soll Da sowohl in der System als auch in der Softwareentwicklung Modelle genutzt werden erscheinen die Ans tze der modellgetriebenen Entwicklung als eine M glich keit die angestrebte Verzahnung von System und Softwareentwicklung zu erreichen Eine aktuell sehr bekannte Auspr gung von modellgetriebener Entwicklung ist die Mode Driven Architecture MDA Unter diesem Oberbegriff b ndelt die Object Management Group OMG einige Standardisierungsaktivit ten die z B die Formalisierung von Modellen Meta modellierung den Austausch von Modellen und die Transformationsregeln umfassen Ein Ziel der MDA ist es mit diesen Technologien plattformunabh ngige Modelle Platform Independent Models PIMs automatisch in plattformspezifische Modelle Platform Specific Models PSMs berf hren zu k nnen In der Praxis hat sich die modellgetriebene Entwicklung noch nicht umfassend durchgesetzt Ein Grund hierf r ist der noch relativ niedrige Reifegrad d
380. t gt Beziehung eingeht Ziel der Abfrage ist es zu ermitteln welche Designmuster durch eine Transformation aus diesem Analysemuster hervorgegangen sind Wie in Abbildung 5 6 zu sehen ist werden die bei der Transformation verwendeten Optimierungskriterien des Transformationsvorgangs die entsprechenden Designmuster sowie ggf die Antworten auf gestellte Benutzerr ckfragen angezeigt 173 5 Prototypische Umsetzung POTAD Traceability Navigator Analysispattern x i Traceability Information Gewahltes Analysemuster ClosedlLoop A CruiseClosedloop Globale Aspekte des Transformationsvorgangs Portability False Performance False Resources False Security true sefundene Designpattern ClosedLoop DS CyclicExecutive ClosedLoop_D3 Blackboard ClosedLoop_D3 PubSubscriber1 ClosedLoop_ DS cloop Userquestion Muss der Regelalgorithmus mehrere Zust nde unterscheiden gt false ClosedLoop_D3 PubSubscriber Userquestion Werden die Sensordaten ber einen Datenbus zur Yerf gung gestellt gt false Abbildung 5 6 Ergebnis einer Abfrage f r den Kontext Ana ysemuster 2 Die Abfrage Design kann ber das Kontextmen einer Musterinstanz im Model Explorer oder einem Diagramm aufgerufen werden die eine lt lt design for gt gt Beziehung eingeht Ziel der Abfrage ist es zu ermitteln aus welchem Analysemuster dieses Designmuster durch eine Transformation hervorgegangen ist Wie in Abbildung 5 7 zu sehen ist w
381. t werden die Regelungsalgorithmen f r die unterschiedlichen Zust nde in separaten Objekten gekapselt ControlLoop Der Regelungsalgorithmus wird in einem separaten Objekt gekapselt PublisherSubscriber Wiederverwendung M gliche zuk nftige Datenkonsumenten der Sensoren k nnen einfach durch Registrierung als Abonnent hinzugef gt werden Strategy Wiederverwendung Der Regelungsalgorithmus kann leicht ausgetauscht werden Template Wiederverwendung Gibt eine f r Regelungen typische Algorithmenstruktur vor calcControlDeviation berechnet die Regelabweichung calcControlValue berechnet den Stellwert Es wird eine konkrete Klasse generiert die diese Algorithmen implementiert Weitere Implementierungen k nnen durch Subtypbildung hinzugef gt werden HeterogeneousRedundancy Sicherheit Heterogene Redundanz der Sensorik Aktuatorik und des Reglers unterst tzen SecondGuess Sicherheit Den in der Regelschleife verwendeten Algorithmus durch einen k rzeren Algorithmus absichern und beide Algorithmen in separaten Objekten kapseln Watchdog Sicherheit Periodisch pr fen ob die Regelschleife noch aktiv ist 2 OpenLoopControl 2 1 Zweck Eine Steuerkette engl feedforward control beschreiben 195 2 2 Motivation Viele Funktionen im Fahrzeug haben steuerungstechnischen Charakter Nach DIN 19226 1 DIN 94 wird eine Steuerung wie folgt definiert Die Steuerung ist der Vorgang in einem System bei dem eine
382. t optimCriteriaSetting name Performance value gt lt designpattern id F6C82ADF gt lt optimCriteria name gt lt designpattern gt lt designpattern id EDBOE89B gt lt designmodel gt lt trace gt By l tints lt AnalysisCollaboration lt Analysemuster Bindung gt wein i ar Design For a ana Ban ee Design For _ lt Designmuster Bindung 0 gt gt lt lt Designmuster Bindung 1 gt gt _ lt Designmuster Bindung 2 gt gt m Mt I eee me La Da 222 ee Des Abbildung 4 13 lt lt Design For gt gt Beziehung mit Dokumentation der Designentscheidungen Das folgende Listing zeigt ein Beispiel f r das XML Dokument in Ausz gen Das Format wird anschlie end informell beschrieben race lt designmodel id 20B80688 5F01 path Design mdx gt lt optimCriteriaSetting name Performance value false gt lt designpattern id 848E0EA5 gt lt designpattern gt lt designpattern id 9A84CBA6 7047 4213 B9D5 22 9EOF 9B20CB gt lt userquestion text Werden die Daten ber einen Datenbus zur Verf gung gestellt answer false gt lt designpattern gt lt designpattern id 96B2E34D gt lt designpattern gt lt designpattern id 50032718 gt lt userquestion text Soll der Regelalgorithmus verschiedene Strategien besitzen answer true gt lt designpattern gt lt designmodel gt lt trace gt Eine Aufzeichnu
383. t sehr hohe Optimierungsanforderungen in der Softwareent wicklung zur Folge e Wiederverwendung und Portabilitat Ein Hersteller produziert in der Regel mehrere Baureihen die viele identische Funktionen aufweisen Entsprechend sollte die Software Implementierung f r die verschiedenen Baureihen wiederverwendbar sein Dabei muss auch ber cksichtigt werden dass in den unterschiedlichen Baureihen verschiedene Steuerger te plattformen zum Einsatz kommen k nnen sowohl Prozessor als auch Betriebssystem e Variabilit t Viele Softwarefunktionen k nnen in Abh ngigkeit mit der vom Kunden ge w hlten Ausstattungsvariante variieren Da Software Varianten einfacher zu handhaben sind als Hardware Varianten besteht au erdem h ufig die Anforderung variantenspezifische An teile eines elektronischen Systems m glichst ausschlie lich durch Software zu realisieren Dar ber hinaus gibt es zahlreiche gesetzliche Bestimmungen und Industriestandards die zu ber cksichtigen sind Dazu geh ren z B Daten bertragungsprotokolle Stecker Layouts Diagnoseprotokolle sowie Standards f r das Flashen und Codieren von Steuerger ten 3 1 1 f Bildung von Subsystemen Einige der bisher genannten Anforderungen stehen im Konflikt so dass das System oder Soft waredesign nicht gleicherma en in alle Richtungen optimiert werden kann und eine ent sprechende Gewichtung vorgenommen werden muss In der Automobilindustrie hat es sich bew hrt diese Gewi
384. t wurde enth lt aber Konzepte die diese M ngel beheben k nnen Es kann mit einem verh ltnism ig m chtigen Mustermechanismus aufwarten der sowohl eine formalisierte Beschreibung eigener Muster erlaubt als auch die Verschmelzung der Muster struktur mit einem Zielmodell wahrend der Instanziierung unterst tzt Der Mustermechanismus von XDE ist allerdings nicht in jedem Detail konform mit den UML Templates Das Werkzeug XDE und sein Musterkonzept werden f r die weitere Diskussion als Referenz betrachtet und dienen in dieser Arbeit als Basisinfrastruktur f r neue Mechanismen Bei dem intensiven Einsatz von Mustern im Rahmen der Fallstudie und weiteren Evaluierungs modellen konnte festgestellt werden dass der Entscheidungsprozess welches Designmuster zum Einsatz kommt bei der vorherigen Verwendung von Analysemustern systematisiert werden kann So wurde beobachtet dass Instanzen eines Analysemusters auf der Designebene in Ab hangigkeit von nichtfunktionalen Anforderungen und der technischen Systemarchitektur durch dieselben Designmuster realisiert werden k nnen Eine erste in Kapitel 3 2 4 e beschriebene informelle Systematik beschreibt den Zusammenhang zwischen Analyse und Designmustern mit Hilfe von Parameterabbildungen zwischen Mustern Operatoren f r den Umgang mit Mengen und Bedingungen Diese Systematik ist eine Antwort auf die in der Problemstellung siehe Kapitel 1 2 gestellte Frage nach der Systematisierbarkeit des Zusammenh
385. tState Die abstrakte Zustandsklasse kann durch beliebig viele konkrete Zust nde ConcreteState spezialisiert werden Bei Aufruf der call_operation der Kontextklasse wird dann jeweils die Implementierung aus der aktuellen Zustandsklasse verwendet Das Muster bietet sich an wenn das Verhalten eines Objekts stark von seinem Zustand abh ngt 222 16 Strategy 16 1 Zweck Eine Familie von austauschbaren Algorithmen definieren und in separaten Objekten kapseln 16 2 Struktur Context lt Strategy gt Strategy io i mm i gt contextInterface algorithminterface Context Class Strategy Class ConcreteStrategy 1 Class algorithminterface Operation ConcreteStrategy SR Strategy gt algorithminterface Soo 4 0 ame 16 3 Erl uterung Das Strategy Muster von Gamma et al Gamma et al 95 definiert eine Familie von aus tauschbaren Algorithmen die unabhangig von dem benutzenden Kontext variiert werden k nnen Dies wird durch eine abstrakte Strategieklasse Strategy realisiert die ihren Unter klassen ConcreteStrategy die Implementierung einer Operation algorithmInterface vorgibt und somit eine einheitliche Schnittstelle deklariert Die Strategien werden von der Kontextklasse Context geb ndelt Deren Operation contextInterface ruft die Strategien dann ber die Schnittstelle auf Die genaue Auswahl der konkreten S
386. tamodellierungs Tool GME Ledeczi et al verwiesen Ein Transformator der selbst als Sammlung von UMLX 124 Modelltransformationen Transformationen definiert und in XSLT implementiert werden soll war zum Zeitpunkt der Veroffentlichung des Beitrags noch in der Entwicklung 3 3 4 h Model Transformation Language MOLA Der in Kalnins et al 04 vorgestellte Ansatz kombiniert die Konzepte einer strukturierten Programmiersprache und von Mustern in einer graphischen Transformationssprache Ein MOLA Programm engl program transformiert ein Quell in ein Zielmodell wobei beide Modelle jeweils konform zu einem Metamodell sein m ssen Das Programm besteht aus einer Sequenz von sog Statements die in einer graphischen Form modelliert werden die von den Autoren mit einem Kontrollflussgraphen engl structured flowchart verglichen wird Die wichtigsten Statements sind Regeln engl Ru es und Schleifen engl Loops Eine Regel ent h lt ein Muster engl Pattern das f r den Matching Teil der Regel steht und eine Action Spezifikation Letztere umfasst Klassen oder Assoziationen die bei einem Auftreten des Musters erzeugt oder gel scht werden sollen sowie Modifikationen von Attributwerten F r die graphische Modellierung der Muster und des Action Teils wird eine eigene Form von UML Objektdiagrammen verwendet Abbildung 3 56 zeigt einen Ausschnitt des auch in den anderen Ans tzen oft verwendeten Beispiels bei dem UML Klassen in ein Model
387. te der MDA auf der Grundlage von Miller et al 03 naher erlautert F r eine detaillierte Beschreibung des Ansatzes sei auf die offiziellen OMG Dokumente OMG b und entsprechende Sekundarliteratur z B Kleppe et al 03 IESE b oder Kempa et al 05 verwiesen 3 3 1 a Grundlegende Konzepte und Artefakte Der Betrachtungsrahmen aller MDA Konzepte umfasst ein geplantes oder existierendes System Dies kann nach Definition alles enthalten Ein Programm ein Computersystem aber auch komplexe organisatorische Gebilde wie ganze Unternehmen Dem Fokus der OMG ent sprechend liegt der Schwerpunkt jedoch auf softwareintensiven Systemen Ein Modell ist eine Beschreibung oder Spezifikation eines solchen Systems f r einen bestimmten Zweck und kann sowohl graphisch als auch in Textform vorliegen Bei der technischen Realisierung eines solchen Systems spielt der Begriff Plattform eine zentrale Rolle Eine Plattform wird zun chst als Menge von Subsystemen und Technologien be schrieben die zusammenh ngende Funktionen durch Schnittstellen und spezifizierte Nutzungsmuster anbietet die jede von dieser Plattform unterst tzte Anwendung benutzen kann Miller et al 03 Solche Plattformen k nnen generisch ber architektonische Besonder heiten auf eine bestimmte Technologie bezogen z B CORBA J2EE oder auch hersteller oder produktspezifisch definiert werden Nach den Vorstellungen der OMG sollte dies in einem 109 3
388. ten Vorschlage aus dem Bereich der Systementwicklung modellbasierte Ans tze die eng mit den in der Softwareentwicklung etablierten Ans tzen ver wandt sind Diese Modelle werden f r die Softwareentwicklung durch die angesprochene Ver zahnung zu Ber hrungspunkten mit der Systementwicklung Zu den f r die Softwareentwicklung relevanten Artefakten die aus Systementwicklung hervor gehen geh ren die ogische und technische Systemarchitektur Die logische Systemarchitektur beschreibt die Funktionen und Eigenschaften des Gesamtsystems auch der Nicht Softwareanteile unabh ngig von einer m glichen technischen Realisierung Der Fokus liegt hierbei auf der abstrakten Beschreibung der Systemstruktur und des Zusammenwirkens der einzelnen Subsysteme mit den vorhandenen logischen Sensoren Sollwertgebern und Aktuatoren Die logische Systemarchitektur wird im Laufe der Systementwicklung auf die technische Systemarchitektur abgebildet die eine m gliche technische Realisierung f r die Funktionen der logischen Systemarchitektur darstellt Bei dieser Partitionierung wird eine Funktion in Einzel teile zerlegt die unterschiedlichen Steuerger ten zugeordnet werden k nnen Die technische Systemarchitektur beschreibt z B den Hardware Aufbau von Sensoren Aktuatoren und Steuerger ten sowie die Vernetzung der Hardwareeinheiten Abbildung 1 2 zeigt schematisch die Inhalte der logischen und technischen Systemarchitektur Die logische Systemarchitektur um
389. ter IN Technische Systemarchitektur EAST ADL Transformation sanken een L e Speicherverbrauch v eSicherheit und Verf gbarkeit e Wartbarkeit Portabilitat Verfolgbarkeits Erweiterbarkeit Wiederverwendung information N l l l l l V Mechanistic Design Object Model UML Klassenmodell Abbildung 3 50 Illustration der angestrebten Transformation Auf der Basis dieses Grobkonzepts kann nun die bereits in Kapitel 3 1 4 begonnene Sammlung von Anforderungen an den Modelltransformationsmechanismus verfeinert werden Mit in den Klammern angegebenen Kurzeln werden sie fur die weitere Diskussion referenzierbar gemacht e UML Klassenmodelle UML Ein und Ausgabemodell der Transformation sind UML Klassenmodelle Die in Kapitel 3 2 1 c beschriebene Modellierungsweise fur Funktionsnetze muss unterstutzt werden e Template Definition und Bindung TEM Ein wie in Kapitel 3 2 4 f erlautertes Template Konzept muss unterstutzt werden Zu den Kernanforderungen gehoren o Ein Template kann definiert werden Zu der Definition gehoren ein Name und ein Klassenmodell aus dem einzelne Elemente als formale Template Parameter deklariert sind o Ein Template kann gebunden werden Bei der Bindung werden den formalen Template Parametern die tats chlichen Parameter aus dem Zielmodell zu gewiesen 107 3 Bel Stand der Technik Template Ex
390. ter Systern andor dewze specific in thes example a reset action is tiggered Figure 7 6 UML sequence diagram example of a timeout detector in the Detector Corrector Pattern Consequences e If a detector monitors a device on a periodic basis then the device must send life ticks periodically to the detector e A local fault handler must be present to handle fault messages from a detector and to activate correctors e The system must contain a reset operation or a more elaborate fault recovery mechanism that the corrector can perform in case of a violation Constraints The following constraints must be satisfied after the Detector Corrector pattern has been applied Anmerkung Ausdr cke in der formalen Constraint Sprache wurden weggelassen e If there is a violation then the detector should eventually detect the violation e When the detector detects a violation the corresponding local fault handler must be noti fied e If a fault is reported to the local fault handler then the local fault handler must activate the corresponding corrector appropriate to the fault reported e If a corrector is activated then the local fault handler will eventually perform the corre sponding recovery action appropriate to the system being modeled e g activating a cor rector that resets the device e When a fault is reported to the local fault handler the global fault handler is eventually notified 208 Applicab
391. teraus pragung soll an eigene Bed rfnisse anpassbar sein Muster sollten geeignet kombinierbar sein e Ausgeglichenheit Ein Muster soll eine m glichst gute Balance zwischen inneren Erforder nissen und u eren Sachzw ngen darstellen Es sollen alle Invarianten der Problemstellung erf llt und Inkonsistenzen in der L sung vermieden werden Einheitliches Beschreibungsschema f r Muster Bisher konnte sich kein einheitliches Schema f r die Beschreibung eines Musters herausbilden Neben der urspr nglichen Notation von Alexander Alexander 77 ist vor allem das Schema der GoF Gamma et al 95 bekannt Die Hillside Group sieht folgende Inhalte einer Muster beschreibung als wichtig an Hillside Group 19 3 Stand der Technik e Einen Bezeichner um das Muster eindeutig zu identifizieren und zus tzlich Verweise auf weitere Bezeichnungen A so Known As unter denen das Muster bekannt ist e Eine exakte Beschreibung der Problemstellung die klar die Ziele des Musters innerhalb eines bestimmten Kontextes definiert e Eine Beschreibung des Kontextes und der Bedingungen unter denen das Muster an gewendet werden kann e Auflistung aller Einflussfaktoren und Invarianten Dadurch wird das Losungsumfeld des Musters genau definiert wodurch inkonsistente bzw ungeeignete L sungen vermieden werden e Die eigentliche Losungsbeschreibung f r das Problem die oftmals in einer Anleitung zur Erstellung des gew nschten Ergebnis
392. tert XDE IBM b integriert eine klassische Entwicklungsumgebung C und Java und ein UML Modellierungswerkzeug auf der Basis von Eclipse Eine Besonderheit dieses Werkzeugs ist ein verh ltnism ig m chtiger Mustermechanismus der unter anderem das Erstellen eigener UML Muster erlaubt die um Code Templates erg nzt werden k nnen Bibliotheken der bekannten Gamma Muster Gamma et al 95 f r Java und C werden mitgeliefert Das betrachtete Rational XDE lag in Version 2003 06 12 vor Definition von Mustern Im Folgenden soll der Mustermechanismus anhand des Beispiel Musters C osedlLoopContro siehe Anhang A 1 erl utert werden Abbildung 3 38 zeigt die Definition dieses Musters im Modellbaum Wurzelelement ist ein sog Asset Dabei handelt es sich um einen XDE eigenen Mechanismus zur Bildung wiederverwendbarer und austauschbarer Modelleinheiten Das eigent liche Muster wird in der Notation einer Collaboration Ellipse mit Parametern rote Punkte angelegt F r den Parameter ClosedLoopController wurde au erdem ein Defaultwert angegeben Symbol lt gt Das UML Element unterhalb des Parameters im Beispiel Klasse oder Signal spezifiziert den Typ des Parameters Die Kind Elemente dieser Elemente im Fall von ClosedLoopController z B der Signal Empfang lt lt signal gt gt FeedbackValue werden bei einer Muster Anwendung von dem tats chlichen Parameter entsprechend der Verschmelzungsregeln siehe folgendes Unter kapitel
393. tete Funktionsnetzwerk besteht im Wesentlichen aus Blocken die uber gerichtete Kanten verbunden sind und uber diese abstrakte Datenelemente austauschen Abbildung 3 12 zeigt die vereinfachte Darstellung die in Anlehnung an Schauffele et al 03 z B in Abbildung 2 1 verwendet wurde am Beispiel eines Signals SensorValue das von Block Sensor zu Block ControlFunction versendet wird SensorValue Sensor gt ControlFunction Abbildung 3 12 Beispiel eines Blockdiagramms Bei der Konzeption der Modellierungssprachen f r die Systementwicklung die die Modellierung eines solchen Funktionsnetzwerks unterst tzten siehe Kapitel 3 1 3 b wurde teilweise auf eine m glichst weitgehende UML Konformit t geachtet Bei der EAST ADL bezieht sich diese auf die UML2 Das Beispiel in Abbildung 3 13 zeigt f r einige Elemente der Functional Analysis Architecture wie diese mit Hilfe eines UML Profils dargestellt werden k nnte Die Bl cke werden als stereotypisierte Klassen dargestellt die ber Interfaces verf gen Im Gegensatz zur offiziellen Notation der EAST ADL haben die Interfaces hier nicht die Dreieck Symbolik da diese nicht zur Standardnotation der UML geh rt Die Zeitangaben im Beispiel period 10 lassen sich als tagged value realisieren deren Darstellung jedoch werkzeugabhangig sein kann FunctionalDevice AnalysisFunction Sensor ControlFunction D Ei SignalFunctionPortinterface IF_Sensor sen
394. the first type Figure 7 3 detects a timeout of the Device and reports the error to the LocalFaultHandler The LocalFaultHandler In turn reports the fault to the GlobalFaultHandler and activates the Corrector which initiates a reset of the Device 205 PerformRecoveryActon ID send Conector RecoveryActon D ReportLocalFauliiFaulilDyy ReportNoAction do Report fault to global fault handler OverrideMode Normalkdodesid u a PerfomRecoveryActon IDV i i send Corector_InitiateRecoveryAchon ID RespondToFaults dofCompute and initiate required recovery action in detector do Report fault to global fault handler ReportLocalFault FaulilDyy Figure 7 2 UML state diagram of the LocalFaultHandler in the Detector Corrector Pattern Update i ResetTimert V DetStarti WjResetTimeri courting DetStopi ip Timeout if Violation entry Report fault to local fault handler Figure 7 3 UML state diagram of a timeout detector in the Detector Corrector Pattern DetStart ResetTimer w EA DeiStopiHy Mo violation found meourty if HesefTimer Wiolation found Check dofCheck conditions Violation entryindicate violation entry Report fault to local fault handler Figure 7 4 UML state diagram of a constraint violation detector in the Detector Corrector Pattern 206 System and or dewice specific recovery action appropriate
395. tiales Analysis Object Strutural Model verwendet wird Im Modell werden die Funktionen und logischen Sensoren Aktuatoren als Klassen modelliert die Uber Signale aus dem UML Metamodell miteinander kommunizieren Die bei der Umwandlung anzuwendenden Abbildungsregeln sind sehr einfach und lassen sich z B per Skript realisieren Die manuelle Erstellung des Analysemodells entfallt dadurch weit gehend da sich dieses fast vollstandig aus den Systementwicklungsmodellen ableitet Eine entscheidende Erweiterung der ROPES Methode erfolgt durch die Einf hrung von Mustern in das Analysis Object Model Diese in Kapitel 4 2 3 a n her erlauterten Analysemuster m ssen zum Ende der Analysephase m glichst umfassend in das Modell in Form von Musterinstanzen eingebracht worden sein Analysemustertypen und instanzen basieren dabei auf einem eigenen Template Mechanismus der in Kapitel 4 2 1 naher erlautert wird Als Beispiel eines solchen Object Analysis Models kann der obere Teil von Abbildung 3 45 herangezogen werden in dem das Analysemuster ClosedLoopControl f r das Funktionsnetzwerk eines Tempomaten gebunden wurde Das Einbringen der Analysemuster erfordert Expertise in der Systementwicklung Wie an dieser Stelle genau die Arbeitsteilung zwischen System und Softwareentwicklung aussieht wird hier nicht weiter ausgearbeitet Da die Analysemuster inhaltlich den Fachbereich der Systement wicklung adressieren erscheint die Vorstellung nicht abwegig dass d
396. tionsparameter erreicht werden die anderen Ans tze bieten hier lediglich den Umweg ber zus tzliche Quellmodelle Die gew nschte Verfolgbarkeit auf der Basis verlinkter Template Instanzen Anforderung TRC muss bei allen Ans tzen ber eine Erweiterung realisiert werden wobei das Konzept der QV Merge Group mit dem bereits existierenden 131 3 Stand der Technik Verfolgbarkeitsmechanismus eine bessere Ausgangsbasis bietet Die Moglichkeit bereits er zeugte Elemente im Zielmodell zu benennen und spater erneut auf sie zuzugreifen Anforderung ZBE kann bei QVT und EXMOF Uber die Definition von Attributen bzw Variablen realisiert werden wobei dies in den imperativen Mappings der QV 7 Merge Group flexibler ist Die beiden graphischen Ans tze bieten diese M glichkeit nicht ber Mengen kann in allen Ans tzen iteriert werden Anforderung IT bei QVT und EXMOF ber OCL bei den anderen teilweise etwas eingeschr nkt ber Kontrollstrukturen Zusammenfassend muss festgehalten werden dass Kernanforderungen wie die Handhabung von Templates das Variabilitatsmodell und die M glichkeit der Nachverfolgbarkeit von keinem Ansatz umfassend unterst tzt werden EXMOF und QVT kommen den gestellten An forderungen am n chsten und lassen es sinnvoll erscheinen konkreter zu pr fen inwiefern sich die nicht erf llten Anforderungen durch Erweiterungen realisieren lassen In der Diplomarbeit von Buchwald 05 wurde die in Kapitel 3 2 4 8 beschrie
397. tivitaten geh rt die Realisierung von Assoziationen Aggregationen und Kompositionen Assoziationen k nnen hier beispielsweise als Zeiger Referenzen oder TCP IP Sockets verwirk licht werden Au erdem werden die Sichtbarkeit und der Datentyp von Attributen bestimmt sowie ihr G ltigkeitsbereich und bestimmte Ausnahmebehandlungen Der Entwickler kann sich in dieser Phase auf einfache Faustregeln oder Idiome siehe Kapitel 3 2 4 st tzen Als Artefakt entsteht das Detailed Design Model das eine Weiterentwicklung der schon existierenden Struktur und Verhaltensdiagramme darstellt 3 2 2 e Translation In dieser Phase wird aus dem UML Modell Quellcode erzeugt der i d R unter Hinzunahme weiterer Codeteile kompiliert und gelinkt wird Nach einem Test der so erzeugten Einheiten konnen schlieBlich ausfuhrbare Komponenten zur Verfugung gestellt werden Die Erzeugung des Quellcodes kann manuell Manuel Code Generation automatisiert Automatic Code Generation oder aus einer Kombination von beiden erfolgen siehe Abbildung 3 24 Im ersten Fall wird der Code manuell durch Verfeinerung und Ausarbeitung des Analyse bzw Designmodells entwickelt Da hier die Gefahr besteht dass die Modelle und der Code nicht mehr synchronisiert sind empfiehlt ROPES grunds tzlich eine automatische Code generierung Zu den Aktivitaten des Entwicklers geh ren beim manuellen Ansatz die Erzeugung des Quell codes f r eine objektorientierte Programmiersprache od
398. trategie bleibt in der Formulierung von Gamma offen es hei t nur dass die Kontextklasse mit einem ConcreteStrategy Objekt konfiguriert werden kann Das Muster sollte eingesetzt werden wenn es f r komplexe Algorithmen mehrere Alternativen gibt 17 TemplateMethod 17 1 Zweck Das Skelett eines Algorithmus definieren und einzelne Rechenschritte in separate Objekte auslagern 17 2 Struktur AbstractClass templateMethod AbstractClass Class primitiveOperation c 1 ConcreteClass Class _templateMethod Operation 1 c 1 primitiveOperation Operation T TemplateMethod gt ee Zu ConcreteClass primitiveOperation 223 17 3 Erlauterung Das TemplateMethod Muster von Gamma et al 95 erm glicht die Definition eines Skelettes f r einen Algorithmus TemplateMethod indem einzelne Schritte auf separate Operationen PrimitiveOperation aufgeteilt werden Die Schablonenmethode wird nur in einer abstrakten Klasse AbstractClass definiert und berl sst die Implementierung der primitiven Operationen deren Unterklassen ConcreteClass Damit k nnen die Schritte auch einzeln ausgetauscht werden Der Einsatz dieses Musters bietet sich an wenn die grobe Struktur eines komplexen Algorithmus konstant ist seine konkrete Implementierung jedoch in verschiedenen Teilen variiert 18 Watchdog 18 1 Zweck Eine Zeituberwachung in einem Objekt kapseln
399. trolLoop initialize step shutDown wird wie folgt mit dem Zielmodell verschmolzen _DesiredSpeed _CurrentSpeed i _InputRepository bind Bind Repository InputRepository Data DesiredSpeed Current lt input Speed Client CruiseController_ Master J Di bind Bind ControlLoop CruiseController_ControlLoop Sensor Inputr Repository Actuator Throttle Sensor_getMethod getDesired Speed getCurrentSpeed Actuator_setMethod setThrottleSet Value Context CruiseController_ Master _CruiseController_ControlLoop X Konflikt Element wird nicht neu angelegt Bei dieser Verschmelzung treten einige Konflikte auf Kreuze in Orange die durch die Ver schmelzungsregeln behandelt werden So werden f r die Parameter Context hier CruiseController Master und Sensor keine neuen Klassen angelegt da namensgleiche Klassen bereits im Modell existieren Auch die in der Struktur von ControlLoop definierte gerichtete Assoziation zwischen Context hier CruiseController_ Master und Sensor hier Repository wird nicht angelegt da solch eine Assoziation bereits durch das Repository Muster erzeugt wurde Gleiches gilt f r den Parameter Sensor_getMethod Die sich hier ergebenden get Methoden sind bereits vorhanden und werden wiederverwendet 177 5 Prototypische Umsetzung Im n chsten Schritt wird das Template PubSubscriber PublischerSubscribe
400. troller Name des berwachungssensors ThrottleMonitorSensor Klasse die den Sollwert liefert CruiseController Methode fur die Abfrage des Sollwerts getDesiredSpeed 238 EngineController Throttle Throttle I call ReferenceValueSource_getMethod setThrottleValue CruiseController CruiseController eee ene getDesiredSpeed er 2 i troller j _CruiseControlle _ThrottleMalfunctionDetector ThrottleMalfunctionDetector ThrottleMonitorSensor ThrottleMonitorSensor 1 MonitorState Boolean call getThrottleValue setT hrottleValue ChangeToFailSafeMode getThrottleValue ExceptionRecord Be Le I ee er ExceptionRecord ExceptionLog ceptionLog ioe g 1 uniquelnstance ExceptionLog 0 5 i singExLog Heinen ExceptionSafeClass ExceptionSafeClass ey aa q etUni rear ExceptionLog ExceptionLog 0 1 EngineFault Handler EngineF aultHandler _ExceptionSafeClass get_GlobalExceptionHandler get_ExceptionLog 0 1 _GlobalExceptionHandler a pe en GobalExceptionHandler EUER SER ap cia 2 we singGlobExHand uniquelnstance GlobalExceptionHandler 0 ER severity String ExceptionID Integer _ThrottleMalfunctionDetector 9etUniquelnstance ExceptionHandler
401. ttstellen gibt es keine direkte Verbindung zu den Steuerungs und Regelungsfunktionen sondern die Werte der Bedien und Anzeigeelemente werden Vor bzw Nachbearbeitet So kann die Benutzerschnitt stelle z B zustandsbehaftet sein und je nach Zustand einzelne Elemente aktivieren oder de aktivieren Auf der Analyseebene wird von der konkreten technischen Realisierung der Benutzerschnittstelle abstrahiert Im Fokus stehen lediglich die dem Benutzer zur Verf gung stehenden Bedien und Anzeigeelemente sowie die entsprechenden Ein und Ausgangssignale zwischen der Benutzer schnittstelle und den Steuerungs und Regelungsfunktionen 3 3 Struktur und Informationsfluss UserInterface Class i 0 Indicator Class c 0 Control Class i 0 IndicatorValue Signal c 0 ControlValue Signal s 0 Source Class d 0 Drain Class s 0 d 0 UilnputValue Signal UiOutputValue Signal UserInterface gt aan COA ae lt UilnputValue gt lt UiOutputValue gt lt ControlValue gt lt IndicatorValue gt e Source Eine Steuerungs und Regelungsfunktion deren Signal UiInputValue an der Be nutzerschnittstelle angezeigt werden soll e Drain Eine Steuerungs und Regelungsfunktion die das ber die Benutzerschnittstelle erfasste Signal UiOutputValue verarbeitet e Userlnterface Vermittelt zwischen den Bedien und Anzeig
402. tware Architektur s PE a Ra er i oftware Komponenten Spezifikation der Software Komponenten Terier Software Komponenten Design amp Implementierung der Software Komponenten Abbildung 3 3 Ein Kernprozess f r System und Softwareentwicklung Sch uffele et al 03 Durch den Kernprozess werden die Spezifikations und Integrationsschnittstellen zwischen System und Softwareentwicklung aufgezeigt Diese Schnittstellen m ssen wiederum von der verwendeten Softwareentwicklungsmethode ber cksichtigt werden um das Ziel eines durch g ngigen Entwicklungsprozesses verwirklichen zu k nnen In den folgenden Kapiteln werden die 21 3 Stand der Technik einzelnen Prozessschritte und Artefakte der System und Softwareentwicklung etwas detaillierter vorgestellt Dem Schwerpunkt dieser Arbeit entsprechend beschr nkt sich diese Betrachtung auf den linken Zweig des V Modells 3 1 2 a Prozessschritte und Artefakte der Systementwicklung Analyse der Benutzeranforderungen und Spezifikation der logischen Systemarchitektur Ausgangspunkt sind die akzeptierten Benutzeranforderungen die die Anforderungen der unter schiedlichen Benutzergruppen z B Fahrer Servicemitarbeiter oder Gesetzgeber an das Fahr zeug in nat rlicher Sprache und i d R nicht technisch beschreiben Hierbei kann zwischen funktionalen und nichtfunktionalen Anforderungen unterschieden werden W hrend funktionale Anforderungen die Normal und Fehlfunktionen des Systems besch
403. twicklung verwendet In Analogie zur Definition von Programmiersprachen wird oftmals davon gesprochen dass die durch ein Metametamodell definierbaren Metamodelle eine abstrakte Syntax f r Modelle be schreiben die eine notationsunabh ngige Grammatik der verwendbaren Konzepte darstellt Ein Metamodell stellt somit eine Sprache dar Um eine Einschr nkung vorzunehmen welche mit der Grammatik erzeugbaren Ausdr cke inhaltlich sinnvoll sind im Allgemeinen als statische Semantik bezeichnet werden sog Woh geformtheitsrege n eingef hrt die beispielsweise Be dingungen wie Zyklenfreiheit beschreiben Die dynamische oder operationale Semantik die die Bedeutung von wohlgeformten Ausdr cken festlegt wird blicherweise nur als Semantik be zeichnet und meist in nat rlicher Sprache ausgedr ckt Die abstrakte Syntax der Sprache kann durch verschiedene konkrete Syntaxen realisiert werden zum einen durch graphische Notationen meist verschiedene Arten von Diagrammen zum anderen durch textuelle Dar stellungen Details der Realisierung werden dann durch ein Mapping definiert das Elemente aus der abstrakten Syntax mit den zugeh rigen Notationselementen aus der konkreten Syntax verkn pft Die gesamte Beschreibung eines Metamodells beinhaltet somit die abstrakte Syntax statische und dynamische Semantik sowie eventuelle konkrete Notationen mit Mappings Mit dem Begriff Metamodell selbst ist allerdings berwiegend nur die abstrakte Syntax gem
404. twicklungsphasen automatisiert ineinander berf hrt und deren Modellelemente so miteinander verkn pft dass ihr Zusammenhang im Nachhinein systematisch verfolgbar ist Im Rahmen dieser Arbeit wird berpr ft inwiefern sich diese Ans tze f r die Integration von System und Softwareentwicklung bei der Entwicklung von softwareintensiven Fahrzeug funktionen nutzen lassen Zielstellung ist es die Modelle der Systementwicklung als Analyse modell im Rahmen der Softwareentwicklung wiederzuverwenden und mit Hilfe von Modelltrans formationen automatisiert in eine Vorlage f r ein Softwaredesignmodell zu berf hren Die spezifischen Anforderungen die f r dieses Zielszenario an einen Modelltransformations mechanismus gestellt werden m ssen wurden aus den grundlegenden Anforderungen der Dom ne den herk mmlichen Methoden der System und Softwareentwicklung und den einsetz baren Modellen abgleitet Mit dem Kernprozess und ROPES bzw der EAST ADL und der UML wurden zun chst zwei Referenzmethoden bzw Modellierungssprachen f r die System und Softwareentwicklung identifiziert In diesem Kontext lassen sich die Kernanforderungen dann wie folgt zusammenfassen Eine Modelltransformation muss f r eine Funktion der logischen Systemarchitektur ein Softwaredesign erzeugen und dies anhand unterschiedlicher nicht funktionaler Anforderungen und der technischen Systemarchitektur variieren k nnen Bei den Untersuchungen erwiesen sich Muster als eine
405. uage for automotive embedded electronic architecture description Version 1 02 EAST EEA Embedded Electronic Architecture 2004 URL http www east eea net Milicev 02 Milicev Dragan Domain Mapping Using Extended UML Object Diagrams IEEE Softw Ausgabe 19 IEEE Computer Society Press 2002 S 90 97 URL http se2c uni lu tiki se2c bib_download php id 615 Miller et al 03 Miller Joaquin Mukerji Jishnu MDA Guide Version 1 0 1 OMG 2003 URL http www omg org docs omg 03 06 01 pdf Oestereich 04 Oestereich Bernd Die UML 2 0 Kurzreferenz f r die Praxis Kurz b ndig ballastfrei Verlag Oldenbourg 2004 OMG 02a Object Management Group OMG Meta Object Facility MOF Specification Version 1 4 2002a URL http www omg org cgi bin doc formal 02 04 03 OMG 02b Object Management Group OMG MOF 2 0 query views transformations QVT request for proposals 2002b URL 260 http www omg org techprocess meetings schedule MOF_2 0_Query_View_Transf _RFP htm l OMG 03 Object Management Group OMG Common Warehouse Metamodel CWM Specication v1 1 2003 URL http www omg org cgi bin doc formal 03 03 02 OMG 05a Object Management Group OMG MOF 2 0 XMI Mapping Specification v2 1 formal 05 09 01 2005a URL http www omg org docs formal 05 09 01 pdf OMG 05b Object Management Group OMG Unified Modeling Language Infrastructure Version 2 0 2005b URL http www omg org cgi b
406. ubject Elemente zugreifen k nnen ndert sich ein Datum so wird der Datenbus von den Subjects ber die Operation update sofort ber diese nderung informiert Somit ist gew hrleistet dass die Clients ber die Operation get immer den aktuellen Wert der jeweiligen AbstractClient AbstractSubject zu AbstractData bedeuten nicht dass diese auch direkt auf alle Daten zugreifen konkreten Datenklasse erhalten Die Aggregationsbeziehungen von und d rfen sondern dienen nur der Festlegung derjenigen Daten die diese ber den Datenbus auslesen bzw f r die sie neue Werte bereitstellen F r eine Instanz des Musters k nnen jeweils beliebig viele konkrete lesende oder schreibende Elemente ConcreteClient bzw ConcreteSubject und konkrete Datenklassen ConcreteData dem allgemeinen Busmechanismus untergeordnet werden 212 4 Decorator 4 1 Zweck Ein Objekt um Zustandigkeiten erweitern 4 2 Struktur _ lt Component gt Decorator Component Component Class Operation gt Operation ConcreteComponent 1 Class Decorator Class ConcreteDecorator 1 Class Operation 1 Operation per N Decorator gt ConcreteDecorator zu ConcreteComponent Operation addedBehaviour F Operation 1 y 4 3 Erl uterung Das Decorator Muster von Gamma et al Gamma et al 95 erweitert ein Objekt dynamisch um zusatz
407. udie siehe Kapitel 2 bew hrt Die Grenzen von POTAD ergeben sich einerseits aus den allgemeinen Besonderheiten von Modell transformationen selbst und andererseits aus den Erfahrungen der bisher durchgef hrten Projekte mit der hier vorgestellten L sung e Die Erfassung von Mustern nach dem Schema von POTAD und die Formulierung von Transformationsregeln sind mit anfanglichem Aufwand verbunden Dieser Aufwand amortisiert sich wenn Muster und Transformationsregeln wiederverwendet werden Eine Wiederverwendung kann i d R realisiert werden wenn die Entwicklung mehrerer ahn licher Funktionen Verwendung derselben Analysemuster geplant ist und die Zielplattform sich nicht wesentlich ndert Eine empirische Untersuchung die die Frage beantworten k nnte ab wie vielen Anwendungen einer Transformationsregel eine Amortisierung der an fanglichen Kosten erreicht wird war im Rahmen dieser Arbeit nicht m glich e POTAD wurde anhand des Fallbeispiels Kombiinstrument und Fahrfunktionen System KFS evaluiert Die Auswahl der im KFS enthaltenen Funktionen wurde so gew hlt dass m glichst unterschiedliche Funktionseigenschaften und Subsysteme eines Fahrzeugs siehe 187 6 Validierung und Bewertung 188 Kapitel 3 1 1 f vertreten sind Trotz dieser unterschiedlichen Funktionen bei deren Ent wicklung POTAD erfolgreich eingesetzt wurde wird in dieser Arbeit nicht der Anspruch er hoben POTAD f r alle Softwarefunktionen im Fahrzeug
408. uerger ts k nnen z B Prozessoren verschiedene Speicherarten und Verbindungen zwischen diesen modelliert werden Eine E E Komponente kann mit Steckern und Pins ver sehen werden die mit unterschiedlichen Leitungstypen verbunden werden k nnen Die Leistungsversorgung Stromversorgung ist ebenfalls Teil des Modells und umfasst z B die Beschreibung von Batterien Generatoren Leistungsverteilern und den entsprechenden Leistungsversorgungsleitungen e Physikalische Architektur Beschreibt die Bauraume und ihre Einbauorte eines Fahrzeugs in denen E E Komponenten verbaut werden k nnen sowie die verbindenden Segmente durch die Leitungen verlegt werden k nnen Tabelle 3 6 ordnet einige Elemente aus dem Metamodell des E E Konzept Tools den in Tabelle 3 1 Tabelle 3 3 definierten Inhalten der Systementwicklung zu Die Elemente f r die Inhalte der logischen und technischen Systemarchitektur stammen berwiegend aus der Funktions und Komponentennetzwerk Architektur Die logische Systemarchitektur kann im E E Konzept Tool durch das Funktionsnetzwerk aus der Funktions Architektur abgebildet werden In Abbildung 3 8 ist ein kleiner Ausschnitt eines m glichen Funktionsnetzwerks f r das KFS aus Kapitel 2 dargestellt der inhaltlich aus Abbildung 2 1 abgeleitet ist Ein Logischer Sensor mit Namen Tempomathebel verf gt ber einen Sender Port mit dem Namen Benutzerkommando Der Port ist durch das Interface IF _Benutzerkommando getypt das die Besch
409. uft ber die gesamte Projektlaufzeit bis mehrere Jahre und unterteilt sich in die berlappenden Phasen key concepts Schl sselkonzepte refinement of concepts Konzeptverfeinerung design and implementation Design und Implementierung und optimisation amp deployment Optimierung und Verteilung In jeder Phase der Makroebene werden 3 4 Mikrozyklen nach dem Spiralmodell durchlaufen die immer mit der Bereitstellung eines Prototyps beendet werden Jeder neue Prototyp erweitert den letzten Prototyp wobei sich der Erweiterungs schwerpunkt nach der aktuellen Phase der Makroebene richtet Ein Nanozyklus umfasst im 50 Softwareentwicklung ROPES Prozess eine abgeschlossene Abfolge aus Design Codierung Ubersetzung und De bugging Fur Projekte bei denen der Softwareentwicklung eine langer andauernde Entwicklung von Hardwarekomponenten vorausgeht sieht ROPES ein alternatives Lebenszyklusmodell vor Abbildung 3 18 zeigt die Variante Sem Spira bei der der Mikrozyklus in Entwicklungsphasen eingebettet ist die das Gesamtsystem betreffen und nach dem Wasserfallprinzip durchlaufen werden Da diese Variante konform mit dem in Kapitel 3 1 2 vorgestellten Kernprozess der Systementwicklung ist eine genauere Einordnung erfolgt in Kapitel 3 2 2 g wird nur diese im weiteren Verlauf der Arbeit betrachtet 1 Jahre Spiral Part
410. ulz Hahsler Analysis Patterns Geyer Groupware Systeme Schulz et al 01 Analysemuster Buschmann et al Architectural Patterns Buschmann allgemein 98 Douglass Real Time Design Patterns Douglass 02 Eingebettete Steuerungs und Regelungssysteme Welch Marinucci Dynamic Resource Management Eingebettete Steuerungs Architecture Patterns Welch et al 02 und Regelungssysteme Architekturmuster Cross Proactive and Reactive Resource Allocation Eingebettete Steuerungs Patterns Cross 02 und Regelungssysteme Gamma et al Design Patterns Gamma et al 95 Buschmann et al Design Patterns Buschmann 98 Douglass Mechanistic Design Patterns Douglass 99 Eingebettete Steuerungs Designmuster und Regelungssysteme Buschmann et al Idioms Buschmann 98 allgemein C Pont Patterns for Time Triggered Embedded Sys Eingebettete Steuerungs tems Pont 01 und Regelungssysteme C 8051 Prozessor Homann Muster f r OSEK Homann 04 Eingebettete Steuerungs und Regelungssysteme C OSEK Betriebssystem Tabelle 3 8 Musterkategorien rl 3 Stand der Technik Die Beschreibungen von Analysemustern verwenden dagegen oft die Sprache eines Fachgebiets z B Lagerverwaltung oder die hier betrachteten eingebetteten Steuerungs und Regelungs systeme und sind somit tendenziell dom nenspezifisch Idiome beschreiben die L sung immer f r eine spezifische Programmiersprach
411. um eine parametrisierbare Klasse handelt Der UML Notation f r Klassen Templates w rde die rechte Darstellung in Abbildung 3 44 entsprechen nd makePersistent Operation a PersistentClass gt Pes ee u ee EBENE makePersistent Operation PersistentClass PersistentClass makePersistent makePersistent Abbildung 3 44 Ein Klassen Template in XDE links und in UML Notation rechts Einen weiteren Unterschied zwischen den Mustern in XDE und den UML Templates betrifft das Verschmelzungskonzept bei der Instanziierung von Mustern Wie im vorherigen Unterkapitel bereits erl utert liefert XDE in diesem Bereich f r die in Kapitel 3 2 4 e identifizierten M ngel der UML Templates entsprechende L sungskonzepte Der ebenfalls in Kapitel 3 2 4 e als sinn voll erachtete Gruppierungsmechanismus f r Template Parameter fehlt aber auch in XDE XDE wird im Laufe der weiteren Diskussion als Referenzwerkzeug verwendet Dementsprechend werden auch alle Konzepte dieses Werkzeugs rund um Templates bzw Muster bernommen inkl der Anteile die nicht konform mit den in Kapitel 3 2 4 e erlauterten UML Templates sind Dies bedeutet z B auch dass die Ellipsen Notation f r Templates beibehalten wird auch wenn es sich hier nicht um eine Kollaboration handelt Die in XDE verwendete Bezeichnung Pattern wird jedoch nicht bernommen und stattdessen der in der UML verwendete Begriff
412. umfeld einsetzen zu k nnen Auch zu der Einsetzbarkeit in anderen Dom nen kann an dieser Stelle keine allgemeine Aussage getroffen werden f r grunds tzliche berlegungen sei jedoch auf Kapitel 7 1 verwiesen Durch die M glichkeit eigene Muster zu beschreiben und Transformationsregeln mit Hilfe der beschriebenen Syntax selbst zu definieren kann POTAD jedoch grunds tzlich flexibel auf den eigenen Anwendungskontext angepasst werden Mit einer POTAD Transformationsregel kann ein optimiertes Design f r ein Analysemuster beschrieben werden Umfasst das Analysemodell mehrere Analysemusterinstanzen werden die Transformationsregeln seriell hintereinander ausgef hrt und erzeugen ein in Grenzen zu sammenh ngendes Designmodell Wie bei der Evaluierung in Kapitel 6 2 beobachtet wurde k nnen hier einzelne Muster zusammengefasst werden Au erdem k nnen einzelne Ana lysemuster Kombination neue Designmuster sinnvoll erscheinen lassen die durch die Trans formationsregeln nicht erzeugt werden k nnen Ein von POTAD erzeugtes Designmodell muss somit i d R in einem gewissen Umfang manuell nachbearbeitet werden Durch die Integration von Musterkompositionstechniken wie z B bei Yacoub et al 04 beschrieben k nnte diese Aktivit t evtl vereinfacht oder sogar automatisiert werden POTAD verwendet f r die unterschiedlichen Designvarianten eines Analysemusters Be dingungen die an beliebiger Stelle einer Transformationsregel vorkommen k nne
413. unden ist Auf diese Weise wird der abstrakte Signalfluss zwischen den beiden logischen Einheiten Tempomathebel und Tempomat Speedtronic ausgedr ckt lt lt FunctionalDevice gt gt Tempomathebel Soe q Benutzerkommando IF_Benutzerkommando l lt lt Analysis Function gt gt Tempomat Speedtronic SEs a SSS lt Benutzerkommando IF_Benutzerkommando Drehmoment_Sol l IF_Drehmoment l lt lt AnalysisFunction gt gt a Motorsteuerung Drehmoment_Soll_ Tempomat IF_Drehmoment Abbildung 3 5 Ausschnitt einer m glichen funktional Analysis Architecture f r das KFS F r die Darstellung der Inhalte aus der technischen Systemarchitektur bietet sich vor allem die Hardware Architecture an Abbildung 3 6 zeigt einen Ausschnitt einer m glichen Hardware Architecture f r das KFS der aus Abbildung 2 2 abgleitet ist Ber cksichtigt man dass die technische Systemarchitektur auch die Auslegung der K Matrix beschreibt so lassen sich z B auch in den Artefakten A location Model und Function Instance Mode viele Inhalte finden die der technischen Systemarchitektur hinzuzurechnen sind Die unterschiedlichen Artefakte der EAST ADL folgen somit der im Kernprozess verankerten Idee zwischen einer logischen und technischen Perspektive zu trennen unterteilen diese aber weiter Auf eine Prozessbeschreibung f r die Nutzung der EAST ADL wird in der Spezifikation ver zichtet Die Artefakte wurde
414. ung explizit ausgeklammert wurden F r die Betrachtungen im Rahmen dieses Kapitels wird f r den Begriff Modelltransformation die folgende an Sendall et al 03a angelehnte Definition verwendet Eine Modelltransformation ist ein automatisierter Prozess mit festen Regeln der eine Menge von Quellmodellen als Eingabe erhalt und eine Menge von Zielmodellen als Ausgabe produziert Diese allgemeingultige Definition ist allerdings nur als kleinster gemeinsamer Nenner aller An satze aufzufassen und beinhaltet noch keine der in Kapitel 3 1 4 bzw 3 2 5 genannten An forderungen wie beispielsweise die Variabilitat der Transformation in Abh ngigkeit von be stimmten Parametern oder die R ckverfolgbarkeit der Transformationsergebnisse Diese und weitere Aspekte werden vielmehr als konkrete Unterscheidungsmerkmale einzelner Ans tze betrachtet die im folgenden Abschnitt aufgef hrt und erl utert werden 3 3 2 b Unterscheidungsmerkmale In der Literatur werden Modelltransformationsans tze anhand bestimmter Merkmale verglichen Die folgenden Merkmale wurden aus verschiedenen Quellen zusammengetragen und ausgewahlt wobei die Hauptquelle ein Merkmalmodell von Czarnecki et al 03 ist Die Merkmale beziehen sich auf die Anforderungen an einen Modelltransformationsmechanismus und legen somit noch nicht die Art der Realisierung fest Unterschieden werden kann nach e Ziel oder Einsatzzweck Modelltransformationen k nnen f r die Optimierung vo
415. ung nach unten bewegt werden 3 Hebel kann in Pfeilrichtung nach vorne bewegt werden 4 Hebel kann in Pfeilrichtung nach hinten bewegt werden 242 5 Hebel kann in Pfeilrichtung nach innen gedr ckt werden 6 Statusanzeige leuchtet falls Speedtronic aktiv ist 2 Tempomat 1 Der Tempomat halt eine vorgegebene Geschwindigkeit uber eine beliebige Strecke oder Zeit Nur bei laufendem Motor aktiv Jede Geschwindigkeit ber 30 km h einstellbar Eingaben des Fahrers Hebel nach oben um aktuelle oder h here Geschwindigkeit zu speichern Hebel nach unten um aktuelle oder niedrigere Geschwindigkeit zu speichern Hebel nach vorne um Tempomat auszuschalten Hebel nach hinten um die zuletzt gespeicherte Geschwindigkeit abzurufen Hebel nach innen dr cken um zwischen Tempomat und Speedtronic zu wechseln Durch kurzzeitiges Bet tigen des Hebels nach oben bzw nach unten wird die gegenwartige Geschwindigkeit gespeichert und konstant gehalten Der Fahrer hat nun die M glichkeit durch Antippen des Hebels nach oben bzw nach unten die Geschwindigkeit um jeweils 1 km h zu erh hen bzw zu verringern Ein langeres Bet tigen des Hebels nach oben bzw nach unten hat zur Folge dass das Fahrzeug kontinuierlich beschleunigt bzw verlangsamt wird Sobald der Fahrer das Gaspedal durchdr ckt wird das Fahrzeug beschleunigt und beim Loslassen stellt sich wiederum die gespeicherte Geschwindigkeit ein Der Tempomat wi
416. unktionen im Fahrzeug haben regelungstechnischen Charakter Nach DIN 19226 1 DIN 94 wird eine Regelung wie folgt definiert Das Regeln die Regelung ist ein Vorgang bei dem fortlaufend eine Gr e die Regelgr e die zu regelnde Gr e erfasst mit einer anderen Gr e der F hrungsgr e verglichen und im Sinne einer Angleichung an die F hrungsgr e beeinflusst wird Kennzeichen f r das Regeln ist der geschlossene Wirkungsablauf bei dem die Regelgr e im Wirkungskreis des Regelkreises fortlaufend sich selbst beeinflusst Das folgende Blockdiagramm zeigt die beteiligten Komponenten und Gr en angelehnt an Sch uffele et al 03 Benutzer Umwelt e R Mess oder R ckf hrgr e e U Ausgangs oder Stellgr e des Reglers e W F hrungs oder Sollgr e e W Sollwert des Benutzers e X Regelgr e e Y Stellgr e e Z St rgr e n Der geschlossene Wirkungsablauf wird dadurch hergestellt dass es sich bei der F hrungs und der R ckf hrgr e um denselben Typ handelt Damit wird ein fortlaufender Vergleich von Soll und Istwert m glich und die Ber cksichtigung einzelner St rgr en berfl ssig 193 Ein ubliches Verfahren f r die Berechnung der Ausgangsgr e ist Proportional Integral Differential Control PID Pont 01 1 3 Struktur und Informationsfluss ReferenceValue Signal ClosedLoopController Class FeedbackValue Signal ControlOutputValue Sig
417. ur Ein solches Mapping existiert z B zwischen den Kunden anforderungen und der Komponentennetzwerkarchitektur und tragt der Tatsache Rechnung dass nicht in jedem Projekt die Funktionalitaten und Funktionsarchitektur modelliert werden Im Folgenden sind die Inhalte der einzelnen Modelle kurz erl utert e Kundenanforderungen Die Kundenanforderungen werden in Form von Features aus einem Anforderungsmanagementwerkzeug importiert Sie fungieren als Ausgangspunkt f r 36 Systementwicklung die Mappings um alle weiteren Modellelemente bis auf die Anforderungen zuruckverfolgen zu konnen e Funktionalitaten Architektur Ein Modell um Wirkketten von Features zu analysieren Die dahinter stehende Methode wurde insbesondere mit der Zielstellung entwickelt unter schiedliche Architekturen die ahnliche Funktionen realisieren systematisch vergleichen zu konnen e Funktions Architektur Beschreibt ein Netz aus Funktionen logischen Sensoren und Aktuatoren in dem Datenelemente und Operationsaufrufe ausgetauscht werden Das Metamodell orientiert sich an dem Wrtua Function Bus von Autosar e Komponentennetzwerkarchitektur Beschreibt die Hardware von E E Komponenten und Verbindungen Bussystem und konventionelle Verbindungen die diese verbinden In diese Architektur integriert ist ein Modell in dem die Busbotschaften und die darin enthaltenen Signale und Routingtabellen von Gateways modelliert werden Bzgl des internen Aufbaus eines Ste
418. urce Class OutputValueDrain CompressorControlValve FeedbackValue ControlOutputValueDrain Class eee Source TemperatureS ensor ReferenceValue Desired __ FeedbackValueSource Class te Temperature N ClosedLoopControl_ClimateControl ae NM ClosedLoopControl DesiredTemperature CompressorSetValue TemperatureDirector CimateController ssssatesscszesssapssiteneotecgesdersentsedsedeovied E gt CompressorControlValve CurrentT emperature Te ratureSensor He bind Bind ConcreteS ubscriber InputRepository updateMethode set DesiredT emperature Publisher T emperatureDirector Subscriber Subscriber bind Bind ConcreteS ubscriber InputRepository updateMethode set CurrentT emperature Publisher T emperatureS ensor _DesiredTemperature _CurrentTemperature _CurrentTemperature bind Bind Repository InputRepository Data DesiredTemperature C nuten CurrentT emperature Client ClimateController_Master gt Throttle 0 1 _InputRepository bind Bind ControlLoop ClimateController_ControlLoop Sensor Input Repository Actuator CompressorControlValve Sensor get n Method getDesiredTemperature getCurrent Temperature Actuator_setMethod setCompressorSet Value Context ClimateController Master _ClimateController_ControlLoop bind Bind Strategy ClimateController_Strategy Concrete Strategy Winter Summer Algo
419. usters die Verschmelzung mit dem existierenden Modell individuell gesteuert werden Im Rahmen der Expansion werden Elemente des Musters zu den tats chlichen Parametern und dem foot Context hinzuf gt Bez glich des Verschmelzungsverhaltens kann f r jedes Musterelement bei der Musterdefinition eine der folgenden Optionen gew hlt werden Merge verschmelzen Preserve bewahren Replace ersetzen und Wo Copy keine Kopie Standardm ig wird Merge verwendet Bis auf die Option Wo Copy haben diese Einstellungen nur Auswirkungen wenn bei der Ver schmelzung eine Kollision auftritt Eine Kollision liegt in diesem Kontext vor wenn ein Element aus dem Muster denselben Namen denselben UML Typ und denselben Kontext dieselbe Vater und Kindelementstruktur wie das Zielelement hat Eine Ausnahme bilden Kollisionen zwischen formalen und tats chlichen Parametern Diese Elemente werden bei der Option Merge auch verschmolzen wenn keine Namensgleichheit gegeben ist In Tabelle 3 10 werden die Verschmelzungshinweise erl utert 94 Softwareentwicklung Merge Bei einer Kollision werden alle Merkmale des Musterelements die nicht den Default Wert haben auf das Zielelement bertragen Dabei wird f r jedes Merkmalpaar nach folgender Fallunterscheidung vorgegangen 1 Das Merkmal des Musterelements hat den Default Wert Das Zielelement wird nicht geandert Das Merkmal des Musterelements hat nicht den Default Wert Das Merkmal des Zielelements b
420. von Elementen gibt es in dieser Realisierung nicht F r die Realisierung der Iterationsfunktion kann einem mengenwertigen Ausdruck das Schl sselwort elements angef gt werden das beim Aufruf von Hilfsregeln oder bei einem Argument einer Template Instanziierung verdeutlicht dass ber diese Menge iteriert werden soll F r eine komfortablere Handhabung von Mengen wurde zudem die M glichkeit eingef hrt Elemente und oder Mengen ber das Symbol zu vereinigen F r die Namensermittlung sind verschiedene M glichkeiten vorgesehen e Der Programmierer der Transformationsregeln gibt den Namen vor indem er einen String in Anf hrungszeichen gefasster Text als Argument angibt e Der Name wird von einem Element vorgegeben das bereits uber den Variablennamen einer Template Instanz im Analyse oder Designmodell ansprechbar ist In diesem Fall kann der Name ber lt Variablenname gt lt Parametername gt aufgel st werden e Der Benutzer muss eigene Namen vorgeben Dazu wird die Methode getNames lt Aufforderungstext gt lt Anzahl gt bereitgestellt die insgesamt Anzahl mal ber einen Benutzerdialog einen String abfragt Wird als Anzahl 1 bergeben wird die Abfrage 162 Modelltransformationssprache in einer offenen Schleife wiederholt bis der Benutzer sie beendet Der Benutzer kann somit beliebig viele Namen eingeben e Mit der Methode getNamesByMachineQuery lt Anfrage gt wird analog zu MachineQuery eine m
421. von Plug ins f r Modelltrans formationen geschlossen werde Die hier zur Verf gung gestellte MDA Toolkit API bietet unter anderem die gesuchten Methoden um Muster zu binden und zu expandieren Des Weiteren erm glicht das Toolkit auch die komfortable Programmierung von Transformationen als weitere Plug ins die von einer Vorlage abgeleitet werden und auf zahlreiche Hilfsmethoden zugreifen 167 5 Prototypische Umsetzung k nnen Ist das MDA Toolkit installiert m ssen solche Transformationen nur noch als Plug in exportiert und in ein spezielles Verzeichnis kopiert werden damit sie innerhalb der Benutzer oberflache von XDE als Menueintrag auftauchen und gestartet werden k nnen F r die Trans formationen lassen sich auf einfache Weise Parameter definieren die in einem automatisch generierten Dialog vor deren Start vom Benutzer abgefragt werden Die Implementierung einer Transformation kann beliebigen Java Code enthalten der insbesondere auch auf das RXE und MDA Toolkit API zur ckgreifen kann Abbildung 5 1 zeigt im schematischen berblick wie das realisierte XDE Plug in aufgebaut ist Diese Grundarchitektur wurde in Zusammenarbeit mit einem Diplomanden entwickelt Teile der folgenden Erl uterungen lehnen sich daher stark an die in der entsprechenden Diplomarbeit Buchwald 05 gemachte Dokumentation an Rational XDE Abbildung 5 1 Schematische Darstellung der Architektur des XDE Plug ins Die Klasse POTAD Transformation r
422. wird angef hrt dass die L sung rein deklarativ sehr pr zise und durch Verwendung vorhandener Technologien im Umfeld von Attributgrammatiken einfach und effizient implementierbar ist Bei dem im Beitrag geschilderten Beispiel handelt es sich um die haufig diskutierte Transformation die eine UML Klasse mit Attributen in eine Tabelle einer relationalen Datenbank transformiert Weitere Anwendungsszenarien waren bislang auf Migrationen beschr nkt so dass keine Erfahrungen f r die Einsetzbarkeit des Ansatzes f r komplexere Transformationen vorliegen Erweiterung der Object Constraint Language OCL Viele der Einreichungen zu QVT siehe Kapitel 3 3 3 st tzen sich auf Teile der OCL siehe Kapitel 3 2 1 beschr nken sich jedoch dabei auf Abfragen oder die Formulierung von Be dingungen innerhalb einer Transformation Es gibt dar ber hinaus aber auch Ans tze die die OCL direkt durch Erweiterungen zu einer Transformationssprache ausbauen In Pollet et al 02 wird vorgeschlagen das Ergebnis einer Transformation mit Hilfe von Vor und Nachbedingungen darzustellen die als OCL Constraints auf Metamodell Ebene ausgedr ckt werden Um diesen deklarativen Teil einer Transformation um eine Ausfuhrungssemantik zu erg nzen wird eine Erweiterung der OCL um Actions als M glichkeit gesehen Eine so er weiterte OCL h tte nach Ansicht der Autoren den Vorteil dass keine weitere Sprache f r Modelltransformationen hinzukame und bestehende Mechanisme
423. ysemuster zu der Phase Object Analysis In der Beschreibung der ROPES Analysephase werden die Analysemuster zwar nicht als Artefakte genannt im Grundlagenteil zu den Mustern findet sich jedoch ein Hinweis dass Analysemuster Kandidaten f r das Object Analysis Model sind Douglass 99 Zu den Aufgaben bei der Er 74 Softwareentwicklung stellung dieses Modells gehort die Modellierung der wesentlichen Konzepte und Objekte die fur das korrekte Verhalten des Systems notwendig sind Entsprechend unterstutzen Analysemuster den Entwickler dabei Konzepte die immer wieder beschrieben werden mussen in geeigneter Weise zu modellieren Der bekannteste Beitrag zu Analysemustern ist das Buch Analysis Patterns reusable Object Models von Martin Fowler Fowler 97 Er definiert ein Analysemuster als eine Idee die in einem praktischen Kontext hilfreich war und dies wahrscheinlich auch in einem anderen sein k nnte Ein entscheidendes Abgrenzungskriterium zu den Designmustern sieht Fowler in der Eigenschaft dass Analysemuster keine Softwareimplementierung beschreiben Die von Fowler beschriebenen Muster beschreiben Sachverhalte auf der Analyseebene aus den Bereichen Buchhaltung Handel und Beziehungen innerhalb von Organisationen Abbildung 3 28 zeigt das Muster Accounting Transaction aus dem Bereich Buchhaltung enhy 2 Accounting Account 3 Transaction 1 3 amount Money sum of amounts of entries equals 0 Abbildung 3 28 Ana
424. zer das KFS am PC bedienen kann Durch die Bereitstellung eines virtuellen Busses lasst sich die technische Systemarchitektur mit zwei Rechenknoten abbilden Ferner enth lt die Simulation f r den Geschwindigkeitssensor ein Um 13 2 Fallbeispiel Kombiinstrument und Fahrfunktionen gebungsmodell Regelstreckenmodell so dass die Fahrfunktionen mit plausiblen Geschwindig keitswerten versorgt werden konnen Letztendlich stellt der Simulator eine Umgebung zur Verfugung in der die Hardware der technischen Systemarchitektur Uber eine Programmier schnittstelle virtuell nutzbar gemacht wird In diesen Rahmen hinein konnen die eigentlichen Softwarefunktionen des KFS implementiert werden deren Entwurfsmethodik im Fokus dieser Arbeit ist Anzeige der aktuellen a CruiseControl Ed Anzeige von Geschwindigkeit Fahrzeuginformationen im Display Computer Multifunktionsdisplay Tageskilometer Gesamtkilometer EHE eWartungsanzeige Jump from menu to menu Tageskilometer i 5 8 km Jump in menu Fehlermeldungen Cockpitleuchten Gesamtkilometer nu ca Werkseinstellungen Schaltprogramm IL 5 k n co Ee Motorwarnleuchte Reset Men steuerung Tempomatmodus 1km h CruiseControl S peedtronic Manual Control Environment Steigung der Speedlimiter r Brake slope Strecke 10 km h 4 m E amp bestimmen Tempomatmodus Tempomat ausschalten Simulate Malfunction Speedlimiter da P Behavior PENET SIMmUNErEN i T
425. zt die korrigierenden Ma nahmen um Diese Trennung muss sich nicht in der Implementierung widerspiegeln Hier kommt es vor dass alle drei Klassen durch eine Funktion implementiert werden 5 3 Struktur und Informationsfluss Detector Class Corrector Class LocalFaultHandler Class CorrectiveAction Signal LocalFault Signal Actuator Class ze __DetectorCorrecto r_Actuator gt RR a 7 LocalFaultHandler lt LocalFault gt lt CorrectiveAction gt Detector Actuator a Corrector monitors gt lt provides corrective 7 actions for e Detector Sendet nach der Entdeckung eines Fehlers oder einer St rung LocalFault an LocalFaultHandler 202 e LocalFaultHandler Wendet nach Erhalt von FaultIndication eine lokale Sicherheitslogik an und versendet gegebenenfalls CorrectiveAction an Corrector e Corrector F hrt nach Erhalt von IndicateCorrectiveAction korrigierende Ma nahmen durch e Actuator der Aktuator der berwacht wird 5 4 Quelle Verwandte Muster Das Muster stammt von Konrad et al 04b ist in der hier gezeigten Fassung aber f r die berwachung eines Aktuators spezialisiert und hinsichtlich der Signale und der Musterpara meter pr zisiert worden 5 5 Beispiel Das Beispiel zeigt die berwachung einer Drosselklappe Throttle Wird durch die Erkennungs funktion ThrottleMalfunctio
426. zur Template Bindung aus der UML2 4 2 2 Notation und Werkzeugumsetzung Nachdem das Metamodel und die Semantik der Elemente erl utert wurden soll nun die ent sprechende graphische Notation vorgestellt werden Diese wurde so gew hlt dass sie auch mit Modellierungswerkzeugen nach dem UML 1 4 Standard dargestellt werden kann Die Notation ist au erdem stark an die Darstellung von Patterns in Rational XDE siehe Kapitel 3 2 4 f angelehnt da die prototypische Umsetzung von POTAD siehe Kapitel 5 auf diesem Werkzeug aufsetzt Im Folgenden wird bezugnehmend auf die Elemente aus dem Metamodell des vor herigen Unterkapitels die Notation anhand eines Beispiels erlautert Abbildung 4 8 zeigt eine Template Definition am Beispiel des Musters Strategy Gamma et al 95 Ein Template wird mit einer gestrichelten Ellipse dargestellt Dieses Symbol wird in der UML f r Kollaborationen verwendet hat im Kontext von POTAD aber ausschlie lich die durch das 148 Context ce lt S trategy gt Strategy ss A contextInterface algorithminterface Context Class Strategy Class ConcreteStrategy 1 Class _ algorithminterface Operation ConcreteStrategy Strategy Bee ne aa algorithmInterface Abbildung 4 8 Eine Template Definition am Beispiel des Strategy Musters Muster Metamodell aus dem vorherigen Unterkapitel beschriebene Semanti

POTAD - Digitale Bibliothek Thüringen

Contents

Download Pdf Manuals

Related Search

Related Contents

POTAD - Digitale Bibliothek Th&uuml;ringen

Contents

Download Pdf Manuals

Related Search

Related Contents

POTAD - Digitale Bibliothek Thüringen