Home

Dokument 1 - Dokumentenserverhosting der SUB

1. History getDepthOfUndo int getDepthOfRedo int lt lt Interface gt gt IHistory undoable bool redoble bool undo redo done llInstruction ins lt lt Interface gt gt IInstruction Abbildung 11 Teststruktur der History Komponente Auch f r die History Komponente wurden Testf lle erdacht die in Tabelle 9 aufge f hrt werden Die Auflistung beschreibt Testf lle die aus der Sicht von au en auf die Komponente also der Blackbox Sicht entstanden sind Testfall Arrangieren Agieren Best tigen 1 Leerer Undo Stack undo Exception 2 Leerer Undo Stack undoable ist false 3 DummyCommand ausf hren undo DummyCommand undone ist true 4 Leerer Redo Stack redo Exception 5 Leerer Redo Stack redoable ist false 6 DummyCommand ausf hren redo DummyCommand redone ist true undo ausf hren Tabelle 9 M gliche Testf lle f r die History Komponente aus Blackbox Sicht Der letzte Testfall in Tabelle 9 l sst sich zum Beispiel auch leicht zu einem Test f r die Robustheit erweitern Bei einem einzigen Element auf dem Stack m ssten die Flags undoable und redoable abwechselnd true sein wenn undo und redo im Wechsel ausgef hrt werden 3 2 4 DESIGNENTSCHEIDUNGEN Die Entscheidung f r die Herangehensweise mit dem Command Muster und den Stacks soll in diesem Abschnitt begr ndet werden F r das Zur cknehmen von Aktionen gi
2. a Ein Fenster ffnen in dem die programmweiten Einstellungen ver n In Abbildung 5 ist die Programmoberfl che vollst ndig abgebildet Zur Zeit der Aufnahme ist ein Modell ge ffnet Die windloads Komponente ist geladen und de ren Oberfl chenelemente werden in einer Registerkarte dargestellt Windloode Ge Wind Directions 135 00 Averaging Time ECH Reference Time 10 00 5 Reference Windspeed 29 00 mis Reference Hecht 10 00 m Projection Length Groth ii Te Teen me ee e ie d Da Zei Dei Wei Dei Zu jaz mmama Greular Hollow 2 10 21 00 0 50 0 00 0 00 0 00 0 00 0 00 0 00 0 00 4 dep sm nenns jones sa al E as ea amp u EES e Ee a e a a a n ees Torr 041 169 osol 000 lest osal sossool lte EECHER fo warn 20640125 oreder rohe 0a 100 at eat emt test ano osol ooo BE Ee s rep narm 206125 Orar panow oaf Leaf asof ooaj 2829 2830 oaz zeas eass en EECHER EE oal 1al asol ood asal EE EREECHEN EE EE O E EE 1fRr6 wem 200 120 10 same ao 02 0751 200 000 stael s 1e osol eraoo 19836 106 36 0 00 E Jeom 2001120 10 sgee nahen 02 040 E 000f sa s 2e ERC Tore som 2001120 10 Suse aka ozs sel zool ocol srie s116 1a AHE eo 2001120110 EE 15a mam 2001120110 squre EE fr am zo0120110 saure nal ozs oaf zo __osef ar s 21 16 oso sraao 19635 106 36 o oo GEES EES EECHER EES EE EE ETC REECH EE EECH See 200120110 Saume hates 02 es arat arae oal amasol roeas asee
3. ao Rne morm 200120010 saure Halow ozs oss 116 s116 osol sraao 6 36 19636 oaol leen 200120110 Suare ton At stae ool sranool 18638 196381 omol A E e E T Cl aal 0 60 8780 00 ax O RHP warm 200 120x10 Square Hollow or el 3116 ele el ez oo Zlert warm 200 120x10 Square Hollow 023 Gi a 3146 sel 0 s0 8780 00 196 36 196 36 _ 0 00 32 RHP warm 200x120x10 Square Hollow az Go nn oao BE EE r zem 200x120x110 Square mes 0 23 L E EET Sr 196 36 296 36 oa RHP morm 20012010 HERE II RHP puar 200120110 Suare HEEN S RHP warm 20012010 Square Halow az 075 ST RHP warm 200x120x10 Square Hollow aal 0 75 O RHP warm 200x120x10 Square Hollow al 0 43 lg warm 200x120x110 Square Hakm cr 043 EIER BT 2 jur um el eener onj Sei S ululo EIEIE ajaja Di Abbildung 5 Grafische Benutzeroberfl che des Straus Multitools Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur 2 3 7 INITIALIZATION Die Initialization Komponente bernimmt die Herstellung des Settings Sie instanziiert alle Komponenten mit Ausnahme von Mission Komponenten und bergibt ihnen jeweils Referenzen auf andere Komponenten die sie ben tigen Abbildung 6 zeigt den Startbildschirm der w hrend der Arbeitszeit der Initiali zation Komponente sichtbar ist Im Anschluss startet sie die Ambience Komponente OVERDICK D Straus Multito
4. der Laufzeit des Programms keine neuen Paare entstehen 2 3 2 HISTORY Die History Komponente erm glicht generell Undo und Redo Funktionen REQ 057 Da diese Funktion die Sicherheit der Daten zur Programmlaufzeit unter st tzt ist die History Komponente ebenfalls der Infrastruktur Schicht zugeordnet F r die Umsetzung der Komponente soll das Command Muster Gamma et al verwendet werden Dieses Muster beinhaltet dass ein Kommando als Objekt mo delliert wird Damit besteht die M glichkeit dem Kommando Objekt Informatio nen mitzugeben wie das Kommando r ckg ngig gemacht werden kann vgl Freeman et al 2005 F r die History Komponente werden zwei Schnittstellen ben tigt Die Schnittstelle die beschreibt wie ein Kommando auszusehen hat und die Schnittstelle f r die Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur Benutzung der History Komponente von au en Aufgrund einer Doppeldeutigkeit des Begriffs Command in NET wird ein Kommando in der Implementierung immer mit Instruction bezeichnet Das IInstruction Interface schreibt folgende Methoden vor void execute bool undo bool redo Damit kann jede Instruction die das Interface implementiert ausgef hrt werden und anschlie end r ckg ngig gemacht und wieder hergestellt werden Die Verwaltung dar ber welche Instruction aktuell diejenige ist die r ckg ngig gemacht werden soll wenn de
5. Ist dies nicht der Fall soll die neue Version des Programms installiert werden Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang amp sp ter RE REQ 013 Lizenz als Programmschutz Das Programm soll nur mit einem Passwort oder einer Lizenz benutzbar sein um den Nutzerkreis auf Mitarbeiter von Overdick einzuschr nken D Durchstich FLO KO REQ 057 Undo Redo nderungen an der Modelldatei oder angezeigten ungespeicherten Daten in Ta bellen sollen r ckg ngig gemacht und ebenso wieder hergestellt werden k nnen A 1 3 ANFORDERUNGEN AN PERFORMANCE In diesem Kapitel werden Aussagen zur gew nschten Performance des Straus Multitools gemacht Da es in diesem Programm kein zeitkritisches Verhalten gibt geben die Aussagen nur eine Richtung vor Ob die Programmperformance und die Reaktivit t den W nschen der Benutzer entsprechen muss in einer Evaluation ermittelt werden REQ 015 Ladezeiten 2 ZE Das Laden von Datenmengen von der Festplatte oder aus dem Arbeitsspeicher soll so programmiert werden dass auch bei gro en Mengen die Oberfl che be nutzbar bleibt Dabei kann zwischen der Handhabung gro er Datenmengen unterschieden wer den und der berlegung der Notwendigkeit einer vollst ndigen Darstellung f r den Anwender In vielen F llen mag vielleicht eine Zusammenfassung der Da tenmenge mehr helfen F r die Handhabung gro e
6. das tempor re Verzeichnis f r die Straus API und die Konfigurationsdatei 3 Symbole stammen von http www creativefreedom co uk icon design info free windows 7 icons und sind frei verf gbar Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang A 2 GLOSSAR DER FACHDOM NE Attribut Beam Brick Finite Elemente Methode Knoten Last Lastfall Lastfall Kombination Load Load Case Load Case Combination Member Modellelement Node Plate Platte Property Stab Strand Straus7 Jedes gt Modellelement hat eine bestimmte Konfiguration die die Eigenschaften der Elemente festlegt Beispielsweise definiert ein Stab Attribut eine bestimm te Dicke ein Material und ein Profil des gt Stabs Eine bestimmte Konfiguration wiederholt sich innerhalb eines Modells sehr h ufig weshalb eine bestimmte Konfiguration als Attribut gespeichert wird Aus diesem Grund ist jedem Element ein Attribut zugeordnet Stab Dreidimensionales Modellelement das von mindestens acht Knoten defi niert und begrenzt wird Ein numerisches Verfahren zur L sung von partiellen Differentialgleichun gen Sie ist ein weit verbreitetes modernes Berechnungsverfahren im Ingeni eurwesen und ist das Standardwerkzeug bei der Festk rpersimulation Verbindungselemente zwischen anderen Modellelementen wie St ben oder Platten Eine ver nderliche oder bewegliche Einwirkung auf ein
7. lt Key gt gravity lt Key gt lt Value gt z lt Value gt lt Item gt lt Configuration gt Abbildung 7 Die Datei configuration xml Die XML Datei wird beim Beenden des Programms in dem Zustand hinterlassen der als letztes im Programm hergestellt wurde Falls Werte ver ndert wurden sind diese gespeichert Die in Abbildung 7 gezeigten Schl ssel Wert Paare werden in dieser Form vom Straus Multitool verwendet Abgesehen von gravity und scratchpath gibt es Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten aktuell noch keine weiteren Schl ssel in der Konfigurationsdatei Dies wird sich aber mit der Erweiterung des Programms ndern wenn die Einstellungen f r hin zukommende Module angelegt werden 3 1 2 STRUKTUR Die innere Struktur der Configuration Komponente ist in Abbildung 8 als UML Schema dargestellt Die Komponente setzt sich im Wesentlichen aus drei Klassen zusammen Der Klasse Configuration die die Schnittstelle zu anderen Modulen implementiert die Klasse XmlConfigurationManager die sich um die Verbindung mit der XML Datei k mmert diese liest schreibt und interpretiert und die Klasse Con figurationItem mit der ein Schl ssel Wert Paar modelliert ist Diese drei Klassen sind der funktionale Kern der Komponente Eine vierte Klasse wrongFormatExcepti on die von Exception erbt dient der passenden Benachrichtigung des Anwenders wenn
8. ndert wird nderungen die nicht gespeichert wurden werden bei Programmende verworfen 3 6 AMBIENCE KOMPONENTE Die Ambience Komponente ist enth lt die zu Grunde liegende Oberfl che f r das Programm Sie beinhaltet die grundlegenden Steuerelemente und ruft weitere Programmteile auf Au erdem ist sie f r Benutzerdialoge im Fehlerfall zust ndig Wenn das Straus Multitool auch mit Straus Ergebnisdateien arbeiten k nnen soll vgl REQ 021 und Abschnitt 3 5 4 soll hierf r soll keine neue Oberfl chenstruk tur geschaffen werden Die Dateien sollen ber die vorhandenen Buttons ge ffnet und geschlossen werden k nnen Die hinzukommende Ablauflogik wird ber den Kontext gel st in dem die Befehle verwendet werden 3 6 1 VOR UND NACHBEDINGUNGEN Die Ambience Komponente wird von der Initialization Komponente als letztes ini tialisiert und erwartet Referenzen auf drei Objekte von denen jeweils eins IHisto ry IConfiguration und IModelManager realisiert Wird das Programm geschlossen beendet die Ambience Komponente die Verbindung zur Straus API nachdem sie eine eventuell ge ffnete Straus Datei geschlossen hat 3 6 2 STRUKTUR Das Klassendiagramm der Ambience Komponente ist in Abbildung 23 dargestellt Durch die Entscheidung WPF f r die Beschreibung der Oberfl che einzusetzen entspricht das Klassendiagramm nicht dem UML Standard Im Klassendiagramm wurde f r das Configurationwindow keine getrennte Darstellung gew hlt da
9. um weitere Paare zu erg nzen muss wenn er diese benutzen m chte Schl ssel nicht als XML Tag modelliert In der Konfigurationsdatei h tte der Schl ssel z B gravity auch direkt als XML Tag modelliert werden k nnen Al SO lt gravity gt z lt gravity gt anstelle von lt Item gt lt Key gt gravity lt Key gt lt Value gt z lt Value gt lt Item gt Die gew hlte Variante erlaubt aber die Items um weitere Werte zu erweitern Zum Beispiel um eine textuelle Beschreibung hinzuzuf gen die dynamisch in die Oberfl che des Konfigurationsfensters eingebunden werden kann Auch f r die Umsetzung der Anforderung REQ 007 die das Speichern einer Menge von zusammenh ngenden Werten als Parameter Konfiguration fordert ist diese Notation sinnvoll Mit der gew hlten Variante steht auch einer m glichen Einf hrung der dynamischen Moduleinbindung nichts im Weg Die Configuration Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Komponente m sste nur um einige Funktionen erweitert werden die es erm gli chen die Konfigurationsdatei um neue Eintr ge zu erg nzen und die komplexe ren Daten zur ckzugeben Nur string als Datenformat f r Keys und Values Die M glichkeit die Schl ssel Wert Paare in verschiedenen Zahlenformaten zu speichern h tte die Schnittstelle der Komponente auf ein Vielfaches vergr ert Au erdem werden die Werte in der Datei als Text abgelegt was
10. 3 3 3 TESTBARKEIT Diese Komponente ist nicht auf einem herk mmlichen Weg mit Unit Tests ber pr fbar Die Fehlerstring Methode greift direkt auf die API Funktionen zu Sie k nnte mit dem Moles Framework Microsoft Research getestet werden Die bei den anderen Modules geh ren direkt zur API deshalb werden hier keine Tests an gesetzt Die Klasse ApiException enth lt keine Logik und muss deshalb nicht getes tet werden Die Struktur der straus7 Komponente beeinflusst aber ganz entscheidend die Testbarkeit aller Objekte die ber sie auf die Straus API zugreifen Deshalb wer den im nachfolgenden Abschnitt Designentscheidungen dokumentiert die inner halb der straus7 Komponente getroffen werden mussten die aber auch alle ande ren Komponenten auf der Dom nenschicht betreffen 3 3 4 DESIGNENTSCHEIDUNGEN Es ist wichtig f r die Testbarkeit der Komponenten die die straus7 Komponente verwenden dass sie vom direkten Zugriff auf das Fremdsystem isoliert werden k nnen Dies spr che f r die Einf hrung eines Interfaces das den Zugriff auf die Straus API beschreibt Dies ist jedoch nicht m glich weil die Dateien die f r die Nutzung der API eingebunden wurden Modules enthalten und diese keine Inter faces implementieren k nnen Da Modules auch weder instanziiert noch beerbt werden k nnen entf llt damit auch die n chste M glichkeit f r das Isolieren der Komponente Die Methode Extract and Override nach Roy Osherove she
11. 3 5 2 STRUKTUR Die ModelManagement Komponente besteht nur aus einer Klasse und zwei Interfaces siehe Abbildung 21 Die Unterscheidung der beiden Interfaces dient dem Zweck dass andere Komponenten mit unterschiedlichen fachlichen Anforderungen auf die Klasse ModelManager zugreifen Die Ambience Komponente nutzt das Interface Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten IManageModel sie ist die einzige die das ffnen Speichern und Schlie en von Mo dell Dateien veranlasst Die Mission Komponenten nutzten das Interface IModel ber das sie die ID der ge ffneten Modelldatei erfragen k nnen die sie f r die Kommunikation mit der Straus API ben tigen Dar ber hinaus k nnen sie abfra gen ob die API bereits initialisiert wurde und k nnen das Feld modified auf true setzen sobald sie das Modell im Arbeitsspeicher ver ndert haben vgl Abschnitt 2 35 ModelManagement lt lt Interface gt gt IManageModel opened bool lt lt Interface gt gt modified bool IModel apilnitialized bool openModel String filename bool saveModel bool saveModelAs String filename bool closeModel bool ModelManager modelid int config IConfiguration St7lnit St7Release bool St7APlVersion string storeUnits restoreUnits Abbildung 21 Klassenstruktur der ModelManagement Komponente Die Ambience Komponente kann auf das
12. 6 EFFIZIENZ B Es wurden von Overdick keine quantitativen Vorgaben zur Effizienz gemacht allein eine hohe Reaktivit t gef hlte Performance wurde vorausgesetzt Im Vergleich zum Straus API Tool konnte f r das Straus Multitool eine markante Steigerung der Reaktivit t erreicht werden indem pro Aufgabe nur die Daten aus der Modelldatei gelesen werden die in diesem Kontext ben tigt werden Es wird kein alles umfassendes Strukturmodell in Objekten abgebildet Dadurch verteilt sich die Zeit des Einlesens auf unterschiedliche Momente F r den Benutzer be deutet dies dass die Wartezeit f r das ffnen eines Modells sich von 4 8 Sekun den je nach Modellgr e auf unter eine Sekunde verringert hat abh ngig von Rechenleistung und Modellgr e Damit gibt es im Straus Multitool keine sp r bare Unterbrechung des Arbeitsflusses Insgesamt k nnen die Anforderungen an die Effizienz des Straus Multitools also als erf llt angesehen werden 5 2 ZUKUNFT DES PROJEKTS Im weiteren Entwicklungsverlauf muss die geforderte Funktionalit t noch voll st ndig implementiert werden Dazu muss zun chst das Anforderungsdokument in diesen Bereichen genauer spezifiziert werden da die momentane Version nur Ideen von den Funktionen skizziert Einige Aufgaben sind dar ber hinaus zu erf llen e Die Benutzeroberfl che sollte durch das Ingenieursteam abschlie end eva luiert werden e Es m ssen ausf hrliche Testf lle erdacht und implementie
13. Erlernbarkeit der Sprache eine wichtige Rolle damit m gliche Neuzug nge des Entwicklerteams m glichst schnell Verst ndnis f r den vorhandenen Code erlangen k nnen Das Unternehmen TIOBE Software stellt online einen Index ber die Verbreitung der einzelnen Programmiersprachen zur Verf gung Der Index wird monatlich neu berechnet anhand der Trefferzahl die popul re Suchmaschinen zu diesem Thema erzeugen Hier steht C in 2011 12 st ndig unter den ersten f nf Sprachen zusammen mit Java C C Objective C und PHP vgl Abbildung 3 Tiobe Programming Community Index Tiobe Programming Community Index 275 25 0 22 5 20 0 17 5 15 0 12 5 10 0 75 Normalized fraction oftotal hits 5 0 2 5 0 0 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 Time Java C Objective C Visual Basic Perl zs CC C PHP Python JavaScript Abbildung 3 Tiobe Programming Community Index TIOBE Software Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur Visual Basic NET hingegen findet sich z B im Februar 2012 auf Platz 16 aufge r ckt von Platz 24 der Rangordnung TIOBE Software Hinzu kommt dass C mit Kenntnissen einer der anderen Sprachen der Top5 sehr leicht zu lernen ist weil die Syntax sich nicht stark unterscheidet Die Ordnungsm igkeit also die Erf llung von anwendungsspezifischen Nor men stellt kein
14. F higkeit der Software ihr Leistungsniveau unter festge legten Bedingungen ber einen festgelegten Zeitraum zu bewahren Benutzbarkeit Aufwand der zur Benutzung erforderlich ist und indi viduelle Beurteilung der Benutzung durch eine festgeleg te oder vorausgesetzte Benutzergruppe Effizienz Verh ltnis zwischen dem Leistungsniveau der Software Performance und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen nderbarkeit Aufwand der zur Durchf hrung vorgegebener nde rungen notwendig ist nderungen Korrekturen Ver besserungen oder Anpassungen an nderungen der Umgebung der Anforderungen und der funktionalen Spezifikationen bertragbarkeit Eignung der Software von einer Umgebung in die ande re bertragen zu werden Austauschbarkeit M glichkeit diese Software anstelle einer spezifizierten anderen in der Umgebung jeder Software zu verwenden sowie der daf r n tige Aufwand Tabelle 1 Qualit tskriterien der DIN ISO 9126 Starke 2011 In den folgenden Abschnitten wird auf die einzelnen Kriterien n her eingegangen Alle genannten Kriterien werden genauer beschrieben ihre Relevanz f r die zu entwickelnde Anwendung wird beurteilt und es wird erl utert welche Ma nah men ergriffen werden um das Qualit tskriterium zu erf llen Die Relevanz der Kriterien wird ber eine Bewertungsskala von A wichtig ber B mittel bis zu C weniger wich
15. Hinzuf gen eines Lastfalls mit neuem Namen m glich langfristig soll es an dieser Stelle auch die M glichkeit geben Lasten zu einem bestehenden Lastfall hinzuzuf gen ApplyLoads N R k lt use gt gt Loadcases l LoadcaseViewModel loadcases List lt Loadcase gt name string read int modelid S number int l p lt use gt gt I beams List lt Beam gt modelid int applyLoadsToNewLoadcase string loadcaseName applyLoadsToLoadcase int loadcase Abbildung 19 ApplyLoads UserControl und beteiligte Klassen In Abbildung 19 ist die Klassenstruktur hinter dem UserControl ApplyLoadsToModel dargestellt Sie ist schon so ausgelegt dass bestehende Lastf lle aus dem Modell ausgelesen und angezeigt werden k nnen Aktuell greift die Oberfl che auf die Methode applyLoadsToNewLoadcase zu um einen neuen Lastfall zu erstellen Die bestehenden Lasten sollen sp ter ber ihren Namen mit Hilfe einer ComboBox identi fiziert werden damit auch ihnen berechnete Lasten zugeordnet werden k nnen 3 4 3 TESTBARKEIT Das Testen der Oberfl che soll mit Hilfe von Integrationstests durchgef hrt wer den Diese k nnen zun chst manuell durchgef hrt und sp ter automatisiert wer den Dieser Abschnitt soll sich vor allem mit der Testbarkeit des Daten verarbei tenden Codes besch ftigen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Wie schon
16. IHistory windloads Windloads modelid int windloads Windloads beamreader BeamReader config IConfiguration beamDataViewModel B calculateWindSpeed_DNV d update Update calculateWindPressure_DNV lt lt instantiate gt gt calculateShapeCoefficient_D calculateWindForces_DNV B calculateProfileProjection_D valuesBeforeExecute Li readGravityDirection string newValue double beamNumber int adjustUnits propertyName string calculateWindloads_DNV Lis profileType string CC BEE ee globalMarineGrowth double windSpeed doublef windDirection double windPressure double readZCoordinates int modelid int actual airDensity double projection double readBeamlLength int modelid int actualB globalShapeCoefficient dou length double readProfileType int modelid int beamPro averagingTime double height double readBeamPropertyNumberfint modelid i referenceTime double forces double readBeamPropertyName int modelid int referenceWindSpeed double getNumberOfBeams int modelid int referenceHeight double positive bool Abbildung 17 Klassendiagramm hinter dem UserControl Windloads Table Die Klassenstruktur hinter dem UserControl windloadsTable ist in Abbildung 17 dar gestellt Links im Bild findet sich die Subkomponente BeamData die das ViewModel f r die Tabelle enth lt Mit der Initiali
17. Metriken hinzuziehen die diesen Aspekt vergleichbar machen sollen Um einzusch tzen ob der Quellcode des Straus Multitools verst ndlicher ist als der des Straus API Tools wurden mit Hilfe des freien Programms SourceMonitor Campwood Software LCC vergleichende Messungen durchgef hrt Diese wer den im Folgenden beschrieben Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Fazit Es sollen drei Metriken f r die Verst ndlichkeit zu Rate gezogen werden Die pro zentuale Anzahl der Zeilen mit Code Dokumentation die Komplexit t nach McConnell 1993 und die mittlere Einr cktiefe der Codezeilen Die Zeilen mit Code Dokumentation sind alle Zeilen in denen die Kommentare ein Format haben das von Microsoft als Basis f r eine automatisch generierbare Code Dokumentation vorgesehen ist Einfache Kommentare werden dabei nicht mitgewertet Das macht die Messung etwas unscharf weil auch gew hnliche Kommentare die Verst ndlichkeit des Codes deutlich verbessern k nnen So wer den aber auskommentierte Bl cke von Code wie sie im Straus API Tool h ufiger vorkommen nicht mitgewertet Als Ergebnis der Messung liegt das neu entwi ckelte Straus Multitool mit 12 2 Code Dokumentation deutlich vor dem Straus API Tool mit 2 5 Code Dokumentation Die Komplexit t nach Steve McConnell kann als maximaler und durchschnittli cher Wert berechnet werden Die Werte werden so berechnet dass die Ausf h rungspfade durch eine M
18. Per formance auswirken k nnte Transactions Im Namespace System Transaction von NET findet sich die M glich keit Transaktionen zu definieren die mittels Rollback wieder zur ckgenommen werden k nnen Diese M glichkeit wurde verworfen weil sich die Bibliothek auf Datenbanken bezieht und die Struktur der Dateien so beibehalten werden soll Eine zus tzliche Einf hrung einer Datenbank zum Speichern der Zwischenst nde wurde wegen zu hohen Aufwands verworfen Stacks Command Muster Diese M glichkeit ist verh ltnism ig einfach zu im plementieren und bietet nebenbei die schnelle Erweiterbarkeit um das Aufzeich nen von Makros was seitens Overdick als m gliche Erweiterung genannt wurde REQ 018 Au erdem kann so entschieden werden welche Aktionen als inver tierbar implementiert werden sollen und bei welchen dies nicht wichtig ist Ein weiterer Vorteil bei der Benutzung des Command Musters ist Wenn das Straus Multitool durch das Aufnehmen von Makros erweitert werden soll REQ 018 kann dies leicht durch Anpassung der History Komponente geschehen Denn sie bietet durch das IInstruction Interface schon die M glichkeit an Kommandos zu wiederholen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten 3 3 STRAUS7 KOMPONENTE Die Straus7 Komponente dient der Anbindung des Programms an die Straus API Dadurch unterscheidet sie sich stark von den anderen Komponenten we
19. REQ 035 Clean Mesh REQ 036 Tekla Import und REQ 040 Lastfall Kombinationen generieren Das Generie ren der Windlasten nach DIN Norm REQ 022a kann als zus tzliche Funktion der Windloads Mission implementiert werden REQ 018 Makros aufzeichnen kann leicht mit Hilfe der History Komponente realisiert werden Die Anforderung REQ 038 Verschiedene Pfade pro Funktion l sst sich einfach in der Ambience Komponente und in der Mission Komponente um setzen Durch die Nutzung von Routedcommands siehe Abschnitt 3 6 4 ist dies sogar besonders einfach Die Umsetzung der Anforderung REQ 007 Konfigurationen speichern ist mit der Configuration Komponente m glich siehe Abschnitt 3 1 4 Die Tabellenfunktionen f r das Kontextmen einer Tabellenansicht REQ 053 und die M glichkeit Daten als Funktionen an zu zeigen REQ 043 kann als Zu satzfunktion zum UserControl windloadsTable hinzugef gt werden Da diese Funkti onen auch f r andere Tabellendarstellungen in Frage kommen w re es hilfreich ein allgemeines UserControl f r Tabellen einzuf hren das diese Funktionen zur Verf gung stellt und die speziellen Tabellenansichten von diesem erben zu lassen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Fazit Auch die Anforderungen REQ 054 Werte in Tabelle visualisieren und REQ 055 Labellenwerte filtern k nnen auf diese Weise implementiert werden Falls da
20. WindloadsChart 46 Abbildung 19 ApplyLoads UserControl und beteiligte Klassen s nsses1sssse010 47 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle vii Abbildung 20 Testbarkeit der Windloads Klasse mit Unit Tests 48 Abbildung 21 Klassenstruktur der ModelManagement Komponente 51 Abbildung 22 Zust nde innerhalb der Klasse ModelManager ue 52 Abbildung 23 Klassendiagramm der Ambience Komponente 54 Abbildung 24 Die wichtigsten Schritte der Iopaltzatpon Komponente 56 Abbildung 25 Eingabe zum Generieren von Lastfall Kombinationen Beispiel 76 Abbildung 26 Beispi lzeile f r de Le Didi une 80 Abbildung 27 Struktur RE 86 TABELLEN Tabelle 1 Qualit tskriterien der DIN ISO 9126 Starke 2011 un en 9 Tabelle 2 Aspekte des Qualit tsmerkmals Funktionalit t Starke 2011 12 Tabelle 3 Aspekte des Qualit tsmerkmals Zuverl ssigkeit Starke 2011 14 Tabelle 4 Aspekte des Qualit tsmerkmals Benutzbarkeit Starke 2011 15 Tabelle 5 Aspekte des Qualit tsmerkmals Effizienz Starke 2011 16 Tabelle 6 Aspekte des Qualit tsmerkmals Anderbarkeit Starke 2011 16 Tabelle 7 Aspekte des Qualit tsmerkmals bertragbarkeit Starke 2011 17 Tabelle 8 M gliche Testf lle f r die Configuraion Komponente s s sssssesssres1s 32 Tabelle 9 M gliche T
21. bietet sich eine Da teidopplung beim ffnen der Datei an es w re zu untersuchen wie sinnvoll sich ein Versionskontrollsystem zur Speicherung von Zwischenst nden zur Pro grammlaufzeit verwenden l sst 5 1 5 BENUTZBARKEIT B Die Benutzbarkeit messbar zu beurteilen f llt schwer So bemerkt schon Dirk Hoffmann in seinem Buch Software Qualit t dass die Ergonomieeigenschaften einer Applikation zwar subjektiv zu sp ren aber nur schwer zu quantifizieren sind Hoffmann 2008 S 247 Deshalb soll die Benutzbarkeit im Rahmen einer Evaluation beurteilt werden Bisher steht diese noch aus weil das Straus Multitool noch nicht ausreichend Funktionen zur Verf gung stellt um ein aussagekr ftiges Ergebnis erreichen zu k nnen Es wurden allerdings verschiedene Ma nahmen ergriffen die Benutzbarkeit zu gew hrleisten die als positiv einzustufen sind Die Oberfl che zeigt in jedem Kon text die verwendeten Gr eneinheiten an es wurde ein Konzept f r den Umgang mit Fehlern etabliert die Funktionen eines gemeinsamen Kontexts werden in der Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Kan Fazit Oberfl che gruppiert und es ist ein Benutzerhandbuch geplant Eine wichtige Hil fe bei der Gestaltung der Oberfl che waren regelm ige Reviews mit den sp teren Benutzern sowie die positiv ausgefallene Bewertung eines externen Usability Experten dem das fertige Konzept pr sentiert wurde 5 1
22. den als virtual berschreibbar markiert hat und ob deren Umfang klein genug ist um nicht getestet werden zu m ssen 3 4 MISSION KOMPONENTE Die Mission Komponente existiert in mehreren Auspr gungen und dient jeweils der Ausf hrung einer bestimmten Aufgabe Damit bilden die mission Komponenten den wesentlichen Teil des Programms Eine Mission Komponente arbeitet sowohl auf der Pr sentations als auch auf der Dom nenschicht und nutzt die Komponenten der Infrastrukturschicht Die Einbindung in das Hauptpro gramm erfolgt ber die Pr sentationsschicht durch die Ambience Komponente F r die Durchstich Implementierung wird eine Komponente ausgew hlt die Windlasten berechnet und in der Modelldatei speichert REQ 022 und REQ 022c Die folgenden Betrachtungen gehen also von der windloads Mission aus Aufgaben f r weitere Mission Komponenten k nnen Anhang A entnommen werden z B fordert REQ 045 die Generierung von Wellenlasten 3 4 1 VOR UND NACHBEDINGUNGEN Die windloads Mission muss in eine grafische Benutzeroberfl che eingebettet wer den Sie ist als grafisches UserControl implementiert das eine Registerkarte Tab realisiert Bevor die Registerkarte geladen wird muss ein Modell zum Arbeiten ge ffnet worden sein Die Nachbedingungen richten sich nach den Handlungen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten des Benutzers Je nach Nutzung der Komponente kann
23. der entwickel ten Architektur erfordert eine etwas umfangreichere Analyse Im Folgenden sollen die nicht funktionalen Aspekte priorisiert und ihre Erf llung bewertet werden Da diese von Overdick eher weich formuliert wurden kann diese Bewertung nicht rein objektiv erfolgen Alle nicht funktionalen Anforderungen wurden eingangs genannt nderbarkeit bzw Erweiterbarkeit Testbarkeit und Verst ndlichkeit Diese Punkte sind auch in den in Kapitel 2 1 benannten Qualit tskriterien an eine Software Architektur im Allgemeinen enthalten Hinzu kommen als relevante nicht funktionale Aspekte noch Zuverl ssigkeit Benutzbarkeit und Effizienz Die se sechs Punkte sollen im Folgenden zur Bewertung herangezogen werden Dabei wird mit Hilfe der Skala A wichtig B mittel C weniger wichtig priori siert die Begr ndung f r die Einstufungen wird in Kapitel 2 1 gegeben Die f r diese Architektur nicht relevanten Punkte werden hier nicht aufgez hlt 5 1 1 ERWEITERBARKEIT A Die Erweiterbarkeit der Architektur ist ein sehr wichtiges Kriterium Das Straus Multitool soll problemlos durch neue Funktionen erweitert werden k nnen ohne dass sich die Struktur ndert Die Erweiterbarkeit l sst sich schwer messen Ein geeigneter Ansatz zur Bewertung dieses Aspekts scheint der Weg ber sogenann Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Fazit te Qualit tsszenarien nach Starke 2011 zu sein Dies
24. der richtige Ort da f r Allerdings wird ein ge ffnetes Straus Modell nach Angaben des Strand7 Supports bereits durch die API im Arbeitsspeicher gehalten Ein vollst ndiges Abbild zu reproduzieren w rde also unn tig viel Arbeitsspeicher kosten und die Wartezeiten f r den Benutzer verl ngern Deshalb wurde entschieden nur die Teile des Strukturmodells im Straus Multitool zu modellieren mit denen aktuell gearbeitet werden soll Dies geschieht dann in der jeweils passenden Form in den Mission Modulen In den Anforderungen wird das Verarbeiten von Ergebnisdateien gefordert REQ 021 Eine Ergebnisdatei beinhaltet das Ergebnis einer Simulation innerhalb der Straus Software Wenn die Umsetzung von REQ 021 geplant wird kann Model Management als Blaupause f r eine ResultManagement Komponente dienen Diese w r de die Funktionen ffnen speichern und schlie en f r Ergebnisdateien zur Verf gung stellen Um die Datensicherheit zu verbessern REQ 52 besteht die M glichkeit beim ffnen der Datei die Komponente zun chst einmal mit einer lokalen Kopie arbei Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten ten zu lassen Damit k nnte garantiert werden dass das Straus Multitool auch bei Fehlerzust nden keine Modelldatei besch digt Die zus tzliche Sicherung wurde bisher von Overdick als unn tig eingestuft da die Modelldatei erst mit dem Spei chern Befehl wirklich ver
25. die XML Datei syntaktisch oder semantisch nicht konform ist Configuration IConfiguration getValue String key string changeValue string key string newValue Configuration IConfigurationManager mgr List localConfigList Configuration mgr IConfigurationManager Configuration filename string update lt lt Interface gt gt IConfigurationManager update List configList save List configList lt lt use gt gt XmiIConfiguration Manager Le Configurationltem string configFile string key XmlConfigurationManager string filename string value i Configurationltem string key string value lt throws gt gt Configurationltem WrongFormatException Abbildung 8 Die Configuration Komponente von innen Die Schnittstelle nach au en wird durch das Interface IConfiguration definiert Dies sollte in allen Komponenten die die Configuration Komponente nutzen verwendet werden damit die Komponente im Bedarfsfall leicht ausgetauscht werden kann Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Dies ist zum Beispiel bei Unit Tests interessant aber auch wenn das Konzept der Configuration Komponente ge ndert werden soll Die Klasse wrongFormatException erbt ihre Eigenschaften von der Klasse Exception Dieser Umstand wurde der bersicht halber in der Darstellung weggelassen Die Schnittstelle IConfigurationManager dien
26. diesen Stellen wurden exemplarisch Unit Tests angelegt die mit Einf hrung eines genauen Testplans erweitert werden sollten Die Testbarkeit der anderen Klassen kann durch Mock Frameworks und Integrationstests erreicht werden Die Integrationstests sollen zun chst manuell durchgef hrt werden Mit wachsender Anzahl von Testdaten durch die sp teren Benutzer soll auch diese Form von Test automatisiert durchgef hrt werden k nnen Um sicher zu stellen ob die Funktionen die Anforderungen erf llen kann mit den Hilfsmitteln der Ak zeptanztest getriebenen Entwicklung wie beispielsweise dem Framework FitNes se Martin et al gearbeitet werden Es kann somit von einer umfassenden Testbarkeit des Straus Multitools ausge gangen werden Die genaue Ausarbeitung und Umsetzung eines umfassenden Testplans muss nach Abschluss dieser Arbeit erfolgen 5 1 3 VERST NDLICHKEIT A Die Verst ndlichkeit der Struktur des Straus Multitools wird mit diesem Doku ment als Dokumentation der Architektur sichergestellt Wichtig ist hierbei dass auch die Entscheidungen die zu der vorliegenden Architektur gef hrt haben do kumentiert sind Der Quellcode wurde nach Anregungen von McConnell 2004 zu Struktur und Kommentaren so dokumentiert dass er auch f r neue Entwickler schnell ver st ndlich werden sollte Die Qualit t der Kommentare ist nicht quantitativ mess bar allerdings lassen sich zur Beurteilung der Verst ndlichkeit des Quellcodes an sich
27. machen die Ingeni eure w rden sich aber auf die Software verlassen und das damit berechnete Mo dell so bauen lassen k nnte das sp tere Bauwerk einst rzen und dabei Leben ge f hrden Damit l sst sich nach der Definition von Andreas Spillner und Tilo Linz der f r dieses Projekt wichtigste Teil des Testens mit Unit Tests abdecken da sie deren wichtigste Aufgabe in der Sicherstellung sehen dass das jeweilige Testob jekt die laut seiner Spezifikation geforderte Funktionalit t korrekt und vollst ndig realisiert Spillner et al 2003 Dar ber hinaus sind aber auch sogenannte Akzeptanztests eine gute M glichkeit die Qualit t der Software sicher zu stellen Sie pr fen ob das getestete St ck Code die richtige Aufgabe erledigt Diese Art von Test wird sicherlich sp ter hilfreich wenn die Software umfangreicher geworden ist Momentan wird die Akzeptanz pragmatisch angegangen indem der geschriebene Code per Review mit dem Entwickler des Straus API Tools durchgegangen wird Dieser ist als Reviewer deshalb gut geeignet da er als Entwickler den Code versteht und als Bauingenieur ebenfalls Nutzer des Straus Multitools wird und deshalb die Anforderungen und deren Umsetzung sehr genau einsch tzen kann Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur F r die Architektur Entscheidungen ist hier also nur der Unit Test relevant Mit Hilfe von verschiedenen Techniken und Mustern wurde die I
28. read only bool opened get read only bool modified get read only bool apilnitialized get read only bool openModel string filename bool saveModel bool saveModelAs string filename bool closeModel Das Feld id enth lt die eindeutige Nummer ber die die Straus API das Modell identifiziert Wenn die API initialisiert ist enth lt das Feld apilInitialized den Wert true ber die Felder opened und modified kann der Zustand des verwalteten Mo dells ausgelesen werden w hrend die Funktionen openModel saveModel saveMo delAs string filename und closeModel Befehle der Oberfl che umsetzen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur F r eine Mission Komponente ist nur wichtig mit welchem Modell gearbeitet wer den soll und wie dessen Zustand ist Deshalb kann es das Interface IModel nutzen ber das nur drei Zustandsfelder zur Verf gung stehen int id get bool modified set get bool apilnitialized get Hier ist das Feld modified allerdings auch schreibbar damit die Mission Komponente den Zustand aktualisieren kann wenn sie das Modell seit dem ff nen ver ndert hat 2 3 6 AMBIENCE Die Ambience Komponente enth lt einen Gro teil der Oberfl che des Programms mit dessen Funktionen Deshalb ist sie in der Pr sentationsschicht angeordnet Sie definiert das Hauptmen und belegt es mit Funktionalit t Au erdem instanziie
29. sicherheitskritischen Berechnungen durchgef hrt werden mit deren Hilfe die Straus Modelle auf Stabilit t gepr ft werden REQ 039 Was die anderen Klassen der Komponente angeht ist die Klasse DistributedLoads ViewModel die aus der Liste der vorhandenen St be die Streckenlasten berechnet auf hnliche Weise testbar wie die windloads Klasse Auch f r sie wurde eine Test klasse erstellt die einen beispielhaften Testfall enth lt Auf herk mmlichen Weg nicht sinnvoll mit Unit Tests testbar sind die Usercon trols sowie die Klassen LoadCases und LoadCaseViewModel weil sie in jeder Methode externe Zugriffe beinhalten Hier kann auch nur auf Integrationstests oder die Verwendung des Moles Frameworks zur ckgegriffen werden hnlich sieht es mit der Klasse BeamReader aus hier arbeitet lediglich die Methode beamprofileType ToString ohne externe Zugriffe Weiterhin gibt es eine Reihe von Klassen bei denen Unit Tests nicht zwingend n tig sind weil sie keine Logik beinhalten sondern nur Aufrufe Dabei handelt es sich um die Klassen Beam BeamDataViewModel DistributedLoad WindloadsInstruction Factory Recalculatewindloads SetGlobalMarineGrowth Loadcase Parameters und wind loadCommands Diese Klassen werden sinnvollerweise im Rahmen von Integrations tests gepr ft 3 4 4 DESIGNENTSCHEIDUNGEN Auch f r die windloads Mission und die Mission Komponente im Allgemeinen wur den wichtige Entscheidungen getroffen die hier begr
30. sie im Durchstich nicht ausprogrammiert wurde Trotzdem besteht sie aus einer XAML Datei f r die Fensterbeschreibung und einer Code Behind Datei Die Klasse Mainwindow ist die Code Behind Datei f r die in Abbildung 23 als Klasse dargestellte Mainwindow xaml Die Klassendarstellung f r die XAML Datei wurde gew hlt um die Abh ngigkeiten klar ausdr cken zu k nnen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Ambience MainWindow xaml ConfigurationWindow lt lt use gt gt Open RoutedCommand mgr IModelManager Save RoutedCommand SaveAs RoutedCommand showProgress message string FileDialogs mgr IModelManager Close RoutedCommand hideProgress Undo RoutedCommand Open_CanExecute sender objec Redo RoutedCommand Open_Executed sender object OpenStrausWindow RoutedCommand Save_CanExecute sender objec OpenConfiguration RoutedCommand Save_Executed sender object e OpenHelprFile RoutedCommand SaveAs_CanExecute sender obj SaveAs_Executed sender object apiErrorMessage message string infoMessagettitle string message string Abbildung 23 Klassendiagramm der Ambience Komponente Um die Struktur verst ndlicher zu machen wird hier eine kurze Einf hrung in die Funktionsweise von selbst geschriebenen Routedcommands in WPF gegeben die von der Oberfl che verwendet werden
31. tsnachweis m glich Besser w re es Wellenberge und t ler als entsprechende Lasten so ber das Mo dell zu verteilen wie sie tats chlich auftreten k nnen Damit wird die Berechnung genauer und die Konstruktionen werden wirtschaftlicher Auf diese Weise w rde die Bestimmung der Lasten aber so komplex dass die Ingenieure deutlich l nger als bisher brauchen w rden um die Daten in das Simulationsprogramm einzuge ben Die Kosten die durch die manuelle Eingabe der genauen Lasten entstehen w rden k nnten aber durch die Materialeinsparung nicht gerechtfertigt werden Aus diesem Grund soll eine Anwendung entwickelt werden die automatisch die Verteilung der Lasten f r eine Welle ber die r umliche und zeitliche Dimension berechnet und diese Lastf lle automatisiert an das Simulationsprogramm ber Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle gem Einleitung tr gt sodass die Rechnung insgesamt genauer und die Bearbeitung schneller wird So k nnte Arbeitszeit eingespart werden weil die Lasten jetzt automatisch generiert w rden Gleichzeitig k nnte die Rechnung beliebig genau programmiert werden wodurch Material in der Konstruktion eingespart werden k nnte weil die Berechnungen nicht mehr so pessimistisch abgesch tzt werden 1 4 BESTEHENDER L SUNGSANSATZ Es wurde bereits ein Programm entwickelt das diese und hnliche Aufgaben zur Optimierung des Entwicklungsablaufes bernehmen soll Da
32. Bauteil zum Beispiel infolge Personen Einrichtungsgegenst nden Lagerstoffen Maschinen oder Fahrzeugen Angabe von Lasten und Verformungen die gleichzeitig einwirken Der Be griff wird auch als Synonym f r die in den Normen geregelten Lasten bzw Einwirkungen verwendet welche auf die Konstruktion bzw den Aufbau einwirken und diese beeinflussen k nnen Zusammenfassung von mehreren Lastf llen in Straus7 Zur einfacheren Handhabung k nnen mehrere Lastf lle linear zu einem neuen Lastfall kombi niert werden Last Lastfall Lastfall Kombination Oberbegriff f r Knoten gt St be gt Platten und Bricks Knoten Zweidimensionales Modellelement das von mindestens drei Knoten defi niert und begrenzt wird Attribut Eindimensionales Modellelement das von mindestens zwei Knoten defi niert und begrenzt wird Strand ist ein Desktopprogramm das in einer gemeinsamen Umgebung strukturelle Modelle analysiert und Ergebnisse von Lastf llen mit Hilfe der Finite Elemente Methode berechnet Name von Strand7 f r den europ ischen Markt Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang VERSICHERUNG DER SELBSTST NDIGKEIT Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Pr fungsord nung nach 816 5 APSO TI BM ohne fremde Hilfe selbstst ndig verfasst und nur die angegebenen Hilfsmittel benutzt habe W rtlich oder dem Sinn nach aus a
33. Benutzer eingegebe nen Parametern wie Windgeschwindigkeit und Windrichtung berechnet Dies kann f r Modelle durchgef hrt werden die mit St ben und Verbindungsknoten modelliert wurden Pro Stab wird dabei eine Streckenlast berechnet also eine als linear angenommene Gr e die Auskunft auf die Last auf einem bestimmten L ngenst ck des Stabes gibt Die Lasten sollen als Werte in einer Tabelle und als mathematischer Graph darge stellt werden REQ 022b Die Tabelle soll dazu Eingangsparameter und Ergebnis se der Rechnung f r jeden Stab im Modell anzeigen Der Graph zeigt f r St be mit gleichem Querschnittsprofil eine Verteilung der Lasten ber die H he an 1 5 1 4 PROTOKOLLIERUNG Das neue Programm soll w hrend des Durchlaufs wichtige Schritte in einer Log ging Datei protokollieren REQ 006 Damit sollen auch eventuell auftretende Programmfehler leicht lokalisiert werden k nnen die erst bei der Berechnung durch die Ingenieure auffallen 1 5 1 5 UNDO UND REDO Es soll prinzipiell m glich sein Befehle per Undo und Redo Schaltfl che zur ck zunehmen und zu wiederholen REQ 057 F r welche Befehle dies erforderlich ist ist im Einzelfall zu entscheiden 1 5 2 NICHT FUNKTIONALE ASPEKTE Bei der Entwicklung des neuen Programms sind die Aspekte Erweiterbarkeit Wartbarkeit und Testbarkeit besonders wichtig Eine Unterteilung in Komponen ten macht das Programm leichter erweiterbar Besonders f r das Hinzuf gen von neue
34. Das Programm soll als Sammlung von Werkzeugen so lange zur Verf gung stehen bis der Benutzer das Programm wieder schlie t Das Programm ist also nicht terminierend Module k nnen aller dings auch als Transformation konzipiert werden damit w ren diese dann terminierend e Reaktives System Das Programm h lt andauernde Kommunikation mit dem Benutzer aufrecht Au erdem kann man sagen dass es sich um ein Einbenutzersystem handelt Die Module sind teilweise sehr berechnungsintensiv Das Programm muss aber keine Echtzeitanforderungen erf llen 1 6 AUFBAU DER ARBEIT Diese Arbeit ist wie folgt aufgebaut Im n chsten Kapitel werden Qualit tskrite rien f r Software Architekturen eingef hrt und es wird beschrieben wie diese Kriterien f r das Straus Multitool erreicht werden sollen Au erdem wird eine bersicht ber die neue Software Architektur gegeben und die Entscheidungen die zu dieser L sung gef hrt haben werden dokumentiert und begr ndet Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Fan Einleitung Das dritte Kapitel beschreibt einzeln die Bausteine aus denen die Architektur zu sammengesetzt ist und ihre Funktion aus der Innenansicht Auch auf dieser Ebe ne werden getroffene Entscheidungen zum Nachvollziehen festgehalten Die As pekte Implementierung und Test werden f r jede Komponente einzeln beschrie ben sofern dies f r die Architektur wichtig ist Im vierten Kapitel werden t
35. Dies geschieht beim Schlie en des Straus Multitools 3 3 2 STRUKTUR Wie bereits angedeutet unterscheidet sich die Struktur der Straus7 Komponente deutlich von der der anderen Komponenten Nach Au en weist sie kein Interface f r die Kommunikation mit anderen Komponenten auf Intern besteht sie aus drei Modules und einer Klasse Modules sind eine Eigenheit der Programmiersprache Vi sualBasic NET Sie enthalten Methoden und Variablen die global zugreifbar sind wenn das Module nicht als private deklariert wurde Die Klasse definiert eine spezielle Exception die ApiException die im ganzen Pro gramm f r Ausnahmen verwendet wird die durch Funktionen der Straus API auftreten Das Modul Errors enth lt nur die Funktion handle rror die in der Lage Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten ist die Fehlercodes der API in eine aussagekr ftigere Zeichenkette umzuwandeln Sie verwendet dazu eine Funktion der Straus API Dar ber hinaus enth lt die Komponente die beiden Modules St7APIcall und St7APIConst die die Funktionsk pfe und die Konstanten enthalten die von den Straus7 Entwicklern zur Nutzung der API zur Verf gung gestellt werden Die Dateien werden mit der Straus7 Installation ausgeliefert und unver ndert verwendet Durch die Verwendung die ser beiden Modules kann nun auch von anderen Komponenten aus ber die Straus7 Komponente auf die API zugegriffen werden
36. Feld modified ber IManageModel nur lesend zugreifen Sie entscheidet anhand des Wertes von modified ob sie den Speichern Button aktiviert und ob beim Schlie en des Programms nachgefragt wird ob das Modell gespeichert werden soll 3 5 3 TESTBARKEIT Die Komponente ModelManagement ist nur mit Hilfe von Integrationstests oder einem Framework wie Moles testbar Das liegt daran dass jeder Teil dieser Komponen ten auf die Straus API zugreift 3 5 4 DESIGNENTSCHEIDUNGEN Nutzung von Zustandsvariablen Das Verhalten von Ambience und Mission h ngt in einigen Situationen davon ab welchen Zustand das Modell und die API Schnittstelle haben Deshalb wurden diese Zust nde mit Hilfe von booleschen Va riablen modelliert Die Zust nde und ihre Transitionen sind in Abbildung 22 dar gestellt Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Modell ver ndert modified true ver ndern speichern Modelldatei ge ffnet speichern unter opened true Modell unver ndert modified false speichern speichern unter Modelldatei geschlossen opened false Abbildung 22 Zust nde innerhalb der Klasse ModelManager Keine vollst ndige Entsprechung des Straus Modells in Software W rde das Straus Modell vollst ndig in Software modelliert werden wie man REQ 019 auch interpretieren k nnte w re die ModelManagement Komponente
37. Funktion tut REQ 009 damit er einsch tzen kann wann er die Funktion einsetzen kann und mit welchen Ergebnissen und To leranzen er zu rechnen hat e Es wird gemeinsam mit den Nutzern versucht die Funktionsaufrufe in But tons oder Men s so zu platzieren dass Funktionen im gleichen Kontext in der Programmoberfl che nah beieinander liegen e Zur Oberfl chenstruktur des Programms wurde ein Usability Experte zu Hilfe gerufen der die aktuelle Aufteilung als positiv und hilfreich einge sch tzt hat Ob die berlegungen richtig waren kann sich nur langfristig durch Nutzerevaluation herausstellen F r eine gute Benutzbarkeit ist es auch wichtig wie gut sich der Anwender im Fehlerfall informiert f hlt und wie sehr er den Eindruck hat dass die Anwendung f r die L sung seines Problems geeignet ist Dies sind subjektive wenn auch teil weise messbare Kriterien die im Rahmen einer Benutzer Evaluation gepr ft wer den k nnen sobald die Anwendung gen gend Funktionen unterst tzt die aus probiert werden k nnen Dies wird erst nach Ende dieser Arbeit geschehen weil der hier implementierte Funktionsumfang noch zu gering ist 2 1 6 EFFIZIENZ Die Effizienz ist f r das Programm insofern wichtig dass der Benutzer in einem angemessenen zeitlichen Rahmen mit einer Antwort rechnen darf Relevanz B Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur Ob eine Anwendung effizient ist richtet s
38. Hochschule f r Angewandte Wissenschaften Hamburg Hamburg University of Applied Sciences Bachelorthesis Friederike L we Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informations und Department of Information and Elektrotechnik Electrical Engineering Friederike L we Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Bachelorthesis eingereicht im Rahmen der Bachelorpr fung im Studiengang Informations und Elektrotechnik am Department Informations und Elektrotechnik der Fakult t Technik und Informatik der Hochschule f r Angewandte Wissenschaften Hamburg Betreuender Pr fer Prof Dr Thomas Lehmann Zweitgutachter Prof Dr Stefan Sarstedt Abgegeben am 16 Februar 2012 Friederike L we Thema der Bachelorthesis Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Stichworte Software Architektur Neuentwicklung Schichtenmodell Komponenten Schnittstellen Software Qualit t Testbarkeit Erweiterbarkeit Verst ndlichkeit Kurzzusammenfassung Die Aufgabe dieser Bachelorthesis ist es die Architektur einer vorhandenen Software zur Verifikation von Strukturmodellen neu zu entwickeln Um die Qualit t der entwickelten Architektur zu belegen wird ein Durchstich imple mentiert Als wichtigste Qualit tskriterien gelten Testbarkeit Erweiterbarkeit und Ve
39. I Tool oder das K rzel eines Overdick Mitarbeiters sein 1 5 1 FUNKTIONALIT T In diesem Abschnitt wird der im Rahmen dieser Arbeit zu implementierende Funktionsumfang beschrieben Aspekte die f r Architektur Entscheidungen wichtig sind aber nicht f r die Durchstich Implementierung vorgesehen sind werden hier nicht beschrieben Sie finden sich in den Anforderungen und werden in den sp teren Kapiteln bei der Begr ndung der entsprechenden Architektur Entscheidung referenziert 1 5 1 1 PERSISTENZ Das Programm soll die M glichkeit bieten Informationen wie die Konfiguration des Programms oder Parameter f r Berechnungen zu speichern Die Werte sollen nach einem Neustart des Programms wieder hergestellt werden Diese Anforde rung ist nach der Analyse hinzugekommen betrifft aber auch REQ 007 1 5 1 2 MODELLVERWALTUNG Das Programm soll mit Straus Modelldateien arbeiten k nnen Es soll in der Lage sein sie zu ffnen zu lesen zu bearbeiten zu speichern und zu schlie en siehe Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Einleitung REQ 019 REQ 026 und REQ 50 Dazu geh rt insbesondere dass neue Lasten in der Datei gespeichert werden REQ 020 und REQ 022c damit ihre Auswirkungen sp ter mit Hilfe von Straus7 simuliert werden k nnen 1 5 1 3 WINDLASTEN Um eine der geplanten Berechnungen umzusetzen soll das Programm Windlasten generieren k nnen REQ 022 und REQ 022a die es aus vom
40. NA Das Programm ist in der Lage Dateien des Programms Tekla zu importieren und in ein Straus Modell zu konvertieren REOQ 018 Makros aufnehmen 2 spier Die einzelnen Schritte die im Verlauf einer Session durchgef hrt werden sollten auf Wunsch des Nutzers hin aufgezeichnet werden k nnen wie ein Makro um sp ter automatisch wiederholt werden zu k nnen A 1 2 6 ADMINISTRATIVE FUNKTIONEN In diesem Abschnitt sollen Anforderungen zur Programmverwaltung beschrieben werden D Durchstich REQ 006 Logging RE Straus API Tool Das Programm soll eine Log Datei generieren in der man den Status von Lade oder Berechnungsvorg ngen sehen kann und auch wo m glicherweise Fehler aufgetreten sind Es soll klar sein an welcher Stelle ein Vorgang m glicherweise abgebrochen wur de Dazu sollen die Zeilen mit Datum und Uhrzeit versehen werden Die Module sollten der bersichtlichkeit wegen in die gleiche Log Datei schreiben wie das Hauptprogramm Die Eintr ge sollten aber entsprechend gekennzeichnet werden sodass klar ist in welcher Komponente ein m glicher Fehler aufgetreten ist 2011 11 21 09 32 24 Modulname Vorgang und Status Abbildung 26 Beispielzeile f r die Log Datei REQ 016 Automatisches Update 2 E RE FLO Es soll eine Funktion geben die beim Starten des Programms abgleicht ob die ak tuelle Version des Programms vorliegt
41. Systems Au erdem ist die Fremd software weiter entwickelt und somit weniger fehleranf llig als eine Neuentwick lung 4 3 EINHEITEN In der Oberfl che werden die physikalischen Einheiten zu jeder angezeigten Gr fe Ein und Ausgabe vermerkt Im Quellcode werden die Einheiten nicht einzeln modelliert Es wird direkt mit Zahlenwerten gerechnet Einheiten sollten m g lichst st ndig in den Kommentaren mitgef hrt werden Dieser Umgang mit phy sikalischen Einheiten ist f r gew hnlich stark fehleranf llig deshalb soll im Fol genden beschrieben werden warum er dennoch gew hlt wurde Zun chst gibt es unterschiedliche Wege f r den Umgang mit physikalischen Ein heiten Der objektorientierte Ansatz w re die Gr en als Objekte zu modellieren Damit entsteht ein Entwicklungsaufwand f r die Skalierung der Gr en Zum Beispiel bei der Umrechnung von Pascal in Mega Pascal F r jede Gr e m ssten Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Technische Konzepte alle diese Umrechnungen implementiert werden Viel schwerer wiegt aber der Umgang mit zusammengesetzten Einheiten Die Gr en m ssten Methoden im plementieren die ihre mathematische Kombination erm glichen Dabei m ssen ein Zahlenwert und eine sinnvolle Einheit herauskommen Bei diesen Vorg ngen gibt es sehr viele m gliche Kombinationen die die Implementierung dieses Grundger stes sehr fehleranf llig machen Einige exis
42. Zun chst wird in der Klasse AppCommands ein neues Objekt der Klasse Routed vents instanziiert In der Klasse Mainwindow gibt es dazu zwei Methoden die sich um die Ausf hrbarkeit CanExecute und die Ausf h rung Executed k mmern Die Bindung des Kommandos an Schaltfl chen und an die ausf hrenden Methoden bernimmt die XAML Datei die die Oberfl che be schreibt Mainwindlow xaml Die Initialisierung der Mission Module erfolgt durch die Methode openTabs in der Mainwindow Klasse Hier wird f r jedes Mission Modul berpr ft ob dessen Vorbe dingungen erf llt wurden Ist dies der Fall wird das Modul in die Darstellung des Programms eingebunden 3 6 3 TESTBARKEIT Da es sich bei der Anbience Komponente um eine reine Realisierung der Oberfl che und deren Funktionen handelt ist sie nicht durch Komponententests berpr fbar Deshalb wurde die Testbarkeit beim Design nicht weiter ber cksichtigt Zwei M glichkeiten die Komponente dennoch zu testen sind manuelle Tests und au tomatisierte Funktionaltest Die Testdurchf hrung liegt allerdings au erhalb des Rahmens dieser Arbeit 3 6 4 DESIGNENTSCHEIDUNGEN Verwendung des MVVM Musters und WPF REQ 002 Die WPF Version des Model View Controller Musters ist das MVVM Muster Die Abk rzung steht f r Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Model View ViewModel Das Muster schreibt vor dass es ein Model gibt da
43. alb wurde die Idee ver worfen Nutzung von Routedcommands f r Befehle Routedcommands bieten einen Mehrwert zu einfachen Events Neben einigen anderen Vorteilen die f r das Straus Multitool nicht entscheidend sind bieten Routedcommands die M glichkeit die Ausf hrbarkeit der Kommandos zentral zu regeln Zum Beispiel m ssen ein Button f r Undo und ein Programmst ck dass auf die Tastenkombination Strg Z reagiert nicht einzeln aktiviert und deaktiviert werden wenn nichts mehr r ckg ngig gemacht werden kann Die Logik hierf r liegt zentral an einer Stelle und gilt f r das RoutedCommand Durch die Bindung des Routedcommands an Schaltfl chen und Tastenkombinationen geschieht die Aktivierung und Deaktivierung der Funktonalit t automatisch Das erh ht die Wiederverwendbarkeit des Codes Thomas Claudius Huber beschreibt den Grund f r die Nutzung von Routedcommands mit den folgenden Worten Nat r lich lie e sich f r jede Aktion auch ein Event Handler f r ein bestimmtes Event installieren Doch dann m ssten Sie vieles zu Fu erledigen wie eben beispiels weise das Aktivieren und Deaktivieren von Menultems oder Buttons Dies Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten f hrt zu umfangreicherem Code den Sie sich mit Commands bei der WPF teilwei se oder in manchen F llen auch ganz sparen k nnen Huber 2010 S 469 Mit der Verwendung von Routedc
44. amic Data Display Online 15 November 2011 http dynamicdatadisplay codeplex com Collins Sussman Ben Fitzpatrick Brian W und Pilato C Michael Versionskontrolle mit Subversion Buch K ln O Reilly 2009 Feathers Michael C Effektives Arbeiten mit Legacy Code Buch Heidelberg mitp 2011 Fowler Martin Refactoring Buch M nchen Addison Wesley 2005 Freeman Eric und Freeman Elisabeth Entwurfsmuster von Kopf bis Fu Buch Sebastopol O Reilly 2005 Gamma Erich et al Entwurfsmuster Buch M nchen Addison Wesley 2004 Hibernating Rhinos LTD Rhino Mocks Software Sede Izhak http hibernatingrhinos com open source rhino mocks Hoffmann Dirk W Software Qualit t Buch Berlin Springer 2008 Huber Thomas Claudius Windows Presentation Foundation Buch Bonn Galileo Press 2010 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Kg Literatur IEEE Computer Society IEEE Std 830 1998 IEEE Recommended Practice for Software Requirements Specification New York The Institute of Electrical and Electronics Engineers Inc 1998 Krypczyk Veikko Die Arbeit mit WPF Commands Journal dot NET Magazin Frankfurt am Main Software amp Support Media 2011 6 Krypczyk Veikko Konzeption und Umsetzung einer Undo Redo Funktion Journal dot NET Magazin Frankfurt am Main Software amp Support Media 2011 11 Martin Robert C Martin Mica
45. an Objektfluss Configuration ModelManagement initialisieren 8 initialisieren 8 Mavy INNERMEIerEN Ende QO Ambience Start Abbildung 24 Die wichtigsten Schritte der Initialization Komponente Die Initialization Komponente ist der Punkt an dem langfristig die berpr fung eines Lizenzschl ssels f r das Straus Multitool stattfinden k nnte Au erdem ist sie die letzte Instanz f r ungefangene Exceptions Hier werden Exceptions sp tes tens gefangen und eine entsprechende Fehlermeldung f r den Anwender gene riert Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Technische Konzepte 4 TECHNISCHE KONZEPTE In diesem Kapitel werden Baustein bergreifende Themen vorgestellt die wichtig f r das Straus Multitool sind Die Themen Persistenz Ergonomie und Testbarkeit z hlen auch zu den baustein bergreifenden Themen wurden aber bereits in Kapi tel 2 1 beschrieben und werden daher hier nicht erneut betrachtet Beschrieben wird hier der Umgang mit den Themen Fehlerbehandlung Logging und physika lische Einheiten 4 1 AUSNAHME UND FEHLERBEHANDLUNG In diesem Kontext sollen Fehler als Zust nde betrachtet werden die problema tisch sind mit denen das Programm aber weiter arbeitsf hig ist Eine falsche Be nutzereingabe ist ein passendes Beispiel Mit dem Begriff der Ausnahme soll ein abnormer Zustand beschrieben werden der dann entsteht wenn das Programm in eine ausweglose Situation
46. and dieser Arbeit Sie soll einer seits alle geforderten Funktionen erm glichen andererseits aber auch einer Reihe nicht funktionaler Anforderungen gerecht werden die sp ter in diesem Kapitel benannt werden Als Qualit tstest f r die Architektur wird ein Durchstich imple Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Einleitung mentiert der eine m glichst repr sentative Auswahl der geforderten Funktionen enth lt Das neue Programm wird als Straus Multitool bezeichnet Es soll lang fristig das Straus API Tool ersetzen Dadurch wird der Gesch ftsprozess nicht weiter ver ndert das Prinzip des Programms bleibt bestehen F r das Straus Multitool wurde eine Anforderungsanalyse durchgef hrt In An hang A TI sind die Ergebnisse als Menge von Anforderungen zusammengefasst Die Dokumentation einer Anforderung liegt in folgendem Format vor Durchstich REQ 023 Name der Anforderung X sp ter Quelle Beschreibung der Anforderung in einem Flie text Die Anforderungen haben eine eindeutige Nummer in der Form REQ xxx und einen eindeutigen Namen Im Feld rechts oben steht die Einordnung zu welchem Zeitpunkt die Anforderung ber cksichtigt wird also ob sie im Rahmen dieser Ar beit umgesetzt wird Durchstich oder sp ter Das Feld Quelle beinhaltet die Information von wem oder von welcher Stelle die Anforderung stammt Das kann ein Meetingprotokoll das Straus AP
47. ault Konstruktor f r Configuration Ein parameterloser Konstruktor f r die Configuration Klasse w rde bedeuten dass es einen Standard Pfad f r die Konfigurationsdatei geben m sste der in diesem Fall von der Klasse genutzt wird W rde eine solche Einstellung umgesetzt werden w rde dies aber bedeu ten dass von mehreren Stellen auf die gleiche Datei geschrieben wird falls mehre re Instanzen der Komponente erstellt werden Damit k nnte die Konsistenz der Datei nicht mehr garantiert werden Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten 3 2 HISTORY KOMPONENTE Die History Komponente verwaltet eine globale Undo und eine globale Redo Liste REQ 057 auf denen die ausgef hrten Kommandos abgelegt werden Bei Bedarf wird ein Kommando zur ckgenommen oder erneut ausgef hrt Zus tzlich stellt die History Komponente das Interface IInstruction bereit nach dessen Vor gabe alle Kommandos implementiert werden m ssen die invertiert werden k n nen 3 2 1 VOR UND NACHBEDINGUNGEN Zur Benutzung der History Komponente sind keine Vor oder Nachbedingungen definiert Mit der Initialisierung eines History Objekts kann dieses ber das Inter face IHistory von beliebig vielen Objekten genutzt werden die Kommandos aus f hren Diese Kommandos m ssen lediglich das IInstruction Interface implemen tieren 3 2 2 STRUKTUR Die History Komponente besteht aus einem History Objekt und
48. ble zeigt f r jeden Stab engl beam des ge ffneten Modells spezifische Werte an Dazu geh ren Informatio nen ber das Querschnittsprofil die L nge die Position im Raum und die Kr fte die unter den aktuell eingestellten Bedingungen auf den Stab einwirken ber das Windloadschart werden die Kr fte abh ngig von der H he aufgetragen Dabei ergibt sich f r jede Querschnittsart eine neue Datenreihe Der Benutzer kann die berech neten Lasten in der Modelldatei ber das UserControl ApplyLoadsToModel speichern E lt lt Interface gt gt MndloadsChart Instructions Iinstruction DistributedLoadViewModel distributedLoads List lt Distribute u beams List Beam gt Ren ect Sei leg er fillDistributedLoadsList FE config Ieoniguration ee ee R D DistributedLoad initinstructions were isUsable L___SatGinhalMarineGrawth propertyName string update RecalculateWindloads ble gt EE double gt parametersBeforeExecute Par gw u newParameters Parameters add double height double distrib ApplyLoadsToModel LoadcaseViewModel loadcases List lt Loadcase gt read int modelid WindloadsTable beams List lt Beam gt windloads Windloads beamreader BeamReader createBeamList int modelid List lt B Windloads parameters Parameters units int modelid int config IConfiguration calculateW
49. bt es im Allgemeinen mehrere L sungen die im Folgenden kurz ange rissen werden sollen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Checkpoints Basiert auf der Idee einen Schnappschuss vom aktuellen Zustand der Applikation zu machen um diesen sp ter wieder herstellen zu k nnen Wikipedia Dies w rde f r das hier behandelte Programm bedeuten dass die Straus Modelldatei mehrfach gespeichert werden m sste Da diese Dateien h ufig Gr en im Gigabyte Bereich erreichen wurde diese Technik als L sung verwor fen Das Zwischenspeichern w rde zu lange dauern und der Speicherplatzbedarf w re zu hoch Speichern von Differenzen Man k nnte die nderungen als Differenzen zwi schen Dateien speichern wie es in Versionskontrollsystemen wie Subversion ge handhabt wird Allerdings konnte keine Bibliothek gefunden werden die ein sol ches Verfahren unterst tzt und schon ausreichend getestet ist Subversion bietet direkt eine Programmierschnittstelle an vgl Collins Sussman et al 2009 S 190ff Da sich die Differenzen auf eine Modelldatei beziehen w re auch CVS eine denkbare Option Auch andere Versionskontrollsysteme wie git mercurial usw k nnten auf entsprechende M glichkeiten untersucht werden Bisher wurden die se Ideen aber wegen zu hohen Aufwands verworfen Auch wird bef rchtet dass sich ein Commit nach jeder Aktion des Straus Multitools zu nachteilig auf die
50. ciety 1998 Deshalb werden zuerst Angaben ber die externen Schnittstellen des Straus Multitools gemacht anschlie end werden die funktiona len und die nicht funktionalen Anforderungen beschrieben Der Abstraktionsgrad der Anforderungen f r eine sp tere Umsetzung wurde auf Lastenheftniveau ge halten Anforderungen f r die Durchstich Implementierung wurden auf Pflich tenheftniveau erhoben Alle Anforderungen werden auf Grund der zeitlichen Be schr nkung der Arbeit nur so detailliert beschrieben wie f r den Architekturent wurf und die Durchstich Implementierung notwendig ist A 1 1 EXTERNE SCHNITTSTELLEN Das Straus Multitool soll mit externen Programmen zusammenarbeiten Dies wird in diesem Abschnitt beschrieben Die Systemgrenzen der Anwendung werden in Kapitel 2 Abbildung 1 auf Seite 8 beschrieben Bisher ist die Zusammenarbeit mit der Programmierschnittstelle von Straus7 und mit einer Bibliothek zur Generierung von Wellenlasten fest eingeplant In Zukunft k nnte sich dieses Kapitel um Anforderungen zu Schnittstellen mit anderen Ent wicklungsprogrammen f r Strukturmodelle oder Programme f r technische Zeichnungen erweitern Durchstich Straus API Tool REQ 023 Straus API Das Straus Multitool soll die Funktionen der Straus API nutzen Die API stellt Funktionen zur Verf gung die den Umgang mit Straus Modelldateien erm gli chen Dazu geh rt das ffnen Schlie en und Speichern der Dateien abe
51. ctionF actory WindloadsP references initialisieren windloads ApplyLoadsToModel initialisieren modell loadcases WindloadsChart initialsieren beamDataViewModel beams beams Abbildung 15 Initialisierung der Windloads Komponente 3 4 2 2 WINDLOADSPARAMETERS Das UserControl windloadsParameters wird als Leiste von Eingabefeldern im oberen Teil des windloadsTabs angezeigt Hier kann der Nutzer Parameter einstellen die bei der Windlastenberechnung ber cksichtigt werden sollen siehe auch REQ 022 Die innere Struktur der Code Behind Dateien f r die windloadsParameters ist in Ab bildung 16 dargestellt Die Abbildung zeigt dass das UserControl windloadsParameters das Parameters Objekt ver ndert auf das die windloads Klasse bei der Berechnung zugreift Um eine er neute Berechnung anzusto en ist die Instruction Recalculatewindloads implemen tiert worden von der das InstructionFfactory Objekt eine Instanz herstellt wenn es durch das userControl dazu aufgefordert wird Das Recalculatewindloads Objekt Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten meldet sich nach der Ausf hrung bei der History Komponente an Damit l sst sich die Neuberechnung auch r ckg ngig machen wobei die alten Parameter wieder eingestellt werden und die Rechnung erneut durchgef hrt wird WindloadsParameters 1 g lt use gt gt lt lt use gt gt T Windloads Windloads Inst
52. d s E nucsinsessoisiineaineie snn isnie 85 A 2 Glossar der Fachdom ne 87 Versicherung der Selbssf ndiekeit ugereegt eege iaeiiai 88 ABBILDUNGEN Abbildung 1 Kontextsicht des neuen Programms 8 Abbildung 2 Abh ngigkeiten der Klassen innerhalb des Straus API Tools 10 Abbildung 3 Tiobe Programming Community Index TIOBE Software 13 Abbildung 4 Die Architektur des Straus MulttocB un 21 Abbildung 5 Grafische Benutzeroberfl che des Straus Multitools 26 Abbildung 6 Startbildschirm des Straus Multitools une 27 Abbildung 7 Die Datei configuration Xml ana EgeerEEdeg 28 Abbildung 8 Die Configuration Komponente von INNEN ua 29 Abbildung 9 Teststruktur der Configuration Komponente uusssseneseernneee 31 Abbildung 10 Klassendiagramm der History Komponente 34 Abbildung 11 Teststruktur der History Komp nente nasse 35 Abbildung 12 Strukturelle Anordnung der Oberfl chenelemente s s n sss1sssses10 40 Abbildung 13 Unterteilung des Windloads Tabs in einzelne UserControls 40 Abbildung 14 Klassendiagramm der Windloads Mission s s ssssessssensresesrsssresees 41 Abbildung 15 Initialisierung der Windloade Komponente s sssssssssssereresesrsrsresesee 43 Abbildung 16 Klassendiagramm hinter den Parametern f r die Windlasten 44 Abbildung 17 Klassendiagramm hinter dem UserControl WindloadsTable 45 Abbildung 18 Klassendiagramm hinter dem UserControl
53. der Durchstich Imple mentierung A 1 1 ONLINE QUELLEN AUS DEM LITERATURVERZEICHNIS Die online abgerufenen Quellen wurden aufgrund ihrer Fl chtigkeit in dem Zu stand gespeichert den sie bei Abruf der zitierten Information hatten Wenn allge mein auf eine Internetseite als Herkunft eines Projekts verwiesen wird wurde die Seite nicht als Quelle auf die CD aufgenommen Auch auf das Aufnehmen von verwendeter Open Source Software auf die CD wurde verzichtet Die f r das Straus Multitool verwendeten Bibliotheken sind im Quellcode Verzeichnis abge legt siehe Kapitel 0 Die Quellen wurden als PDF gespeichert obwohl sie dadurch in ihrer Form ver ndert wurden da ansonsten keine einfache Konservie rung des Zustands m glich war Die Dateien sind im Order Online Quellen auf der CD abgelegt Martin The Dependency Inversion Principle dip pdf MSDN Library 2012 Sprach bergreifende Interoperabilit t Interoperabilit t pdf IIOBE Software TIOBE Programming Community Index Tiobe pdf Wikipedia Application Checkpointing checkpointing pdf A 1 2 QUELLCODE DES PROJEKTS Der vollst ndige Quellcode der Durchstich Implementierung befindet sich auf der CD im Verzeichnis Quellcode Die Ordnerstruktur ist in Abbildung 27 darge stellt und wird im Folgenden erl utert Der Quellcode ist pro Komponente in einem eigenen Microsoft Visual Studio Pro jekt organisiert damit der berblick beim Hinzuf gen von Testprojekten trotz dem gewa
54. der den anderen Bereichen zur Verf gung steht Der windloads Bereich be rechnet die aus den eingestellten Parametern resultierenden Windlasten Damit wird er ebenfalls von verschiedenen Stellen benutzt Im den folgenden Abschnitten sollen die f nf Usercontrols der Windloads Komponente detaillierter beschrieben werden Dabei werden Elemente aus Abbil dung 14 wieder verwendet pr zisiert und teilweise in anderem Kontext darge stellt F r das bessere Verst ndnis folgt zun chst ein Exkurs zur Oberfl chentech nik WPF im NET Framework Exkurs Die Windows Presentation Foundation WPF ist eine Technik zur Beschreibung und Programmierung von Oberfl chen im NET Framework Bei dieser Technik exis tieren f r jede Oberfl chen Komponente eine XAML Datei und eine Datei in einer Programmiersprache z B in C Die XAML Datei beschreibt allgemein Formatei genschaften wie Farbe Gr e und Position der Elemente kann aber z B auch sta tische Einstellungen zur Bindung an Code Elemente beinhalten In der Datei mit dem Programmcode der sogenannten Code Behind Datei k nnen beispielsweise Ereignishandler implementiert werden die ber die Bindung zur XAML Datei bei bestimmten Oberfl chenaktionen ausgel st werden 3 4 2 1 WINDLOADSTAB In der Code Behind Datei zum windloadsTab werden die einzelnen Teile der Kom ponente initialisiert Dazu werden Instanzen von ben tigten Klassen erzeugt und diese werden miteinander verkn pft Dieser V
55. die Modelldatei ver ndert sein oder auch nicht 3 4 2 STRUKTUR Die Struktur der windloads Komponente richtet sich nach Strukturen innerhalb der Benutzeroberfl che Ein Ausschnitt ist in Abbildung 12 dargestellt Die Einbin dungsstelle in das Hauptfenster ist f r ein Mission Modul ein grafisches TabItem in dem die Ansicht des windloadsTab angezeigt wird windloadsTab ist vom Typ Usercon trol also ein benutzerdefinierte Oberfl chenelement MainWindow WaveloadsTab WindloadsTab WindloadsParameters WindloadsTable WindloadsChart Abbildung 12 Strukturelle Anordnung der Oberfl chenelemente ApplyLoadsToModel Das UserControl WindloadsTab unterteilt sich in vier weitere UserControls die eine Funktionsgruppe bilden und sich auch optisch zusammenh ngen Es handelt sich hierbei um windloadsParameters WindloadsTable WindloadsChart und ApplyLoadsToModel Die Zuordnung der Oberfl chenelemente zu den usercontrols ist in Abbildung 13 dargestellt WindloadsTab WindloadsParameters Winde mare ApplyLoadsToModel Abbildung 13 Unterteilung des Windloads Tabs in einzelne UserControls Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Mit dem Usercontrol WindloadsParameters k nnen globale Parameter f r die Wind lastenberechnung eingestellt werden windloadsTa
56. e Die Architektur Hand Dateien kopiert werden Dem soll beim Straus Multitool mit einer Installati onsroutine begegnet werden die automatisch alle notwendigen Pakete installiert die das Programm verwendet und eine Ordnerstruktur erstellt in der das Pro gramm lauff hig ist Hierf r gibt es von Microsoft verschiedene vorgefertigte Techniken Dieser Aspekt muss f r die Architektur also keine Ber cksichtigung finden und ist in der Durchstich Implementierung nicht vorgesehen 2 1 9 AUSTAUSCHBARKEIT Als letztes Kriterium nennt die DIN ISO 9126 die Austauschbarkeit Das Straus Multitool kann mit Hilfe einer Installationsroutine leicht anstelle des bisherigen Programms eingesetzt werden Daf r muss nur das alte Programm gel scht und das neue installiert werden Hierf r sind keine Ma nahmen an der Architektur erforderlich Damit wird die Relevanz dieses Kriteriums f r die Entwicklung des Programms als gering C eingestuft 2 2 PLANUNG DER ARCHITEKTUR Um sich in der Wahl des L sungsansatzes an bew hrten Techniken zu orientieren wurde eine Literaturrecherche durchgef hrt Das Ergebnis war nicht so umfang reich wie erwartet Es existieren wenige Architektur Muster es gibt viele Heuris tiken zum Software Entwurf und einige Vorgehensmodelle In diesem Abschnitt werden die gefundenen M glichkeiten kurz vorgestellt um ein Bild vom L sungsraum zu vermitteln 2 2 1 ARCHITEKTURMUSTER Als Entwurfsmuster auf Architekturebene sind d
57. e architektonische Herausforderung dar Normen der Softwareent wicklung m ssen nach Vorgabe von Overdick nicht eingehalten werden Normen f r die Lastenrechnungen flie en in die Algorithmen zur Berechnung ein und m ssen in der Umsetzung sehr penibel getestet werden spielen aber dar ber hin aus aus Architektursicht keine Rolle 2 1 4 ZUVERL SSIGKEIT Als Aspekte des Themas Zuverl ssigkeit werden in der DIN ISO 9126 die Be griffe Reife Fehlertoleranz und Wiederherstellbarkeit vorgeschlagen In Tabelle 3 werden die Begriffe n her erl utert Von Overdick wurde der Zuverl ssigkeit des Programms nur eine geringe Priorit t beigemessen Relevanz C Reife Geringere Versagensh ufigkeit durch Fehlzust nde Fehlertoleranz F higkeit ein spezifiziertes Leistungsniveau bei Soft ware Fehlern oder Nicht Einhaltung ihrer spezifizierten Schnittstelle zu bewahren Wiederherstellbarkeit F higkeit bei einem Versagen das Leistungsniveau wie derherzustellen und die direkt betroffenen Daten wieder zugewinnen Tabelle 3 Aspekte des Qualit tsmerkmals Zuverl ssigkeit Starke 2011 Eine Form von Reife kann innerhalb einer Durchstich Implementierung nicht er reicht werden Sie ist ein langfristiges Ziel das durch gute Testbarkeit gr ndliche Reviews und bersichtliches Design angestrebt wird Fehlertoleranz ist in diesem System nicht vorgesehen Beinhaltet das Modell Feh ler oder ist ein Teilsyste
58. e ausf hrlich auszuarbeiten w rde ber den Rahmen dieser Arbeit hinausgehen Durch die f r sp ter ange setzten Anforderungen sind allerdings schon einige wichtige geplante Erweite rungen bekannt Diese sollen hier kurz betrachtet werden REQ 001 fordert eine modulare Bauform des Programms Das Straus Multitool soll problemlos durch neue Module die eine bestimmte Aufgabe erf llen erwei tert werden k nnen Dies ist durch die Konzipierung der Mission Komponenten umgesetzt worden Dabei wurde keine Plugin Architektur implementiert in dem Sinne dass ein Hauptprogramm erg nzende Plugin Komponenten automatisch einbinden w rde Die Mission Komponenten werden direkt geladen die nde rung zur Einbindung einer neuen Mission ist aber nur an einer Stelle des Quell codes erforderlich Dies wirkt sich positiv auf die Flexibilit t aus weil der Pro grammierer bei jeder neuen Mission Komponente entscheiden kann ob sie in einen Tab eingebunden werden ein neues Fenster ffnen oder einfach im Hintergrund ausgef hrt werden soll Anforderungen deren Umsetzung durch Einf hrung der Mission Komponente einfach m glich werden sind REQ 045 Wellenlasten gene rieren und damit REQ 024 Waveloads dll und REQ 037 Extreme Lasten aus w hlen Hinzu kommen die Anforderungen REQ 029 Joint Check REQ 028 Beam Buckling Check REQ 030 Auffinden von unverbundenen St ben REQ 033 Selektieren von St ben bestimmter L nge
59. e die Komponente als Blackbox betrachten sich also nur die u ere Schnittstelle beziehen sind in Tabelle 8 aufgef hrt Diese Testf lle bezie hen sich auf den Zustand der XML Datei sind also Integrationstests Hier kann die Klasse xMLconfigurationManager nicht ersetzt werden sondern ist im Gegenteil wichtigster Gegenstand der Tests Diese Testf lle lassen sich mit Hilfe des NUnit Testframeworks implementieren sind aber streng genommen keine Unit Tests da mehrere Klassen gleichzeitig getestet werden und dabei unmittelbar auf eine Datei zugegriffen wird Test Arrangieren Agieren Best tigen fall 1 G ltige XML Datei getValue key noSuchKeyException ohne Eintr ge 2 Ung ltige XML Datei getValue key Exception 3 Keine XML Datei getValue key Exception 4 G ltiges Key Value getValue key Value wird zur ck Paar in XML Datei gegeben 5 G ltige XML Datei getValue notExistingKey noSuchKeyException mit Key Value Paaren 6 G ltige XML Datei getValue key Exception mit einem Paar Value zu lang f r den Daten typ String 7 G ltige XML Datei changeValue key value noSuchKeyException ohne Eintr ge Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten 8 Ung ltige XML Datei hangeValue key value Exception 9 Keine XML Datei changeValue key value IOException 10 G ltige XML Datei changeValue key val
60. e f r Strukturmodelle Literatur Strand Pty Ltd Strand website Online 2 Oktober 2011 http www strand com Straus7 Software API Manual Sydney Strand Pty Limited 2010 Szyperski Clemens Grundtz Dominik und Murer Stephan Component software Buch Harlow Pearson Education 2002 TIOBE Software TIOBE Programming Community Index Online 12 Februar 2012 http www tiobe com index php content paperinfo tpci index html Wikipedia Application checkpointing Online 16 Januar 2012 http en wikipedia org w index php title Application_checkpointing amp oldid 4683 52446 Wirfs Brock Rebecca und McKean Alan Object Design Buch Boston Pearson Education 2002 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang A ANHANG Der Anhang zu dieser Arbeit ist in elektronischer Form auf einer CD abgelegt Diese kann beim Pr fer Prof Dr Thomas Lehmann eingesehen werden A 1 LISTE DER ANFORDERUNGEN In diesem Kapitel werden die bei der Anforderungsanalyse ermittelten Anforde rungen aufgef hrt Die Notation der Anforderungen ist in Kapitel 1 5 erkl rt F r einen berblick ber die geplanten Funktionen des Straus Multitools sollte auch zuerst dort nachgelesen werden Dom nenspezifische Begriffe k nnen in Anhang A 2 Glossar der Fachdom ne nachgeschlagen werden Die Struktur dieses Kapitels orientiert sich an den Vorschl gen der Norm IEEE 830 IEEE Computer So
61. ea ee 2 1 4 Bestehender L sungsansatz au nn 3 LE 3 1 5 1 ee 4 1 5 2 Nicht funkbionale Aspekte ae 5 1 5 3 Merkmale des Straus Multitools u neuen 6 1 6 Aufbauder Arpetaren ea 6 2 Die SICH ine EE eaa aeaii Eesaia et Fresken 8 2 1 Qualit t der Sokware Architektur une ne 9 ett Meester 10 22V east 11 2 1 3 Fink Dale een en 12 2 14 Zuverl ssigkeit een ee 14 EE ernennen 15 SAU E VRR RER FIEBER E E EE MEN RERSN AARAU 15 Ch BEE E 16 21 8 bertragbarkeit een enge 17 2 129 Austauschbaekeit anne neh 18 2 2 Planang der Archiieck n ers a ee 18 2 2 1 Architekt rm stert een 18 2 2 2 Komponenten nee a aia aaia 19 220 QUASSA EE 20 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle 1V 2 Die Komponenten as 20 2 3 1 Configuratio ee ee ie ee 22 E ER EE energie 23 Se EE a A E E EEES 23 2 35 eerste ee 24 EE Ee Ee 25 PAS ER Un UT 1 174 9 E 27 3 Beschreib ng der Komponenten sisiesrreseiisenssoniiinna ie iasi ies 28 3 1 Conlieuraton Komponente nen ea 28 3 1 1 Vor und Nahbedingungn un een 28 RM DAB E 29 KR EN nee 30 3 12 Desishenisch DE nennen 32 KR EN 34 3 2 1 Vor ER iirinn 34 TE 34 323 EN nenne 34 3 24 Desipnentscheidungen E 35 KE arena RERA 37 3 3 1 Vor E 37 II EE Eeer 37 Steechen eegene EES 38 3 34 Desssnenischeidungen unse ee 38 3 4 items 39 gt 41 Vor und Nachbeding ungen EE 39 Se E A0 3 4 3 E EE 47 34A Desisnentscheidungen anne 49 Architekt
62. echnische Konzepte beschrieben die Komponenten bergreifend f r die Architektur relevant sind Auch Aspekte die auf Design und Implementierungsebene f r alle Komponenten wichtig sind werden hier vorge stellt Mit dieser Abschlussarbeit hat die Implementierung der neuen Software erst be gonnen Deshalb werden in Kapitel f nf die bisher erreichten Arbeitsschritte zu sammengefasst und bewertet Au erdem wird ein Ausblick auf die zuk nftige Entwicklung gegeben Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Em Die Architektur 2 DIE ARCHITEKTUR Nach Len Bass Paul Clements und Rick Kazman ist die Software Architektur ei nes Programms dessen Struktur Dazu geh ren die Software Elemente deren von au en sichtbare Schnittstellen und die Beziehungen dieser Elemente untereinan der Bass et al 2003 Weiterhin sagen die Autoren dass Architektur die h chste Ebene des Designs ist Damit umfasst der Begriff Design den vollst ndigen Entwurf die Architektur ist ein Teil des Designs Nach dieser Definition soll in diesem Kapitel die Architektur der neuen Anwendung beschrieben werden Alle weiteren Designentscheidungen finden Platz in den Kapiteln 3 und 4 Zum Entwurf der Architektur ist es wichtig sich ber die Systemgrenzen klar zu sein Dazu zeigt Abbildung 1 die Kontextsicht des Programms Es sind das Nach barsystem Straus7 die Zusammenh nge zu Dateien sowie die Interaktionen mit den Benutzer
63. ein REQ 022a Windloads Lastf lle generieren DIN 2 Straus API Tool Das Windloads Modul soll Lastf lle nach DIN 1055 generieren k nnen Dabei sol len die folgenden Parameter frei einstellbar sein in Klammern stehen die vorein gestellten Werte Gel ndekategorie 0 Windzone 3 Vref 30 m sec qre 0 56 kN m Probability of Exceedence 0 98 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang Hinzu kommen die fett gedruckten Parameter die auch in REQ 022 aufgef hrt werden Die Kombination der Parameter soll nicht speicherbar sein amp Durchstich Straus API Tool REQ 022b Windlasten anzeigen Die generierten Windlasten k nnen in einer Tabellenansicht berpr ft werden Eine Grafik zeigt die aus den eingestellten Parametern resultierenden Windlasten D Durchstich Straus API Tool REQ 022c Windlasten speichern Der Benutzer kann die berechneten Lasten in einem neuen oder einem vorhande nen Lastfall in der Modelldatei abspeichern siehe REQ 020 A 1 2 3 3 WEITERE LASTPR FUNGEN hnlich wie die Module Waveloads und Windloads sind Module wie der Beam Buckling Check und der Joint Check auch Pr fungen der Modellstabilit t durch Lastaufbringung Die Implementierung dieser beiden Module ist f r sp ter ge plant REQ 028 Beam Buckling Check Z sp ter Straus API Tool Das Programm s
64. eine umst ndliche Umwandlung der Werte in nerhalb der Komponente bedeutet h tte Das Format in dem ein Schl ssel Wert Paar gespeichert werden soll w re immer eingeschr nkt durch die von IConfigura tion vorgegebenen Datentypen Werden aber alle Schl ssel und Werte einheitlich als Strings behandelt kann die Umwandlung und Interpretation der Werte au er halb der Komponente erfolgen und jeder Nutzer der Configuration Komponente kann sich sein eigenes Zahlenformat definieren und den erhaltenen String selbst interpretieren Einf hrung der IconfigurationManager Schnittstelle Diese Schnittstelle wurde ein gef gt damit die Klasse Configuration mit Hilfe von Unit Tests getestet werden kann So kann der Teil der Komponente der f r den Dateizugriff zust ndig ist durch einen Stub ersetzt werden damit die Configuration Klasse isoliert ist Keine Verwendung des Singleton Musters Das Singleton Muster scheint sich gerade im Infrastructure Layer anzubieten Komponenten die eindeutig und ein zigartig sein sollen und die von nahezu allen anderen Komponenten benutzt wer den sind perfekte Kandidaten f r dieses Muster Generell spricht aber gegen Sin gletons dass sie zum Testen nicht durch Fake Objekte ersetzt werden k nnen Sie k nnen also nicht ausgetauscht werden was ein sinnvolles Unit Testen ohne den Einsatz eines Mock Frameworks unm glich macht Diese Entscheidung gilt f r alle Komponenten im Infrastructure Layer Kein Def
65. en h lt Auslagern von API Aufrufen in eigene Methoden Diese Entscheidung wurde ausf hrlich im Abschnitt Testbarkeit erl utert Der Grund f r die Auslagerung ist dass die ausgelagerten Methoden wenn sie als virtual gekennzeichnet werden von einer erbenden Klasse berschrieben werden k nnen Damit werden die an deren Methoden dieser Klasse f r Unit Tests isolierbar und testbar 3 5 MODELMANAGEMENT Diese Komponente wird nur einmal instanziiert weil nur ein Modell zurzeit ge ffnet sein kann Sie ist f r das ffnen Speichern und Schlie en der Modelldatei zust ndig REQ 026 und REQ 050 Dazu werden die Funktionen der Straus API genutzt REQ 023 Au erdem werden beim ffnen einer Datei die enthaltenen Einheiten gesichert und mit dem Speichern der Datei wieder hergestellt damit die Einheiten Einstellungen in der Modelldatei f r den Benutzer unver ndert bleiben Die m glichen Fehler wie Datei bereits ge ffnet Keine Datei mit diesem Na men etc werden als Exception verpackt und an den Aufrufer weitergegeben 3 5 1 VOR UND NACHBEDINGUNGEN Um diese Komponente nutzen zu k nnen muss eine g ltige Straus API Lizenz vorhanden und registriert sein Das Straus Programm muss installiert sein Nach Verwendung der Model Management Komponente kann je nach Reihenfolge und Art der benutzten Methoden das Programm in einem beliebigen Zustand sein Siehe dazu auch das Zustandsdiagramm in Abschnitt 3 5 4
66. er Configuration Komponente einfach eingef hrt werden Dazu k nnten eindeutige Schl ssel als Platzhalter definiert werden die in den nachfolgenden XML Tags in unterschied liche Sprachen bersetzt werden Zwei nderungen die nicht zwangsl ufig leicht umsetzbar w ren sind das Aus tauschen der vorhandenen Logging Bibliothek Log4NET und nderungen in der Straus API Letzteres wird aber durch die Auslagerung der Straus Aufrufe in ei gene Methoden siehe Kapitel 3 3 erleichtert da nur diese Methoden an sich n dernde Straus Funktionen angepasst werden m ssten Anhand der vorangegangenen Betrachtungen l sst sich schlie en dass das Straus Multitool nach aktuellem Kenntnisstand sehr gut erweiterbar ist Einschr nkun gen gibt es lediglich im Bereich der Austauschbarkeit der Log4NET und der Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Fazit Straus7 Komponente Eine nderung in einer dieser Komponenten durch ein Up date der Bibliotheken w rde nur dann einen gr eren Anpassungsaufwand mit sich bringen wenn die neue Version nicht abw rtskompatibel ist Beide Szenarien werden aber nicht als wahrscheinlich eingestuft 5 1 2 TESTBARKEIT A Das System soll leicht zu testen sein Dies ist vor allem in den Programmteilen wichtig in denen es um die sicherheitsrelevanten Berechnungen geht Aber auch Infrastruktur Komponenten auf die sich das System verl sst sollten gut getestet sein An allen
67. erf gung vgl REQ 023 i Durchstich REQ 019 Geometriedaten einlesen Straus API Tool Das Programm soll die Geometriedaten eines Straus Modells Dateiendung st7 ber die Straus API einlesen interpretieren und in einer geeigneten Form anzei gen k nnen Die Anzeige kann z B eine Tabellenansicht von Daten oder die 3D Ansicht des Modells sein vgl REQ 014 je nach Anwendungsbereich D Durchstich REQ 026 Modell ver ndern und speichern Straus API Tool Das Programm soll das Modell anpassen k nnen und in der Lage sein es ver n dert abzuspeichern Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang D Durchstich FLO REQ 050 Modell schlie en Eine Modelldatei soll geschlossen werden k nnen damit ein anderes Modell ge ffnet und bearbeitet werden kann ohne dass das Programm neu gestartet wer den muss A 1 2 3 LASTENAUFBRINGUNG In diesem Abschnitt soll auf die Anforderungen eingegangen werden die sich mit der Aufbringung von Lasten auf ein Straus Modell besch ftigen Die Lasten wer den ebenso wie die Geometriedaten in der Straus Modelldatei gespeichert Zugriff darauf bietet die Straus API siehe REQ 023 D Durchstich Straus API Tool REQ 020 Lastf lle verwalten Die Lastf lle und Lastfallkombinationen zu einem Modell sollen geladen gespei chert und angezeigt werden k nnen Au erdem so
68. estf lle f r die History Komponente aus Blackbox Sicht 35 Tabelle 10 Code Komplexit t der Programme nach Steve McConnell 2 20 2 64 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Eine Einleitung 1 EINLEITUNG Diese Arbeit beschreibt die Neuentwicklung der Software Architektur eines Pro gramms zur Verifikation von Strukturmodellen im Offshorebereich Als Basis f r die Neuentwicklung dient eine existierende Software die in ihrem Funktionsum fang erweitert und um zus tzliche Qualit tsmerkmale wie z B Erweiterbarkeit und Testbarkeit erg nzt werden soll Nach einer Aufwandsabsch tzung f r eine Erweiterung der existierenden Software einerseits und einer Neuentwicklung auf Grundlage der bestehenden Funktionalit t andererseits wurde die Entscheidung zugunsten der Neuentwicklung getroffen Die neu entwickelte Architektur wird als Durchstich implementiert um damit exemplarisch zu belegen dass alle geforderten Qualit tsmerkmale erf llt werden Ein Schwerpunkt der Anforderungen an die neue Software ist die einfache Erwei terbarkeit um neue Funktionen Um die Erf llung dieser Anforderung zu belegen wird ein Funktionsbereich mit allen wesentlichen Strukturen implementiert der als Vorlage f r alle weiteren Funktionsbereiche dienen kann Dadurch wird der Nachweis gef hrt dass sich die Software leicht um diese Aspekte erweitern l sst ohne dass grundlegende nderungen in den Konzepten notwe
69. ethode gez hlt werden Dabei erh lt jede Methode eine initiale Komplexit t von eins zus tzlich erh ht sich die Komplexit t um eins f r jede Aufteilung des Ausf hrungspfads durch if else for oder while Au erdem wird der Wert f r jeden logischen Operator wie amp amp oder in einem logischen Statement um eins erh ht F r jede M glichkeit einer switch Anweisung wird die Komplexit tszahl auch um eins erh ht hinzu kommt je eine Erh hung um eins bei den Schl sselw rtern break goto return throw continue catch und except Das Ergebnis der Berechnung zeigt Tabelle 10 maximale mittlere Komplexit t Komplexit t Straus API Tool 108 5 06 Straus Multitool 19 1 74 Tabelle 10 Code Komplexit t der Programme nach Steve McConnell Es ist deutlich zu sehen dass nach dieser Berechnung der Komplexit t das Straus Multitool besser abschneidet Teilweise l sst sich dies darauf zur ckf hren dass bei der Durchstich Implementierung noch nicht alle Eventualit ten ber cksichtigt wurden Trotzdem ist dies durch die gro e Differenz als gutes Ergebnis zu werten Auch die Einr cktiefe l sst R ckschl sse auf die Komplexit t des Quellcodes zu Die maximale Einr cktiefe des Straus API Tools ist h her als neun h here Werte werden nicht gemessen beim Straus Multitool liegt dieser Wert bei f nf Die mitt lere Einr cktiefe liegt bei 1 83 Einr ckungen w hrend sie beim Straus API Tool Architektu
70. f hrungsphase sichergestellt F r die Angemes senheit existieren keine quantitativen Anforderungen seitens der Firma Es wer den aber Ideen festgehalten wie die Genauigkeit der Rechnungen langfristig ver bessert werden kann Da die Rechnungsgenauigkeit nicht im Fokus dieser Arbeit liegt werden diese noch nicht implementiert F r den Aspekt Interoperabilit t ist wichtig dass das Programm sowohl mit Straus7 zusammenarbeiten soll als sich auch langfristig in den betrieblichen Ab lauf bei Overdick einpassen soll Das Programm soll eng mit der Software Straus7 zusammenarbeiten Dazu stellt die Firma Strand eine Programmierschnittstelle bereit die mit Delphi C C Matlab VisualBasic verschiedene Versionen und Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur VBA und Fortran angesprochen werden kann vgl Straus7 Software 2010 Der Entwickler des Straus API Tools hat sich f r die Programmiersprache Visual Basic NET entschieden Um sich auch auf die Kenntnisse dieses Entwicklers st tzen zu k nnen und diesen sp ter bei der Implementierung mit einbeziehen zu k nnen soll weiterhin mit dem NET Framework entwickelt werden Dieses unterst tzt mehrere Sprachen die ber eine gemeinsame Zwischenschicht problemlos mitei nander kommunizieren k nnen vgl MSDN Library 2012 Um die Sprache festzulegen mit der das neue Programm entwickelt werden soll spielt hier die Verbreitung bzw
71. geraten ist In dieser Situation kann das Programm nicht weiter arbeiten Siedersleben 2004 Johannes Siedersleben bezeichnet den Umgang mit Fehlern und Ausnahmen als eines der wichtigsten Themen der Software Architektur Siedersleben 2004 Deshalb sollte prinzipiell gut berlegt sein wie mit diesem Thema innerhalb der Architektur umgegangen werden wird Siedersleben stellt ein Muster Vorschlag unter Verwendung einer Sicherheitsfassade und einer Diagnose und Reparatur Schnittstelle f r jede Komponente vor Allerdings schr nkt er ein Nicht jede Komposition braucht eine Sicherheitsfassade In kleinen und mittleren Systemen wird eine einzige Sicherheitsfassade f r den gesamten Anwendungskern ausrei chen Siedersleben 2004 F r das hier entwickelte Straus Multitool wurde folgende Vorgehensweise ge w hlt Auf den unteren Ebenen werden nur Fehler aufgefangen und behandelt Diese Fehler werden in der Software als Exception abgebildet In Form einer neu en Exception mit einer Beschreibung der Umst nde und dem Ort des Auftretens wird der Fehler weiter gereicht Fehler sind Probleme die der Benutzer beheben kann wie das Fehlen einer g ltigen Straus Lizenz fehlerhafte Modelldatei etc Diese Fehler werden dann auf der Pr sentationsschicht dem Benutzer mitgeteilt Die lokale Bearbeitung von Fehlern l sst sich dadurch begr nden dass ihre an gemessene Behandlung dem Entwickler im Kontext eines Methodenaufrufs deut lich
72. gruppe festgelegt werden und das Attribut S V st ndig ver nderlich gesetzt werden k nnen Eine beispielhafte Tabelle ist in Abbildung 25 dargestellt Aus den Angaben in der Tabelle sollten dann automatisch die Lastfall Kombinationen DIN Lastgruppe e LFI LF2 LF4 Lastfall 1 Eigengewicht S e LFI LF2 LF5 Lastfall 2 Wind x V 1 e LF1 LF3 LF4 Lastfall 3 Wind y V 1 e LF1 LEF3 LF5 Lastfall 4 Welle x V 2 Lastfall 5 Welle y V 2 generiert werden Damit wird Abbildung 25 Eingabe zum Generieren von Lastfall das Eigengewicht immer be Kombinationen Beispiel r cksichtigt und es werden alle m glichen Kombinationen gene riert mit R cksicht darauf dass Lastf lle innerhalb einer Lastgruppe nicht ge meinsam auftreten k nnen entweder kommt der Wind aus der x Richtung oder aus der y Richtung A 1 2 3 1 WAVELOADS Eine wichtige Funktion des Straus Multitools soll das Generieren von Wellenlas ten sein die auf das Modell aufgebracht werden k nnen Die damit zusammen h ngenden Anforderungen werden in diesem Abschnitt beschrieben ZS sp ter REQ 045 Waveloads Lastf lle generieren Straus API Tool Das Waveloads Modul soll Lastf lle generieren k nnen Dabei sollen verschiedene Parameter frei einstellbar sein Die Parameter sind dem Straus API Tool zu ent nehmen und im Detail mit den Mitarbeitern von Overdick abzusprechen A sp ter REQ 007 Konfigurationen speic
73. h D und Wilson Welsh Patrick FitNesse User Guide Online 26 Januar 2012 http fitnesse org FitNesse UserGuide Martin Robert Object Mentor Online The Dependency Inversion Principle 26 Januar 2012 http www objectmentor com resources articles dip pdf McConnell Steve Code Complete Buch Redmond Microsoft Press 1993 McConnell Steve Code Complete 2 Buch Redmond Microsoft Press 2004 Microsoft Patterns amp Practices Team Microsoft Application Architecture Guide Buch s 1 Microsoft Press 2009 Microsoft Research Moles Isolation framework for NET Software http research microsoft com en us projects moles s n MSDN Library Sprach bergreifende Interoperabilit t Online Microsoft 2012 10 Februar 2012 http msdn microsoft com de de library a2c7tshk aspx Osherove Roy The Art of Unit Testing Buch Heidelberg mitp 2010 Poole Charlie Cansdale Jamie und Feldman Gary NUnit org Online 26 Januar 2012 http www nunit org Siedersleben Johannes Moderne Softwarearchitektur Buch Heidelberg dpunkt 2004 Spillner Andreas und Linz Tilo Basiswissen Softwaretest Buch Heidelberg dpunkt 2003 Starke Gernot Effektive Software Architekturen Buch M nchen Hanser 2011 Starke Gernot und Hruschka Peter Software Architektur kompakt Buch Heidelberg Spektrum Akademischer Verlag 2011 Architektur Reengineering einer Verifikationssoftwar
74. he da zu auch Fowler 2005 und Kapitel 2 3 2 1 8 BERTRAGBARKEIT Als n chstes Qualit tskriterium nennt die DIN ISO 9126 die bertragbarkeit Da zu werden als Unterpunkte Anpassbarkeit Installierbarkeit und Konformit t vor geschlagen Beschreibungen dieser Begriffe sind in Tabelle 7 angegeben Anpassbarkeit Software an verschiedene festgelegte Umgebungen anpassen Installierbarkeit Aufwand der zum Installieren der Software in einer festgeleg ten Umgebung n tig ist Konformit t Grad in dem die Software Normen oder Vereinbarungen zur bertragbarkeit erf llt Tabelle 7 Aspekte des Qualit tsmerkmals bertragbarkeit Starke 2011 Abgesehen von dem Aspekt Installierbarkeit ist die bertragbarkeit f r das Straus Multitool nicht relevant Das Programm soll nur firmenintern verwendet werden Dabei ist klar dass auf den Arbeitsplatz Rechnern ein Microsoft Windows Betriebssystem laufen wird aktuell Windows XP oder Windows 7 Da mit ist die Lauff higkeit von unter NET entwickelten Programmen gesichert F r das Straus Multitool ergibt sich damit insgesamt eine Relevanz auf B Niveau Die Installierbarkeit ist ein wichtiger Aspekt siehe auch REQ 017 gerade vor dem Hintergrund dass das Straus API Tool hierbei Probleme bereitet Nicht ber all l uft das Programm beim ersten Versuch und es m ssen vom Benutzer per Architektur Reengineering einer Verifikationssoftware f r Strukturmodell
75. hern Meetingprotokoll vom 24 5 2011 Eine einmal eingestellte Kombination von Parametern f r die Berechnung der Windlasten sollte als Konfiguration speicherbar sein Eine so gespeicherte Konfi guration sollte einfach auch wieder geladen und durch einen eindeutigen Namen identifiziert werden k nnen REQ 037 Extreme Lasten ausw hlen Straus API Tool Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang A sp ter NW Nach Generierung der Lastf lle und Berechnung der Ergebnisse sollen die ext remsten Lasten im Modell als neue Kombination abgespeichert werden A 1 2 3 2 WINDLOADS Ein weiteres Modul soll Windlasten generieren k nnen Die zugeh rigen Anforde rungen werden in diesem Abschnitt beschrieben REQ 022 Windloads Lastf lle generieren DNV D Durchstich Straus API Tool Das Windloads Modul soll Lastf lle nach der Norm DNV RP C205 generieren k nnen Dabei sollen verschiedene Parameter frei einstellbar sein in Klammern stehen die voreingestellten Werte Reference Height 10m Average Time 3 sec Reference Time 10 sec Reference Wind Speed 30 m sec Wind Spreading 0 Density of Air 1 2260 kg m Gravity Direction Z Direction negative axis Translation 0 mm Marine Growth Thickness 10 cm Height of natural cover minimal height an maximal height Die Parameterkombinationen sollen nicht speicherbar s
76. hrt bleibt Mit einer Ausnahme sind die in der Abbildung rechts darge stellten Ordner jeweils einer Komponente zugeordnet Lediglich der Ordner StrausMultitool enth lt sowohl die Initialization Komponente als auch die Am bience Komponente Projekt StrausMultitool In jedem Ordner befindet sich eine Visual Studio Projektmappe in der die rechts als Papiere dargestellten Pro jekte organisiert sind Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle ae Anhang configuration xml Data Quellcode StrausMultitool g j D h StrausMultitool log L A Initialization W WindloadsComponent UI WindloadsTab ModelScratchFolder W 1 WindloadsComponent externalLibraries j WindloadsPreferences x Ki 1 WindloadsTable Fa sl U WindloadsGraph DynamicDataDisplay Log4NET 1 ApplyLoadsToModel ModelManagementComponent HI ModelManagementComponent Straus7 Lil Straus7 HistoryComponent HI HistoryComponent Configuration U e e gt Configuration Abbildung 27 Struktur des Quellcodes Zus tzlich zu den dargestellten Projekten sind Testprojekte angelegt worden Je des Projekt wird beim Kompilieren zu einer Bibliothek bersetzt Diese werden wiederum von anderen Projekten verwendet Links in der Darstellung ist der Ordner Data abgebildet In ihm wurden zus tz liche Daten abgelegt Dazu z hlen externe Bibliotheken die Protokolldateien die von Log4NET angelegt werden
77. ich laut der DIN ISO 9126 nach zwei Kriterien Zeitverhalten Antwort und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausf hrung Verbrauchsverhalten Anzahl und Dauer der ben tigten Betriebsmittel f r die Erf llung der Funktionen Tabelle 5 Aspekte des Qualit tsmerkmals Effizienz Starke 2011 Da es f r beide Effizienz Kriterien keine Zahlenvorgaben von Seiten des Unter nehmens gibt sie aber insgesamt f r die Benutzer eine wichtige Rolle spielen wird Effizienz nur als allgemeines Ideal im Rahmen der Implementierung ber ck sichtigt Siehe hierzu auch REQ 015 Eine Entscheidung die sich positiv auf das Zeitverhalten auswirkt wurde aller dings auf der Architekturseite getroffen Das Modell wird nicht mehr vollst ndig in den Arbeitsspeicher geladen wie es beim Straus API Tool der Fall war Statt dessen wird nur der Teil dessen Daten f r die aktuelle Aufgabe notwendig sind eingelesen und verarbeitet So werden l ngere Lade und Aktualisierungszeiten gespart 2 1 7 NDERBARKEIT Unter dem Begriff Erweiterbarkeit wurde dieses Kriterium schon in der Aufga benstellung als wichtig beurteilt Relevanz A Als Aspekte des Qualit tsmerk mals nderbarkeit schl gt die DIN ISO 9126 Analysierbarkeit Modifizierbar keit Stabilit t und Pr fbarkeit vor Die Begriffe werden in Tabelle 6 erkl rt Analysierbarkeit Aufwand um M ngel oder Ursachen von Versagen zu Diag no
78. icklern erm glichen sich auf die fachlichen Aspekte des Systems zu konzentrie ren w hrend die Infrastrukturschicht die Komplexit t der technischen Infra struktur kapselt Zur technischen Infrastruktur geh ren e Persistenz und Datenhaltung e Physikalische Infrastruktur Schnittstellen zur Hardware e Integration von Fremdsystemen e Sicherheit e Kommunikation und Verteilung Hinweis Alle Komponenten nutzen die log4net Schnittstelle Presentation Layer i i lt lt instantiate gt gt lt lt component gt gt 8 lt lt component gt gt a lt lt use gt gt lt lt component gt gt s Initialization Ambience Ir Mission IHistory IConfiguration Domain Layer IManageModel IModel History IConfiguration lt lt use gt gt lt lt component gt gt a Straus7 lt lt component gt gt lt lt component gt gt Configuration History Abbildung 4 Die Architektur des Straus Multitools Nach Gernot Starke und Peter Hruschka entstehen sinnvolle Architekturen nur in iterativen Entwurfsprozessen Starke et al 2011 Es wird also ein Entwurf f r eine Architektur ausgearbeitet dieser Entwurf wird gepr ft per Durchstich um gesetzt und aus den so gewonnenen Erfahrungen entsteht ein neuer Entwurf Die sen Vorgang bei dem die interne Struktur der Software ge ndert wird ohne ihr beobachtetes Verhalten zu ndern nennt man Refaktorisierung vgl Fowler 2005 Architektur Reengineeri
79. il einige Vorgaben der Straus Entwickler eingehalten werden m ssen Zuerst einmal ist die Programmiersprache VisualBasic NET weil die API nach Auskunft der Entwickler nicht korrekt in C eingebunden werden kann Zum anderen unterscheidet sich ihre Struktur stark von der anderer Komponenten siehe hierzu auch Abschnitt 3 3 2 Struktur 3 3 1 VOR UND NACHBEDINGUNGEN Um die Straus API verwenden zu k nnen muss die Straus7 Software auf dem Arbeitsplatzrechner des Benutzers installiert sein und ber eine g ltige Lizenz verf gen Die Installation von Straus soll Vorbedingung der Installation des neuen Programms sein die g ltige Lizenz muss bei jedem Programmstart berpr ft werden weil sich die Lizenz auf einem USB Stick befindet Ist dieser nicht einge steckt funktioniert die Straus API nicht und das Straus Multitool kann nicht sinn voll arbeiten Die berpr fung wird in der Initialization Komponente bernom men Anschlie end ruft die ModelManagement Komponente die Initialisierungsfunk tion der Straus API auf die vor der Verwendung aller anderen API Funktionen aufgerufen werden muss bevor eine Straus Datei ge ffnet wird Vorher d rfen keine Benutzerfunktionen aktiviert sein die die Straus API verwenden weil sich diese sonst in einem undefinierten Zustand befindet Nach der Verwendung der Straus7 Komponente darf keine Straus Datei mehr ge ffnet sein und die Schnittstelle muss mit Sst7Release freigegeben worden sein
80. im Abschnitt zur straus Komponente beschrieben erweist sich das Testen von Methoden die auf die Straus APl zugreifen als umst ndlich Die ge w hlte Vorgehensweise soll im Folgenden anhand des Unit Tests f r die windloads Klasse exemplarisch gezeigt werden da diese f r die sicherheitsrelevanten Be rechnungen zust ndig ist In Abbildung 20 ist die Klassenstruktur f r den Test dargestellt Win dloads Windloads parameters Parameters units int modella int fig I fi ti globalMarineGrowth double config IConfiguration windDirection double calculateWindSpeed_DNV double airDensity double calculateWindPressure_DNV doubl globalShapeCoefficient double takulsleShapeConflcisri_DINVIE averagingTime double calculateWindForces_DNV Beam b lt lt Interface gt gt referenceTime double calculateProfileProjection_DNV do IConfiguration referenceWindSpeed double readGravityDirection string count int referenceHeight double adjustUnits getValue String key string positive bool calculateWindloads_DNV List bea changeValue string key string newValue d 4 TestableWindloads gravityDirection string gravityDirectionOK bool lt lt instantiate gt gt adjustUnitsOK bool lt lt call gt gt readGravityDirection string ee adjustUnits calculateProfileProjection_DNV double Beam beam double Abbildung 20 Testbarkeit der Windloads Kla
81. indSpeed_DNV double calculateWindPressure_DNV doubl lt use gt gt calculateShapeCoefficient_DNV B calculateWindForces_DNV Beam b beamNumber int calculateProfileProjection_DNV do propertyName string readGravityDirection string profileType string adjustUnits shapeCoefficient double calculateWindloads_DNV List bea Kup windSpeed double modelid int projection double applyLoadsToNewLoadcaselistring lo length double applyLoadsToLoadcase int badcase height double D Loadcase name string number int Z u forces double Abbildung 14 Klassendiagramm der Windloads Mission Die hier benannten Strukturen finden sich auch im Klassendiagramm der Kompo nente wieder Die wesentlichen Elemente sind in Abbildung 14 dargestellt Zentra ler Ausgangspunkt der Struktur ist auch hier windloadsTab Die Klasse enth lt Refe renzen auf alle Einstiegspunkte in tiefere Ebenen Im Wesentlichen sind auch die anderen Bereiche der Komponente nach usercontrols aufgeteilt Eine Ausnahme bilden die Bereiche Instructions und windloads Mit der InstructionFactory wurde Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten f r alle Elemente eine zentrale Stelle geschaffen an der zur cknehmbare Kom mandos instanziiert werden Damit bietet dieser Bereich einen Querschnittsser vice
82. iner eigenen Mission Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur Komponente implementiert F r den Durchstich soll hier stellvertretend f r alle noch kommenden Mission Komponenten die Berechnung der Windlasten REQ 022 und REQ 022a c implementiert werden Jedes Mission Modul hat seine eigenen Oberfl chenelemente die im Rahmen des Hauptprogramms angezeigt werden sodass die Funktionen dem Benutzer zur Verf gung stehen sobald diese Mission Komponente instanziiert und geladen wurde 2 3 5 MODELMANAGEMENT Die ModelManagement Komponente ist f r das ffnen Schlie en und Speichern des Straus Modells zust ndig REQ 026 und REQ 050 Sie greift dazu auf die Straus7 Komponente zu und nutzt f r diese Zwecke bereitgestellte Funktionen Pro In stanz der ModelManagement Komponente kann nur ein Modell gleichzeitig ge ffnet sein Da sich die Komponente ausschlie lich mit der Fachdom ne besch ftigt wird sie in dieser Schicht eingeordnet Es stehen zwei verschiedene Schnittstellen zur Verf gung die beide von der Komponente implementiert werden um f r verschiedene Perspektiven jeweils den optimalen Zugriff zur Verf gung zu stellen Von der Oberfl che her Ambience Komponente siehe Abschnitt 2 3 6 sollen ffnen Speichern und Schlie en unter st tzt werden Dies geschieht ber das Interface IModelManager das die folgenden Methoden und Felder vorschreibt int id get
83. ist es zu verstehen Auch nderungen k nnen leichter realisiert werden da Bausteine einfach ausgetauscht oder hinzugef gt werden k nnen Die Bausteine der h chsten Ebene sind die Komponenten Um eine m glichst ge ringe Abh ngigkeit zu erreichen werden Klassen zu Komponenten zusammenge fasst die ihrerseits Schichten zugeordnet werden Zur Einteilung der Architektur in Schichten dient der Standard Vorschlag f r Softwareschichten von Gernot Starke als Orientierung siehe auch Starke 2011 S 143ff Dieser Vorschlag sieht das Vorhandensein der folgenden Schichten vor e Pr sentation e Applikationsschicht optional e Fachdom ne e Infrastruktur F r die neue Architektur wurden die drei nicht optionalen Schichten Pr sentation Fachdom ne und Infrastruktur bernommen Der Vorteil des Schichtenmodells ist unter anderem in der Vorschrift begr ndet dass m glichst nur von h heren Schichten auf niedrigere Schichten zugegriffen wird Dadurch werden zyklische Abh ngigkeiten vermieden und das System bleibt flexibel Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur Der Standard Vorschlag f r Software Schichten von Gernot Starke beinhaltet fol gende Beschreibungen zu den einzelnen Schichten Die Pr sentationsschicht ent h lt nur Funktionen der Benutzeroberfl che Damit kann bei Bedarf die konkrete Benutzeroberfl che leicht ausgetauscht werden Die Fachdom ne soll den Ent w
84. klarer ist als wenn die Behandlung zentralisiert w re Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle i Technische Konzepte Benutzereingaben werden in den Code Behind Dateien zu den Eingabeelementen gepr ft und validiert Trotzdem sollen Methoden Werte zur ckweisen die sie nicht verarbeiten k nnen und in einer passenden Exception den Fehler beschreiben Ausnahmen werden bis zur Sicherheitsfassade hinaufgereicht Diese k mmert sich um einen entsprechenden Dialog mit dem Benutzer und um ein ordnungs gem es Beenden des Programms 4 2 LOGGING Als Technik f r die Protokollierung wurde die Entscheidung zugunsten der Log4NET Bibliothek von Apache getroffen Diese Bibliothek ist online unter einer freien Lizenz verf gbar vgl Apache Software Foundation Normalerweise w rde man versuchen das Logging ber eine eigene Komponente zu kapseln damit die Bibliothek leicht austauschbar ist und die direkten Aufrufe sich auf einen lokalen Bereich beschr nken Dagegen spricht jedoch dass die Log4NET Bibliothek protokollieren kann welche Methode den Logging Befehl aufgerufen hat Diese hilfreiche Mehrinformation m sste bei einer Kapselung ber Reflection weiter gegeben werden Insgesamt wurde eine Kapselung der Logging Komponente wegen einem zu hohen Aufwand verworfen Ein gro er Vorteil beim Benutzen der externen Bibliothek ist der gro e Funktions umfang und die gute Konfigurierbarkeit des
85. lfe von Tabellen dargestellt werden z B bei REQ 019 und bei einigen Modulen Die angezeigten Tabellen sollen ein umfangreiches Kontextmen aufweisen mit dessen Hilfe Be reiche der Tabelle kopiert gesucht gefiltert ver ndert und konfiguriert werden k nnen Folgende Funktionen sind geplant e Copy with Header Text Die angeklickte Spalte bzw die markierten Spal ten werden so in die Zwischenablage kopiert dass sie mit der Spalten ber schrift in ein Excel Sheet eingef gt werden k nnen e Copy without Header Text Funktion wie bei Copy with Header Text nur ohne die Spalten berschrift e Paste Ein einzelner Wert aus als Zeichenkette oder mehrere Zellen die aus einem Excel Sheet in die Zwischenablage kopiert wurden werden an der angeklickten Stelle in die Tabelle eingef gt e Select All Markiert alle Zellen der Tabelle e Select Row Markiert alle Zellen der angeklickten Zeile e Select Column Markiert alle Zellen der angeklickten Spalte e Find Sucht die erste Fundstelle eines einzugebenden Werts in der Tabelle e Find Next Sucht den zuletzt gesuchten Wert unterhalb der letzten Fund stelle e Find amp Replace Sucht einen einzugebenden Wert in der Tabelle und er setzt ihn durch einen weiteren einzugebenden Wert e Visualize Values siehe REQ 054 e Filtering siehe REQ 055 e Show Graph siehe REQ 043 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang REQ 043 Daten a
86. llen neue Lasten zu einem Last fall hinzugef gt werden k nnen und neue Lastf lle sollen angelegt werden k n nen D Durchstich Straus API Tool REQ 046 Elemente f r Lasten ausw hlen F r die Aufbringung von Lasten sollen Elemente ausgew hlt werden auf denen die Lasten simuliert werden sollen Diese Elemente k nnen nach den Kriterien Group Beam Properties Plate Properties und ID ausgew hlt werden Zun chst sollen die Elemente ber eine Auflistung der Elemente ausgew hlt wer den k nnen Die Gruppen k nnen dabei drei Zust nde aufweisen selektiert nicht selektiert teilweise selektiert je nachdem ob alle Elemente keine Elemente oder nur einige Elemente aus der Gruppe selektiert wurden Die einzelnen Elemente k nnen nur selektiert oder nicht selektiert sein Langfristig sollen die Elemente auch grafisch durch Markieren in der Modellan sicht ausgew hlt werden k nnen Die Auswahl soll jeweils der Lastengenerierung durch das Windloads Modul und das Waveloads Modul vorgelagert sein Die Module sollen dann nur mit den se lektierten Elementen arbeiten Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang amp sp ter REQ 040 Lastfall Kombinationen generieren SS Aus angelegten Lastf llen sollen automatisch Lastfall Kombinationen generiert werden k nnen Dazu kann f r jeden Lastfall eine Gruppenzugeh rigkeit Last
87. ls Funktionen anzeigen 2 sp ter Straus API Tool In Tabellenansichten sollen Spalten ausgew hlt werden k nnen und die enthalte nen Daten sollen als Funktion voneinander grafisch dargestellt werden k nnen Das Ausl sen dieser Funktion erfolgt zum Beispiel ber einen Eintrag im Kon textmen siehe REQ 053 REOQ 054 Werte in Tabelle visualisieren 2 Spa RE Mit dem Befehl Visualize Values des Kontextmen s f r Tabellen REQ 053 sol len alle Werte in den markierten Spalten mit farbigen Balken hinterlegt werden deren L nge und Farbe den Wert der Zelle im Vergleich zu allen anderen Zellen dieser Spalte abbilden Dabei soll ein kurzer dunkelblauer Balken das Minimum einer Spalte markieren und ein langer roter Balken das Maximum Die Werte die zwischen diesen liegen werden farblich und in der L nge interpoliert REQ 055 Tabellenwerte filtern 2 spoue RE Mit dem Befehl Filtering vgl Kontextmen in REQ 053 soll eine M glichkeit gegeben werden die Zeilen der Tabelle nach bestimmten Kriterien zu filtern Momentan ist die Idee dies ber eine Konsoleneingabe zu realisieren A 1 2 2 MODELLVERWALTUNG In diesem Abschnitt werden Anforderungen beschrieben die sich mit der Verwal tung des Straus Modells besch ftigen Dies beinhaltet lesende und schreibende Zugriffe auf Modelldateien Die Straus APl stellt hilfreiche Funktionen f r diese Anforderungen zur V
88. lung auch keine Anhaltspunkte f r regelm ige Dienste zu finden 2 2 2 KOMPONENTEN Die Empfehlung eine Software Architektur als eine Struktur aus einzelnen Kom ponenten aufzubauen findet sich h ufig in der g ngigen Literatur vgl Microsoft Patterns amp Practices Team 2009 Siedersleben 2004 Starke 2011 Szyperski et al 2002 und Wirfs Brock et al 2002 Dahinter steckt einerseits der Wunsch die Aufgabe in immer kleinere Unteraufgaben zu zerteilen um sie m glichst leicht berblicken zu k nnen Andererseits erleichtert die Strukturierung der Objekte in Komponenten auch den Umgang mit Abh ngigkeiten indem Schnittstellen defi niert werden ber die die Komponenten miteinander kommunizieren In dieser Arbeit soll die Definition von Johannes Siedersleben Siedersleben 2004 S 42f verwendet werden in dessen Augen jede Komponente die folgenden Merkmale bes e 1 Sie exportiert eine oder mehrere Schnittstellen 2 Sie importiert andere Schnittstellen 3 Sie versteckt die Implementierung und kann daher durch eine andere Komponente ersetzt werden die dieselbe Schnittstelle exportiert 4 Sie eignet sich als Einheit der Wiederverwendung denn sie kennt nicht die Umgebung in der sie l uft sondern macht dar ber nur minimale Annah men 5 Komponenten k nnen andere Komponenten enthalten 6 Die Komponente ist neben der Schnittstelle die wesentliche Einheit des Entwurfs de
89. m nicht zugreifbar soll dieser Zustand zun chst behoben werden bevor das Programm mit der eigentlichen Rechnung beginnt Dazu wird der Nutzer m glichst pr zise ber den aufgetretenen Fehler unterrichtet Der F higkeit zur Wiederherstellung von Zust nden des Modells wurde eine eher geringere Priorit t beigemessen da die Modelldatei so lange unver ndert bleibt wie der Benutzer nicht auf speichern dr ckt Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur 2 1 5 BENUTZBARKEIT Der Benutzbarkeit wird von Overdick eine untergeordnete Relevanz zugeordnet Relevanz B weil die Meinung besteht dass der Einarbeitungsaufwand nicht so wichtig ist wie richtige Funktionalit t Unter dem Thema Benutzbarkeit finden sich in der DIN ISO 9126 folgende Aspekte Verst ndlichkeit Aufwand f r den Benutzer das Konzept der Anwendung zu verstehen Erlernbarkeit Aufwand f r den Benutzer die Anwendung zu erlernen z B Bedienung Ein Ausgabe Bedienbarkeit Aufwand f r den Benutzer die Anwendung zu bedienen Tabelle 4 Aspekte des Qualit tsmerkmals Benutzbarkeit Starke 2011 Die drei Kriterien f r gute Benutzbarkeit siehe auch REQ 012 sollen mit ver schiedenen Aktivit ten erreicht werden e Es wird ein Benutzerhandbuch erstellt REQ 003 das dem Ingenieur hilft die Funktionen des Programms leicht zu finden und genau zu verstehen was eine bestimmte
90. n Berechnungsm glichkeiten sollen leicht Module hinzugef gt werden k n nen Unter dem Begriff Modul soll im Rahmen dieser Arbeit ein Paket von Funktionen verstanden werden die eine gemeinsame Aufgabe erf llen und das vorhandene Programm erweitern REQ 001 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle EEE Einleitung Bei der Testbarkeit wird vor Allem auf die leichte Anwendbarkeit von Unit Tests geachtet Die Struktur des Quellcodes muss also m glichst geringe Abh ngigkei ten aufweisen damit einzelne Elemente leicht isoliert werden k nnen und einzeln in ein Test Korsett eingespannt werden k nnen F r die Wartbarkeit der Software ist es wichtig dass sowohl die Struktur des Pro gramms als auch der Quellcode leicht verst ndlich ist damit die Wahrscheinlich keit f r Fehler so weit reduziert werden kann wie m glich Die Code Dokumentation REQ 008 soll m glichst hilfreich und umfassend sein darf aber nicht zu lang werden damit sie leicht wartbar bleibt vgl dazu McConnell 2004 1 5 3 MERKMALE DES STRAUS MULTITOOLS Um eine passende Architektur f r das Straus Multitool entwerfen zu k nnen ist es wichtig sich ber die geplanten Merkmale des Programms klar zu werden Da bei konnten folgende Merkmale gefunden werden e Offenes System Das Programm soll durch Module erweitert werden k nnen e Applikation Das Programm wird direkt von Menschen genutzt e Nicht terminierend
91. n StubConfigurationManager implementiert der so konfigurier bar ist dass er die Funktionen des XmlConfigurationManagers nachahmen kann und sich jeweils so verhalten kann wie der Test es fordert Auf diese Weise kann die Klasse Configuration mit beliebigen Umgebungsszenarios getestet werden F r jeden Test wird in der Klasse ConfigurationTests eine Instanz der Klasse Confi guration und ein StubConfigurationManager erzeugt Es wird jeweils eine bestimmte Umgebungssituation geschaffen anschlie end wird die zu testende Funktion aus gef hrt bevor der Erfolg dieser Funktion mit dem NUnit Testframework ber pr ft wird vgl Poole et al Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Configuration IConfigurationManager mgr lt lt Interface gt gt IConfigurationManager List localConfigList update List configList Configuration mgr IConfigurationManager save List configList Configuration filename string update IN D StubConfigurationManager KE V Configurationitem string key string value ConfigurationTests Configurationltem string key string value Configurationltem Abbildung 9 Teststruktur der Configuration Komponente Eine Reihe von Tests die die innere Logik der Komponente abdecken sollen sind mit Hilfe eines stubConfigurationManagers bereits implementiert worden Weitere m gliche Testf lle di
92. n dargestellt Der Zugriff auf die Straus Dateien kann ber die Straus APl erfolgen deshalb ist kein direkter Zugriff vorgesehen sondern es wird auf die vom Hersteller zur Verf gung gestellten Funktionen zur ckgegriffen gt gt Straus Multitool Benutzer Straus7 Straus x Dateien In diesem Kapitel wird zun chst beschrieben wie die Qualit t von Software N e O N Log Datei Konfigurations Se datei Abbildung 1 Kontextsicht des neuen Programms Architektur definiert werden kann und wie sie f r das Straus Multitool sicherge stellt werden soll Anschlie end wird die entwickelte Architektur vorgestellt und erl utert Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur 2 1 QUALIT T DER SOFTWARE ARCHITEKTUR Um die Qualit t von Software zu bewerten gibt die DIN ISO 9126 die Kriterien Funktionalit t Benutzbarkeit Effizienz nderbarkeit bertragbarkeit und Aus tauschbarkeit an Diese sind je nach Aufgabe der Software unterschiedlich schwie rig umzusetzen und unterschiedlich relevant Gernot Starke f gt in seinem Buch Effektive Software Architekturen 2011 den in der Norm genannten Kriterien noch Verst ndlichkeit und Testbarkeit hinzu Tabelle 1 zeigt die Definitionen der Begriffe aus der Norm Funktionalit t Vorhandensein von Funktionen mit festgelegten Eigen schaften diese Funktionen erf llen die definierten An forderungen Zuverl ssigkeit
93. n und ber cksichtigt D Durchstich KO REQ 012 Gute Benutzbarkeit Das Programm soll f r die Nutzer verst ndlich und eindeutig sein Ein neuer Be nutzer soll sich relativ schnell einfinden k nnen REQ 017 Einfache Installation 2 sp ter TW FLO Die Installation des Programms soll einfach und intuitiv sein Das selbstst ndige Kopieren von DLL Dateien und Eintragen von Pfaden soll nicht n tig sein statt dessen soll sich die Installation am Windows Standard f r Installationsroutinen orientieren Anmerkung Diese Anforderung war zun chst f r den Durchstich vorgesehen Dies hat sich aufgrund des geringen Funktionsumfangs als unn tig herausgestellt Durchstich REQ 004 Physikalische Einheiten in der GUI Meetingprotokoll vom 24 5 2011 Es soll zu jeder Zeit deutlich sein welche Einheiten verwendet werden Dazu ist jede Ein oder Ausgabe von Zahlenwerten ist sofern der Wert nicht eindeutig als einheitenlos erkannt wird mit einem Hinweis auf die verwendete Einheit zu ver sehen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang REQ 011 bersichtliche Ergebnisdarstellung 2 rer KO Die Darstellung der Ergebnisse soll bersichtlich und informativ sein Dazu k n nen Tabellen Listen Text oder auch H llkurven verwendet werden Die ber sichtlichkeit muss mit Hilfe der zuk nftigen Anwender eval
94. n und mehrere Ansichten parallel sehen kann Die Straus AP I bietet die M glichkeit ein Modellfenster zu erzeugen das sich in der Ansicht nicht von der Darstellung innerhalb von Straus7 unterscheidet Dieses Modellfenster bringt auch einige Funktionen mit die die Darstellung den Bed rf nissen des Benutzers anpassen Das Modell kann z B gedreht werden und ver schiedene Lastf lle k nnen als Vektoren eingeblendet werden Dieses Modellfens ter ist mit dieser Anforderung gemeint D Durchstich FLO REQ 056 Sprache Englisch 2 http www gigawind de fileadmin gigawind downloads waveloads UsermanualWL pdf Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang Die Sprache der Hilfe und der Oberfl che des Programms soll Englisch sein In ternationale Mitarbeiter sollen das Programm ebenfalls verstehen und bedienen k nnen in internationalen Zweigstellen des Unternehmens wird Englisch gespro chen Eine Mehrsprachigkeit des Programms wird zun chst nicht angestrebt REQ 038 Verschiedene Pfade pro Funktion 2 ap eher RE FLO Zu den Programm Funktionen wie z B ffnen einer Modelldatei sollen mehrere m gliche Pfade f hren Dazu geh ren Symbolleisten Elemente Eintr ge in Men und ggf Kontextmen sowie die Ansteuerung ber Tastenk rzel REQ 053 Tabellenfunktionen 2 27 An mehreren Stellen im Straus Multitool m ssen Daten mit Hi
95. nde ren Werken entnommene Stellen habe ich unter Angabe der Quellen kenntlich gemacht Hamburg 15 Februar 2012 Friederike L we
96. ndet werden Alle Ent scheidungen sollten bei der Implementierung weiter Missions bedacht werden Verwenden von usercontrols zur Einbindung von Mission Komponenten Die Einbindung der Mission Komponenten rein auf der Ebene der Benutzeroberfl che erlaubt eine gr tm gliche Unabh ngigkeit der Funktionalit t vom Hauptpro gramm deshalb wurde diese Schicht als Schnittstelle genutzt Eine weitere M g lichkeit w re das Einbinden ber ein sogenanntes ResourceDictionary auf XAML Ebene Ein ResourceDictionary kann beliebige XAML Elemente beinhalten und in eine andere Datei auslagern Auch Code Behind Dateien sind m glich Allerdings erscheint der Weg ber userControls sauberer und bersichtlicher weil sie direkt die passende Struktur f r diesen Anwendungsfall anbieten Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Verwenden einer Fabrik Klasse Das Generieren von Instructions in dieser Kom ponente entspricht keinem Erzeugermuster von Gamma et al 2004 In Anleh nung an den Musterkatalog werden jedoch in der InstructionsFactory Klasse Me thoden genutzt die unterschiedliche Instruction Objekte erzeugen Dies dient da zu die Menge an Objekt Referenzen die von den Instructions ben tigt werden zu reduzieren Durch Einf hrung der Fabrik m ssen die aufrufenden Klassen diese Referenzen nicht halten sondern kennen nur das Fabrik Objekt das wiederum die passenden Referenz
97. ndig werden Eine Software Architektur zu entwerfen sollte ein zyklischer Prozess sein Starke 2011 Diese Arbeit beschreibt die entstandene Architektur sowie die Entschei dungen und Rahmenbedingungen die dazu gef hrt haben In diese Entscheidun gen sind alle derzeit geplanten und absehbaren Anforderungen an vollst ndige Software eingeflossen Deshalb sollten keine grundlegenden nderungen an der Architektur notwendig sein um diese Anforderungen umzusetzen Sollten weite re hinzukommen die au erhalb des betrachteten L sungsraumes liegen sollte eine erneute Refaktorisierung der Architektur auf Basis der dokumentierten Ar chitekturentscheidungen problemlos m glich sein 1 1 DAS UNTERNEHMEN Diese Arbeit entsteht bei der Overdick GmbH amp Co KG einem Ingenieursb ro in dem Bauingenieure und Schiffbauingenieure unter anderem Simulationsmodelle von Offshoreplattformen entwerfen Aktuell bearbeiten hier 53 Mitarbeiter Ent wicklungsauftr ge bei denen die Kunden von der Entwicklung bis zur Installa tion einer Offshoreplattform begleitet werden Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Eeer Einleitung 1 2 DER GESCH FTSPROZESS Wenn ein Kunde beispielsweise eine Plattform in Auftrag gibt so entwickeln die Ingenieure zun chst anhand der identifizierten Anforderungen ein simulationsf higes Strukturmodell Dieses entsteht innerhalb einer Software die speziell f r diesen Einsatzzweck k
98. ndiges und hilfreiches Benutzerhandbuch entstehen Darin sollen mindestens die Installation wenn sie nicht vollst ndig gef hrt ist und die g ngigsten Anwendungsschritte erkl rt werden Ein nicht an der Entwicklung beteiligter Anwender soll das Programm nur mit Hilfe des Handbuchs installieren und ausprobieren k nnen d f REQ 008 Quellcode Dokumentation Durchstich KO Aus der Quellcode Dokumentation soll hervorgehen wie das Programm funktio niert wozu die einzelnen Abschnitte gedacht sind und wie die Architektur aufge baut ist ggf mit einem Zusatz Dokument Zuk nftige Entwickler sollen sich einfach im Code zurechtfinden Ihn verstehen und nderungen einpflegen k nnen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang i Durchstich NW REQ 009 Dokumentation der Module F r jede Funktion soll eine Beschreibung existieren aus der hervorgeht welches Verfahren verwendet wird welche Einschr nkungen dieses Verfahren mit sich bringt und welche Randbedingungen f r die Rechnung angenommen werden Im Programmhandbuch und ggf an weiteren Stellen im Programm werden ent sprechende Angaben gemacht A 1 6 BENUTZBARKEIT In diesem Kapitel werden von Overdick Mitarbeitern formulierte Anforderungen an die Benutzbarkeit des Straus Multitools dokumentiert Teilweise konnten diese nicht genau spezifiziert werden werden aber als Leitgedanke aufgenomme
99. nenten verwendet werden um die Ausf hrung von Instructions zu verein fachen 3 4 2 3 WINDLOADSTABLE Das UserControl WindloadsTable hat zwei wichtige Funktionen Zun chst einmal dient es der Darstellung der Eigenschaften der zur Konstruktion des Modells ver wendeten St be Jede Zeile der Tabelle stellt die Stab Nummer Spalte Beam zusammen mit einer Menge anderer Werte dar Dazu geh ren verschiedene Ab messungswerte der angenommene maritime Bewuchs Marine Growth an der Oberfl che des Stabs die angreifenden Windgeschwindigkeiten an den beiden Endpunkten und die daraus resultierenden Kr fte REQ 022b Die Windge schwindigkeit und die angreifenden Kr fte werden aus den anderen Werten be rechnet REQ 022 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Die zweite Funktion ist die Ver nderung von Parametern So k nnen die Werte f r Marine Growth und den ShapeCoefficient C f r jeden einzelnen Stab in der Tabelle ver ndert werden was eine Neuberechnung der Lasten anst t Die Parameter k nnen entweder f r die gesamte Spalte gleich oder f r jede Zelle ein zeln ver ndert werden Diese nderungen k nnen r ckg ngig gemacht werden da sie ber Instructions realisiert werden die sich nach Ausf hrung bei der Histo ry Komponente registrieren WindloadsTable InstructionFactory beams List lt Beam gt units int history
100. ng einer Verifikationssoftware f r Strukturmodelle Die Architektur Auch zwischenzeitlich ver nderte Anforderungen k nnen in den neuen Entwurf aufgenommen werden dann spricht man allerdings nicht mehr von einer Refakto risierung Nach gr ndlicher Besch ftigung mit den Anforderungen und mit itera tiver Vorgehensweise ist die Architektur in Abbildung 4 entstanden Die verschiedenen Schichten Komponenten und Schnittstellen sollen im Folgen den aus der Sicht von au en als sogenannte Black Box beschrieben werden Die Zuordnung der Komponenten zu den genannten Schichten in dem Abschnitt zu der jeweiligen Komponente erl utert 2 3 1 CONFIGURATION Die Configuration Komponente sorgt daf r dass Daten ber das Programmende hinaus gespeichert werden k nnen und damit beim n chsten Programmstart wie der zur Verf gung stehen Sie erf llt also die Forderung nach Persistenz und ist somit der Infrastruktur Schicht zugeordnet Zum Speichern m ssen die Daten als Schl ssel Wert Paare vorliegen Jeweils ein Schl ssel zum Wiederfinden der Information und ein Wert der unter diesem Schl ssel abgelegt werden soll bilden ein Paar Die Schnittstelle Iconfiguration bietet im Wesentlichen zwei Methoden an string getValue string key void changeValue string key string newValue Damit kann von au en ein Wert gelesen oder ge ndert werden Das Hinzuf gen von neuen Wertepaaren ber Programmcode ist nicht vorgesehen da w hrend
101. ol Abbildung 6 Startbildschirm des Straus Multitools Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten 3 BESCHREIBUNG DER KOMPONENTEN In diesem Kapitel wird die Innenansicht der einzelnen Komponenten vorgestellt Dabei enth lt jeder Abschnitt die Beschreibung einer Komponente und folgt dabei diesem Aufbau Zun chst wird der Zweck der Komponente zusammengefasst Anschlie end werden die Vor und Nachbedingungen der Komponente beschrie ben sowie ihre innere Struktur Dann folgt eine Beschreibung von Ma nahmen zur Testbarkeit sowie wichtige getroffene Designentscheidungen und deren Begr n dung 3 1 CONFIGURATION KOMPONENTE Die Configuration Komponente verwaltet global die Konfiguration des Programms Es k nnen Paare von Zeichenketten bergeben wieder abgerufen und persistent abgelegt werden 3 1 1 VOR UND NACHBEDINGUNGEN Die Komponente erwartet eine bestehende XML Datei mit der in Abbildung 7 ge zeigten Struktur Bei der Instantiierung der Komponente muss der Pfad zu dieser Datei angegeben werden Alle Schl ssel Wert Paare die mit der Configuration Komponente verarbeitet werden sollen m ssen in der XML Datei beim Starten des Programms schon angelegt sein lt xml version 1 0 encoding utf 8 gt lt Configuration gt Item gt lt Key gt scratchpath lt Key gt lt Value gt C Multitool Data ModelScratchFolder lt Value gt lt Item gt lt Item
102. oll die Berechnung eines Beam Buckling Checks nach Norm EC3 oder DIN 18800 durchf hren k nnen und ein korrektes Ergebnis dieser Rechnung zur ckliefern REQ 029 Joint Check ZS sp ter Straus API Tool Das Programm soll die Berechnung eines Joint Checks durchf hren k nnen und ein korrektes Ergebnis dieser Rechnung zur ckliefern A 1 2 4 ERGEBNISSE Langfristig soll das Straus Multitool m glicherweise auch mit Ergebnisdateien umgehen k nnen Das sind Dateien die vom Programm Straus erstellt werden und die das Ergebnis einer bestimmten Berechnung an einem bestimmten Modell enthalten Da Straus zum Umgang mit Ergebnissen aber auch viele gute eigene Funktionen anbietet ist noch nicht klar ob die Anforderungen in diesem Kapitel umgesetzt werden Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang amp sp ter REQ 021 Ergebnisdaten verwalten Straus API Tool Straus Ergebnisdateien sollen gelesen und geschrieben werden k nnen In den Ergebnisdateien befindet sich das Ergebnis jeweils einer Berechnung in Straus ZS sp ter Straus API Tool REQ 031 Modell als vorverformte Struktur Das Modell soll als vorverformte Struktur speicherbar sein Die ermittelten Ergeb nisse sollen also als neues verformtes Modell gespeichert werden k nnen A sp ter REQ 005 Automatischer Bericht Meetingprotokoll vom 24 5 2011 A
103. ommands wird auch die Austauschbarkeit der Pro grammoberfl che erleichtert Denn das dahinter liegende Konzept hilft dabei Programmlogik und Oberfl chenlogik sauber zu trennen Damit spricht auch die ser Punkt f r die Nutzung von Routedcommands vgl Krypczyk 2011 3 7 INITIALIZATION KOMPONENTE Diese Komponente ist der Einstiegs und der Endpunkt des Programms Von hier aus werden alle anderen Vorg nge angesto en Beim Startvorgang wird ein Start bildschirm angezeigt der dem Nutzer mitteilt was im Hintergrund passiert Die Komponente verrichtet dabei eine Reihe von Initialisierungsschritten und ber pr fungen Da die Komponente nur diesen einen linearen Ablauf enth lt wird auf Struktur und Testbarkeit der Komponente nicht weiter eingegangen Eine Aufgabe der Komponente ist zu berpr fen ob alle zur Ausf hrung not wendigen Programme und Bibliotheken zur Verf gung stehen Im Fehlerfall gibt sie eine entsprechende Meldung aus Dabei wird konkret das Vorhandensein der Straus7 APl Installation g ltiger Straus Lizenzschl ssel berpr ft Die Komponente initialisiert au erdem die Komponenten ModelManagement Configu ration und History sowie die Oberfl chenkomponente Ambience Abbildung 24 zeigt den Ablauf der Initialization Komponente in einem Aktivit tsdiagramm Mit ro ten Pfeilen ist der Kontrollfluss dargestellt die schwarzen Pfeile zeigen die ber gabe von Referenzen auf bereits initialisierte Komponenten
104. on ausgegangen werden dass die physikalischen Einheiten auf eine bestimmte Weise eingestellt sind Jede Rech nung stellt sich die passenden Einheiten im Modell ber eine passende Funktion selbst ein bevor die Berechnung erfolgt Die passende Funktion verwendet den Straus Aufruf st7setunits und ist als virtual gekennzeichnet damit sie f r Kom ponententests berschrieben werden kann Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle KT Fazit 5 FAZIT Im Rahmen dieser Arbeit ist ein lauff higes Programm entstanden das die entwi ckelte Architektur illustriert In diesem Kapitel wird der Status Quo betrachtet und bewertet sowie ein Ausblick auf die Weiterentwicklung der Anwendung ge geben 5 1 ERGEBNIS Das Straus Multitool erf llt die f r diese Arbeit geplanten funktionalen Anforde rungen mit wenigen Einschr nkungen Es gibt eine Komponente Configuration die f r die Persistenz des Programms zust ndig ist Die Komponente ModelManagement bernimmt die Modellverwaltung Die History Komponente sorgt f r eine zentrale Speicherung ausgef hrter Befehle die zur ckgenommen und wiederholt werden k nnen Es wurde eine Mission Komponente implementiert die aus vorgegebenen Parametern Windlasten berechnet grafisch darstellt und in der Modelldatei spei chern kann Die Programmschritte werden mit Hilfe der Log4NET Bibliothek grob protokolliert Die Bewertung der nicht funktionalen Aspekte des Programms und
105. onzipiert ist zum Beispiel Staus Strand Pty Ltd Mit die ser Software ist es m glich die Stabilit t des Modells zu pr fen indem man Las ten simuliert die darauf einwirken Als Simulationsergebnisse erhalten die Inge nieure Daten ber Verformungen und Kr fte anhand derer sie einsch tzen k n nen wie sich die Plattform sp ter unter dem Einfluss von Winden und Wellen verhalten wird Welche Kr fte auftreten k nnen und wie die Ergebnisse zu beur teilen sind ist in verschiedenen Normen festgelegt die eingehalten werden m s sen Ergibt die Simulation dass die Plattform den aufgebrachten Lasten nicht standhalten k nnen wird m ssen die Ingenieure ihren Entwurf berarbeiten und die Simulation sp ter erneut durchf hren 1 3 DIE PROBLEMSTELLUNG Bisher werden die Lasten mit denen das Strukturmodell gepr ft werden soll per Hand in das Simulationsprogramm eingegeben Da dieser Vorgang zeitaufwendig ist werden die Modelle nur so genau wie n tig gepr ft Bei der manuellen Last aufbringung nehmen die Ingenieure beispielsweise f r die Wellenlasten r umlich konstante Maximalwerte an was bedeutet dass eine sehr pessimistische Einsch t zung der Haltbarkeit der Plattform entsteht Dadurch m ssen die Modelle oft un n tig stark ausgelegt werden auch ber einen eingeplanten Sicherheitsfaktor hin aus Dies f hrt zu erh hten Kosten f r Arbeitszeit und Material Teilweise ist mit dieser Herangehensweise gar kein Stabilit
106. organg ist in Abbildung 15 abgebil det S mtliche in der Abbildung dargestellten Pins sind Input Pins Der bersicht halber wurde weitestgehend auf die Darstellung des Objektflusses schwarze Pfei le verzichtet Die roten Pfeile bilden den Kontrollfluss ab Die unterschiedlich umrandeten Aktivit ten sollen die Initialisierungsschritte der grafischen Elemente blau fett von denen f r die Initialisierung der domainspezifischen Klassen ab heben schwarz Im Wesentlichen geschieht Folgendes Zun chst werden die Objekte initialisiert die im Hintergrund arbeiten und ihre Referenzen werden gehalten Anschlie end werden die vier UserControls initialisiert aus denen windloadsTab besteht Ihnen werden dazu Referenzen auf Objekte mitgegeben mit denen sie sp ter kommuni zieren m ssen Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten WindloadsTab initialisieren config confi windloads goe g IConfiguration Windloads initialisieren Windbads LL modeliD windbads f beamDataViewModel model id BeamData initialisier model IModel D s TEE EEN BeamDataViewModel beamDataViewModel beams LoadCases initialisieren modell loadcases history IHi iewM LoadCases ry History history beamDataViewModel 77 Instructions initialisieren windloads instructionFactory InstructionF actory instructionF actory WindloadsTable initialisieren beamDataViewModel instru
107. propertyName string beams List lt Beam gt height Stack lt double gt fillDistributedLoadsList distributedLoad Stack lt double gt add double height double distributedLoad Abbildung 18 Klassendiagramm hinter dem UserControl WindloadsChart In Abbildung 18 wird die Klassenstruktur hinter dem windloadschart gezeigt Das UserControl greift auf das ViewModel f r Streckenlasten engl distributed loads zu Das DistributedLoadviewModel bekommt bei der Initialisierung die Referenz auf die Liste der St be bergeben die in windloadsTable angezeigt werden Aus dieser Liste wird aus den Einzellasten an den Stabenden eine Streckenlast f r jeden Stab berechnet die in einer Liste aus DistributedLoad Objekten gespeichert wird So ein Objekt enth lt die drei Felder propertyname Querschnittsbezeichnung height mitt lere Stabh he und distributedLoad Streckenlast also Last pro L ngeneinheit Im Windloadschart ergeben height und distributedLoad die Koordinaten eines Punktes Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten w hrend Punkte mit gleichem Wert f r propertyName in einer Datenreihe zusam mengefasst werden 3 4 2 5 APPLYLOADSTOMODEL Im unteren Bereich des windloads Tabs lassen sich die berechneten Lasten zusam menfassen und als Lastfall in der Straus Modelldatei abspeichern REQ 022c und REQ 020 Aktuell ist das
108. r Benutzer den Undo Befehl ausl st bernimmt die History Komponente Angesprochen werden die Funktionen ber das Interface IHistory Die Methoden die mit der Nutzung dieser Schnittstelle den u eren Komponenten zugesichert werden sind bool undo bool redo void done IInstruction instruction Sie stellen die M glichkeiten her dass eine Instruction sich als ausgef hrt anmel den kann done r ckg ngig gemacht werden kann undo und anschlie end erneut ausgef hrt werden kann redo 2 3 3 STRAUS7 Die Straus API Funktionen werden im Straus Multitool nicht direkt angesprochen Es ist eine Komponente f r den API Zugriff vorgesehen die die passenden Me thodensignaturen und weitere Hilfsfunktionen enth lt Das liegt daran dass die API mit dem NEI Framework nur korrekt in VisualBasic NET angesprochen werden kann und nicht mit C Deshalb wird diese Komponente in VisualBa sic NET entwickelt und stellt die Funktionen der Straus API f r das restliche Pro gramm bereit REQ 023 Da es sich bei der Aufgabe dieser Komponente um die Integration eines Fremdsystems handelt wird die Komponente der Infrastruktur Schicht zugeordnet 2 3 4 MISSION Die Mission Komponente ist in Abbildung 4 gelb umrandet und hebt sich somit von den anderen Komponenten ab Das soll bedeuten dass es von dieser Kompo nente verschiedene Implementierungen geben wird Jede Aufgabe die in einem geschlossenen Kontext gel st werden kann wird in e
109. r Datenmengen ist REQ 015a eine M glichkeit REQ 015a Dynamisches Nachladen 2 27 Beim Laden von Listen z B in eine Tabelle sollen die Daten in Abschnitte unter teilt werden die nacheinander geladen werden Dies ist zum Beispiel beim Data6 ridview mit dem Virtual Mode m glich A 1 4 DESIGN CONSTRAINTS In diesem Kapitel werden Anforderungen beschrieben die an das Design des Pro gramms gestellt werden Es handelt sich hierbei um von Overdick Mitarbeitern gew nschte Eigenschaften Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang E e REQ 001 Modulare Bauform Durchstich RE FLO Verschiedene Berechnungen sollen als Module ber Assemblies eingebunden werden Durch eine derartige Struktur nehmen die Erweiterungen ber eine ein heitliche Schnittstelle Kontakt zum Hauptprogramm auf ndern den Quellcode aber nicht EN REQ 002 Trennung von GUI und Funktionen EEN FLO Die Anwendung trennt die Zust ndigkeiten der grafischen Oberfl che von der Funktion ber Einhaltung des Model View Controller Patterns oder einer ver gleichbaren Aufteilung A 1 5 DOKUMENTATION Die Anforderungen an die Dokumentation der Programmfunktionen und der Im plementierung werden in diesem Kapitel beschrieben D Durchstich REQ 003 Benutzerhandbuch Meetingprotokoll vom 24 5 2011 Es soll ein m glichst vollst
110. r Implementierung und damit der Planung Das Ideal einer Komponente dr ckt sich durch geringe Kopplung und hohe Koh sion aus Das bedeutet dass zwei Komponenten m glichst unabh ngig voneinan der sein sollten geringe Kopplung die Elemente innerhalb einer Komponente Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur aber logisch und inhaltlich eng zusammengeh ren sollten hohe Koh sion Nach Helmut Balzert f hrt eine hohe Koh sion zu spezialisierten Modulen die besser wiederverwendbar und einfacher zu warten und zu ndern sind Balzert 1998 2 2 3 QUASAR Der Name Quasar steht f r Qualit tssoftwarearchitektur und beschreibt eine Sammlung von Heuristiken die im Softwarehaus sd amp m gesammelt wurden In seinem Buch Moderne Software Architektur beschreibt Johannes Siedersleben wie man gr ere Systeme strukturieren und planen kann Siedersleben 2004 Aus diesem Buch werden einige Anregungen und Definitionen verwendet Aufgrund der verh ltnism ig geringen Gr e des Straus Multitools wurde eine vollst ndi ge Entwicklung nach Quasar als unverh ltnism ig beurteilt und ausgeschlossen 2 3 DIE KOMPONENTEN F r die Entwicklung einer neuen Architektur ist es zun chst wichtig die Verant wortlichkeiten des Systems so auf Bausteine zu verteilen dass die Abh ngigkeiten minimiert werden Je weniger Abh ngigkeiten in einem System bestehen desto leichter
111. r Reengineering einer Verifikationssoftware f r Strukturmodelle Fazit bei 3 99 Einr ckungen liegt Auch hier gilt dass sich die Komplexit t des Straus Multitools mit der vollst ndigen Implementierung aller Funktionen noch erh hen wird insgesamt best tigen die Ergebnisse zur Verst ndlichkeit aber die Entschei dung f r eine Neuentwicklung 5 1 4 ZUVERL SSIGKEIT C Der Zuverl ssigkeit im Sinne der Kriterien Reife Fehlertoleranz und Wiederher stellbarkeit wird seitens Overdick nur geringe Priorit t beigemessen Trotzdem scheint eine Verbesserung der Zuverl ssigkeit des Straus Multitools langfristig sinnvoll Eine gute Reife des Programms l sst sich auf l ngere Sicht durch gr nd liches Testen erreichen Die Abdeckung durch Tests l sst sich im Gegensatz zur allgemeinen Zuverl ssigkeit leicht durch eine statische Analyse messen Weitere Aspekte der Zuverl ssigkeit lassen sich durch gezieltes Hinzuf gen von entsprechenden Funktionen verbessern Die hierdurch erreichte h here Zuverl s sigkeit w re allerdings nur durch das Aufzeichnen von Ausfallstatistiken in der Evaluationsphase messbar Die Verbesserung der Wiederherstellbarkeit scheint zum Beispiel angemessen wenn man den Aufwand bedenkt den die Ingenieure mit der Entwicklung der Modelldateien haben Es ist den Ingenieuren nicht zu zumuten sich selbst um die doppelte Speicherung der Dateien zu k mmern die sie mit dem Straus Multitool ffnen wollen Als M glichkeit
112. r auch Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang das Interpretieren des Dateiinhalts Ein Handbuch zu den Funktionen der Straus API findet sich im Installationsverzeichnis von Straus7 im Unterordner API REOQ 024 Waveloads dll 2 sp ter Straus API Tool Das Straus Multitool soll mit der Bibliothek Waveloads dll zusammenarbeiten k nnen Die Bibliothek wird von der Forschergruppe GIGAWIND der Universit t Hannover zur Verf gung gestellt Sie stellt Daten zur Generierung von Wellenlas ten bereit Eine Dokumentation dazu findet sich im Internet A 1 2 FUNKTIONALE ANFORDERUNGEN In diesem Abschnitt sollen die funktionalen Anforderungen des Programms be schrieben werden Dabei werden die Programmfunktonen in Funktionengruppen eingeteilt denen die Anforderungen zugeordnet werden A 1 2 1 GRAFISCHE BENUTZEROBERFL CHE In diesem Abschnitt werden Anforderungen aufgef hrt die der Benutzeroberfl che zugeordnet sind Anforderungen an die Oberfl che die speziellen Modulen zugeordnet sind werden in den entsprechenden Abschnitten zu diesen Modulen beschrieben D Durchstich KO REQ 014 Modellfenster Das Straus Modell soll als grafische Darstellung in einem eigenen Fenster ange zeigt werden k nnen Dieses Fenster sollte unabh ngig vom Hauptfenster des Straus Multitools sein damit man es z B auf einen zweiten Monitor verschieben kan
113. rei sehr bekannte Muster zu nen nen Layer Pipes amp Filters und Client Server Architekturen All well structured object oriented architectures have clearly defined layers Mit diesem Satz spricht sich Grady Booch Booch 1996 S 54 deutlich f r die Verwendung von Schichten als Strukturierungselement einer Software aus Vor teilhaft nach Gernot Starke Starke 2011 an der Verwendung von Schichten ist dass diese voneinander unabh ngig sind Die Implementierung einer Schicht kann leicht durch eine andere Implementierung ausgetauscht werden wenn in der Aus tausch Schicht die gleichen Funktionen angeboten werden Vor allem minimiert die Schichtenbildung Abh ngigkeiten zwischen Komponenten und f hrt zu einem schnelleren Verst ndnis der Architektur Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur Das Prinzip des Pipes amp Filters Musters ist die nacheinander erfolgende schrittwei se Bearbeitung von Daten Ein Beispiel f r dieses Muster ist der Compiler der den Quellcode schrittweise in verschiedenen Phasen analysiert Dieses Muster eignet sich nicht f r das Straus Multitool weil es einen anderen Prozess vorschreibt als von Overdick erwartet wird F r eine Client Server Architektur ist die Aufgaben stellung ebenfalls wenig geeignet Auch wenn die Anwendung dieses Architektur Musters nicht unbedingt eine Verteilung auf mehrere Systeme bedeuten w rde so sind in der Aufgabenstel
114. rove 2010 bei der innerhalb des Tests die abzukapselnde Klasse beerbt und die Me thoden berschrieben werden Es besteht die M glichkeit eine komplette Abstraktionsschicht einzuf hren die die API vollst ndig kapselt und deren Funktionen berschreibbar sind Da es aber ber tausend Funktionen sind und deren Benutzung f r die Entwicklung sp terer Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Mission Komponenten nicht eingeschr nkt werden soll wurde diese Vorgehens weise wegen zu hohen Aufwands verworfen Im Sinne der Testbarkeit wurde die Entscheidung getroffen Extract und Overri de bei Funktionen anzuwenden die die Straus API benutzen Deshalb m ssen die Methoden innerhalb der Klassen so aufgeteilt werden dass die Methoden die auf die API zugreifen keine zu testende Logik enthalten Damit liegt die Nahtstel le f r die Tests nicht zwischen den Komponenten sondern innerhalb der Klassen die auf die Straus API zugreifen Eine Nahtstelle auch Seam genannt ist nach Mi chael Feathers eine Stelle an der Sie Verhalten in Ihrem Programm modifizieren k nnen ohne es an dieser Stelle zu ndern Feathers 2011 Die Entscheidung bringt den Nachteil mit sich dass sie von der Implementierung nicht erzwungen wird Sich an das Konzept zu halten erfordert sehr viel Disziplin vom Programmierer Er muss jedes Mal selbst pr fen ob er die wichtigen Metho
115. rst ndlichkeit der Architektur Diese werden mit Hilfe einer klaren Struk turierung der Software in Schichten und Komponenten mit definierten Schnitt stellen erreicht Die vorliegende Arbeit dient der Dokumentation der Architek tur und der Entscheidungen die auf dem Weg zu dieser L sung getroffen wurden Friederike L we Title of the paper Architecture reengineering of a verification software for structural analysis models Keywords Software architecture reengineering layering components interfaces soft ware quality testability expandability understandability Abstract This paper aims to describe the reengineering of the architecture of a verifica tion software for structural analysis models To prove the quality of the devel oped architecture a spike was implemented The most important quality crite ria are the testability expandability and understandability of the software archi tecture These are achieved by structuring the software with the aid of layers components and clearly defined interfaces The thesis at hand documents the new software architecture and the decisions which have led to this solution Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle iii INHALT SPD IE ET ee ee Reale vi DE E RAR RE MEER EBENEN I PERLE REN ER ACER WERNER ROHR NEE EIKE EEE SR RERHHNE FREIE WERRERCHEN vii E 1 LL Das Unterneh EE 1 1 2 Der Gesch TS PIOZE8E ein belinseerhaninunanen 2 1 3 Die Fropem er
116. rt sie mit ffnen eines Modells alle passenden Mission Komponenten und ordnet de ren Steuerelemente in die Oberfl che ein Die Sprache der Oberfl che ist Englisch REQ 056 Im Folgenden wird eine bersicht ber die beim Start vorhandenen Buttons und ihre Aufgaben gegeben Dazu geh rt auch an welche Komponenten die Aufgaben delegiert werden Eine Straus Modelldatei ffnen ModelManagement Komponente aufrufen Mission Komponenten initialisieren Die ge ffnete Straus Modelldatei speichern REQ 026 ModelManagement Komponente aufrufen Die ge ffnete Straus Modelldatei unter neuem Namen speichern ModelManagement Komponente aufrufen Die ge ffnete Straus Modelldatei schlie en REQ 050 nicht speichern ModelManagement Komponente aufrufen Die letzte Aktion zur cknehmen Undo REQ 0357 History Komponente aufrufen SERPE 1 Die verwendeten Icons sind im Internet frei verf gbar und stammen aus folgenden Quellen e Oxygen Icon Set www oxygen icons org e Tango Icons http commons wikimedia org wiki Tango_icons Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur Die zur ckgenommene Aktion erneut durchf hren Redo REQ 057 History Komponente aufrufen Ein Straus Modellfenster ffnen REQ 014 Straus7 Komponente benutzen dert werden k nnen Configuration Komponente aufrufen Das Benutzerhandbuch anzeigen REQ 003 und REQ 009
117. rt werden die das Programm und vor allem die sicherheitsrelevanten Abschnitte gr nd lich testen e Ein Benutzerhandbuch muss erstellt werden 5 3 ABSCHLIE ENDE BEWERTUNG Mit dem Straus Multitool hat die Firma Overdick eine gr ndlich dokumentierte und solide Architektur erhalten sowie eine Durchstich Implementierung die im Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Fazit Wesentlichen nur noch funktional erg nzt werden muss Nach einer gr ndlichen Test und Evaluierungsphase kann das Programm in den allt glichen Arbeitsab lauf der Ingenieure bernommen werden und ihnen die Arbeit erleichtern Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Literatur LITERATUR Apache Software Foundation Apache log4net Online 26 Januar 2012 http logging apache org log4net Balzert Helmut Lehrbuch der Software Technik Software Management Software Qualit tssicherung Unternehmensmodellierung Buch Berlin Spektrum Akademischer Verlag 1998 Bass Len Clements Paul und Kazman Rick Software architecture in practice Buch Boston Addison Wesley Professional 2003 Beck Kent Implementation Patterns Buch M nchen Addison Wesley 2008 Booch Grady Object Solutions Buch Amsterdam Addison Wesley 1996 Campwood Software LCC SourceMonitor Software Hrsg www campwoodsw com Burlington s n 3 2 3 218 CodePlex Open Source Community Dyn
118. ructions parameters Parameters je InstructionFacto modelid int config IConfiguration calculateWindSpeed_DNV double calculateWindPressure_DNV doubl calculateShapeCoefficient_DNV B calculateWindForces_DNV Beam Sn Wes instantia referenceWindSpeed double calculateProfileProjection_DNV do referenceHeight double readGravityDirection string RecalculateWindloads adjustUnits lt lt use gt gt parametersBeforeExecute Par positive bool calculateWindloads_DNV List bea FE er n A Abbildung 16 Klassendiagramm hinter den Parametern f r die Windlasten globalMarineGrowth double windDirection double airDensity double globalShapeCoefficient double averagingTime double history History windloads Windloads beamDataViewModel B update Update referenceTime double Zur leichteren Handhabung von Referenzen wurde die Instructionfactory einge f hrt Von ihr wird bei der Initialisierung der Komponente ein Objekt erstellt das die notwendigen Referenzen zur History Komponente und zum internen Modell enth lt Damit kann z B das windloadsParameters Usercontrol beliebig viele Instruc tions vom Typ Recalculatewindloads erstellen die ausgef hrt und r ckg ngig ge macht werden k nnen Das gleiche Instructionractory Objekt verwaltet auch In structions f r andere UserControls Dieses Modell kann auch in anderen Mission Kompo
119. s Arbeiten mit Ergebnisdaten weiterhin gew nscht wird diese Entschei dung steht zum Erstellungszeitpunkt dieser Arbeit noch aus sollten die zugeh rigen Anforderungen in einer eigenen Komponente umgesetzt werden Dabei kann f r REQ 021 Ergebnisdaten verwalten die ModelManagement Komponente zum Vorbild genommen werden Die Anforderung REQ 005 Automatischer Be richt k nnte auch innerhalb dieser Komponente umgesetzt werden Das Spei chern des Modells als vorverformte Struktur REQ 031 scheint allerdings eher in eine Mission Komponente zu passen da auf die Ergebnis und auf die ModelManage ment Komponente zugegriffen werden m sste Die automatische berpr fung auf verf gbare Updates REQ 016 findet ihren Platz in der Initialization Komponente Die Installation des Updates sollte mit einem Installer Paket gel st werden Die berpr fung einer Benutzerlizenz als Programmschutz REQ 013 kann ebenfalls in der Initialization Komponente im plementiert werden Infrastruktur Komponenten k nnen relativ problemlos ausgetauscht werden da die Abh ngigkeiten zwischen den Komponenten mit Hilfe des Dependency In version Principle reduziert werden konnte vgl auch den gleichnamigen Artikel von Martin Dabei werden allerdings nicht wie dort beschrieben abstrakte Klassen sondern Interfaces verwendet die eine lose Kopplung zwischen den Komponenten erreichen Eine Mehrsprachigkeit k nnte durch eine Anpassung d
120. s Programm schlie t an die vorhandene Simulationssoftware Straus7 an und wird als Straus API Tool bezeichnet API steht f r Application Programming Interface und bezieht sich auf die Programmierschnittstelle von Straus7 Damit sieht der Gesch ftsprozess so aus dass das konstruierte Straus Modell in das API Tool geladen wird und aus diesem Programm anhand von eingestellten Parametern Lasten generiert werden die anschlie end automatisch in der Mo dell Datei gespeichert werden Wird die Straus Modell Datei in Straus7 ge ffnet kann die Simulation mit den generierten Lasten gestartet werden Der Aufwand f r das Aufbringen der Lasten hat sich erheblich verringert Bei der Benutzung des Straus API Tools treten allerdings unspezifische Fehler auf die h ufige Neustarts des Programms erforderlich machen Eine Verbesserung der Benutzbarkeit durch einen systematischen Testansatz erweist sich als schwierig da die Programmstruktur keine konsequente Kapselung und Modularisierung enth lt Das Beheben von Fehlern ist aufwendig da der Quellcode l ckenhaft do kumentiert ist Nach softwaretechnischer Analyse des vorhandenen Programms wurde davon Abstand genommen das Programm zu erweitern oder zu verbessern Stattdessen wurde gemeinsam mit dem bisherigen Entwickler der Entschluss getroffen das Programm von Grund auf neu zu konzipieren und zu implementieren 1 5 AUFGABENSTELLUNG Die Architektur des neuen Programms ist Gegenst
121. s die Fachlogik implementiert Dieses entspricht dem Model beim Model View Controller Muster Au erdem gibt es ein oder mehrere ViewModels die die dar zustellenden Sichten auf das Model modellieren Dieses ViewModel kann zum Beispiel eine Liste von Objekten sein die dann vom View als ComboBox Tabelle oder Graph dargestellt werden Da WPF f r das NET Framework der aktuelle Stand der Technik ist und durch dessen Anwendung automatisch eine leichte Aus tauschbarkeit der Benutzeroberfl che gew hrleistet wird wurde diese Technik ausgew hlt F r weitere Informationen zu WPF und dem MVVM Muster siehe Huber 2010 Verwendung eines Ribbon Men s verworfen Im Designprozess kam der Ge danke auf die Oberfl che nicht in Tabs aufzuteilen sondern f r die verschiedenen Steuerm glichkeiten ein Ribbon Men einzuf gen wie es Microsoft f r aktuelle Office Versionen entwickelt hat Dagegen spricht dass das Konzept des Ribbons ist ein bearbeitetes Objekt z B ein Dokument zu haben das konstant im Hauptbe reich der Oberfl che angezeigt wird Die Methoden zum Arbeiten mit dem Objekt sind in dem Ribbon nach unterschiedlichem Kontext angeordnet Das Straus Multitool ben tigt f r die unterschiedlichen Module auch unterschiedliche Dar stellungen des Modells Damit w rde sich beim Wechseln der Ansicht zu einem anderen Modul nicht nur das Men sondern auch die Ansicht des Objekts ndern m ssen Daf r ist das Ribbon aber nicht konzipiert Desh
122. sierung des BeamdataviewModel Objekts wer den die Stab Daten aus dem Straus Modell gelesen REQ 019 und die erste Be rechnung der Lasten ber die windloads Klasse wird angesto en REQ 022 Rechts oben im Bild findet sich auch hier das Instructionractory Objekt das hier die In struction SetGlobalMarineGrowth erstellt Damit kann der Wert f r den maritimen Bewuchs f r alle St be gleichzeitig ver ndert werden Falls der Benutzer vorher Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten aufwendig Werte per Hand in diese Spalte eingetragen hat und diesen Stand wie der herstellen m chte kann er den globalen Befehl r ckg ngig machen 3 4 2 4 WINDLOADSCHART Das UserControl windloadschart zeigt das Verh ltnis von H he zu Windlast von St ben gleichen Querschnitts an In der Legende f r die einzelnen Datenreihen wird also die Bezeichnung f r die Querschnittseinstellung angezeigt REQ 022b Zur Anzeige nutzt das windloadschart das online frei verf gbare Projekt Dynamic Data Display CodePlex Open Source Community Es sollte im weiteren Verlauf der Implementierung m glicherweise durch ein geeigneteres ersetzt werden da die freie Bibliothek Schw chen in der gemeinsamen Darstellung von Linien und Punktgraphen aufweist WindloadsChart K lt use gt gt Distributed Loads DistributedLoadViewModel DistributedLoad distributedLoads List lt DistributedLoad gt
123. solierbarkeit von Klassen und Methoden sichergestellt sodass diese von Testmethoden nutzbar wurden Die Techniken und Muster werden jeweils in dem Kapitel ber den Ar chitekturbaustein beschrieben in dem sie verwendet werden 2 1 3 FUNKTIONALIT T Die Gew hrleistung der richtigen Funktionalit t eines Programmes ist sehr wich tig Relevanz A Nach der DIN ISO 9126 kann das Qualit tskriterium Funktiona lit t zum Beispiel die Aspekte Angemessenheit Richtigkeit Interoperabilit t und Ordnungsm igkeit umfassen Die Beschreibung dieser Aspekte ist in Tabelle 2 zusammengefasst Angemessenheit Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen z B die ben tigte Genauigkeit von berechne ten Werten Richtigkeit Eignung der Funktionen f r spezifizierte Aufgaben z B aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen Interoperabilit t F higkeit mit vorgegebenen Systemen zusammenzuwir ken Hierunter f llt auch die Einbettung in die Betriebsinf rastruktur Ordnungsm igkeit Erf llung von anwendungsspezifischen Normen Verein barungen gesetzlichen Bestimmungen und hnlichen Vor schriften Tabelle 2 Aspekte des Qualit tsmerkmals Funktionalit t Starke 2011 Die Angemessenheit der Funktionalit t wird ebenso wie die Richtigkeit durch regelm ige pers nliche Gespr che innerhalb der Planungsphase und ausf hrli chen Reviews innerhalb der Durch
124. sse mit Unit Tests WindloadsTests Test Wie in der Abbildung zu sehen wird im Testprojekt die Testablewindloads Klasse definiert die von der windloads Klasse erbt Diese Klasse bernimmt alle Eigen schaften der Vaterklasse berschreibt aber die drei Methoden die auf die Straus API zugreifen mit Fake Methoden Da die windloads Klasse eine Referenz auf ein Objekt ben tigt das IConfiguration implementiert wird im Testprojekt ein Fake Objekt der Klasse Fakeconfig erstellt das nur diesen Zweck erf llt Die originale windloads Klasse nutzt die Configuration Komponente um die Richtung der Schwerkraft auszulesen die in der Modelldatei eingestellt ist In der Testablewind loads Klasse wird die Richtung im Feld gravityDirection abgelegt und ist an dieser Stelle auch f r den Test konfigurierbar Die Testf lle der Klasse windloadsTest tes ten die abgeleitete Klasse Testablewindloads anstelle der Original windloads Klasse Dazu nutzt sie au erdem die Klasse Parameters mit deren Hilfe sie beliebig konfi gurierte Parameters Objekte erstellen kann die sie der Testablewindloads Klasse zur Berechnung mitgeben kann Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten Auf diese Weise k nnen die Berechnungen der windloads Klasse unabh ngig von den Zugriffen auf die Straus API getestet werden Die Testbarkeit ist an dieser Stelle ausgesprochen wichtig weil hier die
125. stizieren oder um nderungsbed rftige Teile zu bestimmen Modifizierbarkeit Aufwand zur Ausf hrung von Verbesserungen zur Fehler beseitigung oder Anpassung an Umgebungs nderungen Stabilit t Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von nderungen Pr fbarkeit Aufwand der zur Pr fung der ge nderten Software notwen dig ist Tabelle 6 Aspekte des Qualit tsmerkmals nderbarkeit Starke 2011 Um eine gute Analysierbarkeit zu erreichen werden bei der Implementierung folgende Punkte ber cksichtigt e Ausf hrliche Logging Eintr ge REQ 006 e Konsequentes Dokumentieren des Codes REQ 008 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur e Gro fl chige Testabdeckung des Codes e Geworfene Exceptions enthalten Informationen ber die Situation in der sie aufgetreten sind Zu einer guten Modifizierbarkeit tragen bei e Schichtenarchitektur e Planung in Komponenten e Implementierung gegen Interfaces Die Stabilit t des Programms ber die Zeit soll durch die Einplanung zuk nftiger Anforderungen erm glicht werden Au erdem vereinfacht die modulare Bauwei se ein Einf gen von beliebigen Funktionen ohne dass die bersicht der Oberfl che oder des Quellcodes leiden muss Die Pr fbarkeit der Software soll durch Unit Tests sichergestellt werden Unit Tests bilden auch die Grundlage f r jede Refaktorisierung der Software Sie
126. t der Testbarkeit der Klasse Mehr dazu im folgenden Abschnitt 3 1 3 TESTBARKEIT Mit herk mmlichen Methoden von Unit Tests l sst sich lediglich die Configurati on Klasse testen weil sich diese einfach isolieren l sst Die Klasse XmlConfiguration Manager greift unmittelbar auf das Dateisystem zu und l sst sich somit nicht so ein fach vom Umfeld trennen Um die Klasse dennoch zu testen kann ein Mock Framework wie Moles vgl Microsoft Research verwendet werden das in der Lage ist auch statische Klassen und Funktionen aus NET Bibliotheken im Testfall zu ersetzen Viele Open Source Mock Frameworks wie Rhino Mocks Hibernating Rhinos LTD bieten diese M glichkeit nicht an Eine weitere M glichkeit die Klasse XmlConfigurationManager zu testen sind Integrationstests die das Zusam menspiel von Klassen untersuchen In diesem Abschnitt wird zun chst gezeigt wie die Configuration Klasse getestet werden kann Anschlie end werden m gliche Integrationstests f r die Klasse xml ConfigurationManager thematisiert Um die Configuration Klasse zu testen wird diese isoliert und von Testklassen umgeben Abbildung 9 gr n fett umrandete Klassen Die Klasse ConfigurationItem kann dabei ohne nderungen weiter verwendet werden weil sie keine Logik be inhaltet sondern lediglich als Container dient Sollte sich dies ndern muss der Test mit einem Stub f r die Klasse ConfigurationItem durchgef hrt werden F r die Tests wird ei
127. tierende Bibliotheken die dieses Problem adressieren wurden ober fl chlich untersucht Der Evaluierungsaufwand f r eine sichere Entscheidung hat sich dabei als zu gro erwiesen In der Programmiersprache F werden solche Rechnungen nativ unterst tzt Ob wohl diese Sprache direkt in das Programm integrierbare w re wurde auf die Einf hrung einer weiteren Programmiersprache verzichtet um die Komplexit t nicht unn tig zu vergr ern und die Wartbarkeit nicht einzuschr nken Die Situation f r die Handhabung der physikalischen Gr en als einfache Zah lenwerte wird dadurch entsch rft dass eine Umwandlung der Einheiten ber die Straus API jederzeit m glich ist Die L sung sieht nun so aus dass die im Modell eingestellten Einheiten beim ffnen einmal zwischengespeichert und beim Schlie en wiederhergestellt werden Damit merkt der benutzende Ingenieur nichts von der internen Umstellung Damit kann aber an jeder Stelle im Programm an der eine Berechnung erfolgen soll zun chst bequem die passende Umgebung herge stellt werden Als erstes werden die Einheiten im Modell eingestellt die f r die Rechnung passend erscheinen Dann werden die ben tigten Gr en aus dem Mo dell gelesen direkt mit den passenden Einheiten Die Rechnung wird durchge f hrt und das Ergebnis kann direkt gespeichert oder weiter verarbeitet werden Die Einheit der Ergebnisgr e kann leicht ermittelt werden Deshalb soll beim Programmieren nicht dav
128. tig eingestuft Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur 2 1 1 VERST NDLICHKEIT Verst ndlichkeit ist eine wichtige Eigenschaft Relevanz A einer guten Software Architektur Dazu schreibt Kent Beck in seinem Buch Implementation Patterns 2008 Kommunikation und Einfachheit arbeiten oftmals Hand in Hand Je ge ringer die Komplexit t ist desto leichter l sst sich ein System verstehen Je mehr Sie sich auf Kommunikation konzentrieren desto einfacher ist es zu sehen welche Komplexit t verworfen werden kann F r das Straus API Tools existiert keine Strukturdokumentation die das Ver st ndnis erleichtern k nnte Deshalb wurde ber die Funktion Code Visualization in Visual Studio eine bersicht ber die Abh ngigkeiten zwischen den einzelnen Klassen automatisch generiert Das Ergebnis findet sich in Abbildung 2 Dabei ist die Dicke einer Verbindungslinie proportional zur Abh ngigkeit der beiden Klas sen die die Linie verbindet Abh ngigkeiten k nnen zum Beispiel Aufrufe oder Referenzen sein Abbildung 2 Abh ngigkeiten der Klassen innerhalb des Straus API Tools Der Nutzen dieser Visualisierung ist begrenzt da keine Struktur der Klassen un tereinander erkennbar ist Leider bietet die Software nicht die M glichkeit die Anordnung der Klassen zu ver ndern um eine Gruppierung zu erreichen Dieses Bild macht aber deutlich dass eine verst ndliche Architek
129. tur Dokumentation Klassen in Funktionsgruppen aufteilen sollte Auch ist es f r die bersichtlichkeit wichtig die Abh ngigkeiten m glichst gering zu halten und die Verantwortlich Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Die Architektur keiten f r verschiedene Aufgaben auf die Klassen nach einer konsistenten Logik aufzuteilen vgl Wirfs Brock et al 2002 Um eine Ordnung in die Klassen des Straus Multitools zu bringen werden diese in Komponenten gruppiert Diese wiederum werden auf verschiedene Schichten aufgeteilt siehe Kapitel 2 3 Die Komponenten 2 1 2 TESTBARKEIT Bei jeder Software ist Testbarkeit ein wichtiges Kriterium Gernot Starke empfiehlt dass Testbarkeit von Anfang an zu den wichtigsten Kriterien f r den Systement wurf geh ren sollte Starke 2011 S 174 Dies muss nicht zwangsl ufig bedeuten dass nach dem Test Driven Development Prinzip entwickelt wird sondern vor allem dass ein testbares Design garantiert ist Dies definiert Roy Osherove als ein Design in dem f r jedes logische Code St ck leicht und schnell ein Unit Test ge schrieben werden kann sherove 2010 F r das Straus Multitool ist Testbarkeit neben Wartbarkeit eines der beiden Ar gumente f r die Neuentwicklung Denn die Software entsteht in einer Dom ne in der die Korrektheit der Berechnungen relevant f r die Sicherheit ist REQ 039 W rde die Software Rechenfehler bei den Lastenrechnungen
130. ue getValue key gibt mit Key Value Paaren value zur ck 11 G ltige XML Datei changeValue notExistingKey noSuchKeyException value Tabelle 8 M gliche Testf lle f r die Configuraion Komponente Eine Umsetzung der genannten Testf lle mit dem NUnit Framework wird hier umrissen In der Tabelle sind XML Dateien mit unterschiedlichem Inhalt gefor dert Dazu sollten im Test Ordner unterschiedliche Dateien mit dem entsprechen den Inhalt angelegt werden die f r den jeweiligen Testfall genutzt werden ber die TearDown Methode des Testframeworks muss nach jedem Test der urspr ngli che Zustand der Dateien wieder hergestellt werden Dazu sollte keine Methode der Komponente verwendet werden weil diese ja noch getestet werden soll Bes ser w re es Prototyp Dateien zu halten mit denen jeweils die ver nderte Datei wieder berschrieben wird 3 1 4 DESIGNENTSCHEIDUNGEN Eine Reihe von M glichkeiten zur Gestaltung dieser Komponente wurde im Laufe der Konzipierung evaluiert Diese Entscheidungen sollen im Folgenden kurz be gr ndet werden Kein dynamisches Hinzuf gen und L schen von Schl ssel Wert Paaren ber die Komponenten Schnittstelle Einstellungen die langfristig gespeichert werden sollen stehen schon bei der Entwicklung des Programms fest Es gibt bisher kei nen Grund warum zur Laufzeit des Programms Werte hinzugef gt werden soll ten Deshalb wurde beschlossen dass der Entwickler die bestehende XML Datei
131. uiert werden A 1 7 QUALIT TSANFORDERUNGEN In diesem Kapitel finden sich die Qualit tsanforderungen wie sie mit Overdick vereinbart wurden Weitere Qualit tsaspekte die sich in der Recherche Phase er geben haben werden in Kapitel 2 1 n her beschrieben amp Durchstich REQ 039 Berechnungen korrekt FLO Zum Zweck des Programms geh rt es den Nachweis zu erbringen dass ein ent wickeltes Modell einschl gigen Normen entspricht Dazu werden Lasten gene riert mit denen in einer Simulation das Modell belastet wird um die Stabilit t zu testen Aus diesem Grund ist es sehr wichtig dass die programminternen Rech nungen korrekt sind da Fehler schlimme Folgen haben k nnten Daher sollen alle Module die Berechnungen ausf hren besonders gr ndlich mit Hilfe von automa tisierten Unit Tests auf Korrektheit gepr ft werden N REQ 052 Stabilit t Durchstich FLO Das Modell und die Ergebnisse m ssen sich zu jedem Zeitpunkt w hrend der Programmlaufzeit in einem konsistenten Zustand befinden Wenn ein Befehl fehl schl gt oder das Programm unsachgem beendet wird sollte die Datei an der gearbeitet wurde nicht irreparabel besch digt sein Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang A 2 INHALT DER CD Die Inhalte der CD sollen im Folgenden vorgestellt werden Die CD enth lt abge speicherte Online Literaturquellen und den Quellcode
132. ur Reengineering einer Verifikationssoftware f r Strukturmodelle von V 3 5 ModelManasenent une 50 35 1 V r und Nachbeins ngn s unesinnanaen 50 Eege EE 50 2 59 a EN E einen 51 3 34 DesisnnshidweN nennen 51 3 6 Ambience Komponente eege 53 3 6 1 Vor und Nahbeini enee 53 30 2 STOKT si ae aeie e r E EN a aerae AN aa EE EEEN 53 303 Testbark it anne nahen 54 3 64 Desisnentscheidungen nn een 54 3 7 niual2anon Kompenene ernsten 56 2 Technische Kofzeple nie nenne neueren 57 4 1 Ausnahme und Fehlerbehandlme un 57 e OTA 01 E A E E EE 58 AS D ENT EE 58 E 60 SA 60 31 1 Erwelerbarelt A sun 60 5 1 2 T stbarkeit EE 63 51 3 Verst ndlichkeit A nesciens nnion ann 63 5 14 Zuverl ssigkeit EE 65 5 1 5 Benutzbarkeit DB anni 65 e EI eh B een riviin herein 66 5 2 Zu kuntedes Projekts sans euere 66 5 3 Abschlie ende Bewertine iorsin inueniri een 66 Literatu enn E E E E 68 A a A E A E ZA A 1 Liste der Anlorder ngen sein een isie oiiaii 71 Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Kai E BET aus a 72 E Anforderungen an Performance ea 81 A 13 Design Constramtsssinsanseanssneaninnseniaeigenn teen near iaeiae aa 81 A15 Dokumentation zack reichende AAA ANAE 82 A16 Bentitzbarkeit andeelen ee degen 83 4 1 7 Oualitetsanlorderungen ae 84 A2 nhalt der Da aaa ee Teer her 85 A 1 1 Online Quellen aus dem Literaturverzeichnis seeseeseeesosoeeeeseresesersee 85 A 1 2 Quellcode
133. us den Ergebnissen soll ein automatischer Bericht generiert werden k nnen Die ser soll grafische Darstellungen sowie Textelemente Gr en mit Einheiten und Tabellen enthalten k nnen A 1 2 5 KLEINERE HILFSFUNKTIONEN Das Straus Multitool soll eine Reihe kleinerer Hilfsfunktionen anbieten Deren Funktionen werden in diesem Abschnitt kurz angerissen A sp ter JHU REQ 030 Auffinden von unverbundenen St ben Die Software soll bei importierten Modellen siehe auch REQ 036 mit Hilfe eines Zielwinkels unverbundene St be und Platten aufsp ren Dabei soll die Suche auf einzelne Member Gruppen im Modell einschr nkbar sein Member Gruppen sind als Elemente im Modell gespeichert und verweisen auf die einzelnen Elemente St be Knoten in ihnen Selektieren von St ben bestimmter ZS sp ter REOQO 033 L nge Straus API Tool Die Software kann aus dem Modell alle St be oberhalb einer bestimmten L nge selektieren Diese k nnen auf Wunsch unterteilt werden Wenn die St be vorher zu lang waren wird mit diesem Schritt die Berechnung des Modells erst m glich REQ 035 Clean Mesh ZS sp ter Straus API Tool R umlich bereinander liegende Knoten die eigentlich eine Verbindung sein soll ten k nnen zu einem Knoten verschmolzen werden Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Anhang REQ 036 Tekla Import Z sp ter S
134. zwei Interfaces siehe Abbildung 10 Das History Objekt bernimmt die Verwaltung des Undo und des Redo Stacks Objekte die das Interface IInstruction implementieren k n nen sich ber die IHistory Schnittstelle bei dem History Objekt per done Methode registrieren und werden somit auf dem Undo Stack abgelegt Zum detaillierten Vorgehen siehe Krypczyk 2011 lt lt use gt gt IHistory mw undoable bool History lt lt Interface gt gt IInstruction execute undo redo History Abbildung 10 Klassendiagramm der History Komponente 3 2 3 TESTBARKEIT Um die Komponente testen zu k nnen wird ein Objekt der Klasse History erstellt und eine Dummy Instruction implementiert Diese ist von der HistoryTests Klasse v llig kontrollierbar und hilft das Verhalten der History Klasse zu untersuchen Die vollst ndige Teststruktur ist in Abbildung 11 dargestellt Im Vergleich zu Ab bildung 10 ist zu erkennen dass zwei Methoden zur History Klasse hinzugef gt Architektur Reengineering einer Verifikationssoftware f r Strukturmodelle Beschreibung der Komponenten worden sind Sie sind in Abbildung 11 gr n markiert ber diese beiden Metho den ist die Tiefe des Undo und des Redo Stacks auslesbar Dar ber kann das Verhalten der History Klasse ebenfalls berpr ft werden HistoryTests History D undoStack Stack lt IInstruction gt redoStack Stack lt IlInstruction gt

Dokument 1 - Dokumentenserverhosting der SUB

Contents

Download Pdf Manuals

Related Search

Related Contents