Archive for February, 2008

Tutorials auf der SE2008

Monday, February 25th, 2008

Hallo,

kürzlich habe ich zwei Tutorien auf der Software-Engineering-Konferenz 2008 besucht, nämlich “Architekturprüfung in der Praxis” und “Validation and Verification on Model and Coding Level“.

Ich habe das neue Gelände der Technischen Universität München in Garching zum ersten Mal persönlich gesehen. Es ist ein großes, geräumiges Gelände mit dedizierten Gebäuden für die verschiedenen Fakultäten und viel Raum dazwischen. Ich fand das Gelände sehr einladend, wozu sicher auch der strahlende Sonnenschein beigetragen hat. Auch die Gebäude selbst sind sehr schön gestaltet, viel Licht, räumlich großzügig, viele Pflanzen, viel Holz und Metall. Die Atmosphäre wirkte ideal für eine Hochschule, ruhig und konzentriert.

Das Tutorium “Architekturprüfung in der Praxis” wurde von zwei Frauen gehalten, die als Beraterinnen für das Software-Unternehmen C1 WPS tätig sind. Im wesentlichen haben die beiden das kommerzielle Softwaretool Sotoarch des deutschen Unternehmens Software-Tomography vorgestellt. Sotoarc analysiert die Beziehungen zwischen den Klassen eines Softwaresystems und erlaubt es verschiedene Schichten zu definieren. Weiterhin können Regeln festgelegt werden, wie die derart gebildeten Subsysteme auf einander zugreifen können. Sotoarc zeigt dann Verletzungen dieser Regeln auf und unterstützt das finden von refactorings die die Einhaltung der Regeln wieder herstellen.

Im wesentlichen wird man also dabei unterstützt, eine sinnvolle Aufteilung der Verantwortlichkeiten einer Software auf code-Ebene zu erreichen. Damit werden vor allem die Ziele einer leichteren Wartbarkeit (durch Verringerung der Abhängigkeiten) und der besseren Testbarkeit angestrebt.

Ich persönlich würde die Aspekte die Sotoarch unterstützt eher als Design und weniger als Architektur betrachten aber diese Begriffe sind ja ohnehin nicht klar definiert. Zur Software-Architektur zählen für mich eher Konzepte die von der Strukturierung der Software auf Quelltext-Ebene unabhängig sind, wie z.B. die Aufteilung von Funktionalitäten auf verschiedene Rechner, Verfahren zu Speicherung von Daten und Kommunikation, Verwendung von threads, die Auswahl der Infrastruktur etc.

Sotoarc verwendet eine Datenbank, d.h. nach dem parsen des Quellcodes wird eine Repräsentation der Quellcode-Dateien, der in Ihnen definierten Software-Elemente und ihrer Beziehungen dort gespeichert. Dies ist bei grossen Software-systemen sicher von Vorteil, das das Ermitteln dieser Informationen sonst bei jedem Programmstart viel Zeit brauchen würde. Außerdem bekommt man dann mit der Datenbank eine Abfragesprache geschenkt, mit sich erst die interessanten Information extrahieren lassen.

Von der gleichen Firma gibt es die Erweiterung Sotograph, die die Datenbasis von Sotoarc nutzt. Sotograph berechnet im wesentlichen verschiedene Metriken und weist auf die Verletzung vordefinierter Bandbreiten hin. Solche Werkzeuge sind durchaus nützlich, um Schwachstellen in der Software aufzudecken.

Insgesamt war es ein informativer, professioneller Vortrag, vom Focus her aber etwa beschränkter als ich es mir erwartet hatte.

Der zweite Vortrag war hingegen ziemlich enttäuschend. Zum einen war der Fokus eindeutig zu stark auf das Produkt Simulink gesetzt, zum anderen war mir nicht klar dass Simulink in einem so hohen Masse ein domänenspezifisches (Schaltungs- und Regelungstechnik) Produkt ist.

Insgesamt hat es ziemlich Spaß gemacht, mal wieder etwas anderes zu hören und sich mit anderen Software-Entwicklern auszutauschen.

Viele Grüße,
Andreas

MOMOCS Studie zu Software Modernisierungsprojekten

Thursday, February 21st, 2008

Hallo,

Das MOMOCs-Projekt hat die Ergebnisse einer Umfrage zum Thema “Modernization Projects” veröffentlicht. Insgesamt enthält die Zusammenfassung wenig interessante Ergebnisse. Bemerkenswert fand ich:

  • Test Driven Development wurde von vielen Teilnehmern positiv erwähnt
  • Für mich etwas überraschend wurden UML und MDA oft erwähnt – in der Regel positiv
  • SOA (Service Oriented Architecture) wurde kaum erwähnt. Hier wiederum hätte ich mehr Nennungen erwartet denn ein legacy system in einem Web Service zu wrappen und als Dienst verfügbar zu machen wäre für mich eine naheliegende und typische Modernisierungsstragetie.

Das MOMOCS-Projekt scheint eine herstellerübergreifende Initiative ähnlich der OMG (Object Management Group) zu sein, im Gegensatz zur OMG aber auch mit Beteiligung von Hochschulen und öffentlich gefördert.

“Im Rahmen des MOMOCS-Projektes werden Methoden und Werkzeuge zur Modernisierung komplexer Systeme aus dem Software und Anlagenbereich entwickelt.”

Auf der MOMOCS-Website gibt es auch eine Übersicht vieler UML-tools in der unverständlicherweise Enterprise Architect fehlt.

Viele Grüße,
Andreas

Popularität von UML tools

Monday, February 18th, 2008

Guten Tag!

Tim Weilkiens – sicher einer der profiliertesten Experten für UML in Deutschland – hat vor einiger Zeit einen kleinen Artikel über die Popularität von UML tools verfasst. Im wesentlichen deckt sich seine Einschätzung mit meiner: Enterprise Architect von Sparx Systems und MagicDraw von NoMagic sind derzeit die populärsten UML tools, wobei Enterprise Architect meinem Endruck nach deutlich vorne liegt, zumindest in Deutschland. Der Artikel enthält noch eine Übersichtstabelle aktueller Tools mit verschiedenen Entscheidungskriterien.

Viele Grüße,
Andreas

Versionsinformation in managed C++ assemblies

Thursday, February 14th, 2008

Guten Tag,

kürzlich ist mir aufgefallen, dass in einer managed C++ assembly die in Visual Studio erzeugt wurde keine Versionsinformation im klassischen Sinne vorliegt. D.h. tools die die Versionsinformation einer DLL auswerten – wie z.B. Programme die Setups erzeugen – finden keine Versionsinformation und auch der Windows Explorer zeigt keine Versionsinformation an. Dies ist etwas irritierend, da das Projekt ja eine Datei AssemblyInfo.cpp enthält, die genau die Informationen beinhaltet, die man als Versionsinformation betrachten würde. Bei einer C# assembly klappt es ja auch! Dort wird der Inhalt von AssemblyInfo.cpp wie erwartet von allen tools als Versionsinformation erkannt.

Wie man z.B. hier lesen kann wird die Versionsinformation als resource in einem bestimmten Format in der DLL erwartet. In einer managed C++ assembly wird eine solche resource nicht automatisch erzeugt!
Die Information aus AssemblyInfo.cpp wird lediglich für die .NET-interne Verwaltung von assemblies benutzt.

Als Lösung bleibt lediglich selbst eine Versions-resource hinzuzufügen. Dies geht einfach über das Kontexmenü für die assembly: Einfügen/Resource dann im erscheinenden Dialog “Resource hinzufügen” als Typ “Version” auswählen.

Das eigentlich Problem bei dieser Vorgehensweise ist dass die Version nun redundant in der assembly vorhanden ist und es dem Entwickler obliegt die Information konsistent zu halten. Glücklicherweise liegen beide Quellen als normale Textfiles vor so dass man ein kleines Skript oder Programms schreiben kann, dass als “Präbuildereignis”gestartet werden kann und bei Bedarf eine der beiden Dateien aus der anderen aktualisiert (sinnvollerweise sollte man AssemblyInfo.cpp als “master” verwenden da dort noch weitere Information eingetragen ist).
Es wäre interessant zu wissen, ob Microsoft für diese Entscheidung Gründe hatte oder ob das Erzeugen der Versions-resource lediglich vergessen wurde.

Viele Grüße,
Andreas