Video-Interview

Thu, 16 Apr 2009 10:22:53 +0200

"Wir bieten Lösungen, Werkzeuge, Methoden und Schulungen,
um solide Software zu machen..."

Hören Sie sich rein...

Pressemitteilungen

Fri, 11 Jun 2010 15:58:13 +0200

Hier finden Sie interessante Neuigkeiten

UML Code Generierung endlich zu erschwinglichen Preisen!
Die Spezialisten für Embedded UML aus Bückeburg (Willert Software Tools GmbH) und die Wiener Enterprise Architect Experten (LieberLieber Software GmbH) haben gemeinsam eine Code Generierungs-Lösung auf Basis von Enterprise Architect von Sparx Systems, LieberLieber AMUSE und dem RXF von Willert entwickelt. Diese Lösung wird erstmals auf der embedded World 2011 in Nürnberg an den Ständen 510 und 231 in Halle 10 vorgestellt.
mehr Informationen

UML-basierende Entwicklungsumgebung zum kleinen Preis

Debugging von UML Modellen auf realer Hardware ohne Echtzeitverletzung

Sicherheitsnormen und Anforderungsmanagement RiskCAT für das Tailoring von Normen und den Import in IBM® Rational® DOORS®

Artikel

Tue, 05 Oct 2010 16:01:49 +0200

Autor: Andreas Willert

Wie man für konsistente Dokumente im V-Modell sorgt

Ingenieurwesen ist die Wissenschaft des systematischen Erfindens. Doch wieviel Systematik bleibt noch, wenn die Anforderungen eines Projekts in einem Wust unstrukturierter Text-Dokumente definiert sind? Mit einem Repository lassen sich Ordnung und Übersicht in die Dokumentation bringen, so dass der Entwicklungsprozess nicht aus dem Ruder läuft.

Wer bleibt schon von wachsender Komplexität verschont? Müssen Sie sich auch nach einem neuen leistungsfähigeren Mikrocontroller umsehen, weil der derzeitige den Anforderungen nicht mehr gerecht wird? Und wie sieht es aus mit den Anforderungen im Software- und Systems-Engineering? Wie steht es um die Konsistenz der Projektdokumentation, den Lasten- oder Pflichtenheften zum Beispiel gegenüber dem Code? Wurden sie auf Basis von Word-Dokumenten erstellt? Bei steigender Komplexität geraten auch Vorgehen im Software-Engineering an die Grenzen der Effizienz.
Im Software-Engineering werden immer noch viele Informationen in Form von Office-Dokumenten verwaltet. Dabei entstehen je nach Phase und Technik im Engineering-Prozess separate Dokumente mit redundanten Informationen. Unter dem wachsendem Zeitdruck ist es fast unmöglich, diese redundanten Informationen in den verschiedenen Dokumenten konsistent zu halten.
So zeigt eine Umfrage unter unseren Kunden, dass in 95 % der Projekte die Dokumentation der Software (egal, ob sie mit MS Word, MS Visio oder anderen dokumentenzentrischen Werkzeugen erstellt wird) nahezu nutzlos ist, da sie nicht konsistent mit dem Source-Code gehalten werden kann und damit nicht verlässlich ist. In Projekten, in denen auf Grund von Sicherheitsanforderungen hohe Qualität gefordert wird, gehört es schon seit langem zum Stand der Technik, dass alle Dokumente, Modelle, Code und Testfälle untereinander konsistent gehalten werden. Grundsätzlich ist es also möglich und nur eine Frage des Vorgehens. Was mit einer dokumentenzentrischen Arbeitsweise ein fast unmögliches Unterfangen ist, wird auf Basis eines Repository auf einmal sehr einfach.

Lassen sich redundante Informationen vermeiden?

Stellen wir uns einmal die Rollen und Personen in folgendem Projekt vor. Eine Firma möchte die Entwicklung eines Audio-D/A-Konverters in Auftrag geben. Betrachten wir die so genannten Stakeholder in diesem Projekt hinsichtlich einer Produkteigenschaft, dann könnten in etwa folgende Informationen entstehen:
Der angestrebte Zielmarkt sind Menschen mit gehobenem Musikanspruch, hinsichtlich des Sounds steht im Lastenheft "HiFi High End Qualität".Der Projektleiter hat bei dieser Definition berechtigte Bedenken bezüglich der Testbarkeit und definiert etwas exakter eine Auflösung von 16 bit und eine Sample-Frequenz von 44,1 kHz entsprechend dem RedBook-Standard für Audio-CDs.
Der Entwickler programmiert einen Timer, um den Takt für die erforderliche Sample-Frequenz zu erzeugen; die Syntax könnte in etwa so aussehen: GPT1Reload = 0xFF32;
Eigentlich steckt hinter der Syntax aller Stakeholder die gleiche Information, allerdings in verschiedenen sprachlichen Ausprägungen. Könnte man diese vereinheitlichen? Ich befürchte nicht. Die Aussagen sind domänenübergreifend nicht mehr verständlich oder nicht präzise genug. Wir müssen also mit redundanten Informationen leben, aber wie geht das mit vertretbarem Aufwand?

     Bild 1. Wenn Systemdefinitionen und
     -anforderungen in Form üblicher
     Office-Dokumente verwaltet
     werden, entsteht eine große Zahl
     von Dokumenten mit vielen redun-
     danten Informationen.

Im dokumentenzentrischen Vorgehen ergibt sich eine große Anzahl an Dokumenten mit redundanten Informationen und gegenseitigen Abhängigkeiten (Bild 1). Bei einem genaueren Blick in die Dokumente stellt sich heraus, dass es sich in der Regel um 1:n-Beziehungen handelt. In realen Projekten ist die Größe eines Lasten- oder Pflichtenheftes im Bereich von 100 Seiten nicht selten. Ändert sich eine Anforderung im Lastenheft, dann wird niemand das komplette Pflichtenheft durcharbeiten, um alle Abhängigkeiten herauszufinden. Dies ist der erste Schritt zu inkonsistenten Dokumenten.
Einfacher geht es auf Basis eines Repository z.B. mit Hilfe eines Anforderungsmanagement-Werkzeugs. (Bild 2) zeigt die Gegenüberstellung der Dokumente auf Basis ihrer Beziehungen. Hier können Auswirkungen auf einen Blick vollständig erfasst werden. Auf Basis eines Repository lassen sich Abhängigkeiten von Anforderungen eines Projektes in Beziehung setzen.

   Bild 2. Wenn die Anforderungen in
   einem passenden Werkzeug verwaltet
   werden, sind Beziehungen zwischen
   den Dokumenten sofort sichtbar.

Sehr häufig werden als Quellen für Anforderungen lediglich Kunden oder Anwender gesehen. In der Praxis können Anforderungen aber von überall her kommen. Stellen Sie sich vor, die Leistung des eingesetzten Mikrocontrollers ist nicht mehr ausreichend. Ein Hardware-Re-Design ist geplant und in diesem Zusammenhang muss ein neuer Mikrocontroller ausgewählt werden. Was sind die Anforderungen für den Mikrocontroller?
In diesem Fall, in dem die Software wiederverwendet werden soll, kommen die Anforderungen im Wesentlichen aus der Implementierung. Wurden im Repository die Abhängigkeiten zwischen Software und Mikrocontroller-Peripherie definiert, lässt sich sehr schnell ein Dokument erstellen, in dem alle Peripherie-Elemente mit den Anforderungen aus der Software aufgelistet sind.

Implementierung auf Basis eines Repository

Nun werden nicht alle Arbeitsschritte auf Basis textueller Informationen durchgeführt. Zum Beispiel wird Software programmiert oder modelliert. An dieser Stelle entstehen redundante Informationen zwischen Source-Code und Dokumentation. Auch diese Zusammenhänge und Abhängigkeiten lassen sich auf Basis eines Repository leichter verwalten.
Modellierungswerkzeuge, z.B. auf Basis von UML, ermöglichen Import und Synchronisation von Anforderungen in das Modell. Innerhalb des Modells können die Anforderungen (z.B. zur Dokumentation des Modells) direkt in einer Darstellung angezeigt werden, sie können aber auch mit Modellelementen verlinkt und im Fall der Code-Generierung als Kommentar in den Code übernommen werden. Das gleiche gilt auch für andere Werkzeuge, z.B. zur Erstellung von Regression-Tests. Voraussetzung ist immer ein Repository. Auf Basis der Traceability eines Repository oder mehrerer verlinkter Repositories können folgende Analysen durchgeführt werden.

Coverage-Analyse - Sind alle Anforderungen erfüllt?

Impact-Analyse - Analyse der Auswirkung möglicher Änderungen.

Trace-Analyse - Analyse der Ursache.

Automatische Nachricht über Änderungen

   Bild 3. Wenn sich bei den Anfor-
   derungen in der Kette der Bezie-
   hungen ein Glied ändert, wird im
   Anforderungswerkzeug ein
   "Suspect Link" angezeigt, der auf
   Unstimmigkeiten hindeutet. Mit
   einem Mausklick lassen sich
   Änderungen nachverfolgen.

Sind die Abhängigkeiten verschiedener Informationen im Repository definiert und hat jeder Stakeholder ein Dokument mit seiner domänenspezifischen Sichtweise auf das System und anschließend ändert sich etwas im System, zu dem sein Dokument einen Bezug hat, dann wird in seinem Dokument ein so genannter "Suspect Link" angezeigt (Bild 3). Mit einem Mausklick darauf kann er die Änderungen in angrenzenden Domänen nachverfolgen. Auf diese Weise werden alle entstehenden Inkonsistenten sichtbar und einfach nachverfolgbar gehalten - eine wesentliche Voraussetzung, um die entsprechend der Domänen und Stakeholder redundanten Informationen untereinander konsistent zu halten.

Umstellungsaufwand: vom dokumenten- zum repository-zentrierten Vorgehen

Zur Einführung eines Repository zur Speicherung und Strukturierung aller projektrelevanten Informationen sind auf Basis eines geeigneten Anforderungsmanagement-Werkzeuges folgende Schritte erforderlich:

Anpassung der Struktur des Repository auf die Vorgehensweise und die Informationen des Unternehmens (Erstellung eines so genannten Datenbank-Schemas).
Definition und Erstellung von Darstellungen und Ansichten der Repository-Inhalte für die verschiedenen Fachdomänen bzw. Stakeholder.
Eventuell Import vorhandener Dokumente in das Repository.
Definition der Abhängigkeiten.
Eventuell Export der Daten in übliche Dokumente für Stakeholder, die nicht mit dem Werkzeug arbeiten.
Schulung des Teams im Umgang mit Methode und Werkzeug.

Für die Durchführung der obigen Schritte werden folgende Kenntnisse und Aufwand benötigt:
Für die Erstellung eines Datenbank-Schemas muss mit einigen Tagen gerechnet werden. Beim ersten Mal sollte hier auf jeden Fall ein Experte hinzugezogen werden. Das Datenbank-Schema ist das Gerüst des Repository. Bei der Erstellung müssen bereits im Vorfeld mögliche zukünftige Analysen und Darstellungen berücksichtigt werden, die evtl. erst im Verlauf des Projektes interessant werden. Das geht nur mit Erfahrung.
Für die Erstellung der domänenspezifischen Ansichten (Views) müssen ein bis zwei Tage Aufwand gerechnet werden. Auch hierfür ist beim ersten Mal die Unterstützung durch einen Experten hilfreich.
In der Regel liegen bereits Dokumente mit Informationen vor. Gut strukturierte Dokumente lassen sich mit modernen Anforderungsmanagement-Werkzeugen sehr einfach automatisch importieren. Schlecht strukturierte Dokumente müssen vorher strukturiert werden (GIGO - Garbage in, Garbage out). Auf Basis von Styles bzw. Formatvorlagen sind hier pro Seite ca. ein bis drei Minuten zu rechnen, wenn die Inhalte nicht verändert werden müssen.
Die Definition der Abhängigkeiten empfiehlt sich, im Verlauf des Projektes nach und nach durchzuführen. Der Vorgang an sich ist ein einfaches Drag und Drop mit der Maus. Innerhalb einiger Monate sind die wichtigsten Abhängigkeiten in der Regel definiert. (Vorausgesetzt das Team hat den Nutzen erkannt, wird in der Praxis fleißig verlinkt.)
Inhalte aus dem Repository lassen sich sehr einfach in RTF-, MS-Word- oder HTML-Dokumente exportieren. Etwas schwieriger wird es, wenn die Dokumente festgelegte Formate und Inhalte haben müssen. Dann wird auch hier entsprechender Aufwand, z.B. zur Erstellung einer MS-Word-Vorlage, notwendig sein.
Last but not least bleibt die Schulung des Teams. Grundsätzlich wird zwischen Anwendern (Usern) und so genannten Power Usern unterschieden. Die Bedienung der meisten Werkzeuge ist heute nicht viel schwieriger als die Bedienung einer Tabellenkalkulation. Ein Tag Schulung ist hierfür in der Regel ausreichend. Voraussetzung ist, dass das System konfiguriert und eingerichtet ist. Ein bis zwei Mitarbeiter im Unternehmen sollten auch dafür die Kenntnisse besitzen. Hier sind einige Tage Kombination aus Schulung und Coaching notwendig.

In Summe sollte zur Einführung eines Anforderungsmanagement-Systems mit 10 bis 15 Tagen Aufwand, ca. 10.000 Euro für Schulung und Coaching sowie 2.000 bis 5.000 Euro pro Arbeitsplatz für die Lizenz eines Werkzeuges gerechnet werden.

Anforderungen an das Werkzeug

Einer der Hauptvorteile im Anforderungsmanagement liegt in der Traceability - der Analyse der Abhängigkeiten und den daraus entstehenden Ansichten. In der Praxis gibt es häufig verschiedene Sichtweisen auf die Traceability (ist erfüllt durch ..., ist Testfall zu ..., wurde getestet, entspricht Norm ...). Diese sollten bei einer Analyse auch unterschieden werden können. Dazu müssen verschiedene Link-Beziehungen und deren mögliche Richtungen exakt vorgegeben werden (sog. "Link Control"). Ist das nicht möglich, so geben die Analysen in der Regel bereits nach kurzer Zeit keine sinnvollen Aussagen mehr.
Die Möglichkeit der Definition verschiedener Link-Arten und die exakte Vorgabe von Regeln zu deren Anwendung gehören zu den wichtigsten Eigenschaften. Leider versagen an diesem Punkt schon sehr viele Werkzeuge.
Flexible Darstellung der Repository-Inhalte mit guten Filter-Möglichkeiten ist ein weiteres elementares Kriterium für ein gutes Werkzeug. Was hilft das beste Repository, wenn die Informationen und deren Zusammenhänge nicht aussagekräftig dargestellt werden können? Vor allem Filter-Funktionen werden nach einiger Zeit sehr wichtig. Fängt Ihr Repository an, sich mit Daten zu füllen, wird es für aussagekräftige Darstellungen zunehmend wichtiger, zu definieren, was nicht angezeigt werden soll. Sie hätten ja gerne den Blick auf das Wesentliche. Auch an dieser Stelle versagen bereits viele Werkzeuge.
Natürlich sind gute Import- und Export-Funktionen sehr hilfreich. Vor allem auch zu anderen Werkzeugen. Zu diesem Thema ist IBM Jazz eine interessante Entwicklung. Jazz hat u.a. zum Ziel, Repositories verschiedener Werkzeuge zu vereinheitlichen. Wenn sich Jazz durchsetzen kann, wird Daten-Import und -Export in Zukunft der Vergangenheit angehören.
In diesem Sinn wünsche ich Ihnen viel Erfolg mit Ihren Projekten mit und ohne Repository und beantworte auch gerne noch weitergehende Fragen zu diesem Thema.

Info@willert.de
05722 - 9678 60

2. Embedded World News: UML Code Generierung endlich zu erschwinglichen Preisen!
Willert und LieberLieber präsentieren gemeinsame Lösung

AMUSE Logo
[2 Pressefotos anzeigen] [ PDF Datei anzeigen]
Nürnberg (pts/01.03.2011/10:06) - Willert Software Tools GmbH und LieberLieber Software GmbH haben heute auf der embedded world 2011 (http://www.embedded-world.de/de/) erstmalig Ihre gemeinsame high-end Lösung "UML Code Generierung für Embedded Systeme" auf der Basis von Enterprise Architect von Sparx Systems der Öffentlichkeit präsentiert.

Im Focus der neuen Entwicklung stand die wichtigste Problemstellung der Softwareindustrie der letzten Jahren - Reduktion von Produktionskosten und Time-to-Market ohne Qualitätsverluste. Der Schlüsselfaktor dabei ist die nachhaltige Beherrschung der gestiegenen Komplexität der Softwareentwicklung durch das Heben des Abstraktionsniveaus auf die Ebene der UML-Modellierung.

"Mit dieser Lösung wird wieder einmal deutlich, dass Enterprise Architect als Modellierungsplattform für Embedded Software Firmen immer wichtiger wird und durch die Lösungskompetenz unserer Partner können Enterprise Architect Kunden Ihre Toolchain zu vernünftigen Preisen optimieren!", zollt auch Hans Bartmann, Geschäftsführer von SparxSystems Central Europe, der neuen Lösung Respekt.

Willert und LieberLieber nennen folgende Faktoren als Basis für die Stärke der neuen Toolkette:

+ Optimierte Codegenerierung für Echtzeit-Systeme mit geringen Ressourcen
+ Integrierte Toolchain, die das durchgehende Arbeiten auf demselben Abstraktionsniveau der UML erlaubt
+ Umfassende und konsistente Modellierung in UML: statisches Design von Klassen bis hin zur Komponenten Definition, Verhaltens-Modellierung, Initialisierung der Komponenten sowie die Konfiguration der Laufzeitumgebung
+ Für jede Firma erschwinglicher Preis
+ Hervorragende Integrationsmöglichkeiten mit anderen Systemen und Tools dank der gewählten Plattform - Enterprise Architect basierend auf aktuellen UML-Standards
+ Verwendung von Industriestandards und weitgehender Verzicht auf proprietäre Lösungen

UML Watch

Eine der Highlights, die auf Embedded World Kongress in diesem Zusammenhang präsentiert wird, ist die so genannte UML-Watch - eine Sport-Uhr von Texas Instruments, die aus einem UML-Model generierten C-Code ausführt. Der kompilierte Code, der aus mehreren Statemachines und einem schlanken Hardware-Abstraktionslayer besteht, ist unter 3,5kB groß! Die UML-Watch steht auch ganz im Zeichen der Green-Technology. Während die Applikation läuft verbraucht die Uhr gerade mal 13 µA.

Ergänzende Kompetenzen - synergetische Lösung

LieberLieber Software GmbH aus Wien entwickelt seit Jahren erfolgreich Kunden-Lösungen auf Basis einer der bekanntesten Modellierungs-Plattformen - Enterprise Architect von Sparx Systems. Die deutsche Firma Willert Software Tools GmbH ist einer der Pioniere auf dem Gebiet Model Driven Development in der Embedded Welt. Letztes Jahr haben beide Firmen die strategische Entscheidung getroffen, auf der Basis von Enterprise Architekt eine für jedermann erschwingliche MDD Lösung zu entwickeln, die die Softwareentwicklung für Embedded Systeme auf eine neue Entwicklungsstufe heben wird. Das erste Ergebnis dieser Kooperation - eine hochwertige und hoch integrierte Toolkette wird vom 1.-3.März in Nürnberg beim Embedded World Kongress in Nürnberg erstmalig gezeigt.

SW Engineering Report

Tue, 27 May 2008 09:53:12 +0200

Hier können Sie unseren SW Engineering Report oder unseren Techletter abonnieren

NEU !!!!

Elektronischer Software Engineering Report No 28
Schneller, höher, weiter... Halten neue Vorgehen, was sie versprechen?

Aktuelle Umfrage: Pro oder Contra zum elektronischen SW Engineering Report

Software Engineering Report No 27
Software Architektur Design
Techletter No 1
Interfaces in Rhapsody in C

Newsletter No 26 Richtiges richtig tun III - Unser Gehirn als Werkzeug
Newsletter No 25 Richtiges richtig tun II - Methoden und Werkzeuge

Newsletter No 24 Richtiges richtig tun I - Excellence im Engineering
Newsletter No 23 Der steinige Weg zu fehlerfreier Software
Newsletter No 22 Komplexität managen - modellieren statt programmieren
Newsletter No 21 Real-Time Architektur Design - Jonglieren mit der Zeit
Newsletter No 20 ARM-Cortex-Architektur in Embedded Systemen
Newsletter No 19 Heutige Anforderungen an effizientes Software Engineering
Newsletter No 18 Gutes Werkzeug ist halbe Arbeit
Newsletter No 17 Embedded Software Development

Hier können Sie den SW Engineering Report oder die Techletter abbestellen

UML Frameworks auch für Sparx Enterprise Architect

Fri, 01 Jul 2011 14:30:59 +0200

Bückeburg/Wien, 1 Juli 2011

Ab heute sind die etablierten Willert Software Tools UML-Frameworks (zur echtzeitfähigen targetspezifischen Code-Generierung für Embedded Systeme) für IBM Rational Rhapsody auch für Sparx Systems Enterprise Architect verfügbar.

Seit 2001 fokussierte sich Willert Software Tools auf UML-Komplettlösungen für IBM Rational Rhapsody. Ab jetzt ist es auch Enterprise Architect-Anwendern möglich von den Vorteilen dieser Technologie zu profitieren. Alle bisher unterstützten Hardware-Plattformen für Rhapsody sind jetzt auch für EA verfügbar. Die Firmen LieberLieber und WST haben auf Basis von Enterprise Architect eine für jedermann erschwingliche MDD-Lösung entwickelt: eine hoch integrierte Toolkette bestehend aus: Sparx EA + LieberLieber AMUSE und den Tools von WST: Willert Deployer, Willert Runtime Framework und dem Willert UML Target Debugger. Das Framework bildet dabei das Bindeglied zwischen der UML und der Hardware. Basierend auf der Frameworktechnologie von Willert ist es möglich, dass EA Code generiert, mit dem viele Elemente der UML in C-Code abgebildet werden können. Code Generierung ist möglich aus Klassen-, Objekt- und Package Diagrammen, sowie auch aus Statecharts.
Sie erhalten von uns komplett integrierte DVD's mit Trial-Versionen zum downloaden oder auf Bestellung. Testen Sie kostenlos und als einer der ersten diese neue Technologie unter:

www.willert.de/uml-getting-started

Durch Simulation ist Hardware nicht erforderlich. Die Demo basiert auf Keil-Arm Technologie.

Aktuell