Sparx EA Schema Composer Overview

When Sparx Enterprise 12 was release few months ago, I didn’t really rush to see what were the new features until I read this article about new Wireframes feature.

This post can be considered as a continuation of my previous post ‘Deriving XML Schemas from your Information Model’, as this replaces the last step (where we generate the physical XSD file).

If you use Sparx EA for your integration architecture models, this is something that you probably have been waiting for a long time. The XSD Generator functionality (present at least from version 9, when I started to use it) was a helpful way to consistently produce XSD files, but it lacked few functionalities. In my ‘Approach to implement Class Specialisation’ post, I’ve described some of these gaps and the main points are listed below:

• It creates one XSD file per XSD Schema Package – so if you need a ‘self-contained’/flatten XSD file, you need to use another tool to do the job (I used Altova XML Spy).
• It does not allow you to create schema subset
• It does not allow you to define a namespace for a specific XSD schema file

Therefore…

What does the new Sparx EA Schema Composer offer?

The main functionalities were already described in the Sparx EA 12 highlights page, so I’m not going to copy and paste here. However, I would like to present shorter list with my own highlights, based on what I’ve been experienced so far:

•  Create subset of physical models – this the main purpose of the Schema Compser tool (at least in my view). It provides a better way to generate the physical XSD files by creating
•  Out-of-the-box support to multiple formats – who is not talking about JSON and RDF as alternatives for XSDs???
• Support to industry standards – Although I haven’t really tried this, I still think that is a great accelerator (if you use one of the supported standards).
• Automation API support – this is (again, in my humble opinion) a true differentiator from Sparx’s competitors.

Model Example

For the purpose of this overview, I will use the same XSD model that I’ve used in previous posts. It is a simplified version of Customer model.

Defining the Schema Profile

To create a new Schema Profile go to the ‘Tools’ menu and click on ‘Schema Composer’, then click the ‘New’ button. As I’m using my own model/standard, I will work with the ‘Generic’ Schema Set.

Define the profile name and schema namespace. I also found useful to save the Schema Profile as a model artefact (mainly for portability perspective).

Now we can start our Schema Profile definition by dragging and dropping the first class of our model into the tool. I always start with the class that will represent my root element (‘Customer’ in this case).

If you start to select the attributes that will be part of your schema profile, you will notice that the Sparx EA Schema Composer automatically add the respective classes for the selected associations. It also has the option of including the inherited attributes and associations.

In the last step before generating the XSD file, you need to define the root element for your schema. Just right-click on the class that you want to be the root element and select ‘Set element as root’.

When you finish to select all the required attributes/associations and (optionally) defined the root element, you are ready to generate the physical files.

Generating the physical files

As I’ve mentioned before, the Sparx EA Schema Composer tool provides the capability to generate the physical files in different formats (i.e. XML Schema, JSON Schema…). In this specific case I’m generating XML Schemas (XSDs), and will leave the other formats for further discussions in future posts. The main reason is that I still don’t have a well formed opinion about using (or re-using) the UML XML Schema Profile to generate all possible physical formats for my integration services (this is the term I use for SOA services, APIs, micro services…), or waiting for/defining different UML Profiles for each physical data model (e.g. UML Profile for JSON).

Under the Profile section, click on ‘Generate’

Now just select the ‘XML Schema (XSD)’ checkbox and click on ‘Generate’.

Select where you want the file to be saved, and you are done!

What else?

So far we (hopefully) had a good overview of the basic functionality, but there are few other things that we need to explore. I would like to highlight some points to be explored in future posts:

• Inconsistencies with UML XSD profile – this was my main problem when I first tested the tool. The Schema Composer (at the date of publishing this post) does not recognise all the element types defined in the UML profile for XSD. In the example that I presented in this post, the resulting XSD didn’t create contact method choice as a XSD Choice. Instead, it was realised as another complex type. Apparently, the Schema Composer does not check the class stereotypes defined in the UML profile for XSD. I’ve posted something about this issue in the Sparx EA forum, and you can see it following this link: http://goo.gl/RQbyMd
• Namespace prefix – another small issue that annoyed me when I was first testing it. For some reason, you can define the schema namespace, but you can’t define the prefix for it (by default, the Schema Composer defines the prefix as ‘m’ – I would like to know why!).
•  Generating custom formats – this is one of the cool things about Sparx EA in general… if you are not happy with the standard functionalities… extend the tool! I am actually using this approach for my current client by creating an Add-In to generate the schemas according to their standards (this actually was my way to solve the issues above). I will definitely post something soon to talk a bit more about it!