Wir möchten Ihnen einige Begriffe aus dem entracons tool guide erläutern. Wenn Sie Anregungen zur Definition haben oder Begriffe vermissen, kontaktieren Sie uns bitte.

| UML 1.x: (Unified Modeling Language) Die Väter von UML, insbesondere Grady Booch, Ivar Jacobson und
James Rumbaugh, auch "die drei Amigos" genannt, waren in den 1990er-
Jahren bekannte Propagandisten der objektorientierten Programmierung, die
alle bereits ihre mehr oder weniger ähnlichen eigenen Modellierungssprachen
entwickelt hatten. Als sie zusammen beim Unternehmen Rational Software
beschäftigt waren, entstand der Ansatz, die verschiedenen Notationssysteme
strukturiert zusammenzuführen. Als Resultat dieser Bemühungen entstand
UML. Die Standardisierung, Pege und Weiterentwicklung der Sprache wurde
an OMG übergeben, die die Sprache am 19. November 1997 als Standard
akzeptierte.

| UML 2.x: (Unified Modeling Language) Für die UML 2.0 OCL und die UML 2.0 Infrastructure lagen damit
endgültig abgenommene Dokumente (Final Adopted Specication) vor.
Am 21. Oktober 2008 wurde die Beta 1 von UML Version 2.2 durch die OMG
veröffentlicht, die wiederum im Februar 2009 in der nalen Version vorlag. Neu
hinzu gekommen ist in der Version 2.2 das Proldiagramm, um eigendenierte
Stereotypen-Sammlungen strukturieren zu können.
Anfang 2010 soll UML 2.3 veröffentlicht werden. Diese Version wird vor allem
Bugxes am Metamodell und Schärfungen der Semantik von Modellelementen
im Spezikationsdokument der UML enthalten.

 | SysML Systems Modeling Language, ist eine auf der UML basierende standardisierte Sprache für die Modellierung von komplexen Systemen. Sie stellt eine um spezielle Elemente erweiterte Untermenge von UML dar. SysML unterstützt die Analyse, das Design und den Test von komplexen Systemen.

• Systemanforderungen modellieren und zur Verfügung stellen

• Systeme analysieren und evaluieren, um Anforderungs- und Designbelange zu lösen sowie Alternativen zu prüfen

• Systeminformationen zwischen unterschiedlichen Stakeholdern unmissverständlich kommunizieren

Einsatzzweck/ tool applicability for

 | BPMN Eignung für die Modellierungsnotation für Geschäftsprozesse/ applicability for Business Process Modeling Notation

 | Illustration von UML Diagrammen/ Illustration of UML diagrams UML
Werkzeuge dieser Klasse sind vor allem zur Erstellung von Diagrammen zur
Einbindung in Dokumente geeignet. Wichtig dabei ist die Unterstützung von
Grafikformaten. Mindestens JPG, PNG, BMP, EPS, PS, PDF sollten unterstützt werden. Ein weiteres wichtiges Kriterium ist die Vollständigkeit der unterstützten UML-Digramme, sowie die Qualität der Layoutfunktionen.

 | verteilte Entwicklung/ distributed development Werkzeuge dieser Klasse
bieten Funktionen zur verteilten Entwicklung an. Dazu gehört eine Client-
Server-Funktionalität, die es erlaubt, die Modelle in, mindestens einem, besser
mehreren Repositories auf einem Server zentral zu halten und von Clients an
beliebigen Orten darauf zuzugreifen. Wichtig dabei ist das Vorhandensein einer
Benutzer- und Zugriffsrechteverwaltung. Diese sollte möglichst feingranular
sein.

 | Teamfähigkeit/ team ability Unter Teamfähigkeit verstehen wir die Unterstützung des Werkzeugs bei der Kommunikation zwischen verschiedenen Benutzern auf Modellen. Dazu gehört z.B. die Benutzer- bzw. Gruppenspezi-
sche Kommentierung von Modellen. Es gehört ebenfalls dazu, dass Benutzer
Modellteile sperren können, um zeitweise ungestört an diesen arbeiten zu können.
Alternativ kann auch ein anderer Mechanismus zum parallelen Arbeiten
(z.B. Model Merge) implementiert sein.

 | Eignung für Entwicklung in größeren Teams/ applicabilty for big teams
Um für die Entwicklung in größeren Teams geeignet zu sein muss ein Werkzeug
neben den Eigenschaften für die verteilte Entwicklung und Teamfähigkeit
noch Funktionen zum Modelmanagement und Kongurationsmanagement zur
Verfügung stellen. Zum Modelmanagement gehört der Import- und Export
von Modellen und Teilmodellen (mindestens auf Paketebene) sowie das Mangement von Beziehungen zwischen Modellen. Zum Konfigurationsmanagement gehört die Unterstützung des parallelen Arbeitens durch Locking- und Merge-Mechanismen, das Baselining und die Versionsverwaltung. Dabei ist es wichtig, dass neben den Werkzeuginternen Mechanismen für die Arbeit auf Modellebene auch Anbindungen an die verbreiteten Kongurationsmanagementwerkzeuge Subversion, PVCS, Clear Case und CVS vorhanden sind.

 | Anforderungsentwicklung/ Requirements Engineering Ein Werkzeug ist
zur Anforderungsentwicklung geeignet, wenn es Use Case Diagramme, Interaktionsdiagramme, Klassendiagramme, Packages, Notes, Prole unterstützt.

 | Architektur & Design /Architecture & Design Um für die Architektur und
das Design geeignet zu sein, müssen die folgenden Diagrammtypen unterstützt
werden: Klassendiagramme, Komponentendiagramme, Deploymentdiagramme,
Interaktionsdiagramme, Zustandsdiagramme.

 | Code Generierung/ Code Generation Codegenerierung bezeichnet die Erzeugung von Quellcode aus dem Modell. Dabei wird zwischen der Erzeugung
von strukturellen Code und Verhaltenscode unterschieden. Ersterer besteht
aus den Strukturen des Codes, d.h. Datenstrukturen, Beziehungen, Funktionsrümpfen etc. Letzterer bezeichnet die Bodies der Funktionen sowie die Kontrollstrukturen.
Zusammen ensteht eine vollständige Generierung von Sourcecode.

 | Metamodell anpassbar /Metamodell customizable Die Eigenschaft Metamodell anpassbar besagt, dass das dem Werkzeug zugrunde liegende Metamodell anpassbar ist. Somit wäre ein Upgrade auf eine neue UML-Version
unabhängig von der Version des Werkzeuges möglich. Ferner wäre es möglich
das Werkzeug für andere grasche Modellierungssprachen, z.B. Domänenspezi
sche Sprachen einzusetzen.

 | Modellstruktur frei wählbar /Modell structure free choice Eine frei wählbare Modellstruktur erlaubt es, die Modellstruktur an Domänenspezische
Besonderheiten anzupassen.

Features Code Generator

| Code Generation customizable Die Codegenerierung kann durch
editieren von Scripten angepasst werden. Der Vorteil ist die grösstmögliche
Anpassbarkeit der Codegenerierung. Als Nachteil ist der höhere Aufwand der Anpassung zu sehen. Abhängig von der verwendeten Scriptsprache kann es zu Seiteneffekten kommen, die den Debuggingaufwand erhöhen. Ein weiterer Vorteil dieser Variante ist, dass sie für Entwickler leicht zu erlernen ist, da diese es gewohnt sind mit unterschiedlichen Implementierungssprachen zu arbeiten.

| rules composer Bei dieser Customizing Variante wird die Codegenerierung
durch die Denition von Abbildungsregeln zwischen Modell und Sourcecode
beeinusst. Dies ist oft intuitiver verständlich als die Scriptbasierte Variante, setzt aber oft Kenntnisse des Metamodells des jeweiligenWerkzeuges (bzw. des jeweiligen UML-Dialektes voraus). Je nach Realisierung durch den Werkzeughersteller kann eine umfassende Anpassbarkeit gewährleistet werden. Der Aufwand ist in der Regel geringer als bei der Scriptbasierten Variante.

| property composer und property dialoge Bei diesen Varianten wird die Codegenerierung über eine unterschiedlich große Anzahl von Optionen (sogenannten Properties) in entsprechenden Dialogen des Werkzeuges eingestellt. Der Vorteil ist, dass eine Anpassung des Codes mit relativ geringem Aufwand bei geringen Vorkenntnissen möglich ist. Nachteil dieser Variante ist, das je nach konkreter Realisierung durch den Werkzeughersteller die Anpassbarkeit begrenzt ist.

In der Praxis erstreckt sich die Anpassbarkeit zumeist auf mehr oder weniger geläufige Aspekte.

| model based Bei dieser Variante wird die Codegenerierung durch ein Codegenerierungsmodell angepasst, aus dem dann durch einen speziellen
Codegenerator angepasste Code-Generatoren generiert werden. Bei guter
Realisierung durch den Werkzeughersteller können mit dieser Variante
auf einfache und effektive Weise sehr gute Ergebnisse erzielt werden.

Es gibt auch Modelbasierte Varianten, die zusätzlich eine Skriptsprache
verwenden.

| other Dient zur Bezeichnung proprietärer Varianten, die keiner der oben genannten Varianten zugeordnet werden können.

| synchronisation (on-demand /continous) Bei der Codegenerierung werden
zwei Arten von Synchronisation unterschieden.

• On-demand heisst, dass eine Synchronisierung von Code und Modell durch den Nutzer gestartet wird.

• Continuous heisst, dass Modell und Code nach jeder Änderung auf einer der beiden Seiten automatisch synchronisiert wird.

Die On-demand Synchronisation ist vor allem dann besser geeignet, wenn ein Forward-Engineering-Approach der Entwicklung zugrunde liegt. Wenn mit sehr implementierungsnahen Modellen gearbeitet wird, erhöht ein continuous Synchronization Mechanismus den Comfort.

| tag based code generation Bei der Tag Based Code Generation werden
automatisch generierte Kommentare im Code benutzt, um Zuordnung
von Modell und Code zu managen. Dadurch findet auch eine Unterscheidung
zwischen generiertem und manuell erstelltem Code statt. Der Vorteil dieser
Variante ist, dass auch bei einer starken Anpassung/Customization des Codegenerators das Body-Preserving gewährt bleibt.

| body preserving Body Preseving besagt, dass manuell erstellter Code im Body von Funktionen oder Prozeduren nicht beim Generieren oder Neugenerieren aus dem Modell vom Codegenerator überschrieben oder verändert wird.

| parser Parser werden in der Codegenerierung eingesetzt um Body Preserving
ohne Tag based Code Generation zu ermöglichen. Dies ist dann besonders wertvoll, wenn Tags im Code aus speziellen Gründen nicht akzeptabel sind.

| Verhaltenscodegenerierung/ behaviour code generation Unter Verhaltenscodegenerierung versteht man die Erzeugung von Kontrollstrukturen
aus Verhaltensdiagrammen (Zustandsdiagramme, Interaktionsdiagramme).

| support different Targets Diese Eigenschaft besagt, dass Code für verschiedene Targets (Zielsprache, Betriebssystem, Prozessor) erzeugt werden
kann.

| with or without runtime-envrionment zugelinkt Diese Eigenschaft legt fest ob zur Erzeugung lauffähigen Codes das hinzulinken eines vom Hersteller mitgelieferten Runtime-Environments notwendig ist. Wenn ja, ist der Vorteil, dass bei einer guten Qualität des Runtime-Environments schnell gute Ergebnisse erziehlt werden. Dies setzt aber voraus, dass der Hersteller
das Environment sehr gut getestet hat. Der Nachteil ist, dass es oft aufwändiger ist, den generierten Code anzupassen. Außerdem besteht immer eine Abhängigkeit vom Hersteller im Hinblick auf Code Generatoren für neue Targets.

In Domänen, in denen es darauf ankommt immer die neuesten Targets einzusetzen (z.B. Automotive) kann eine termingerechte Anpassung der Codegenerierung an neue Targets oft nicht gewährleistet werden.

| source free available Diese Eigenschaft bezieht sich auf die Eigenschaft
mit/ohne zugelinktem Environment und gibt an, ob der Sourcecode des Runtime-Environments frei verfügbar ist. Dies Ermöglicht eine Anpassung unabhängig vom Hersteller und erlaubt Codereviews.

• Home