Hast du es besonders eilig, mache einen Umweg“
(Japanische Weisheit)
Liebe Kundin, Lieber Kunde,
Jeder, der in der Embedded Softwareentwicklung tätig ist, weiß wie schwer es ist, ein neues Projekt auf einem leeren Tisch anzufangen. Es liegt nahe, bekannte Lösungen und Quellcode von anderen und älteren Projekten in das neue Vorhaben mit einzubinden. Über die eigenen Firmengrenzen wird dabei meist aber nicht hinausgegangen. Leider wird durch dieses „not invented here“-Syndrom ein schnellerer und effizienterer Projektbeginn oft verhindert.
Warum eigentlich?
Andere sind da weniger hakelig
Andere Industrien sind da weniger hakelig (für die Nicht-Österreicher unter Ihnen: hakelig steht für kompliziert oder penibel). In der Automobil-Industrie beispielsweise ist es seit langem gängige Praxis, Komponenten von Fremdmarken, auch solchen, die nicht zum eigenen Konzern gehören, zu verbauen. Solange die Markenidentität dadurch nicht verfälscht wird, bestehen da keine Berührungsängste. Was zählt, ist auf kostengünstigstem Weg schnellstmöglich ans Ziel zu kommen.Auch wenn ich hiermit eine heiße Kartoffel anfasse und mir vielleicht den Zorn einiger Leser zuziehe: oft ist es das Ego des Entwicklers, dass einfach nicht zulässt, dass Lösungen und Code, die von außerhalb der eigenen vier Wände stammen, einbezogen werden. Wenn aber das Ergebnis der Projektentwicklung das einzige wirkliche Ziel ist, wird eigentlich sofort klar, wie sehr es helfen kann, hier über den eigenen Schatten zu springen.
Warum also sollten wir nicht viel-hunderfach geteste Lösungen zu unserem Nutzen wiederverwenden, die ihren Ursprung möglicherweise auf dem Schreibtisch eines Entwicklers in den USA oder Japan haben? Für die objekt-orientierte Programmierung gibt es solche Lösungen in Form einer großen Zahl sogenannter „Design-Patterns“, die wieder verwendbare Lösungen für häufig auftretende Problemstellungen sind.
Design-Pattern bestehen aus drei Aspekten. Der Erste ist die eigentliche Problemstellung selbst. Dieser Aspekt bezieht sich darauf, was auf Grund der Problemstellung gelöst werden soll. Der zweite Aspekt ist die Lösung, und somit das Design-Pattern selbst. Im dritten Aspekt finden sich Konsequenzen (oder Folgerungen), bestehend aus den positiven und negativen Punkten des Design-Patterns, die sich auf Optimierungen und Seiteneffekte beziehen.
Um als Design-Pattern anerkannt zu werden, muss die vom Pattern angebotene Lösung allgemein genug sein, und in einem breiten Spektrum von Anwendungsbereichen adaptierbar sein.
Die Lösung ändern – nicht das Problem
In unterschiedlichsten Anwendungen durch eine große Zahl von Entwicklern vielfach getestet, müssen Design-Patterns aber erst durch Sie als Entwickler an Ihre Anwendung angepasst werden. Machen Sie dabei aber bitte nicht den Fehler, umgekehrt zu verfahren, und Ihr Problem an ein bestimmtes Design-Pattern zu adaptieren! Lachen Sie nicht – das passiert recht häufig!
Für den technisch Interessierten gibt es zum Thema Design-Pattern viel weiterführende Literatur. Besonders erwähnen möchte ich die Autoren Bruce Powel Douglass und Erich Gamma, Richard Helm, et.al., die herausragende Bücher hierzu geschrieben haben.
Wenn Sie auf dem Weg zu einer vollständigen Objekt-orientierten Programmierung mit UML bereits mit Zustandsautomaten arbeiten, sind Ihnen die Konzepte von Zustands-Design-Pattern bereits bekannt. Ein Zustandsautomat, oder eine State Machine, stellt ein abstraktes Modell einer Maschine dar, und wird durch Statecharts dargestellt. Diese werden als Subset in der UML beschrieben, und sind für Anwendungen, die in sich Ereignis-getrieben und in Verhaltenszuständen dargestellt werden können sehr gut geeignet und können „schlank“ realisiert werden.
Viele Anwendungen benötigen keine volle UML; sie können als reine State Machine beschrieben werden. Das ist oft der wirtschaftlichere und weniger komplexe Weg. Damit entfällt viel an zusätzlicher Modellierungs-Struktur, wie Klassen und eine Vielzahl von Diagrammtypen, die großen Overhead (und manchmal auch Verwirrung) entstehen lassen. Dieser kann die Codegröße und damit letztlich das ausführbare Image Ihrer Embedded Anwendung unnötig aufblähen.
Mehr als genug
Mit einem reinen State-Machine Tool, das zusätzliche Werkzeuge für die formale Verifikation, Test und Validierung enthält, und darüber hinaus automatisch sehr kompakten C oder C++ Code erzeugen kann, der 100% konsistent mit Ihrem System-Design ist, ist der Anspruch an ein Objekt-orientiertes Design & Test-Tool für die meisten Embedded Anwendungen mehr als ausreichend erfüllt.Dass dieses Tool auch noch Ihre Dokumentation praktisch als „Abfallprodukt“ ständig aktuell erzeugen kann, ist ein willkommenes, zusätzliches Geschenk.
Wie dieses Tool heißt? Es ist IAR visualSTATE von IAR Systems. Was es kostet? Einen Bruchteil eines „full-blown“ UML Tools. Natürlich kann IAR visualSTATE „nur“ den Subset der Statecharts der UML.
Aber wenn dieser Leistungsumfang den Anforderungen an eine Kosten- und Zeit-effiziente Entwicklung gerecht wird, warum soll man sich dann in jeder Hinsicht mehr antun?
IAR visualSTATE ermöglicht einen durchgängig iterativen Workflow (Design/Verify/Validate). Die formale Verifikation findet auch schwer zu ortende Design-Fehler frühzeitig im Entwicklungsprozess. Der Modell-getriebene Design-Ansatz und die graphische Design-Darstellung ermöglicht zusätzlich eine bessere interne Kommunikation und Abstimmung zwischen allen Ebenen der Expertise im Unternehmen.
Die vollständige Integration von IAR visualSTATE mit der IAR Embedded Workbench komplettiert einen nahtlosen Workflow bis hin zum lauffertigen Image Ihrer embedded Anwendung - und das für eine Vielzahl der gegenwärtig auf dem Markt befindlichen Hardware-Plattformen.
Können Sie sich eine bessere Lösung vorstellen? Gerne sagen wir Ihnen mehr über IAR visualSTATE.
Hier finden Sie die aktuellen Produktneuigkeiten von IAR mit allen Details zu den aktuell unterstützten Hardware-Plattformen.
Die letzten Wochen vor Weihnachten stecken voller Ambivalenz. Einerseits ist Weihnachten gleich um die Ecke, und die nötige Stimmung dafür möchte doch bitte langsam aufkommen, andererseits stehen uns allen noch hektische Tage und Wochen bevor, die das Geschäftsergebnis zum Jahresende verbessern sollen. Kein einfacher Balanceakt – „Operative Hektik ist ein sicheres Mittel gegen ein Leben in Balance“ sagte Cay von Fournier. Ich wünsche Ihnen, dass Sie die richtige Balance finden!
Für die angenehme und erfolgreiche Zusammenarbeit mit Ihnen bedanke ich mich herzlich. Ich wünsche Ihnen eine ruhige und entspannende Weihnachtszeit, Muße zum Auftanken und den Abstand zum Alltag, der uns wieder Pläne schmieden lässt – für ein erfolgreiches Jahr 2010.
Bis zum ersten Februar grüsse ich Sie herzlich,
Ihr
nicht durch den Stillstand deiner Tätigkeiten."
(Friedrich Schiller)
Anmerkung zum neuen Telekommunikationsgesetz (seit 1.03.2006):
Sie erhalten diese Nachricht aufgrund eines bestehenden Kundenkontaktes oder aufgrund einer Anfrage an uns oder einen unserer Partner. Sollten Sie in Zukunft keine Zusendungen mehr von uns wünschen, so klicken Sie bitte auf Unsubscribe in der Fußnote dieser Email. Sie werden unverzüglich aus dem Verteiler genommen.
Impressum: Medieninhaber und Herausgeber: Carnica Technology, A-9620 Hermagor, www.carnica-technology.com, Email: info@carnica-technology.com