Andreas Awenius’ blog

Hallo,

die Entwicklung von sog. “Office Based Applications” – d.h. Lösungen für Geschäftsprobleme die durch Erweiterung der Microsoft Office Programme erstellt werden – scheint derzeit groß in Mode zu sein. Die “Visual Studio Tools for Office” (VSTO) versprechen, die Erstellung von AddIns für Microsofts Office Anwendungen einfacher zu machen und dabei die gesamte Bandbreite .NET basierter Frameworks zu Verfügung zu stellen. Diese neuen technischen Möglichkeiten möchte ich gerne näher erkunden und werde dazu eine kleine, aber praxisnahe Anwendung als AddIn für Word 2007 erstellen. Dieses Projekt wird das Thema meiner nächsten blog-postings sein.

Thema

Da der Aufwand sicher nicht ganz gering sein wird, wäre es schön wenn das Ergebnis auch einen praktischen Nutzen hätte. Andererseits möchte ich mich im Rahmen dieser Blog-Postings nicht mit der Lösung eines Geschäftsproblems beschäftigen sondern mit den Möglichkeiten der Erweiterung und Integration von bzw. mit Microsoft Word.

Deshalb wird die angestrebte Lösung eine Prüfung von OCL-Fragmenten auf syntaktische Korrektheit und Typkonformität implementieren. Falls ein solches AddIn eine gewisse Reife erreichen würde, könnte ich es als kostenlosen download auf meiner Firmenwebsite anbieten und damit neue Besucher gewinnen und evtl. Feedback und Diskussionspartner finden. Die komplexe Funktionalität ist für andere Entwicklungsprojekte bereits implementiert und kann ohne großen Aufwand wiederverwendet werden.

Die Verwendung von OCL erlaubt es, Geschäftsregeln formal zu definieren, bevorzugt im Kontext eines UML-modells.

Anforderungsdefinition

Die genauen Anforderungen definieren wir folgendermaßen:

• Zu einem Word-Dokument kann ein UML-modell als XMI-Datei geladen werden. Mit jedem geladenen Dokument wird eine eigene XMI-Datei assoziiert.
• In dem Word-Dokument können OCL-Fragmente definiert werden. Diese werden mit einer speziellen Formatvorlage formatiert. Diese Formatvorlage dient sowohl zur visuellen Gestaltung des OCL codes als auch zur Erkennung des codes durch das AddIn.
• Dem Word-Ribbon wird ein neues RibbonTab hinzugefügt, das die Funktionalität des AddIns bereitstellt.
• Diese besteht aus zwei buttons, einem zum laden des assoziierten XMI-files, einen zum Auslösen des checks aller OCL-Fragmente im gesamten Dokument. Nach einem click auf diesen button wird das gesamte Dokument nach OCL-Fragmenten durchsucht und diese im Kontext des durch das XMI-file definierten Modells geprüft.
• Die Ergebnisse werden in einem separaten Dialogfenster angezeigt.

Die oben genannten Anforderungen sind die Minimalanforderungen, die in jedem Fall implementiert sein müssen, damit das AddIn einen gewissen praktischen Nutzen hat.

Folgende weitere Anforderungen wären sinnvoll, sind aber eventuell zu aufwendig (”nice to have”):

• Beim Klick mit der rechten Maustaste in ein als OCL-Fragement formatierten Text erscheint ein Kontextmenü, mit dem eine Prüfung nur für dieses Fragment angestoßen werden kann. Alternativ kann auch im Ribbon ein button “Check current fragment” zur Verfügung gestellt werden.
• Die Ergebnisse der Prüfung sollten als eigenes Fenster in der Word-Anwendung (”Task pane”) erscheinen. Damit können die Fehler bearbeitet werden und die Prüfungsergebnisse bleiben weiterhin verfügbar. Weiterhin wäre es sinnvoll, wenn man direkt von einer Fehlermeldung an die fehlerhafte Stelle im Dokument navigieren könnte.
• Das gewählte XMI-file wird dauerhaft mit dem Dokument assoziiert, d.h. beim nächsten Laden des Dokumentes lädt das AddIn automatisch die XMI-Datei. Hierzu müsste dem Dokument eine “user defined property” mit dem entsprechenden Dateinamen/Pfad hinzugefügt werden.

Ressourcen:

Visual Studio Tools for Office Developer Portal (Microsoft)

Microsoft VSTO Forum

Im nächsten posting werde ich die konkreten zu lösenden Problem definieren.

Viele Grüße,
Andreas

Technorati Tags: Microsoft Word AddIn, Visual Studio, C#

Hallo,

kürzlich hat mich Microsofts C# compiler mit seiner intelligenten Analyse verblüfft. Ich hatte sinngemäß folgenden code geschrieben:

for (int jj = 0; jj < parts.Length - 1; ++jj)
{
    part = parts[jj];
    int count = result.getRefCount(refAttr);
    for (int ii = 0; ii < count; ++ii)
    {
        EOInstance packagedElement = result.getRefObject(refAttr, ii);
        if (packagedElement.getValue("Name") == part)
        {
            result = packagedElement;
            continue;
        }

    }
    string msg = "Cannot resolve path '" + parts.ToString() +
                     "' for attribute '" + refAttr + ". Unknown part is '" +
                     parts + "'.";

    throw (new Exceptions.UnknownPathException(msg));
}

Der C# compiler meldete:

Fehler CS0162: Warnung als Fehler: Unerreichbarer Code wurde entdeckt.

und die IDE markierte die Inkrement-Anweisung ‘++jj in der äußeren for-Schleife.

Nach konzentrierter Durchsicht des codes ist mit der Fehler aufgefallen: die throw Anweisung sollte in die innere Schleife verschoben werden. So wie der code geschrieben war, wurde die äußere Schleife tatsächlich nur einmal durchlaufen und die Inkrement-Anweisung nie ausgeführt da immer am Ende des ersten Durchlaufs eine exception geworfen wurde.

Der C++ compiler von Visual Studio findet dieses Problem nicht, auch nicht im release build (wo der compiler weitergehende semantische Prüfungen machen kann unter Ausnutzung der Analyse-Ergebnisse des optimizers).

UnreachableCode - 0 Fehler, 0 Warnung(en)
==== Erstellen: 1 erfolgreich, Fehler bei 0, 0 aktuell, 0 übersprungen ====

Bleibt noch die Frage, was PC-Lint (das ich seit mehr als 10 Jahren für alle C++-Entwicklungen verwende) zu der Sache meint.
Enttäuschenderweise meldet es diesen Fehler auch nicht, nicht mal mit zwei Durchläufen (-passes(2)):

PC-lint for C/C++ (NT) Vers. 8.00w, Copyright Gimpel Software 1985-2007

--- Module:   UnreachableCode.cpp (C++)

/// Start of Pass 2 ///

--- Module:   UnreachableCode.cpp (C++)

--- Global Wrap-up

error 900: (Note -- Successful completion, 0 messages produced)

Für diese Test habe ich folgenden mutmaßlich äquivalenten code verwendet:

        for (int jj = 0; jj < 10; ++jj)
	{
		for (int ii = 0; ii < 10; ++ii)
		{
			if (ii == 5)
			{
				continue;
			}
		}

		throw(std::exception("Huh"));
	}

Also wirklich eine beeindruckende Leistung des C# compilers.

Der code enthält übrigens noch einen weiteren logischen Fehler, auf den ich erst durch die Meldung des C# compilers aufmerksam wurde, was aber für die Intention dieses postings nicht relevant ist.

Viele Grüße,
Andreas

Technorati Tags: C#, compiler, FlexeLint, PC-Lint

Nachtrag vom 04.05.2008: ein kluger Kollege hat mich darauf hingewiesen, dass Microsoft Visual C++ bei Verwendung von warning level 4 den gewünschten Hinweis tatsächlich meldet. Für meine Produktionssoftware verwende ich /W4, für das kleine Beispielprogramm habe ich es aber bei den defaults belassen.

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

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