200812m Metacase Produktivere Softwareentwicklung durch domänenspezifisches Modellieren

»manage it« als

E-Paper 5-6 2011
E-Paper 3-4 2011
E-Paper 1-2 2011
E-Paper 11-12 2010
E-Paper 9-10 2010
E-Paper 7-8 2010
E-Paper 5-6 2010

Domänenspezifisches Modellieren

Produktivere Softwareentwicklung

Domänenspezifisches Modellieren ist ein Ansatz zur Erzielung einer Produktivitätssteigerung im Bereich der Softwareentwicklung. Er basiert auf der Annahme, dass alle signifikanten Steigerungen der Produktivität dadurch erreicht wurden, dass die Abstraktionsebene, in der die Entwickler arbeiten, maßgeblich angehoben wurde. Zwei entscheidende Beispiele hierfür waren der Übergang von Lochkarten zu Assembler in den 50er Jahren sowie ein Jahrzehnt später von Assembler zu Fortran. In diesem Artikel erforschen die Autoren eine Anwendung von domänenspezifischem Modellieren und diskutieren die mit diesem Ansatz erreichbaren Verbesserungen in der Softwareentwicklung.

omänenspezifisches Modellieren (Domain-specific Modeling, DSM) ist ein Modellierungsansatz, der das von den Entwicklern genutzte Abstraktionsniveau anhebt, indem die Lösung durch das Benutzen von Konzepten aus der Anwendungsdomäne spezifiziert wird. Dieses wird erreicht durch den Gebrauch von domänenspezifischen Modellierungs-Sprachen: Eine Modellierungssprache, die der Logik der Domänenabstraktion folgt und den Entwicklern somit gestattet, sich auf die Lösung anstatt auf deren technischen Implementierung zu konzentrieren. Oft können diese direkt von den domänenspezifischen Modellen generiert werden, indem ein geeigneter Codegenerator benutzt wird.

Spezifität der Domänen

Diese Automation ist möglich aufgrund der Domänen-Spezifität: Sowohl die Modellierungssprache als auch die Codegeneratoren entsprechen den Anforderungen von nur einer einzigen begrenzten Domäne. Dies kann die Domäne eines einzelnen Unternehmens oder Lösungsanbieters sein, oder auch eine Domäne, welche umfassend standardisiert ist und von mehreren konkurrierenden und kooperierenden Unternehmen angewendet wird. Standards wie etwa AutoSAR in der Automotive-Domäne und industrielle Bemühungen wie beispielsweise IMS (IP Multimedia Subsystem) in der Netzwerk- und Telekommunikationsdomäne ermöglichen es, die Entwicklerproduktivität und die Produktqualität durch das Benutzen von DSM zu steigern.

Letzteres, Netzwerk und Telekommunikation, stellt die Domäne für unser Fallbeispiel, das zunächst präsentiert werden soll. Daraufhin werden weitere generelle Angelegenheiten bezüglich DSM angesprochen.

Fallbeispiel zu DSM

In diesem Beispiel werden wir den Gebrauch von DSM in einer Feature- und Service-Anwendung in der Telekommunikationsindustrie untersuchen. Diese Features und Services spielen bei Vermittlungen und Voice-over-IP-Server eine wichtige Rolle. Ein Beispiel von einfachen Features ist die Anrufweiterleitung, Voicemail-Verbindung oder Rückruf bei Abwesenheit. Aktuelle Bemühungen, IMS zu realisieren, beinhalten die Integration von diesen traditionellen Telekommunikations-Dienstleistungen mit den Services, die über das Internet bereitgestellt werden, wie etwa Instant Messaging und andere Multimediakommunikationen.

All diese Funktionalitäten müssen von der Maschinerie und der Software, welche das Telefonnetzwerk formt, inklusive Telefonen, Vermittlung und Computern unterstützt werden. Die Kernfunktionalität von diesem Material wird von Software- und ICT-Ingenieuren bereitgestellt, die Last aber, das System für den Endkunden zum Laufen zu bringen, liegt bei den Service-Programmierern und den Systemmanagern der Telekommunikationsanbieter. Oftmals ist es ihre Aufgabe, Konfigurationsdateien und Scripts manuell zu justieren, was eine sich oft wiederholende und umso fehleranfälligere manuelle Aufgabe ist.

Um diese Aufgabe zu unterstützen – bei simultaner Verringerung des Arbeitsaufwandes und der Fehler – haben wir eine Lösung, basierend auf DSM, entwickelt.

Vom Konzept zur Sprache

Bevor man imstande ist, seine eigene domänenspezifische Sprache zu entwickeln, muss die Domäne an sich bestimmt werden. In IMS haben wir, basierend auf unserem architektonischen Design, drei geschichtete Domänen bestimmt (siehe Abbildung 1). Die untere Schicht ist die Verbindungsdomäne, welche aus der bestehenden weltweiten Kommunikationsinfrastruktur besteht: Internet, drahtlose Netzwerke, Festnetzwerke etc. Die mittlere Schicht ist die sogenannte Service Enabling Domain. Das ist die Domäne, wo zuvor benannte Features und Services gefunden und ermöglicht werden. Letztendlich ist die Anwendungsdomäne diejenige, in der die Services von dem Endkonsumenten abgerufen werden. Dies ist auch die Domäne in der Service-Programmierer und technische Produktmanager die Dienstleistungen für den Endkunden ansetzen müssen, daher werden unsere Bemühungen bei DSM an dieser Domäne ansetzen.

Abb. 1: Drei Schichten einer Domäne

In der Architektur unserer IMS-Anwendung ist die Schicht der Anwendungsdomäne mit verschieden Schritten bestückt. Diese Schritte repräsentieren die kleinstmögliche Ausführungseinheit in der Anwendungsdomäne (siehe Abbildung 2). Beispiele für diese Schritte sind Aktionen (etwa Verbindung herstellen), Funktionen (etwa Telefonnummer umwandeln) und Entscheidungen (etwa Empfänger präsent). Alle Services für den Endverbraucher können in drei kleinen Schritten gebaut werden, aber wegen ihrer Körnigkeit ist die individuelle Konfiguration aller dieser Schritte eine mühselige Aufgabe.

Was dies für die Anwender unserer geplanten Service-Kreation noch schwieriger gestaltet, ist die Tatsache, dass die Schritte in einem Ablauf verbunden sind, sich jedoch auf Ereignisse, die von einer Vielzahl vonProzessen (tasks, siehe auch Abbildungen 2 und 3) der Service Enabling Domain abgewickelt werden, beziehen. Die Unterschiede zwischen der ablauforientierten Anwendungsdomäne und der ereignisgesteuerten Welt darunter ist schwer zu erfassen.

Abb. 2: Schritte in der Anwendungsdomäne.

Um die Sache einfacher zu gestalten wird die Abstraktion um eine Ebene angehoben, indem einzelne Schritte in größere Blöcke zusammengefasst werden, die sich Service Building Blocks (Servicebausteine, SBB) nennen. Wie in Abbildung 3 zu sehen ist, repräsentieren diese SBBs Services in der Anwendungsdomäne, welche einfach in einem Ablaufmodell verbunden werden können, ohne die Notwendigkeit von Zwischenentscheidungen, Überprüfungen, Übersetzungen, und ähnlichem.

Abb. 3: Service Building Blocks kombinieren Schritte

Konzepte

Basierend auf dieser logischen Denkweise wird unsere Sprache aus verschiedenen Service Building Blocks und Beziehungen zwischen ihnen bestehen sowie aus einigen zusätzlichen Konzepten zur Ermöglichung der Ablaufmodelle. Dieses resultiert in der folgenden Liste von Elementen, welche zum Modellieren von Abläufen einer Verbindungserstellung zwischen einer anrufenden Partei (der Anrufer) und der Destination, zu welcher der Anrufer verbunden werden möchte, benutzt werden. Grafisch haben wir ein ablaufähnliches Model adoptiert.

Liste der Konzepte

Anrufer (Caller) – trotz des Umfangs von IMS Services haben wir es noch immer, wie schon seit Jahren, mit Anrufern zu tun
Ziel (Destination) – das Ziel, das vom Anrufer angerufen wird, oder eine alternatives Ziel, das vom IMS System vorgegeben wird
Service Building Block (SBB) – ein Service, der aus vielen verschiedene Schritten besteht, um einen bestimmten Service an den Endverbraucher zu erbringen. In der Realität haben wir zahlreiche spezifische SBB zur Verfügung und mehrere können in Zukunft hinzugefügt werden.
Beenden (Terminate) – ein SBB, welcher die Verbindung beendet aufgrund von Regeln, die in dem Model definiert werden müssen, in dem es gebraucht wird.

Beziehungen zwischen Konzepten

Interlink – Verbindung zwischen SBB
Beziehung eingehen (Enter) – die Beziehung zwischen dem Anrufer und der ersten SBB.
Beziehung beenden (Exit) – die Beziehung zwischen dem Anrufer und der letzten SBB.
Ansage (Anouncement) – kann mit allen obigen Beziehungen benutzt werden, um dem Anrufer eine Ansage abzuspielen.

Jedes dieser Konzepte hat verschiedenartige Merkmale, welche Sie detaillierter beschreiben. Abbildung 4 zeigt ein kleines Beispielset von SBBs, in dem die grafischen Symbole für die oben beschriebenen Konzepte und Beziehungen benutzt werden.

Abb. 4: Grafische Symbole für die Sprache

Regeln und Bedingungen

Zusätzlich zu einfachen Modellierungskonzepten muss man also eine Sammlung von Regeln und Bedingungen identifizieren. Diese kontrollieren die Benutzung der Sprache und setzen gleichzeitig die Korrektheit der Modelle durch. Es ist beispielsweise nicht möglich, dass mehr als eine Partei einen Anruf einleitet – auch in Telefonkonferenzen muss jemand den ersten Schritt tun. Wir erstellen Modellsprachen, die an die Konfiguration und die Spezifikationen des Services angepasst sind. Daher erstellen wir unsere Sprache also so, dass nur ein Anrufer spezifiziert werden kann. Weiterhin muss in jedem Modell mindestens ein Ziel oder eine Terminate vorhanden sein, um einen geschlossenen Ablauf zu erhalten. Andere Bedingungen können mit der Reihenfolge zusammenhängen, in der die SBBs abhängig von ihren Funktionen verbunden sind.

Ein Beispielmodell

Durch das Benutzen von dieser definierten Sprache können wir ein Beispielmodell erstellen, welches dessen Gebrauch aufzeigt. Abbildung 5 zeigt, wie ein Script für anwesenheitsbasiertes Routing implementiert wird. Benutzer können im IMS bestimmen, ob sie anwesend sind oder nicht, oder ob sie an einem bestimmten Ort angerufen werden wollen (etwa im Büro). In diesem Fall wollen wir den Anruf an einen alternativen Ort, das Handy der Zielperson, umleiten, nachdem eine Nachricht für den Anrufer abgespielt wurde. Wenn unser Kontakt die Anwesenheit auch an dem alternativen Ort abgeschaltet hat, dann wird der Anruf beendet – auch hier, nachdem eine Standartnachricht für den Anrufer abgespielt wurde.

Abb. 5: Beispiel Modell – Anwesenheitsbasiertes Routing

Ein Service-Programmierer, dem die Möglichkeit gegeben wird, diesen Service auf die eben beschriebene Art und Weise zu modellieren wird kaum in der Lage sein, viele Fehler zu machen, denn das Tool verbietet den Verstoß gegen diese Bedingungen. Programmierer muss sich nicht großartig um die einzelnen Details der Schritte oder um die ereignisgesteuerte Beschaffenheit der Service Enabling Domain kümmern. Weiterhin wird es dem Kunden ermöglicht, gewünschte Funktionsweisen mit dem Service-Programmierer direkt auf dem Level der Endkundenapplikation zu diskutieren.

Generierung von Code und Datenmaterial

Natürlich muss man, um einen DSM-Ansatz gänzlich nützlich zu machen, Scripts generieren, die das IMS-System auch verstehen kann, und welche der Service-Programmierer normalerweise mühevoll in Handarbeit erstellen müsste. Abbildung 6 zeigt einen technischen Überblick der Realisierung der Anwendungsdomäne und der Service Enabling Domain des IMS-Systems.

Die Service Enabling Domain ist auf einen Anwendungsserver aufgebaut, welcher entsprechend zu den XML-Konfigurationsdateien in Software codierte Schritte kombiniert.

Abb. 6: Technischer Überblick von Domänen.

Diese Konfigurationsdateien wurden von unseren Modellen generiert, wie in Abbildung 7 zu sehen ist. Neben den XML-Dateien können ebenfalls Endbenutzer- und Servicedokumentationen von den Modellen generiert werden. Dies basiert auf einer Eigenschaftsbeschreibung, die Teil eines jeden Elements dieser Modellierungssprache ist.

Abb. 7: Codegenerator und Beispiel einer generierten XML Datei

Ein Codegenerator bestimmt, wie Informationen von den Modellen entnommen und in Code umgewandelt werden. Dieser Prozess hängt von der Modellierungssprache ab, da die erstellten Modelle den Input für den Generator darstellen. Die Schlüsselfrage in Bezug auf das Erstellen eines Codegenerators ist, wie die Konzepte des Modells in Code abgebildet werden. Der Framework der Domäne sowie andere verfügbare Bibliotheken können diese Aufgabe vereinfachen, indem sie das Abstraktionsniveau auf Seiten des Codes anheben. Im einfachsten Fall produziert jedes Symbol einen bestimmten, festgelegten Code einschließlich der Werte, die in das Symbol als Argument eingegeben wurden. Der Generator kann ebenfalls anderen Code generieren. Dies ist abhängig von den Werten in den Symbolen, den Beziehungen zu anderen Symbolen und zusätzlichen Informationen im Modell.

Um XML-Anrufskripte für IMF zu produzieren, muss der Generator nur anhand der adressierten Beziehungen die Modellelemente durchlaufen und die nötigen geschachtelten Elemente einfügen.

Zukunftsoptionen

Da unsere IMS-Lösung noch recht jung ist, können viele Verbesserungen und Änderungen identifiziert werden. Hinsichtlich der hier gemachten Ausführungen ist ein zu berücksichtigendes Thema, ob es nützlich wäre, auch SBB-Internes mit Hilfe von DSM zu modellieren. Momentan sind die einzelnen Schritte per Hand codiert und die Kombination in SBB geschieht teilweise gegenseitig (Java Code) und teilweise vom Codegenerator (generierte XML). Die Falle, die man stets vermeiden sollte, ist die sogenannte visuelle Programmierung: Entwickler modellieren ihr Ergebnis auf einem Abstraktionslevel, welches so nahe am Code liegt, dass der zusätzliche Mehrwert von DSM verloren geht. Im Wesentlichen hilft es, DSM-Lösungen so zu generieren, dass man nach dem ersten erfolgreichen Test sichergehen kann, dass auch alle anderen funktionieren. Mithilfe von visueller Programmierung müssten wir jede Lösung einzeln testen und prüfen.

Vorteile von DSM

DSM bietet signifikante Vorteile im Vergleich zu traditionellen, manuellen Ansätzen. Der wohl signifikanteste Vorteil ist die Steigerung der Entwicklerproduktivität- die Konsequenz eines höheren Abstraktionsniveaus. Industrielle Erfahrungen, speziell im Bereich von eingebetteten Systemen wie etwa bei Automotive, Militär und Telekommunikation, haben eine Produktivitätssteigerung von einem Faktor von 3 bis 10 gegenüber traditionellen manuellen Vorgehensweisen. Nokia berichtet beispielsweise, dass es Handys mithilfe von DSM bis zu zehnmal schneller entwickeln kann. Lucent-Alcatel konnte ebenfalls durch domänenspezifische Sprachen die Produktivität je nach Produkt um den Faktor 3 bis 10 steigern.

In unserem Fall erwarten wir einen signifikanten Anstieg der Produktivität gegenüber aktuellen Anwendungen des traditionellen Telefonierens und VoIP, da Service-Programmierer nicht mehr länger Konfigurationsskripte testen und an ihnen herumbasteln müssen. Zusätzlich kann die Zeit des Testens und der Endkundenakzeptanz verringert werden; sie können die Dienstleistung »Design« direkt mit dem Kunden besprechen, ohne technische Details erläutern zu müssen.

Es ist relevant, sich zu erinnern, dass diese Art von Produktivitätsgewinnen nicht gänzlich neu sind: Einen ähnlicher Satz wurde bei der Bewegung von Maschinensprachen zu 3GL gemacht. DSM verfolgt das gleiche Erfolgsrezept und führt das Anheben des Abstraktiosniveaus, auf welchem die Entwickler arbeiten, fort. Universalabstraktionen und -sprachen können jedoch nicht benutzt werden, um näher an die Problemdomäne heranzurücken. Stattdessen müssen die Sprachen domänenspezifisch sein. Die Problemdomäne einer Motorsteuerung ist anders als die der IP-Telefone, daher sind die Abstraktionen des Designs anders. In DSM sind diese Abstraktionen der Domäne Teil der Sprachen, die zur Spezifizierung der Produkte und Eigenschaften benutzt wird.

Eine bessere Angleichung mit der Domäne bietet auch einen Mechanismus, um Qualität zu verbessern. Da es möglich ist, die Regeln der Problemdomäne in Form von Randbedingungen in die Sprache einzubeziehen, ist es unmöglich, illegale oder unerwünschte Design-Modelle genauer zu beschreiben. Einmal erfahren, legen die Entwickler diese Regeln für die Sprache fest und andere Entwickler folgen den Richtlinien des Experten, um qualitativ hochwertigere Designs zu erstellen. Dies ist auch die weitaus preiswertere Lösung, um Programmierfehler auszuschalten – je früher desto besser. Die Qualität erhöht sich ebenfalls, wenn Spezifikationen gemacht werden, sodass Begrifflichkeiten aus der Domäne benutzt werden: Die Spezifikationen sind dann einfacher zu lesen, zu verstehen, zu erinnern, abzugleichen und zu kommunizieren. Dies ermöglicht es den Kunden und anderen Stakeholdern, im Entwicklungsprozess mitzuarbeiten.

DSM im Vergleich zu anderen Lösungen

Eine Abbildung näher an den Betriebsproblemen sowie Automation mithilfe von Codegeneratoren unterscheidet DSM von Mehrzweck-Modellierungssprachen. Die meisten etablierten Modellierungssprachen, wie etwa UML, konzentrieren sich darauf, den Code zu visualisieren. Daher können sie keine signifikante Produktivitätssteigerung gegenüber dem Codieren in C, C++ oder Java aufweisen. Eine Studie von Modelware Project (Dubinsky 2006) analysierte fünf Unternehmen, die UML benutzen; sie konnte keine signifikante Korrelation zwischen UML und Produktivitätssteigerungen nachweisen.

Unserer Meinung nach ist dies offensichtlich ein Resultat der geringen Abstraktion und der eher mäßigen Automationsmöglichkeiten. UML benutzt beispielsweise direkte Programmierungskonzepte (Klassen, Rückgabewerte, etc.) als Modellierungskonstrukte. Die Verwendung eines Dreiecks um eine Klasse in einem Diagramm abzubilden sowie equivalente, textuelle Repräsentationen in eine Programmiersprache verleiht keine reellen Generierungsmöglichkeiten; der Abstraktionsgrad in Modellen und im Code ist derselbe. Des Weiteren erfordert der von diesen Modellen generierte Code eine manuelle Konfiguration, welches die ohnehin schon mäßigen Produktivitätsvorteile weiter schmälert. Als Konsequenz finden sich Entwickler sehr schnell in einer Situation wieder, in der sie Modelle erstellen, die Verhalten und Funktionalitäten beschreiben, denn es scheint einfacher, als den Code direkt zu schreiben. Dieses vernichtet die Idee einer Generierung von vollständigem Code und minimiert die Produktivitätsvorteile.

In DSM sind die Modellierungssprachen mit dem Vorsatz gestaltet, dass sie die Codegenerierung möglich machen. Anstatt die Programmstrukturen zu visualisieren, wird die Problemdomäne visualisiert. Die Entwickler erstellen ein Modell einer Lösung in einer Sprache, die die Konzepte und die Regeln der Domäne enthält, in der der Entwickler arbeitet. Wenn man zum Beispiel sprachkontrollierte Systeme entwickelt, dann sind Konzepte wie Menü, Eingabeaufforderung und Spracheintrag viel näher an der Problemdomäne als Assembler-Mnemonics. Gleichermaßen sind bei der Entwicklung eines Auto-Infotainment-Systems Konzepte wie Display, Programm und Knopf näher am System als irgendein UML-Konzept.

Folgt man aber dem DSM-Ansatz, lesen die Codegeneratoren diese hochgradigen Spezifikationen, um den benötigten Code zu produzieren. Die Art und Weise, wie die Entwickler den Code schreiben, scheint sich von Domäne zu Domäne zu unterscheiden, daher müssen Codegeneratoren für die gegebene Domäne spezifisch sein. Während die meisten Modellierungstools proprietäre Generatoren für festen Code anbieten, verfechtet DSM die Benutzung von ganzheitlich offenem Code und anpassbaren Generatoren zur Generierung von jeder Art von Output: nicht nur Code, sondern auch Testbeispiele, Dokumentation und Konfigurationsdateien und ähnliches. Die Idee ist, dass ein Experte die Freiheit haben soll, diese Generatoren zu definieren – natürlich unterstützt von den Tools, die von DSM-Modellierungsumgebungen angeboten werden. In der Domäne erfahrene Entwickler sind am besten geeignet für das Schreiben von qualitativ hochwertigem Code in der Problemdomäne des Unternehmens.

Basierend auf den Erfahrungen mit den verschiedensten Kunden, mit Fällen die weitaus komplizierter sind als das, was hier in diesem Artikel veranschaulicht werden konnte, ist es einleuchtend, dass DSM in vielen Domänen ein bevorzugter Ansatz zur Steigerung der Qualität und der Produktivität in der Softwareentwicklung ist. Referenzbeispiele schließen Unternehmen wie Nokia, ICT Solutions, EADS, Siemens, und Fuji Xerox ein, wo DSM benutzt wird, um Anwendungen für eine breite Palette an Anwendungen zu erstellen: beispielsweise Handys, Definition und Konfiguration von VoIP-Diensten und Webseitenerstellung für Versicherungsleistungen. Unternehmen untersuchen ebenfalls den Gebrauch von DSM in der Softwareentwicklung, beispielsweise für Silikon-Chip-Produktionsmaschinen, für die Nanotechnologie und für Logistiksysteme.

Wie das Beispiel hier aufzeigt, ist es nicht schwierig mit dem Gebrauch und dem Profitieren von DSM zu beginnen. Es ist auch möglich, dies inkrementell zu tun, zunächst nur einen kleinen Teil der Anwendung in der Sprache und im Codegenerator bestimmen und dann nach und nach kleinere Teile hinzuzufügen. Letztendlich ist dieser Ansatz auch zukunftssicher, da sich die Domäne langsamer verändert als die ihr zugrunde liegende Technologie.

Resümee

Während der eigentlichen Spracherstellung wurde der erste Teil der Sprache konstruiert und unverzüglich getestet, indem Beispielanwendungen modelliert wurden. Wenn das Resultat nicht zufriedenstellend war (etwa das Erstellen unerlaubter Designs nicht verhinderte), machten wir die nötigen Korrekturen im Metamodell. Hier können uns Tools sehr viel weiterhelfen. MetaEdit+ machte den Teil des Sprachtests agil: wir waren schnell in der Lage zu lernen und zu testen, wie die Sprachen in der Praxis aussehen würde und wie einfach es war, Modelle zu erstellen und wieder zu verwenden. Das minimiert das Risiko, eine schlechte Sprache beziehungsweise eine gute Sprache für die falschen Aufgaben zu erstellen. Die Tool-Unterstützung für die Erstellung einer Sprache hilft ebenfalls deutlich, um geeignete Abbildungen für die Codegenerierung zu finden.

Das Beispiel, welches von den Autoren präsentiert wurde, ist Teil des Entwicklungsprojektes in der ICT Solutions, einer Schwesterfirma von ICT NoviQ innerhalb der niederländischen ICT Group. Während das Projekt noch nicht in die finale Entwicklungsphase gelangt ist, sind Erfahrungen mit Kunden bisher sehr positiv. Das steigende Interesse von denen, die in IMS involviert sind, verstärkt den Glauben, dass DSM ein guter Ansatz ist, um mit den Geschwindigkeits- und Qualitätsanforderungen des Telekommunikationsmarkts im 21. Jahrhundert zurechtzukommen.

Referenzen

MetaCase, Nokia Mobile Phones Case Studies, 2007, http://www.metacase.com/papers/MetaEdit_in_Nokia.pdf

Weiss, D., Lai, C. T. R., Software Product-line Engineering, Addison Wesley Longman, 1999.

Dubinsky Y., Hartman, A., Keren, M., Modelware: Industrial ROI, Assessment and Feedback, Modelware project report, 2006, http://www.modelware-ist.org/

DSMForum, http://www.dsmforum.org

Angelo Hulshout, ICT NoviQ und Dr. Juha-Pekka Tolvanen, MetaCase

Folgen Sie »manage it«

auf Google+