M2* Transformations Eclipse NewsPortal - eclipse.modeling.m2t Mailing list: m2t-dev Eclipse NewsPortal - eclipse.modeling.m2m Mailing list: m2m-dev Mailing list: m2m-atl-dev

Concepts

Domain-Specific Languages
A domain-specific language (DSL) is designed to accomplish a specific task or type of task. A well-designed DSL provides an environment that closely matches a task's specific needs. Domain experts can typically be more effective because the DSL uses the vocabulary and concepts of the domain. As a result, domain experts can more quickly build proper models without having to learn a different taxonomy because the models map to the domain concepts. DSLs are typically designed at a high level of abstraction, such as process modeling, and used to generate supporting software artifacts, such as source code and auxiliary text files. The term language in this context can refer to both programming languages and modeling languages. Both types of languages are built upon syntactic and semantic rules. In the context of DSLs, both types of languages can be used. In fact, it is common for a DSL to include several languages for its various components. It might use a modeling language for its models, a programming language for its implementation and a transformation or template language to produce desired output. General-purpose languages are designed to handle many different types of tasks. As such, they typically provide generalized and extensible capabilities that are well-suited for many tasks. The Unified Modeling Language (UML) is an example of a general-purpose modeling language. Note: The UML can be seen as a collection of DSLs that include class modeling and activity modeling. As a result, the UML is ideal for modeling parts of applications, such as class models or state machines. At the same time, the UML can be confusing due to its sheer size and complexity, especially for those who fail to understand the boundaries between those DSLs. Related Topics DSL Capabilities on page 12 DSL Toolkit Workflow on page 13 DSL Toolkit Usage Scenarios on page 19 DSL Toolkit Best Practices on page 15

Domain-Specific Modeling

By nature of their extensibility, some programming languages like LISP, Smalltalk and Ruby can be tailored to provide a programming environment that matches the needs of particular types of tasks. This approach has limitations because the resulting DSL, which Martin Fowler calls an internal DSL, is constrained by the features and capabilities of the general-purpose programming language. The problem domain does not need many capabilities that the general-purpose programming language provides. This makes the DSL more difficult to learn and use. An external DSL is written in a language other than the language the DSL itself uses. While their use has certain advantages in text-based DSLs, external DSLs can cause difficulties in using and understanding the DSL as well as extending or modifying the DSL when necessary. Potential disadvantages include the lack of a proper semantic editor and the lack of debugging facilities.

Code Generation Template

A template language is often used to produce textual output. These templates are typically used to generate source code or auxiliary deployment files.

Report

Reporting is an important part of any DSL. It is often required to visualize model data as text. The DSL Toolkit contains features to help with generation of these reports.

UI contributions

A unique aspect of the DSL Toolkit is its deep integration into the Eclipse run time. The ability to extend the workbench's menus demonstrates this integration and lets practitioners easily execute model transformations and apply templates.

Conclusion

The DSL Toolkit provides the Toolsmith with a variety of tools to make Model-Driven Development (MDD) and generative approaches easier. The Practitioner benefits from a native Eclipse run-time environment that is immediately familiar and integrated into the platform. Although the creation of a DSL requires time and effort, the return on this investment is a higher quality product with fewer bugs because the DSL provides a constrained input model and generated artifacts. The DSL eliminates the need to constantly debug and test the generated artifacts and can result in a time savings when reused across multiple projects. A DSL can include several components, including domain models that describe abstract and concrete syntaxes), diagrams, transformations, reports, and templates. Several of these components are optional, depending on the usage of the DSL.

DSL Capabilities

The DSL Toolkit within Together enables the development of a domain-specific language (DSL). The following table identifies the capabilities that a Toolsmith uses to construct DSLs. Domain modeling The DSL Toolkit supports the creation of new domain models as well as the importing of existing ones. The Toolsmith uses the domain model editing features to capture domain concepts and vocabulary within this model. Every Domain model uses the Eclipse Modeling Framework (EMF), which enables compatibility across the Eclipse ecosystem. Custom diagramming Diagrams can be easily created for the domain model. As a result, diagrams provide a standard, easy-to-use graphical interface for editing domain instance models.

Printing DSL Toolkit Diagrams
To print from Windows, make sure that the org.eclipse.gmf.runtime.common.ui.printing.win32 plug-in is installed. To print from Together, make sure that the Printing Enabled option on the Advanced page of the diagram editor is selected. To print from GMF, make sure that the printingEnabled property of GenPlugin is set to true and that diagram code is regenerated. Note: The Java print library cannot update the standard printer settings. If necessary, set the paper and orientation settings to match the Together Print Preferences. Related Topics Creating a DSL Diagram Definition on page 27 Creating a Figure Gallery on page 29 DSL Explorer View on page 68
Creating a Figure Gallery
To create a figure gallery 1. Open an existing DSL project.
2. Open the DSL Explorer, right-click the project root, and choose New Other. Expand the DSL Toolkit node in the tree view list, select Figure Gallery, and then click Next. The Figure Gallery wizard opens. 3. Type a name for the figure gallery in Model name. Verify the path in Location. Uncheck Use default location to edit Location. Uncheck Use default file name if you want to use alternative names. 4. Click Finish. The Figure Gallery editor opens. Related Topics Diagram Definition Editor on page 58 DSL Explorer View on page 68 Figure Gallery Editor on page 73
Creating a Dynamic Instance Model
To create a dynamic instance model 1. Open an existing domain model. 2. Open the Domain model editor. Within the Diagram page, locate the top-level class in the domain model. Right-click that class and choose Create Dynamic Instance. The Dynamic Model wizard opens. Enter an appropriate name and choose the location for the XMI file. The XMI editor opens. Tip: Within the XMI editor, you can create instance models with sample data. Instance models can be very useful in developing DSLs. Note: Creating a dynamic instance is useful when developing a DSL because it contains sample model data for use when developing reports, templates and transformations. It is an XMI file derived from the domain model.
Related Topics Domain Model Editor on page 51 Domain-Specific Language Glossary on page 106
Creating a DSL Transformation
To create a DSL Transformation 1. Open an existing DSL project. 2. Open the DSL Editor. Within the Getting Started group, click the Model transformation link. Note: Alternatively, you can open the DSL Explorer, right-click the project root and choose New Transformation. The New Operational QVT Transformation wizard opens. 3. Ensure Source container is set to the proper location. If you choose to, type a value for Namespace. Type a name for the transformation in Module Name. Typically, a transformation has one input model parameter and one output model parameter, although Operational QVT allows any number of input, output, and inout models for transformation. 4. Click the Add button. Set Direction as inout or in. Edit Name. Click the button in Metamodel and select the appropriate input models. Select the Entry point type to the desired type. Tip: You can type the first letters of the metamodel and the Entry point names and press Ctrl-Space to use the code completion feature. 5. Click the Add button. Leave Direction as out. Edit Name. Click the button in Metamodel and select the appropriate output models. Select the Entry point type to the desired type. Tip: Use Move up and Move down to add more models and adjust their order. Review the Transformation signature preview. 6. Click Next. The Import metamodels screen opens. 7. Select the additional metamodels to import and click Next. The Import libraries page opens. 8. Select the additional libraries or transformations to import and click Next. The Initial mapping operations screen opens. 9. Create initial mappings as desired and click Finish. The QVT Editor opens.

a form that works without any mapping. For Ecore models, nsURI works; for other models, platform:/plugin/ might be a good choice because it form fits the deployed product well.
Migrating from the Eclipse Modeling Project
Users who are familiar with the Eclipse Modeling Project (EMP) might decide to migrate to the DSL Toolkit in order to take advantage of its functionality. The DSL Toolkit comes with commercial features that are not available in such open source projects as Eclipse Modeling Framework (EMF), Graphical Modeling Framework (GMF), Generative Modeling Technologies (GMT), Model Development Tools (MDT), Model-to-Model Transformation (M2M), and Model To Text (M2T). When migrating from the Eclipse Modeling Project open source project to the Together DSL Toolkit, users can access a number of import wizards that make the transition straightforward. The following scenarios contain best practice considerations when transitioning to the DSL Toolkit. When migrating to a DSL Project 1. In the Together main menu, choose File New DSL Project. 2. Using the New DSL Project wizard, create a DSL project for each domain model and its corresponding artifacts. You can combine the artifacts from the following project types into a single DSL project: EMF GMF QVTO oAW
Related Topics DSL Toolkit Best Practices on page 15 Importing a Figure Gallery on page 39

Importing Using Xpand

When importing using Xpand Note: The underlying expression language used by Together's implementation of Xpand changed from the proprietary language that the Xtend language had built upon. Together's Xpand is based on the OCL and QVT Operational Mapping Language standards. Some noteworthy variations between the two implementations exist, including the following differences: Together Xpand accesses language features as properties instead of operations (for example, isEmpty() instead of isEmpty). There is no metaType property available in Together's Xpand (instead, use eClass() for elements that extend EObject). There are no counter or counter0 properties on iterators in Together Xpand.
For more information on OCL and QVT Operational Mapping Language standards, refer to the Object Constraint Language OMG Available Specification Version 2.0 and the MOF QVT Final Adopted Specification.

1. Replace the use of FILE with workflow-based persistence declaration of files. The Xpand version in Together views templates as string builders, and the persistence of the generated stream is handled external to the file. Typically, an OCL expression accomplishes this persistence in the template invocation, though the specification of a simple file name can also be used. 2. Migrate MWE files to Together workflow scripts (*.exec models).
Importing GMF Artifacts for the Diagram Editor
When importing GMF artifacts for the Diagram Editor 1. To import each graphical definition model to create a Figure Gallery, choose File New Import Figure Gallery. 2. Import each *.gmfgraph model to create a new Figure Gallery. 3. To import each GMF mapping model to create a Diagram Definition, choose File New Diagram Definition. 4. Import each *.gmfmap model to the *.diagram model for use in the Diagram Definition Editor.
Importing ecore for the Domain Model Editor
1. To import metamodels into a domain, choose File New Import Domain Model. 2. Import each *.ecore or *.genmodel to create a *.domain model for use in the Domain Model Editor. Note: The Domain Model Editor supports both *.ecore and *.genmodel diagrams. Updates to both are made simultaneously.
Migrating Xtend-Based Templates to QVTO-Based Xpand Templates
The migration tool to migrate from QVTO-based Xpand comes included with the DSL Toolkit as part of GMF 2.2M4. To migrate to QVTO-based Xpand 1. Ensure that legacy Xtend-based templates are available in the workspace and can be compiled.
You might have to create a valid.xpand-root file in the root of the project with templates so that your project can point local templates to their external template roots in other projects or plug-ins. 2. Right-click the legacy project in your workspace and choose Migrate to new QVTO-based xpand. A new folder with the QVTO-based templates is created as a sibling of each template root specified in the.xpand-root file, which also references newly created *.migrated template folders. In addition, new Java source root (*.qvtlib) is created, QVTO native extensions are registered in the plugin.xml file, the new template builder (org.eclipse.gmf.xpand.xpandBuilder) is registered, and the org.eclipse.m2m.qvt.oml.project.TransformationNature and org.eclipse.m2m.qvt.oml.QvtBuilder are installed on the project. 3. Open the.xpand-root file in a text editor and verify that all external QVTO-based template roots specified there are available in your configuration and were updated during migration. 4. Examine the QVT source container, generated by org.eclipse.m2m.qvt.oml.project.TransformationNature and org.eclipse.m2m.qvt.oml.QvtBuilder, for errors in the *.qvto files. The current QVT builder allows only one root to be specified as the QVT source container. By default, the first migrated template root is designated as the QVT source container. To see QVT build errors for other template roots, specify the appropriate folder as the QVT source container in the corresponding project properties. 5. Add the org.eclipse.m2m.qvt.oml plug-in to the list of required plug-ins. This resolves references to org.eclipse.m2m.qvt.oml.blackbox.java.Operation, which generated Java code imports for Java annotations. 6. Repeat the preceding steps for each template project as necessary. If you have cross-project dependencies, migrate the project with the most commonly referenced templates first. Note: Existing projects with legacy templates cannot be compiled correctly using the new builder until they are migrated. This includes independent template projects. Before the migration templates project gets compiled with the legacy Xtend-based builder, the builder of the project gets replaced with the new QVTO-based project builder. Note that only *.xpt and *.ext files are migrated to the template root. All other files from the legacy template root are copied into the same relative directory beneath the template root. Related Topics

If a node is selected: Remove the node deletes the node mapping from the diagram definition. Add node reference enables this node to specify a child node to be reused from another node mapping. This avoids duplication of mappings throughout the definition if there are many similar nodes. A node reference element has Containment Reference and Children Reference properties, and its Actions section provides the ability to Remove the node reference. Add a node creates a child node below the current node and displays all the properties for a node. An infinite level of children nodes can be mapped in this manner, as dictated by the graphical notation. Add compartment provides a compartment in which a node can be defined. The Child Nodes property lets you select nodes found within the compartment, and the Figures section lets you select from available compartment figures in the referenced galleries. A Remove the compartment action is also available. Add label creates a mapping for an optionally Read Only label using the label selected in the Figure section. Note that unlike an attribute-based label mapping, this is a static label mapping that does not provide text based on a feature. A design label is used when diagrams are defined without a domain model. A Remove this label action becomes available when the label is selected in Diagram Element as well. The Add attribute-based label action creates a label mapping where one or more domain element attributes can be selected for edit and display on the diagram. The following properties are available for attribute-based labels: Read Only prevents the Practitioner from modifying this label's value on the diagram. Add or remove Attributes using hyperlinks. The Add button opens a dialog with the available attributes of the parent node's mapped domain model class. View Pattern defines how the attribute is seen when the label is not in edit mode. By default, the MESSAGE_FORMAT View Method is used, which allows for the specification of patterns using the Java
MessageFormat class. See the JavaDoc on this class for more information. Optionally, select the NATIVE (Java), REGEXP, or PRINTF patterns for View Method and Edit Method. Edit Pattern defines the format of the label when the parser accepts it after changes are made. For example, if the View Pattern displays several attribute values separated by commas, you can type each value into the in-place editor of the label using colon delimiters.

Validation and Generation The Validation and Generation node contains the following options and buttons for enabling features and generating. Actions to convert between text and Check this check box if you want to be able to convert between textual model and XMI representations. Register resource factory for text file Register Text editor for XMI model resource Generate Validate Related Topics Textual Notation Editor on page 64 Check this check box if you want to be able to work with the text file in the same way you work with the usual model. Check this check box if you want to be able to edit XMI files as text (this option transparently converts between textual and XMI representations upon each save/load). Click this button to generate your textual notation. Click this button to validate your textual notation before generating.
Language Page of Textual Notation Editor
Textual Notation The Language page lets you define the syntax and formatting of your textual notation. It contains a single node, the Textual Notation node, which displays the filtered model tree and lets you specify how each of your model elements contribute to your notation. Drag and drop features to reorder them. In addition to the Expand and Collapse display options, use the following icons on the upper right of the window to filter the content of the tree: Show Model Types and Features (default) Show All Inherited Features Without Excluded Hide Excluded Features and Types Show Only Excluded Features and Types
Depending on the language element selected, different configurable options appear that let you control how selected elements appear in the notation, including a Preview window that displays how your settings affect the notation. The following configurable options appear: Class options By default, all classes in your model begin with a reserved word, possibly followed by its instance identifier. All attributes are enumerated one by one in curly braces (class body). Custom Literal Literal Lets you customize the reserved word, which is the metaclass name by default. Space-separated list of tokens and formatting rules, including: identifier !identifier Introduces soft keyword. Introduces hard keyword.
sequence of control characters _ [NL] Element body options Custom identity attribute Show in Outline Feature options
Standard tokens, such as comma and semi-colon. Space in the text. New line in the text.
Lets you customize the class body. Lets you select an identifying attribute that makes references to the class more friendly. This option is inherited by subclasses. Lets you check the appropriateness of the class in the outline.

Finally, out parameters always result in the creation of new model instances that are initially empty and that are then populated during the transformation execution. Note: In standard QVT, the modeltype declaration replaces the metamodel keyword used in legacy QVT. In order to execute a transformation, all formal model parameters must be bound to actual contexts in which existing models are resolved and new model instances are created. This is done external to the transformation, typically in a runtime configuration, as when QVT Interpreter launches configurations in the Eclipse UI. The actual binding is realized by using an EMF resource referenced by URI. The contents of the resource form the logical MOF Extent associated with every model parameter of a transformation. Therefore, after a resource is associated with a model parameter, the transformation can load and eventually modify its contents and save new output there. Standard main() Entry Point The QVT specification defines the entry point of a transformation as a unique imperative operation named main. It has no arguments and return type, and its body is executed immediately after the owning transformation is instantiated. Typically, the body contains the logic to query appropriate objects within the extents of in or inout model parameters.These selected elements become the source objects for mapping calls producing the transformation output. transformation Simpleuml_To_Rdb(in uml : UML, out rdb : RDB); main() { uml.rootObjects()[UML::Model]->map model2RDBModel(); } The standard signature-less main operation helps to define a flexible execution logic accepting input elements of various types, which belong to the declared model types. In many cases, no specific flow is required and a mapping operation between a top-level input type and its corresponding output type is sufficient. This mapping operation then invokes other necessary mappings on its child objects and composes a complete transformation result. This scenario is supported in legacy QVT and is also still valid in the new QVT. A mapping operation as the entry point is shown in the following example. mapping main(in ePackage : EPackage, out umlPackage : Package) Note: mapping main(.) is a legacy construct that originated from early versions of the QVT specification. Collection Types In legacy QVT, the data objects of Collection types cannot contain a null value. All related collection operations or literals do not allow undefined values to be added to resulting collections. The OCL 2.0 specification states that the null value is a legal element in a collection and the new QVT implementation follows this rule. In addition, according to the OCL 2.0 specification, the Collection type no longer conforms to OclAny. Check for potential misuses of OclAny operations because some of these misuses might not be detected by a compilation error. In the following example, legacy QVT takes collections as conforming to OclAny. var bag : Bag(String) := Bag { 'aString'}; -- calls oclIsKindOf() on 'bag', which conforms to OclAny

forAll

includes (or including)

Description element is added to sets and ordered sets only if it does not already reside in them.

includesAll

A standard operation that results in a new collection in which all the objects from the original collection are present. A variant operation that returns an integer value specifying the first position of an element in a collection. A variant operation that results in the insertion of an extra element at the specified position of a sequence or ordered set. A variant operation that results in a collection of objects that holds all elements in both collections. A standard operation that must be true when a collection has no elements. A loop operation that returns true if the value of the evaluated parameter for every element in the source collection is unique. The most basic and complex loop operation, the iterate operation is used to build a value by accumulation over a collection. For example, in the expression

indexOf

insertAt

intersection

Set, Bag

isEmpty

isUnique

iterate

collection->iterate( element : Type; accumulator : Type = <expression> | epeso-iheeetadacmltr xrsinwt-lmn-n-cuuao ), element is the iterator operation
that iterates over a collection.
epeso-iheeetadacmltr xrsinwt-lmn-n-cuuao is evaluated for each element. After
each evaluation, the value is assigned to accumulator. In this way, the value of accumulator is built up during the iteration of a collection.
Collection Type OrderedSet, Sequence
Description A variant operation that results in the last element of a collection. A variant operation that results in a new set that contains all the elements of the set that called the operation but none of the elements in the parameter set. A standard operation that evaluates to true when a collection has at least one element. A variant operation that evaluates to true if all elements in two collections are not the same. A loop operation and variant of the exists operation that returns true if a certain condition for one and only one element in the source collection is true. A loop operation that is like the select operation except it specifies every element from a collection for which the Boolean expression is false. A loop operation that specifies a subset in the resulting collection if a certain condition for the subset is true. For example, if customers must have a card for every service in a collection that they use, their total number of cards is a subset of the total number of cards or services available. The select operation picks among the services.

Note: To ensure that the URI support feature is turned on, open the bundles.info file in the eclipse/configuration/org.eclipse.equinox.simpleconfigurator directory and verify that the line with the com.borland.dsl.ubiquity plug-in entry ends with true. For earlier versions of DSL Toolkit, open the config.ini file in the eclipse/configuration directory and verify that the osgi.bundles line has configured com.borland.dsl.ubiquity@start. Advantages of Common URIs Although DSL Toolkit supports conventional file-like URIs such as platform:/plugin/<bundlename>/<path-to-model-file> and platform:/resource/<projectname>/<path-to-model-file>, using ubiquitous URIs avoids the following constraints: File-like URIs do not allow you to switch model locations easily. The ability to switch becomes important when working in environments that contain many models but only a few of which are actually being modified or accessed at any given time. For example, suppose a modeler is developing two models in a workspace, Model A and Model B, and Model B references elements in Model A by using a platform:/resource reference. If another modeler is developing a Model C that depends on Model Band, implicitly, Model Aany attempt to access elements from Model B requires that all dependencies of Model A are resolved and checked into the workspace before work can continue with Model C. Until the incorporation of ubiquitous URIs, no mechanism was available for models to access models and other artifacts from a target platform. In some environments, not all the modules that a developer uses as artifacts are necessary in the running platform, platform:/, but some modules are more applicable to target platforms like target:/ in which components for an application are developed. Target platforms that are easily configurable and updateable allow users to include in the workspace only those plug-ins that are essential to their subsystems. You can access other dependencies, such as the entire product itself or other needed subsystems, through the platform:/ mechanism. This way, you can easily access updates and install them as new targets.

Supported URI Syntaxes In addition to platform:/plugin/ and platform:/resource/ schemes, the following ubiquitous URI syntaxes are supported in DSL Toolkit. In these schemes, <bundle-id> refers to the Bundle-SymbolicName entry in the bundle or plug-in manifest file (MANIFEST.MF), and <token> is the identifier for a model that maps to a file within the specified bundle by using a models.tg file. target:/plugin/<bundle-ID>/<path-to-model-file>
Allows users to reference a plug-in with model files eithe can then be saved as JAR files like the platform's other p
model:/plugin/<bundle-ID>/<token>
Looks up bundle or plug-in first in workspace, then in targ through a./././ type directory structure, uses the META-INF/ directory of a plug-in and is deployed with the relative-path-to-model-file>, as in the following
ecore-baseline-version=/model/execute.ecor
With this syntax, tokens provide more information for the model were deployed in a /model folder in a bundle nam must contain the framework=model/framework.uml
A path within a model can also be specified, following the specify the model as either of the following paths.model: model:/plugin/com.borland.framework/framew
model:<token>@<bundle-ID>
Similar to the model:/plugin/<bundle-ID>/<token model:latest-domain@com.borland.dsl.exec w the workspace, that model is used. If it is not in the works running Eclipse instance.

Xpand Language Guide

Introduction Xpand is the template language that the DSL Toolkit uses to generate textual output from models. This section provides an overview of the syntax and semantics of the language. Xpand instructions are surrounded by guillemet ( and ) characters. The Xpand editor provides Content Assist entries to aid in writing Xpand templates. Press the Content Assist key combination (CTRL+SPACEBAR by default) to display the window. Note: Mac users must set their workspace encoding settings to ISO-8859-1 when working with Xpand templates in the editor. Open Eclipse Preferences. Expand General and then Workspace. Select Other under Text file encoding. Choose "ISO-8859-1" from the list. Click OK. Xpand files must contain only letters, numbers and underscores. Simple Xpand template The following example template illustrates the basic structure of the language.

IMPORT "http://org.example/ant/2007" DEFINE buildxml FOR BuildScript <?xml version="1.0"?> <project name="name" default="defaultTarget" basedir="basedir"> ENDDEFINE
Syntax COMMENTS Comment tags, legal only outside of other tags. Comments can span multiple lines. REMcommentaryENDREM DEFINE A tag, essentially a method, for an element. It includes a name, parameter list, and the name of the domain model element. IMPORT "http://www.example.org/2007/ant" DEFINE buildxml FOR BuildScript EXPAND genProject FOR this.project ENDDEFINE
DEFINE genProject FOR Project <?xml version="1.0"?> <project name="this.name" default="." basedir="this.basedir"> </project> ENDDEFINE EXPAND This statement expands another DEFINE method in the current context and redirects its output at the current location. IMPORT "http://www.example.org/2007/ant" DEFINE buildxml FOR BuildScript EXPAND genProject FOR this.project ENDDEFINE DEFINE genProject FOR Project <?xml version="1.0"?> <project name="this.name" default="." basedir="this.basedir"> </project> ENDDEFINE EXTENSION Declares an import for an Extend file. EXTENSION example::ExtenderClass FILE The FILE directive is not supported. Instead you can configure file output as part of a transformation sequence or a UI contribution. Applies the designated Expand method against the result of the expression. EXPAND genProject FOR this.project FOREACH Applies the designated Expand method against each element in the collection. EXPAND myDef FOREACH entity.allAttributes Alternatively, you can use FOREACH to iterate inplace. FOREACH targets AS t <target name="t.name"> </target> ENDFOREACH IF Defines conditional expansion statements. ELSEIF and ELSE are optional. IF private private ELSEIF public public ELSE protected ENDIF IMPORT Imports a namespace. IMPORT "http://www.borland.com/2007/mindmap" LET Defines a local variable for use with the expression.
LET "<target name=\"" + t.name + "\"/>" AS tag tag ENDLET Expressions language guide For more information about the expressions language, refer to http://www.eclipse.org/gmt/oaw/doc/4.1/r10_expressionsReference.pdf.
Domain-Specific Language Preferences
Note: A single workspace-wide registry of URI mappings, which is stored in the workspace preferences, can be used to resolve any cross-model references. You can use the project preferences to override the default URI map for each project. DSL Toolkit Save all modified resources automatically prior to code generation Enable this setting to save modified files and avoid warning messages when generating code. These settings assist with maintaining consistent URI references among DSL models during refactoring operations. Participate in workspace resource refactorings enables model-refactoring features. Add history script as project file artifact enables generation of a file to track refactoring history. Adjust the file extension as desired. Search/Update references enables file types for management during refactorings. Use the Add and Remove buttons to modify the list of file types. Search for references from runtime platform Expands detection to references from installed plug-ins. Click Configure to select which plug-ins to include. Project Editor Show model URIs in DSL Explorer view Adds URI to model nodes in the DSL Explorer. Default version for new projects Set this value to configure the version number for new DSL projects. Default prefix for base package Configure this option for your organization's base package, which will automatically appear in new DSL artifacts plug-in configuration. Default Branding Provider for new projects Set this value for new DSL projects. For example, Borland Inc. Report Definition Open the associated perspective when generating a report Select a value of Always, Editor Never or Prompt to adjust behavior when working with reports. Overwrite user changes in.rptdesign when generating a report Select a value [Always, Never or Prompt] to adjust behavior when generating reports. URI Mappings Maps logical URIs and physical URIs. You can add, clone, remove, edit, move, import, or export entries.

Related Topics DSL Artifacts on page 104

DSL Artifacts

Name Type model model model model model diagram diagram Description DSL definition EMF metamodel EMF generator model domain model workflow script model domain diagram workflow diagram
.dsl.ecore.genmodel.domain.exec.domain_diagram.exec_diagram.diagram.gmfgen.gmfgraph.gmfmap.gmftool.qvto.tnt.tmfgen.xpt.dsldesign
diagrams model DSL diagram definition diagrams model GMF generator model diagrams model GMF graphical model diagrams model GMF mapping model diagrams model GMF tooling definition transformations model-to-model transformation model model templates reports Textual Notation Configuration Textual Notation Generator Model Xpand template report design
Related Topics DSL Model Overview on page 102 DSL-Generated Artifacts on page 105

DSL-Generated Artifacts

Name DSL project Type project generated project generated project generated project generated project generated project generated project generated project Description main project for DSL model implementation

project.model

project.model.diagram

diagram implementation

project.edit
model edit implementation

project.editor

model editor implementation

project.text

text editor implementation

project.ui

UI contributions implementation

project-feature

DSL feature plug-in

.qvtotrace

transformations used internally for model-to-model transformation diagrams model used internally for regenerating genmodel textual notation textual representation of the domain model XMI mapping

.trace

Related Topics DSL Model Overview on page 102 DSL Artifacts on page 104
Domain-Specific Language Glossary
This section provides a description of domain-specific language terminology. Diagram Definition A model, also referred to as a http://www.computer-dictionary-online.org/index.asp?q=concrete%20syntax, that references a number of other models used to define a diagram for a domain-specific language. This model's filename extension is.diagram and is located by default in the /diagrams directory of a DSL project. The central model of any DSL, which is sometimes referred to as an http://www.computer-dictionary-online.org/index.asp?q=abstract%20syntax or a metamodel. It defines the elements, attributes and relationships of the domain. It also captures the domain vocabulary in the naming of model members and can ensure data integrity through constraints. The model contains references to the.ecore and.genmodel models. This model's filename extension is.domain and is located by default in the /model directory of a DSL project. A Domain-Specific Language or DSL is a language designed for a particular and singular domain. The DSL Toolkit takes a model-centric approach to DSLs. It extends Eclipse and several key Eclipse projects, such as EMF and GMF, to assist the Toolsmith in creating DSLs and artifacts used in model-driven development scenarios.

project.

MDA Transformation project is a customized Eclipse plug-in project that enables you to develop various
transformations in Together.
Pattern Definition project is a profiled UML 2.0 modeling project that allows you to create new patterns. Profile Definition project is a profiled modeling project that allows you to create new profiles. UML 1.4 project is a design project with no source code support. UML 2.0 from UML 1.4 converts both Java modeling and design projects from UML 1.4 to UML 2.0

specification.

UML 2.0 project is a design project with no source code support.
Note: The project settings are initially specified on project creation. Further, you can update properties for the existing project. Related Procedures Together Projects Related Reference Together Projects

Package Overview

The notion of a package has two facets: logical and physical.
Logically, a model consists of one or more packages. A package is a model element used to group elements,
and provides a namespace for the grouped elements. A package can contain packageable elements (the elements that can be directly owned by a package) and the other packages. A model itself is a package.
Physically, a package is a folder containing the files that store diagrams and model elements.
Contents of a package can be displayed on a special type of the Class Diagram that is synchronized with the package contents (that is, all the classifiers directly owned by this package automatically appear on the package diagram). This diagram is essential for source code projects. Each package contains the single package diagram that is created automatically and cannot be added explicitly. The root package of a project (Model) is usually referenced as the default package. The package diagram of this package is called the default diagram. This diagram is created and opened just after the modeling project creation. By default, all properties of the package diagram, both visual and semantical, are preserved in the default.txvpck diagram file. You can enable split package diagram persistence, which requires turning the default setting off. To do this, right-click the project in the Model Navigator, choose Properties, and make sure the Store package properties in package diagram files option is not checked. With this option off, only diagramspecific information (visual information, such as layout) is retained in the default.txvpck diagram file, while settings that you treat as package properties (semantical information, such as descriptions and custom properties) are moved from the default.txvpck file into the default.txaPackage file. This allows you to track your package changes using version control. Related Concepts Containment Metamodel Package and logical class diagrams Related Procedures Working with a Package

Overview

Business Process Modeling Notation (BPMN) covers many types of business process modeling with various detail levels and enables you to create end-to-end business processes. After you create a diagram in the BPMN project, you can export the diagram to BPEL and WSDL files. You also can create a BPMN project from imported BPEL and WSDL files. Together enables you to perform a simulated run of the designed business process specifying simulation parameters in the run configuration or using default parameters. During the simulation, Together calculates tasks execution duration, execution cost and other parameters. When simulation is finished you can open a report with statistical data on the selected business process. By default, a business process modeling project is created with the enabled BPEL Modeling profile. This profile adds properties necessary to create a BPEL file. You also can specify general options of business process modeling (including the default profile). When you create a BPMN diagram, it is created with a default pool. You can use the diagram immediately for designing your process. A business process project can also contain the following elements that are invisible on the diagram but can be seen in the Model navigator:
Message Event Detail Rule Transaction Assignment Web Service Property Property Set Process Participant Input Set Output Set
The following diagram is an example of the BPMN diagram.
A diagram in the Business Process Modeling project can contain projection bars that mirror pools and lanes from the diagram. The projection bars remain visible when the lanes are too long and the diagram have to be scrolled. You can use the projection bars to select pools or lanes.
The Group element allows you to easily differentiate between sections of a BPMN diagram. You can easily divide a BPMN diagram into logical parts using the Group element. A Group permanently keeps track of content, resizes on element move, colors elements with selected color, etc.
Reusing BPMN Projects Created in Together 2006
To reuse BPMN projects created in Together 2006 for Eclipse, use BPMN Project from Together 2006 Business Process Modeling project. Note: You can open BPMN projects created in Together 2006 for Eclipse but they open as read-only and not accessible via API.

Model-To-Model transformation. Transforms a Together or EMF model into another Together or EMF model.
Model-To-Model transformations produce the target model and an auxiliary trace file with detailed information about every transformation step performed. The target model opens in the corresponding model editor, the trace file opens in the Trace view. transformation script.
Model-To-Text transformation. Transforms a Together or EMF model into an arbitrary text output using a QVT XSL/OCL transformation. Transforms a Together or EMF model into an arbitrary text output using an XSL/OCL
transformation script. The XSL/OCL script uses the OCL language. XSL uses the XPath language.
Composite transformation is the Ant-based MDA transformation, which allows you to automatically (using Ant
tasks) apply multiple MDA transformations to the specified models, and in the specified order. For Model-ToModel transformations, you can create transformation chains, where the output model of the preceding transformation is passed (via Ant properties) to the input of the next transformation in the chain.
By using QVT Model-To-Model transformations, you can transform your Computation Independent Models (CIMs) into Platform Independent Models (PIMs), and then to Platform Specific Models (PSMs). By using Model-To-Text and XSL/OCL transformations, you can generate code from your PSMs. The framework comes with a set of tools that helps you write, run and debug transformations. For Model-To-Model transformations, the QVT Editor provides basic QVT editing features (including code sensitive editing, syntax checking and highlighting). The Eclipse Debugger for QVT allows you to trace the execution of your QVT code step-by-step. The debugger supports breakpoints (including StepOver, StepInto and StepOut features), watches, and the Variables view. The Trace view allows you to inspect the result of your transformation when it is completed. For XSL/OCL transformations, Together provides a powerful and highly customizable XSL/OCL Editor that supports XSL/OCL code sense, syntax highlighting, XSL structure outline, and error checking. The XSL Debugger, which runs in the XSL/OCL Debugging perspective, supports breakpoints (including StepOver, StepInto, StepOut and StepReturn features). Together also provides a number of sample projects for each type of transformation.
Related Procedures Creating an MDA Transformation Project Creating a Model-To-Model Transformation Creating Model-To-Text Transformations Creating an XSL Transformation Creating an Example MDA Transformation Project Related Reference MDA Example Projects

Model Audits and Metrics

You can import and export model metrics and audits all at once, including a set of named OCL queries on metamodels, and other settings. Model audits and metrics can be saved to files with.ModelMetrics and.ModelAudits extensions. When importing such a file, you completely replace your currently defined model audits or metrics. Related Procedures Exporting and Importing Model Audits/Metrics Creating and Using Code QA Sets

Refactoring Overview

Together leverages refactoring operations provided by the platform. When refactoring is applied to source code, the changes propagate to the model. For example, when classes or operations are renamed by means of refactoring, the hyperlinks to the renamed elements are preserved. Refactoring is available for the model elements in Together projects by means of context menus. Refer to JDT documentation for information on Java refactoring and to CDT documentation for information on C++ refactoring.

Requirements Management

Requirements Management allows you to create and manage traces between Together diagram elements and Borland CaliberRM or Rational RequisitePro requirements. Traceability is supported via CaliberRM and RequisitePro Integrations for Together, respectively. You can find more information about working with specific requirements in online help provided with both integrations. Together provides the following requirements management possibilities:
Create and delete traces between requirements and Together diagram elements. Create requirements based on use case. Manage traces between requirements and model elements in the Element Traces view. Synchronize traces that are out of date using the Trace Synchronizer view. Navigate easily between traced elements and related requirements.
Related Procedures Opening Requirements Views Creating Traces from Requirements to Model Elements Deleting Traces Creating Requirements Based on Use Case Viewing Element Traces Synchronizing Traces Navigating from Model Elements to Requirements Related Reference Element Traces View Trace Synchronizer View
Version Control in Together
This topic provides an overview of version control features in Together.
Together uses a file-based approach to store models. This provides openness and choice when selecting a version control system to manage your models. Together supports several version control systems that can be integrated in Eclipse. They include but are not limited to CVS, StarTeam, and ClearCase. Version control in Together enables several users to work with one modeling project. Together leverages the functionality provided by the Version Control System client and maps these menus from the file resources level (as provided by the Version Control System provider) to model elements. Visual team status indicators for items are also displayed in the model navigator. Note: The Together teamwork-related functionality that is provided depends on how well the specific Version Control System integrates with the basic Eclipse team support flow and UI. Therefore, some Version Control System features may be not available or may work differently for a given Version Control System. Your version control system should be set up so that only one user can work with a shared model at a time. In case several users edit the model at a time, use the model compare and merge functionality of Together. You can compare the structure of your models and merge inconsistencies if necessary. Alternatively, you can revert to the saved version of the model. The model merge tooling provides a hierarchy comparison of two models with annotations to show what has been added, what is missing, and what has been changed. However, the model merge does not provide a comparison of changes in the layout, sizing, or ordering of model elements. Note: For more information about each version control system, refer to the appropriate program documentation.

Hyperlinks in Documentation
A hypertext link connects a link reference (starting point or source) to a link destination (target). The link reference is a text or image in the HTML document. The link destination is a file (usually an HTML document or an anchor in an HTML document). Document templates support both references and targets. Link references are properties of controls. Link targets are properties of static sections, headers, and footers. Any generated output that contains an anchor or bookmark can be a link target. Documentation templates have facilities for inserting anchors at the main documentation of model elements. It is occasionally necessary to provide link references to several different documents (or locations in HTML files) created with the same model element. For example, along with the main documentation file created for a package, there could be a different HTML document that simply lists all classes in the package. If this listing document were in a separate navigation pane, it would serve as an index for the package. Clicking the package on a diagram (or in some more general text) could load that listing document in the navigation frame. The Documentation Template Designer enables you to target different documentation locations generated by the same model element. Link references in multi-frame documentation can have multiple targets. Clicking on such a reference could simultaneously load two different documents in two different frames. For example, suppose a diagram element represents a package. Clicking on this element could load the image of the package diagram in one frame and the main (textual) documentation for the package in another. Such link references are named compound. Related Procedures Hyperlinking Documentation Related Reference Control Properties

Javadoc Link References

Javadoc References (or JDRefs) are the expressions associated with Javadoc tags such as {@link} and @see. You can use them to create link references inside documentation text ({@link}) as well as with some other documenting tags. The Documentation Generator can convert JDRefs into real hypertext links. Each JDRef should conform to the rules described in the standard Javadoc documentation. There are three types of Javadoc references.
An element reference refers to an element of the model (such as method, class, or package). The general form
of an element reference is package.class#member label, where package.class#member is the referenced model element and label is optional text to be displayed with the link. (If label is omitted, the name of the referenced element is displayed.) The Documentation Generator can convert each element reference into a hyperlink to the main documentation of the element. href="URL#value">label</a> does not represent a hyperlink.

Click Next. The fourth page of the wizard opens. Specify the name of the master project that contains references to all projects created in the course of the migration. The default name of the master project is based on the source project name. Note: The master project is created to demonstrate the contents and structure of the source project. It is read-only and not intended for editing. Use the real projects to create or edit contents and establish dependencies.
Click Finish to import the selected project.
All resulting projects belong to the same type, which is defined by the properties of the source project and your choice in the Decision field of the Import Wizard. Java modeling projects are created if there is at least one Java source root for which the Copy option is selected. UML 1.4 modeling projects are created if there are no Java source roots, or if such roots exist but the Decision field is set to Skip or Convert to design language. Related Concepts Together Interoperability and Migration Related Reference Import Together Project Wizard
Navigating between the Tree View, Diagram, and Source Code
Together provides constant synchronization between different aspects of your project:
Model hierarchy, presented in the tree view (Model Navigator View) Model graphical representation in the Diagram Editor Source code (for implementation projects)
Tip: You can also use the Refresh function of the Model Tree View to update the entire model, and the Refresh function of the Diagram Editor.
You can navigate between the Model Tree, Diagram Editor, and source code in the following directions:
Navigate to the Diagram Editor from the Model Tree View. Navigate to a model element from the Model Tree View to the Diagram Editor. Navigate from the Diagram Editor to the Model Tree View. Navigate from a lifeline to its classifier in the Model Navigator View or a Class diagram. Navigate from source code to the Tree View. Navigate from the Model Tree View or Diagram Editor to source code (for implementation projects).
To navigate to the Diagram Editor from the Model Navigator View
In the Model Navigator View, right-click the diagram node. Choose Select on Diagram.
Alternatively, double-click the diagram node in the Model Navigator View.
To navigate to a model element from the Model Navigator View to the Diagram Editor
Right-click a model element in the Model Navigator View. Choose Select on Diagram on the context menu. Note: Click the Link with Editor button on the Model Navigator toolbar and all elements selected in the Model Navigator will be automatically selected on diagrams.
To navigate from the Diagram Editor to the Model Navigator View
Right-click the selected element or diagram background in the Diagram Editor. Choose Select in Model Tree on the context menu.

Right-click the main method, and choose Generate Sequence Diagram from the context menu. The Generate Sequence Diagram wizard is displayed. Click Next, accepting the default settings for the first page of the wizard. Click Finish, accepting the default settings for the second page of the wizard. The sequence diagram opens in a new diagram tab of the Diagram Editor.
Tip: By default, the generated diagram gets the name [Class_name].[method_name]
Right-click the activation rectangle of message #1, and choose New
For Block from the context menu.
The in-place editor is activated. Using the in-place editor, enter the following code: int i = 0; i < 4; i+ + The label displays on the activation bar as: for(int i = 0; i < 4; i++) Add an object to the sequence diagram. Click the Object button on the Palette, and click the diagram to create a new object with the name Frame. Right-click the frame object, and choose Select Class box is displayed. More from the context menu. The Select Class dialog
In the Model elements list, expand the following nodes: libraries > javax > swing. Select JFrame from the list, and click Add>>. Click OK to close the dialog. The name of the selected class is displayed on the frame object.
Draw a message link from the for(int i = 0; i < 4; i++) statement block to the lifeline of the Frame object. Message Link 1.1 is created. Note: All of the messages created in the following steps should also have the same source and destination.
Right-click Message Link 1.1, and choose Select Operation from the context menu. Select the JFrame constructor (JFrame:void) from the list. The message label becomes: 1.1: <constructor>()// Message Link1. The message changes visually to the creation type. Note that the message link now points to the frame object, which means that the object is being created. Draw a new message. Its label is Message Link 1.2. Right-click the message link, and choose Select More from the context menu. The Select Operation dialog is displayed. Expand the JFrame Operation node, scroll through the list, and select setDefaultCloseOperation(int):void. Click OK. The message label becomes: 1.2:setDefaultCloseOperation(int):void //Message Link2 In this step, we specify the parameters used on invoking an operation in the source code. These arguments can be entered in the arguments field in the Properties View of a message link. In the arguments field of the Properties View of the message 1.2, enter JFrame.EXIT_ON_CLOSE. The message label becomes: 1.2: setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE):void // Message Link2

To change the event type

Select an event. In the Properties View, select the , intermediate, or end value for the type property. Note: By default, events are created with start type.
When the program detects an incorrect element type, it highlights the element.
To automatically correct the element type
Right-click the highlighted element. Select Fix Element Type on the context menu.
To specify the trigger type
Select an event. In the Properties View, select the trigger type property. Select the trigger type from the list in the Value column. Note: There are ten triggers: None, Cancel, Compensation, Error, Link, Message, Multiple, Rule, Terminate, and Timer. There are also some constraints for event types and triggers (for example, a Compensation event cannot be a start event).
Related Concepts Business Process Modeling Related Procedures Together Business Process Modeling
Using BPMN Layout Features
To align diagram elements using the diagram editor toolbar
Select one or more diagram elements, and click the drop-down arrow to the right of the Align Left button. Choose one of the options to align the elements. Note: The Layout all command performs the following:
All pools are aligned and distributed with the constant distance between them. Sequence Flow links are aligned horizontally and directed from left to right.

Validating BPMN Diagrams

You can validate your BPMN diagram to check BPMN general rules, constraints to be met to make BPEL export possible, and prerequisites for simulation. Validation is performed for the entire diagram. You can perform validation with or without export-specific errors and warnings. Note: Validation is profile-sensitive. For example, there will be no validation for simulation action if simulation profile is turned off (default).
To validate a BPMN diagram for specification compliance
Open a Business Process Modeling project with the diagram you want to validate. Right-click the diagram background and select Validate BPMN diagram.
To validate a BPMN diagram for BPEL4WS export
Open a Business Process Modeling diagram you want to validate. Right-click the diagram background and select Validate for BPEL4WS export.
To navigate to an element that contains an error

Tip: SQL keywords are highlighted in the editor. You can control the list of highlighted keywords by editing the $TogetherArchitect_Home$/eclipse/plugins/com.borland.selena.dbmodeling_8.1.0/ keywords.xml file. Related Concepts Data Modeling Overview
Importing Data Model from Database
You can import a data model from a remote database using a JDBC connection. To reverse engineer a database, you need JDBC driver and JDBC connection parameters for your database.
To import a data model from a database

Choose File

Expand the Modeling node and select DB schema from JDBC as the import source. Click Next. Click Connect to establish a connection to the database. The Connect to Database dialog box displays. In the Source tree view, select a connection profile. If necessary, create a new one. Click Connect. If the connection is successful, you will see the source objects tree. Otherwise, an error message is displayed. Select objects in the source objects tree to import them. Specify the target Data Modeling project where the source object will be imported. Click Finish to start the import process. New schemata are created in the selected project.
Related Concepts Data Modeling Overview Related Procedures Creating Connection Profile
Transforming Logical Data Model to Physical Data Model
After you have created a Logical Data Model (with the help of ER Logical Diagram profile), you can convert it into a schema in an existing Data Modeling project.
To convert a Logical Data model to a schema
Select DB Schema from ER Logical Diagram Profile UML 2.0 project. Click Next. In the Source tree, select ER Logical Diagram elements. Select a valid UML project with ER Logical Diagram Profile. Select the target Data Modeling project from the list where the schema will be created. Select the target schema name (the name of the source file is used by default). Click Next. Select transformation option. Click Finish to start the import process. New schema with the specified name is created in the specified project.
Model Driven Architecture
Topics in this section cover the most common tasks associated with developing model transformations. In This Section Adding a New Ant Task to the Composite Transformation How to add a new Ant task to your Composite transformation. Applying Model-To-Model Transformations How to apply a Model-To-Model transformation. Applying Model-To-Text Transformations How to apply a Model-To-Text transformation. Applying XSL Transformations How to apply an XSL transformation. Building MDA Projects from the Command Line How to build an MDA Transformation project from the command line. Configuring Model-To-Model Transformation Builder How to configure the project builder for a Model-To-Model transformation. Configuring Model-To-Text Transformation Builder How to configure the project builder for Model-To-Text transformation. Creating a Composite Transformation How to create a Composite transformation. Creating a Model-To-Model Transformation How to create a Model-To-Model transformation. Creating a QVT Library How to create a QVT library. Creating an Example MDA Transformation Project How to create an example MDA Transformation project. Creating an MDA Transformation Project How to create an MDA transformation project. Creating an XSL Transformation How to create an XSL transformation. Creating Model-To-Text Transformations How to create a Model-To-Text transformation. Debugging Model-To-Model Transformations How to debug Model-To-Model transformations. Debugging Model-To-Text Transformations How to debug Model-To-Text transformations. Debugging XSL Transformations How to debug XSL transformations. Deploying Transformations How to deploy compiled QVT transformations. Opening MDA Views How to open views related to MDA perspective.

Use the AutoCheckout modeling resource on edit option on the Modeling resources page of the
Team preferences to check out model files when Together attempts to change the corresponding model entities. This mode requires a VCS provider to mark files that are not checked out as read-only. For example, you can configure StarTeam for Eclipse (Window Preferences Team StarTeam File) by checking the Mark unlocked working files read-only and Exclusively lock files on checkout. In this case every unlocked file is marked as read-only and upon any attempt to modify this file in the Java Editor, Diagram Editor or Model Navigator, Eclipse asks StarTeam to check out the file and StarTeam displays a dialog box asking you to lock the file. You can also check the Auto lock read-only files option to avoid this dialog. If the file cannot be locked (set in the manual mode) or a server refuses to do it, all changes will be reverted to the previous state. If AutoCheckout modeling resource on edit is deselected but a VCS provider is configured to mark working files as read-only, all element context modification actions in the Diagram Editor and Model Navigator are disabled until the read-only flag is cleaned from the working files.
For sharing Together model projects with ClearCase, use the ClearCase Adapter for Modeling wizard. Any source files/design diagrams that you created before you shared the project should be added to the

repository.

The project's project file can be shared, but only if the team will use the exact same project name. You should not version control the default package diagrams (those files with the.txvpck extension)
because these change frequently and are easily regenerated automatically by Together if they are missing. To exclude the default package diagrams from sharing, choose Preferences Team Modeling resources and check Ignore default package diagrams. each team member will have the libraries in exactly the same place (for Windows, this includes the drive letter).
You can include the.classpath file if you are using variables to point to libraries, or if you are sure that
You can specify directories and files that you do not want to share: from the main menu, select Window
Preferences Team Ignored Resources. Add "*.txvpck" and the Commit and Update actions will ignore these default package diagrams. Note: Respectively, each team member would also have to set this up locally.

This section displays the common properties of the selected object. The number of fields in this section varies depending on the selected diagram or element. See each element description for details.

Custom

This section displays the custom properties and their values specified for the selected object. Add Creates a new entry in the list of properties. Remove Deletes the selected entry from the list of properties.

Description

Use this field to add description text for a diagram or element. There are 'WYSIWYG and Source View tabs. Text in the Source tab is displayed with HTML formatting. Words that are displayed with a red underline are not recognized by the editor's dictionary. A list of spelling checkersuggestions is available in the context menu. Select the word with a red underline and open the context menu to see spelling suggestions. You can disable automatic spell checking.
Note: You can configure the spelling settings from the WYSIWYG tab. The available Spelling properties are American English, British English, French, German, and Spanish.
Edit tab item Description
Undo Redo B I U S Align left Align center Align right Align justify Decrease indent Increase indent Add ordered list Add unordered list Insert table Insert row below Insert column left Insert image Insert hyperlink Spelling settings Auto spelling checker
Undoes an action Redoes an action Applies bold style Applies italic Applies underlining Applies strikethrough Applies align left Applies align center Applies align right Applies align justify Applies decrease indent Applies increase indent Adds an ordered list Adds an unordered list Inserts a table Inserts a row below the current row Inserts a column to the left of the current column Inserts an image Inserts a hyperlink Apply spelling checker settings Enable or disable automatic spell checking
Use this field to add hyperlinks to the element.
Add hyperlink Opens the Hyperlinks dialog, where you can select elements to be linked with the current element. Remove Deletes the selected hyperlink. Remove all Removes all hyperlinks from the element.

Support for the EMF.Edit framework
For every model plug-in, the EMF API provides an.edit plug-in that contributes to the org.eclipse.emf.edit.itemProviderAdapterFactories extension point. These plug-ins delegate to a Together model the task of providing the label and images for EMF objects.

Samples

The Uml2Ecore example (com.borland.tg.samples.api plug-in) illustrates how to transform a Together UML 2.0 model static structure into an EPackage instance. The generated EPackage contains all packages, classes, enumerations, datatypes, and other core elements. Related Concepts Model Transformation Support Related Reference EMF API for Together Profiles

Model Compare/Merge

Provides reference information on Together Model Compare/Merge facility.
Together provides a generic Model Compare/Merge facility that works with EMF models. It supports Together proprietary models (UML 1.4, UML 2.0, and so on) via the EMF API. Model Compare/Merge is designed to be consistent with the standard Eclipse Compare/Merge functionality and uses similar terms. The term model below means the whole containment tree rooted in an EMF object (EObject). Together elements are adapted to EObject by EMF API. This definition implies that in a model, each object but the root has an unique container. Model Compare/Merge only processes the objects contained in a model and objects that are referenced by an object contained in the model. A reference is called internal when both referencing and referenced object are contained in the same model; a reference is called external when it crosses model boundaries. The external references are references to standard UML types (such as Integer or String) that are not contained in any user model. The term resource denotes either a basic EMF resource or a Together project.
It is possible to compare two or three models. In a two-way compare, case models are called Left and Right. When Model Compare/Merge is used with a VCS like CVS or StarTeam, the Left model represents a local version and the Right model represents a remote version. In a three-way compare, an Ancestor model is added. It represents a common ancestor version when used with VCS. To activate Model Compare/Merge, first either select elements of the same type on a diagram or in the Model Navigator view, or select Together projects or files with saved EMF resources in any resource view (such as the Navigator view). Then choose Compare With Each Other (as Models) in the context menu. Note, that the compare action is disabled if less than two or more than three elements are selected. During comparison, Model Compare/Merge traverses the models, going level-by-level down the containment tree. On each level, objects are matched using ID features that are set on a preference page. A tuple of ID features values should uniquely identify the object in the list of its container's direct contents. When all objects on all levels of the models are matched, Model Compare/Merge compares values of attributes and non-containment references.

Insert Sibling Element Insert Label Control Insert Image Control Insert Panel Control Insert Formula Control Insert Data Control
Opens the Template Properties dialog. Inserts a nested element (static section, element property iterator, folder section, call to stock section, call to template). This action is enabled for iterator sections only. Inserts a sibling element (static section, element property iterator, folder section, call to stock section, call to template). Opens the Label Control dialog that enables you to insert a label into a static section, header or footer of a template. Opens the Image Control dialog that enables you to insert an image into a static section, header or footer of a template. Opens the Panel Control dialog that enables you to insert a panel into a static section, header or footer of a template. Opens the Formula Control dialog that enables you to insert a formula into a static section, header or footer of a template. Opens the Data Control dialog that enables you to insert a data control element into a static section, header or footer of a template.
Insert Include Text Control
Opens the Include Text Control dialog that enables you to insert a text control element into a static section, header or footer of a template. New Stock Section Opens the New Stock Section (Element Iterator) dialog that enables you to create a new stock section in a separate tab. New Stock Section (Folder) Opens the New Stock Section (Folder) dialog that enables you to create a new folder section in a separate tab. Generate Documentation Using Template Opens the Generate Documentation Using Template dialog that enables you to generate project documentation with the current template. Related Concepts Documentation Generation Overview Related Reference Organization of a Documentation Template Documentation Template Properties
Documentation Template Properties
Template Designer toolbar Show Template Properties button Use this dialog box to view and modify the properties of a documentation template. The dialog box contains the following tabs:
General Page Settings Formatting Styles Template Parameters
Model Template type Template Description Report Title Expression
Root Object Metatype Formatting Template Headers/Footers
This read-only field displays the metamodel defined on template creation. This read-only field displays the template type defined on template creation. Enter commentary information in this text field. The field displays report title expression created in the Expression Editor. Click the editor button to the right to open the Edit Expression dialog, choose notation and enter a title expression. Select root object metatype from the drop-down list. Enter the path to the formatting template, or click the Browse button and choose an MS Word document. Choose to generate specified headers and footers.