Builder Projects, Composites and Modules

For the sake of simplicity, assume you start with one UML model. Within the model, we define an xUML service. This smallest deployment unit can be compiled to a so-called xUML service repository, which is then deployed to a Bridge. Deploying means to send the service repository to the  Bridge and execute the repository using an xUML Runtime. This implies that each service repository runs in its own OS process leading to the simple but important rule:

Of course, if more than one service (say Service 1 and Service 2) is used together, they can be put into one composite. For example, if it is required to start, stop and monitor a set of services together, group them into one composite.

Figure: Projects, Composites and Services

Technically, there is no restriction on how many configurations can be put into one UML model. However, for the model compiler each model file (XMI file) is one compile unit being compiled only if necessary. Therefore, it makes sense to keep the XMI files small. In order to achieve this, Magic Draw allows splitting UML models into smaller pieces called modules. Though these MagicDraw modules are just other UML XMI files, other models can use them.

For example, if using a module in your main model, you get access to all model elements within the used module. MagicDraw offers several options to configure this access (read-only, read-write, etc). The main difference is whether modules are automatically loaded if the main model opens or not. These settings have a major impact on the used memory at design time. For details, see the Magic Draw user guide.

How to define sensible module borders? In many cases, this is a matter of taste. However, there are some guidelines:

• Keep classes and their implementations together.
• Keep classes that require each other together. This means, do not try to split cyclic dependencies. However, whenever possible, avoid cyclic dependencies.
• Import external metadata (xUML service libraries, XML schemes, WSDL files, IDocs, EDIFACT, ..) into own modules and just use these modules but do not change them. The reason is, that if you must re-import the meta-data, you can just override the module file. If you would merge the new import into an existing model - which is possible - everything works fine, except: elements that vanished in the import are not deleted while merging new with old meta-data.

Summarizing, modules are used to organize your UML model into smaller parts. The next step is to organize these models. In the Bridge, Builder projects organize UML models. Generally, all model files that must be compiled together must be found in one Builder project. However, our experience suggests avoiding too big projects. It is beneficial, if one person can maintain one project. If this is not possible, you should consider splitting the project into several sub-projects.

In order to do this, it is necessary to re-use work done in other projects. The simplest approach would be to share MagicDraw modules. This can be achieved either by copying the module into other projects or by a file sharing concept. Doing this means to share the implementation. However, in order to manage the complexity of the overall integration solution, it makes sense to share only interfaces and the runtime repository, i.e. to share components.

Merged Libraries

If a UML model shall be reused and - as discussed above - the implementation shall be abstracted, there are two options:

1. Build a service and reuse the functionality at run-time. This has a high abstraction level, because the service consumer does not know the implementation or even the implementation technology. However, there are performance and usability constraints depending on the technical service protocol. For example, SOAP/HTTP is verbose, slow and supports static calls only.
2. Apply the WebService idea to Bridge repositories: Instead of importing WSDL or JAR files, you may import a Bridge repository compiled from a UML model. UML models that define such re-usable components are called xUML service libraries. Compiling these libraries leads then to importable xuml service library repositories (Extension: .lrep).

xUML service libraries are artifacts devised to design reusable components. The following figure shows how two example projects share the repository created in a third Builder project. The important point is, that for re-use only the library repository is required. This repository can be imported into a UML model like any other supported meta-data (e.g. WSDL files). Importing the repository will create model elements that can be used to invoke operations without exhibiting their implementation originally defined in the library project.

Figure: Merged Libraries

MagicDraw Module Versus xUML Service Library

You may ask now, when MagicDraw module and when an xUML service library is to be used.

As a best practice, we have made good experiences using MagicDraw modules only for large Class-Definitions, i.e. imports of WSDL, IDOC segments, Edifact structures, etc. Furthermore, we recommend to avoid dependencies between the MagicDraw modules. When reusing functionality and components, we recommend to use libraries. Modeler is isolated from the implementation and has only to handle the interface of the library.

However, there is also one drawback. If the library interface is not stable and changes frequently, the libraries have to be re-imported and the xUML service has to be re-compiled for each change.