Messages

1

General Board / Re: Synchronize model with ERWIN

« on: April 13, 2016, 02:02:33 am »

Hi Hans,

I had the same problem with my current client. There are few things that we redesigned in terms of processes and tools to deal with this kind of issue.

First, we've identified that all the Sparx EA models' consumers were related to integration (SOA, API...) or business process management. Therefore, an 'objected oriented' view of the information would make more sense.

We then decided to use the MDA approach to derive the XSD models. The challenge came when we had to import the Erwin models as our Platform Independent Model, because it is not a straight forward exercise to translate relational model to class (hierarchical) models. After trying few options, we decided to create an add-in that could consume the reports generated by the Enterprise Data Modelling team from Erwin, and producing a report that could inform the differences between Erwin and Sparx. The add-in also gives you the capability to choose what classes/entities and attributes to merge.

In my view, the main advantage of this approach is that you have better separation of concerns and traceability from the Enterprise Model down to the physical XSD models.

Hope it helps...

2

General Board / Re: XSD transformation: attribute mapping

« on: February 20, 2016, 03:19:06 am »

It would be good to hear their feedback.

3

General Board / Re: XSD transformation: attribute mapping

« on: February 19, 2016, 01:27:46 am »

Was there any particular reason for not following Sparx functionalities for the MDA approach?

PIM -> PSM -> code generation

I found it very useful as I can use the MDA Transformation Templates to translate my PIM to different PSM models.

4

General Board / Re: XSD transformation: attribute mapping

« on: February 19, 2016, 12:23:41 am »

This is a good point for reflexion...

As Geert said, the add-in will allow you to customise the way you generate subset models or files. I like the idea of generating subset models from your PSM XSD models as it gives you the flexibility to make adjustments to the model at the physical level (i.e. flattening the schema, merging classes...) without affecting the XSD "logical model" (PSM). The main trade-off is that this approach results in the management of three different models (PIM, PSM and "physical") instead of two (PIM and PSM).



 

5

General Board / Re: XSD transformation: attribute mapping

« on: February 15, 2016, 10:46:10 pm »

I'm glad it was useful!

I believe that the hidden associations you are talking about is actually the traceability between PIM and PSM. All the transformed classes have the link back to the original ones. You can see this relationship in the traceability window, just click on the transformed class and you will see the relationship under "transformed from".

When you update your PIM model and transform to a specific PSM (i.e. XSD), Sparx uses this relationship to check if the class already exists (to be updated) or if it is a new one (to be created).

Does it make sense?

Cheers,
Rod

6

General Board / Re: XSD transformation: attribute mapping

« on: February 12, 2016, 08:48:05 am »

Hello Chaps!

Here is my humble contribution to this interesting topic...

UML to XSD model transformation

I believe that customising the XSD Transformation Template should solve all your problems. I'm not an expert in this area as I'm not that familiar with the 'Intermediary Language', but I've done a few customisation for problems similar to yours. Starting with the Classes, the only 2 XSD types that are mapped in the default template are XSDComplexType and enumeration. Here is the extract from the XSD Class template:

Code: [Select]

name=%qt%%className%%qt%
%if classStereotype=="enumeration"%
  stereotype="enumeration"
%else%
  stereotype="XSDcomplexType"
%endIf%

I never had to use stereotypes for the attributes, as the most important for me has been the rules to translate the PIM attribute types to XSD types. In order to create this mapping, you can customise the following part of the XSD Attribute template:

Code: [Select]

name=%qt%%attName%%qt%
  scope="Public"
 %if attType=="Date" or attType=="DateYear" or attType=="DateCalendar"%
  type="xs:dateTime"
 %elseIf attType=="Time"%
  type="xs:time"
 %elseIf attType=="Decimal"%
  type="xs:decimal"
 %elseIf attType=="Integer"%
  type="xs:integer"
 %else%
  type="xs:string"

You could also do the same for stereotypes if required.

Regarding the inheritance/generalisation/specialisation, there is a new functionality on schema composer in v12.1 that enables the specialisations of a specific generalised class to be realised as a XSD choice. Check this page of the user guide for more information:

http://goo.gl/1Wqe0R

Although this is a great feature that I've been waiting, it has some bugs that I've already reported. I can post some information in the respective forum area if you guys are interested.

XSD Schema Toolbox

For this one, I will use a traditional phrase from most of the IT support people: "It is working on my machine" 

Attributes are not stereotyped

GOTO my first point.

Other considerations

Regarding the physicalisation of the models as JSON or XSD format, I've been doing few tests and believe that (unless you use exactly the same structure for both formats) they should be treated as 2 different PSMs. The main reason is that XSDs are usually related to coarse grained functionalities (i.e. backend systems integration services, ETL) or persistence storages (i.e. databases), and JSON related to more fine grained functionalities (i.e. APIs, microservices). Therefore, the latter usually demands a flatter structure.

Please let me know if it makes sense or if I misinterpreted any of your points.

Regards,
Rodrigo

7

Automation Interface, Add-Ins and Tools / Re: Generate XML Schema for bi-directional associations

« on: January 12, 2016, 09:33:00 am »

Hi Geert,

I'm assuming you are using the "traditional" XSD generator...

As far as I remember, it uses the source/target to define the "path" it needs to follow for the schema hierarchy, where the destination is always going to be the child element. I had the same problem and tried many configurations related to Navigability (which I believe to be the correct one) and Directionality (as mentioned by Paolo) without success. My "workaround" at that point in time was creating another association in the opposite direction. If you import your expected XSD example into EA, you will see that this is how EA will interpret the XSD.

If you are not constrained by the EA version, I would suggest to use the Schema Composer as it includes all the associations "from and to" a specific class in the Schema Profile configuration.

Cheers,
Rod

 

8

General Board / Re: Generating an XSD for just diagram objects

« on: December 07, 2015, 08:50:41 pm »

Just in case you are interested in extending the Schema Composer, here is the promised link:

http://connection.rnascimento.com/2015/12/03/extending-sparx-ea-schema-composer/

Regards,
Rod

9

General Board / Re: Generating an XSD for just diagram objects

« on: November 27, 2015, 10:31:09 pm »

Take a look at my articles about class specialisation for XSD models and the schema composer overview:

http://connection.rnascimento.com

You can also customise the Schema Composer to behave the way you need. That is what I usually do. I've been promising an article about it... I will try to post it soon...

The new EA 12.1 (beta) also has some promising improvements, but (until build 1223) most of them are still WIP (as I would expect from a beta version).

10

General Board / Re: Schema Composer: how to create simple types?

« on: December 07, 2015, 08:51:49 pm »

Here is the promised article about extending Schema Composer:

http://connection.rnascimento.com/2015/12/03/extending-sparx-ea-schema-composer/

Regards,
Rod

11

General Board / Re: Schema Composer: how to create simple types?

« on: November 07, 2015, 01:40:58 am »

Hi Geert,

What is the main reason you are providing the logical data model as an XSD? are they building and application based on this model? or are they using as a reference for interoperability (i.e. APIs)?

If you are providing the entire logical data model as XSD, I would probably recommend to use the old Schema Generator. I found the Schema Composer very useful to create schema subsets (usually used as message models in systems integration - APIs, SOA...).

Regarding the XSD transformation (I believe you are talking about MDA Transformation), I usually have to customise the datatypes mapping according to the clients rules (i.e. sometimes clients want to simplify the datatype translation to a specific technology - e.g. all numeric types translated to xs:decimal), so the sparx original template needs to be customised.

I wrote few articles about deriving XSD models from Enterprise Information/Data Models, using both old XSD Schema Generator and the new Schema Composer:

http://connection.rnascimento.com

I'm also writing a new article about Schema Composer extension... as I had to customise it to clients' needs.

Cheers,
Rod

12

General Board / Re: EA12.1 beta builds

« on: November 27, 2015, 10:20:52 pm »

Go to menu Help / Read me...

13

General Board / Re: Generate only 1 toplevel element in XML Schema

« on: October 15, 2015, 09:34:23 pm »

Hi,

I believe that you want to produce a XML Schema using the 'Venetian Blind' style, instead of 'Garden of Eden'.

Take a look at this post from my blog, where I explain step-by-step how to do it:

http://connection.rnascimento.com/2015/03/27/deriving-xml-schemas-from-your-enterprise-information-model/

I would also consider upgrading to version 12. There is a new functionality called 'Schema Composer' that has been helping me to create better XSD schemas. I've also wrote an article about it:

http://connection.rnascimento.com/2015/06/24/sparx-ea-schema-composer-overview/

Hope it helps!

Regards,
Rod

14

General Board / Re: XML Schema version

« on: July 09, 2015, 07:10:14 pm »

As far as I know, 1.0 for both XSD Generator and Schema Composer (EA 12)...

15

General Board / Re: Schema Composer - Editing Restrictions

« on: June 26, 2015, 04:22:11 pm »

Hi Simon,

I understand where you guys started with the Schema Composer and appreciate the efforts to listen to feedbacks and, most importantly, considering them in your product development.

If you allow me, I would like to suggest something to your strategic view of the Schema Composer. As one of the mains features of Sparx EA (in my view) is the support to MDA approach, I would leave the transformation from logical to physical models to the Model Transformation (MDA) functionality (for all the benefits that the MDA approach offers). I don't think that the Schema Composer is (or should be) the right tool to give the different perspectives on multiple physical formats, but definitely the right one to generate the respective physical files (a.k.a. code generation functionality). Therefore, I would use the MDA Transformation Templates to deal with the different physical formats (XSD, JSON, RDF...), mainly because it can deal with unavoidable translations between PIM and PSMs, and Schema Composer to create the code generation profiles (schema profiles).

We have been using this approach to deal with our SOA/API challenges by deriving XML and JSON schemas from our Enterprise Information Model, and it has been solving a lot of our problems related to traceability, consistency and delivery time/cost.

Does it make sense?

Regards,
Rod