Sparx Systems Forum

Discussion => General Board => Topic started by: Modesto Vega on March 24, 2016, 04:21:05 am

Title: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 24, 2016, 04:21:05 am
I am developing a meta model and would like to apply it to an existing model. I would appreciate some advice tegarding the following;

1) How do I apply the meta model to an existing project?
2) How can I include existing profiles into the meta model (aka Database Engineering)?
3) How do I customise existing profiles (aka Database Engineering)?
4) How can I get this done iteratively? I have version 0.5 of the meta model but I strongly suspect that quite a number of elements will be added to the meta model overtime?

The project is stored in a SQL Server database repository.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on March 24, 2016, 05:45:55 am
1) depending on the number of elements in the model I would probably write a script to add the required sterotypes
2) 3) you can extend existing profiles. See http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/non-uml_metatypes.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/non-uml_metatypes.html), you cannot change existing profiles.
2) More or less the same way you do it the first time, with a script if needed.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on March 24, 2016, 07:07:51 am
Depending on the size and package structure rather than writing a script, it may just be easier to open the package in list view and edit the elements directly.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: qwerty on March 24, 2016, 07:54:13 am
Applying any MDG is now simply by adding the appropriate stereotype to the element. This can be done manually or via a script. The latter is nice if you can determine the right set automatically. Else you'd probably need to go the manual way. AFAIK (haven't tried, but remember this from a post) you can drag the right element from the MDG toolbox onto the element to change and it will take its properties.

q.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on March 24, 2016, 10:52:44 am
Applying any MDG is now simply by adding the appropriate stereotype to the element. This can be done manually or via a script. The latter is nice if you can determine the right set automatically. Else you'd probably need to go the manual way. AFAIK (haven't tried, but remember this from a post) you can drag the right element from the MDG toolbox onto the element to change and it will take its properties.

q.
I suspect "here be dragons". 

I'm not sure we're necessarily understanding what the OP is asking.

But, assuming it's:  "I've created my own MDG and I want to apply it to an existing repository", I suspect q's point about dragging and dropping the new element type over the old element type MANUALLY is the best option as (hopefully) Sparx have (behind the scene) executed the use cases involved.

Trying to do it via scripts (especially if you're not familiar with EA's internals) could e a recipe for disaster.  Making sure "all the i's are crossed and t's dotted" :) is not trivial.  It's not rocket science, but not trivial.

We are evolving multiple MDGs into one while the repository is "in flight" and it's doable, but there's a lot of "balls to keep in the air".  We have nearly 80,000 items so, manual is not possible.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 24, 2016, 08:40:59 pm
Thanks to all for the replies.
Regarding,
I suspect "here be dragons". 

I'm not sure we're necessarily understanding what the OP is asking.

But, assuming it's:  "I've created my own MDG and I want to apply it to an existing repository", I suspect q's point about dragging and dropping the new element type over the old element type MANUALLY is the best option as (hopefully) Sparx have (behind the scene) executed the use cases involved.

Trying to do it via scripts (especially if you're not familiar with EA's internals) could e a recipe for disaster.  Making sure "all the i's are crossed and t's dotted" :) is not trivial.  It's not rocket science, but not trivial.

We are evolving multiple MDGs into one while the repository is "in flight" and it's doable, but there's a lot of "balls to keep in the air".  We have nearly 80,000 items so, manual is not possible.

Paolo
- There is an EA meta model
- The meta model has not been exported to an MDG because it is not complete, I will rather include changes to existing profiles
- Points 1, 2, and 3 on my OP refer to the creation of the meta model
- Point 4 applies to applying an evolving meta model, possibly using an MDG, to an exisitng "in flight" repository. Doing this manually is not very realistic becuase of the number of elements in the repository

Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 29, 2016, 10:58:41 pm
2) 3) you can extend existing profiles. See http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/non-uml_metatypes.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/non-uml_metatypes.html), you cannot change existing profiles.
Geert
Somehow I sense this is not as straight forward as it may sound. The help in the above link reads:
Quote
In the Project Browser, locate the Package with the <<profile>> Stereotype and open its child diagram.

If you do not have an existing <<profile>> Package, use the 'MDG Technology Builder' option in the Model Wizard to create a new technology, then open the diagram from the newly created <<profile>> Package.
 
But I, of course, cannot see a 'MDG Technology Builder' on my Model Wizard. What am I missing here?
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on March 29, 2016, 11:02:20 pm
You are missing the MDG Technology Builder MDG technology.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 29, 2016, 11:12:18 pm
You are missing the MDG Technology Builder MDG technology.

Geert
What do you exactly mean? I am using a Coporate edition and have an option under Tools called Generate MDG Technology File which does virtually nothing, of course I might have forgotten how to use it.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on March 29, 2016, 11:17:40 pm
Extensions|MDG Technologies and then check the technology called "MDG Technology Builder"

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 29, 2016, 11:28:21 pm
Extensions|MDG Technologies and then check the technology called "MDG Technology Builder"

Geert
Version 1.

I cam even see the MDG I want to generate, it says location: Model.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on March 29, 2016, 11:39:35 pm
You can to check the box next to the MDG technology "MDG Technology Builder" to make it active.
That MDG technology contains toolboxes and helpers to create MDG technologies.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 29, 2016, 11:51:46 pm
You can to check the box next to the MDG technology "MDG Technology Builder" to make it active.
That MDG technology contains toolboxes and helpers to create MDG technologies.

Geert
It is enabled and active. What next, where can I find the helpers and toolboxes?
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on March 30, 2016, 12:10:57 am
http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/umlprofiles_2.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/umlprofiles_2.html)

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 30, 2016, 12:30:17 am
http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/umlprofiles_2.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/umlprofiles_2.html)

Geert
Yes Geert, I know about this link and I have followed the steps in http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/creatingmdgtechnologies.html. Looking at the ouput, the problem must be that the wizard does let me select any Profiles, Patterns or Diagrams.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on March 30, 2016, 12:45:58 am
Maybe you should try to explain in detail (with pictures?) at which step you get stuck.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on March 30, 2016, 01:25:12 am
I am not exactly getting stuck, just getting confused.

I have the folllowing structure:

Root Node - ABC
--------------------Package - ABC1
--------------------Package - ABC2
--------------------Package - ABC3

Package ABC1 uses UML2, classes and activities, where I have added custom stereotypes, using Project\Settings\UML Types

Package ABC2 uses UML2, mainly components

Package ABC3 contains mainly database models, currently all Oracle

When I run the MDG creation on the root node and go through all screens, the reuslting MDG profile is essentially empty, except for the name version and description. With empty I mean it does not contain any metaclasses, it does not contain any of the custom stereotypes on ABC1, it also does not contain anything related to the Oracle pattern.

Perhaps, I am missing something but I was empty the MDG Creation to do something similar to reverse engineering my packages and construct something I can use to extend the metamodel. I am probably wrong but have no idea where I missed a step.

Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on March 30, 2016, 04:19:21 am
EA will not "reverse" engineer whatever you have used into a UML profile.
You will have to create the stereotypes as model elements yourself.
Following the instructions in the help file should suffice.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 02, 2016, 12:22:11 am
Just to summarise the contents of this thread so far:

1) Generating an MDG techology file from an existing model will not include the existing profiles associated with the various packages within a project or any customisation to any of the profiles associated with the packages

[Question: If the above is correct, what is the point of Generating an MDG technology file from an existing project]

2) The only profile which can customised is the UML profile

3) The only way to customise the UML profile is by using steretypes and associating them with metaclasses as described in http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/umlprofiles_2.html

4) Other profiles, such as database profiles, cannot be customised

5) Once a profile has been customised there is no easy way to apply it to an existing model.

Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 02, 2016, 02:25:04 am
I don't think any of your "conclusions" is correct ???

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 02, 2016, 03:16:20 am
I don't think any of your "conclusions" is correct ???

Geert
Geert - generally you are very helfulp except when you choose to use telegraph code or speak Sparkinglish. Which you have been doing in this thread for a while. It will be good if you used more words.

So far I have not managed to produce an MDG containing any profiles used on any of the packages in the project.

It will be a good starting point of if you could provide a step-by-step guide on how to generate an MDG that contains the profiles used in the packages contained within a root node. And please don't tell me again to follow the online help because I have and is rubish.



Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 02, 2016, 03:35:22 am
Thomas Kilian wrote some articles about creating MDG technologies.
http://liquit.biz/brain/enterprise.html (http://liquit.biz/brain/enterprise.html)
Maybe they are more helpful to you.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Sunshine on April 02, 2016, 02:18:30 pm

[/quote]
 And please don't tell me again to follow the online help because I have and is rubish.
[/quote]

Well I have to disagree. I've found online help very useful when creating an MDG. I've managed to successfully extend ArchiMate MDG. The online help for Sparx EA is head and shoulders above other tools I've used in this space.


Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 04, 2016, 06:45:30 am
1) Generating an MDG techology file from an existing model will not include the existing profiles associated with the various packages within a project or any customisation to any of the profiles associated with the packages

[Question: If the above is correct, what is the point of Generating an MDG technology file from an existing project]

Hi there, I think the assumption that EA can some how magically iterate your underlying meta-model is just confusing everybody.  People build MDG technologies to support a particular notation or knowledge model.  There's no facility in EA to do it for you.  EA would have to be quite an advanced AI to semantic reasoning to perform this function.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 04, 2016, 09:58:48 am
1) Generating an MDG techology file from an existing model will not include the existing profiles associated with the various packages within a project or any customisation to any of the profiles associated with the packages

[Question: If the above is correct, what is the point of Generating an MDG technology file from an existing project]

Hi there, I think the assumption that EA can some how magically iterate your underlying meta-model is just confusing everybody.  People build MDG technologies to support a particular notation or knowledge model.  There's no facility in EA to do it for you.  EA would have to be quite an advanced AI to semantic reasoning to perform this function.
And since Sparx EA is internally self inconsistent, the AI would end up in a padded cell screaming at the universe...

As Glassboy implies, MDG generation is (notionally) a forward engineering process.  I do reverse engineer some of the existing MDG elements but only for  the purpose of designing a different MDG.  The reverse engineering, ipso facot, has to be independent of any repository.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 04, 2016, 11:02:39 am
And since Sparx EA is internally self inconsistent, the AI would end up in a padded cell screaming at the universe...

There are some that believe that any AI would be born into pain.  I think this is the show where I heard it discussed http://www.bbc.co.uk/programmes/b06wcsng 
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 05, 2016, 11:00:54 pm

Quote
And please don't tell me again to follow the online help because I have and is rubish.

Well I have to disagree. I've found online help very useful when creating an MDG. I've managed to successfully extend ArchiMate MDG. The online help for Sparx EA is head and shoulders above other tools I've used in this space.
Let's start with this and test the process step-by-step with a simple example, the goal of this example is to extend UML:

Step 1) Step one create a project called SimpleUMLTest using Core Modelling/UML 2/Class
Step 2) Leave the project unchanged
Step 3) Whit this project open, from the Tools menu choose MDG technology file
Step 4) On 2nd screen Use an MTS file choose don't use an MTS file at all for the creation of this technology
Step 5)
i - Enter the following; Documentation ID="Sue" Technology ="SimpleUMLExtension" Version="0.5" Notes="Simple UML Extension"
ii - When choosing a file name create a folder called SimpleUMLExtension, and name the file SimpleUMLExtension.xml
Step 6) Under Metamodel just tick Profiles
Step 7) Next screen appears blank, so I leave it blank
Step 8) Choose next and EA starts generating the MDG Technology file
Step 9) Look into SimpleUMLExtension folder, there is only one file there, it is called SimpleUMLExtension.xml and look like

Code: [Select]
  <?xml version="1.0" encoding="windows-1252" ?>
- <MDG.Technology version="1.0">
  <Documentation id="Sue" name="SimpleUMLExtension" version="0.5" notes="Simple UML Extension" />
  </MDG.Technology>

Have I a miss something? If so, what? Where have I gone wrong?

Once we sort that out, we can try more complicated things; in particular, working around EA self inconsistency, which I presume is playing a factor.

P.S.: I tried http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/umlprofiles_2.html that and it works.
P.S. 2: No need for AI at all, hopefully everybody in the forum can do NI
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 05, 2016, 11:30:04 pm
Step1 is where you have an issue.

You have to model the metamodel (e.g. stereotypes extending metaclasses)
Start reading here: http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/createprofile.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/createprofile.html)
(also notice the learning centre reference)

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 05, 2016, 11:39:49 pm
(also notice the learning centre reference)
LOL

Step1 is where you have an issue.

You have to model the metamodel (e.g. stereotypes extending metaclasses)
Start reading here: http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/createprofile.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/createprofile.html)
So, you are saying that the 1st step is to create profile package needs to be created. Correct?
Title: Re: Developing a meta model and aplying it to an existing project
Post by: qwerty on April 05, 2016, 11:48:30 pm
The steps you list do not seem to make any sense in creating a MDG.

q.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 06, 2016, 12:49:54 am
The steps you list do not seem to make any sense in creating a MDG.

q.
Step1 is where you have an issue.

You have to model the metamodel (e.g. stereotypes extending metaclasses)
Start reading here: http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/createprofile.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/createprofile.html)
So, you are saying that the 1st step is to create profile package needs to be created. Correct?
Gentlemen,

With all my due respects, I think that some contributors  might have missed a trick with the original question.

If, as I expect, I have to start by creating a Profile Package, thanks to Geert who as usual might have just hit the nail on the head, the only way I can do that is by creating a profile package inside a Model.

This is likely to mean that if I have a complex project containing various models all using different customised profiles within the same root node, I need to create a profile package for each customised profile.

In other words, if I have the following structure

Root node
-----Model 1 - Customised BPMN 2.0
-----Model 2 - Customised UML 2.0
-----Model 3 - Customised Oracle Data Model
-----Model 4 - Customised PostGRES Data Model

I need to create 4 package profiles, one per model and not one package profile. This is, of course, assuming that I can customised the data models.

Once I have done that, I am assuming that I can Generate an MDG Technology file including the 4 customised profiles.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: qwerty on April 06, 2016, 01:09:08 am
I give up here. wrt your original question I can not see what your issue is. Maybe you should do the same and start over with a new thread and a clear question.

q.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 06, 2016, 01:17:55 am
I give up here. wrt your original question I can not see what your issue is. Maybe you should do the same and start over with a new thread and a clear question.

q.
The questions we have arrived to cannot be clearer:

1) Do I have to start the process of creating an MDG file by creating a package profile on an existing model?
2) If I am using more than one profile in my project/programme and want to customise all, do I need to create a package profile for each profile I want to use?

Based on Geert's last contribution I think the answer is Yes to both.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: qwerty on April 06, 2016, 01:50:28 am
If you need multiple profiles, create one package or diagram for each.

(The need for multiple profiles as such is rare.)

q.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 06, 2016, 02:17:29 am
(The need for multiple profiles as such is rare.)
Have you ever done Enterprise Architecture with just 1 profile? I haven't.

Unless you buy the TOGAF MDG or Zachman Framework MDG you need more than one profile and I will even go futher and argue that you need more than 1 profile even with both of them as physical data modelling is not covered by any of them.

For me, the whole point of using EA is that it can use many profiles within the same root node.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 06, 2016, 02:19:25 am
(also notice the learning centre reference)
LOL
I don't the the humor here. The learning center topic is an excellent step by step instruction on how to create a UML profile.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: qwerty on April 06, 2016, 04:41:17 am
For me, the whole point of using EA is that it can use many profiles within the same root node.
if you say so.

q.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 06, 2016, 06:55:58 am
1) Do I have to start the process of creating an MDG file by creating a package profile on an existing model?

No.  I recommend you start with a separate EAP file with nothing in it and use the wizard to create you the basic MDG structure.

Quote from: Modesto Vega
2) If I am using more than one profile in my project/programme and want to customise all, do I need to create a package profile for each
profile I want to use?

Each profile is saved as a separate file, as is the diagram extensions, and each set of toolboxes.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 06, 2016, 10:20:14 pm
1) Do I have to start the process of creating an MDG file by creating a package profile on an existing model?

No.  I recommend you start with a separate EAP file with nothing in it and use the wizard to create you the basic MDG structure.

Quote from: Modesto Vega
2) If I am using more than one profile in my project/programme and want to customise all, do I need to create a package profile for each
profile I want to use?

Each profile is saved as a separate file, as is the diagram extensions, and each set of toolboxes.
Thanks Glassboy this clearly answers both questions and the answer is really much appreciated. This essentially means that to do what we have in mind I need 4 or 5 profiles, which is more of less what I have being suspecting all the way through this thread.

1) a profile for a customised domain model,
2) a profile for a customised class model,
3) a profile for a customised component model,
4) a profile for a customised data model,
5) possibly a profile for a customised use case model.

4) assumes that any model with a <<DataModel>> stererotype uses the Data Modelling profile. Anybody can confirm this?

Together with any profiles for custom diagrams, and toolboxes, developing the metamodel we have in mind becomes a project in its own.


Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 06, 2016, 11:28:34 pm
You can in fact choose for yourself if you want to create one large profile with all stereotypes you will ever need, or several smaller ones.

MDG allows to add more then one profile in an MDG file.

I'm not sure what the «DataModel» stereotype is you are referencing.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 07, 2016, 06:46:19 am
Thanks Glassboy this clearly answers both questions and the answer is really much appreciated. This essentially means that to do what we have in mind I need 4 or 5 profiles, which is more of less what I have being suspecting all the way through this thread.

As Geert said, it's up to you.  Making some assumptions about what you're saying tho' I think you actually want one profile and several different diagram types.

Quote from: Modesto Vega
4) assumes that any model with a <<DataModel>> stererotype uses the Data Modelling profile. Anybody can confirm this?

I also don't know what you're referring to here.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 07, 2016, 10:01:36 am
We've taken the route of a single large MDG.  We're aggregating a small number of (previously) distinct MDGs into one, integrated and coherent MDG.

As I've said previously (elsewhere in the forum), we're doing this, while "in flight" so it's a case of (manly) small steps.

We're finding that having one place to find issues and to make common changes make it easier.

I think Modesto in his «DataModel» question is (as is often the case) confusing model with diagram.  He's actually asking: "Does that mean a «DataModel» diagram uses the Data Modelling MDG?"

If that's the question, then it's still (potentially) the wrong question (or at least asked in the wrong way) - but the answer (or at least the explanation of how MDGs work) requires Modesto to confirm that the question as I've outlined above is the question he's asking.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 07, 2016, 10:07:56 am
As I've said previously (elsewhere in the forum), we're doing this, while "in flight" so it's a case of (manly) small steps.

Captain Arthur Phillip is a much older cultural reference than your norm :-)
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 07, 2016, 05:10:47 pm
As I've said previously (elsewhere in the forum), we're doing this, while "in flight" so it's a case of (manly) small steps.

Captain Arthur Phillip is a much older cultural reference than your norm :-)
Well Caught!  :-[

But, I DO like to think my steps ion this case are still manly...  :-X

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 07, 2016, 10:11:31 pm
Thanks for replies.

Regarding
I think Modesto in his «DataModel» question is (as is often the case) confusing model with diagram.  He's actually asking: "Does that mean a «DataModel» diagram uses the Data Modelling MDG?"
<<DataModel>> is a model stereotype. It does not relate to a diagram, to confuse matters. To reproduce follow these steps:

Using the wizard create a model using Database as the Technology and pick anything under Database Engineering. This will create a model with an stereotype of <<DataModel>>, inside 2 packages are created one called 'Logical Data Model' with no sterortype and another with <<Database>> as the stereotype for the pacakge.

Are you saying this is created using a Data Modelling MDG, presumably Database Engineering and/or Entity Relationship Diagram (see Extensions\MDG Technologies)? I so, is there a way of customising this MDG?
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 07, 2016, 11:00:26 pm
You can create your own stereotypes deriving from existing MDG stereotypes.
The procedure is described here: http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/non-uml_metatypes.html (http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/non-uml_metatypes.html)

Not sure if this applies to «DataModel»

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 08, 2016, 07:01:20 am
<<DataModel>> is a model stereotype. It does not relate to a diagram, to confuse matters. To reproduce follow these steps:

Using the wizard create a model using Database as the Technology and pick anything under Database Engineering. This will create a model with an stereotype of <<DataModel>>, inside 2 packages are created one called 'Logical Data Model' with no sterortype and another with <<Database>> as the stereotype for the pacakge.

Are you saying this is created using a Data Modelling MDG, presumably Database Engineering and/or Entity Relationship Diagram (see Extensions\MDG Technologies)? I so, is there a way of customising this MDG?

Ok, what you're seeing is the Database Engineering MDG, the models you can create from the wizard are all in the ModelPatterns directory prefixed with "dm".  I would not start your journey with MDGs by trying to extend any of included MDGs.  Start with something simple.

I've never actually used those wizards before and I experience a moment of nerd rage when  saw that the logical models toolbox includes tables.  Tables are a physical construct and are not a lofical artefact. 
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 08, 2016, 10:17:52 am
[SNIP]

I've never actually used those wizards before and I experience a moment of nerd rage when  saw that the logical models toolbox includes tables.  Tables are a physical construct and are not a logical artefact.
Elsewhere I noted that I've come to the view that there is actually no such thing as a logical model - there's only conceptual and physical, if you have a "three layer framework: (Conceptual, Logical, Physical)".  If you have a two layer framework: (Logical, Physical), the term logical is a proxy for Conceptual.

Maybe we nerds should start a separate discussion on this.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 08, 2016, 12:01:54 pm
Funnily enough, I'm currently putting together a solution design template where I'm illustrating the data model with examples.  The approach I have taken is the conceptual model is a semantic model that describes the entities and their relationship to each other

(https://www.dropbox.com/s/dgtf5ccphe4kt5h/example%20conceptual%20data%20model.png?dl=1)

the logical describes the attributes each has

(https://www.dropbox.com/s/zx38o3orvhvceb3/example%20logical%20data%20model.png?dl=1)

and the physical is how you represent this in your DBMS technology

(https://www.dropbox.com/s/8d0ry9nkfxx68nq/example%20physical%20data%20model.png?dl=1)
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 08, 2016, 04:00:29 pm
Paolo,

I'm with Glassboy on this one.
I'm a firm believer of the Conceptual/Logical/Physical approach.

In the past I've used UML InformationItem's for the Conceptual model, mainly because these don't allow to add attributes, and they can be "conveyed" on information flows.
We also didn't allow associations in the Conceptual data model. Only Taxonomy (Generalization) was allowed.

If you don't have rules like that you risk your Conceptual model to become too detailed and ending up as a logical model.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 08, 2016, 05:47:04 pm
We used the ISO11179 approach.  Conceptual level objects (ArchiMate Business Data Objects) have Characteristics.  These are conceptual level attributes - you decide whether or not to show them using the usual mechanisms.  We took to heart the old UML injunction "a named association End IS an attribute" - so allowing relationships, but not attributes is non-sense.  The often quoted dictum that "Business level Objects have no attributes" is also spurious.  The correct dictum is that the attributes exist, it's just that in most viewpoints (diagrams) we're not interested in seeing them.

In our framework, we distinguish between Applications (conceptual things) - Human Resources Management System and Products (physical things) that realise the application (such as ALESCO or SAP-HR).

Applications require tailored views of the business objects and they link to physical products with physical artifacts from which you can derive the linkage between conceptual level  application view and the physical implementation in one or more physical products.

So far, we have avoided the need to create a logical model with primitive datatypes.

Using the ISO11179 approach, we establish a conceptual (value) domain for the characteristic values.  The Application (remember conceptual here) uses the same characteristics.  When we select a product  to embody that application we model the physical value domains and map them to the conceptual value domains.  Because you can have multiple data elements for the same data element concept in ISO11179, we can map the same data element concept to each of its instantiations in each physical product.

The proof of the pudding will be in the eating, but since I came to the conclusion that the Logical Model was a chimera I (and) many others had unthinkingly accepted without challenge (some 3 years ago); I haven't used a logical model at all.  Indeed, disposing of the concept (pun intended - Glassboy!) has helped clarify my thinking on the problem of how to architect enterprises and the processes and systems that drive them.

We believe that using Characteristics we will be better able to find instances of the same object but under different names.  This is the bane of Enterprise Architecture.  Our objective is to creare the canonical model and the derived viewpoints thereof.

NOTE: as an afterthought; if you DON'T separate the (conceptual) application from the (physical) product, you get sucked into having to create some intermediate model.  But once you make the distinction, the (spurious) intermediate model problem goes away.

"Fightin' words, I know!" - but it's Friday afternoon and I thought I'd" set the cat among the pigeons".  BTW: I'm a cat lover...  :D

Let battle commence!

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 08, 2016, 07:55:51 pm
Just to clarify further what we are trying to do. We are trying to put an MDG together that covers the following:

1) Enterprise Data Architecture - covers both Abstract/Conceptual and Logical (can explain the difference if required) it has 3 levels

1.1) Subject Area Model - currently customised stereotype of Activity
[Note: I am still unclear to which part of Core UML Modelling Activity belongs to]

1.2) Domain Model - currently domain, not customised (can also explain why we are doing this if needed)

1.3) Conceptual Data Model - currently customised stereotype of Class

1.4) Logical Data Model (at the enterprise level) - undecided

2) Application Architecture

2.1) Logical data models for each application using Database Engineering

2.2) Physical data models for each application using Database Engineering although we want to customise this to better represent functional partitioning by scheme

In addition, for reference only we might want to something related to Application Architecture using non-customised Component models, and something about Requirements and Actors.
Like Paolo we have an in-flight project and some customisation has been made by manually adding UML stereotypes using Project/Settings/UML Types; hence the question about “reverse engineering” a project, well really repository. 
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 11, 2016, 07:07:50 am
We used the ISO11179 approach.  Conceptual level objects (ArchiMate Business Data Objects) have Characteristics.  These are conceptual level attributes - you decide whether or not to show them using the usual mechanisms.  We took to heart the old UML injunction "a named association End IS an attribute" - so allowing relationships, but not attributes is non-sense.  The often quoted dictum that "Business level Objects have no attributes" is also spurious.  The correct dictum is that the attributes exist, it's just that in most viewpoints (diagrams) we're not interested in seeing them.

I'm not sure we are that far apart.  I don't want attributes displayed at the conceptual level, and I don't want to render abstractions (and the like) at the logical layer.  The conceptual view point is for discussions with the business and architectural governance fora, the logical level is for discussions with developers and dbas.  They could be the same elements in the repository underneath.

Having a conceptual view also keeps those people who should be doing something else - aka managers, enterprise architects - from rummaging around too deep in a design and bestowing you with their wisdom.

Also from the point of view of managing and mentoring architects I want to be able to see that they have got the concepts right before they start working on the detail.  It has the pay off of meaning less rework and fewer review cycles.



Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 11, 2016, 09:31:14 am
We used the ISO11179 approach.  Conceptual level objects (ArchiMate Business Data Objects) have Characteristics.  These are conceptual level attributes - you decide whether or not to show them using the usual mechanisms.  We took to heart the old UML injunction "a named association End IS an attribute" - so allowing relationships, but not attributes is non-sense.  The often quoted dictum that "Business level Objects have no attributes" is also spurious.  The correct dictum is that the attributes exist, it's just that in most viewpoints (diagrams) we're not interested in seeing them.

I'm not sure we are that far apart.  I don't want attributes displayed at the conceptual level, and I don't want to render abstractions (and the like) at the logical layer.  The conceptual view point is for discussions with the business and architectural governance fora, the logical level is for discussions with developers and dbas.  They could be the same elements in the repository underneath.

Having a conceptual view also keeps those people who should be doing something else - aka managers, enterprise architects - from rummaging around too deep in a design and bestowing you with their wisdom.

Also from the point of view of managing and mentoring architects I want to be able to see that they have got the concepts right before they start working on the detail.  It has the pay off of meaning less rework and fewer review cycles.
Sounds like it...  ;D

In practice, most users just use the items without the detail, secure in the knowledge that if they want to "delve deeper", the information would be there.  Our items are (fairly) rigorously defined, both narratively and structurally; both views, of course, consistent.

Only Modelling Architects (like myself) charged with ensuring the repository holds a usable and falsifiable abstractions of reality worry about the detail and level thereof.

What did you think about my assertion that the Logical Model wasn't necessary?  Remember, in our model, the characteristics aren't simple types, they are semantic types (which when realised in a physical product -may be held in basic types).  When discussing with developers and DBAs, if the product has already been identified, we use the mapping from the conceptual to the physical.  If the product is still unknown, we use the detailed view of the conceptual.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 11, 2016, 10:01:05 am
What did you think about my assertion that the Logical Model wasn't necessary?  Remember, in our model, the characteristics aren't simple types, they are semantic types (which when realised in a physical product) my be held in basic types.  When discussing with developers and DBAs, if the product has already been identified, we use the mapping from the conceptual to the physical.  If the product is still unknown, we use the detailed view of the conceptual.

One of my biggest achievements last week was getting a project team to admit that building stuff before we had any design or functional specification may lead to problems.  Both levels of modelling are necessary for me to drive a more mature environment.  It sounds like your output is a product, and so you can collapse together the conceptual and logical.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 11, 2016, 02:27:58 pm
What did you think about my assertion that the Logical Model wasn't necessary?  Remember, in our model, the characteristics aren't simple types, they are semantic types (which when realised in a physical product) my be held in basic types.  When discussing with developers and DBAs, if the product has already been identified, we use the mapping from the conceptual to the physical.  If the product is still unknown, we use the detailed view of the conceptual.

One of my biggest achievements last week was getting a project team to admit that building stuff before we had any design or functional specification may lead to problems.  Both levels of modelling are necessary for me to drive a more mature environment.  It sounds like your output is a product, and so you can collapse together the conceptual and logical.
I congratulate you!  (And I'm not undervaluing the achievement!)

While most of the time, I'm integrating COTS products, I don't think that invalidates my assertion.  The (in ArchiMate terms) Application view is a specific subset of conceptual items (at the appropriate level of detail) until the design team have decided how these things will be realised into a physical system (product).  At that point you're designing physical artifacts which are part of the physical model.  There will be a one to many relationship between the conceptual and the physical, depending upon various factors.  Each "product' gets its own model of how it's realising the applicable part of the conceptual.

Like with the conceptual model,  you can start the physical modelling with just the items (sans detail) and then add details as required.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Geert Bellekens on April 11, 2016, 04:46:51 pm
Paolo,

Here are some of the reasons/differences between our conceptual data model and logical data model

Conceptual:
 - Managed by business analysts
 - Models things/concepts in the real world as they are know by the business, regardless of later automation
 - Focusses only only on the definitions, not on any relations or attributes. Only taxonomy (Generalization) is allowed.

Logical
 - Managed by functional analysts
 - Models those things that will be automated.
 - Models the complete details with associations, attributes and the likes.
 - Takes functional patterns into account (such as versioning, history, ...)
 - Can be translated easily to the physical world (code, database, xml schema's,)

One of the main reasons we have two separate models is because the models are managed by different teams. If it were the same team we might be able to get away with a merged Conceptual/Logical model, but I think that would be a shame.

Having the model separate allows us to focus on different aspects while modeling. In the conceptual model we really only need to worry about the concepts and their meaning to the business, without worrying about IT concerns.

Geert
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 11, 2016, 05:48:15 pm
Thanks for that Geert,

I don't disagree with the points you are making, but the question I'm asking is: Are the two models two different levels of models or two models at the same level that need to be separate, but linked, for reasons other than the level of the model.

The points you make about functional patterns can be interpreted as: I need to keep history and versioning at a conceptual level, which may, on occasion, need to be surfaced to the business.

We have multiple models of the same piece of reality as each project needs it's view of reality, but said view needs to be related to the other views.

They aren't at different levels of model, just different but related models at the same level.

I believe I can describe/interpret - every concept (again, pun intended) in the Classic "Logical Model" as either a view of the Conceptual Level Model or a view of the Physical Level Model.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 11, 2016, 11:16:40 pm

Conceptual:
 - Managed by business analysts
 - Models things/concepts in the real world as they are know by the business, regardless of later automation
 - Focusses only only on the definitions, not on any relations or attributes. Only taxonomy (Generalization) is allowed.

I would add Association to Generalisation, at least from a data point of view. If you are building an ontology, you need associations.

In utopia, business analysts should drive this but it is rarely the case. Typically I same seen this driven by a Business Architect or Data Architect or modeller with a business outlook.

Are the two models two different levels of models or two models at the same level that need to be separate, but linked, for reasons other than the level of the model.
I see them as 2 linked views of the same model. Furthermore, I will go as far as arguing that they have to be linked all the way down to physical level to map what I would described as the architectural continuum.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 12, 2016, 09:46:17 am

Conceptual:
 - Managed by business analysts
 - Models things/concepts in the real world as they are know by the business, regardless of later automation
 - Focusses only only on the definitions, not on any relations or attributes. Only taxonomy (Generalization) is allowed.

I would add Association to Generalisation, at least from a data point of view. If you are building an ontology, you need associations.

In utopia, business analysts should drive this but it is rarely the case. Typically I same seen this driven by a Business Architect or Data Architect or modeller with a business outlook.

Are the two models two different levels of models or two models at the same level that need to be separate, but linked, for reasons other than the level of the model.
I see them as 2 linked views of the same model. Furthermore, I will go as far as arguing that they have to be linked all the way down to physical level to map what I would described as the architectural continuum.
Hi Modesto,
I want to be clear, the Conceptual Level Model (I'm talking about) is NOT a Ontology.  In our case we have a separate Ontological Model.  The Conceptual View is the model of the real world.  It took me a decade of thinking and experimenting to finally "get it".  That the OTM and the the CIM were not the same thing.  They are INTIMATELY related, of course, but they aren't the same thing.

As to your second comment - I'm on the same page.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 13, 2016, 09:29:14 am
I want to be clear, the Conceptual Level Model (I'm talking about) is NOT a Ontology.  In our case we have a separate Ontological Model.  The Conceptual View is the model of the real world.  It took me a decade of thinking and experimenting to finally "get it".  That the OTM and the the CIM were not the same thing.  They are INTIMATELY related, of course, but they aren't the same thing.

In most designs I'm looking for the conceptual model to be a Ontology-lite or an upper level domain model.  Most architects employed on projects are contractors and have to learn the business domain they're working in, often with no subject matter experts to draw upon for support.  The architectural governance process needs to include a method of determining whether the architect truly understands the business domain.  Having a conceptual model expressed before the logical model is part of this process.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 13, 2016, 09:44:08 am
I want to be clear, the Conceptual Level Model (I'm talking about) is NOT a Ontology.  In our case we have a separate Ontological Model.  The Conceptual View is the model of the real world.  It took me a decade of thinking and experimenting to finally "get it".  That the OTM and the the CIM were not the same thing.  They are INTIMATELY related, of course, but they aren't the same thing.

In most designs I'm looking for the conceptual model to be a Ontology-lite or an upper level domain model.  Most architects employed on projects are contractors and have to learn the business domain they're working in, often with no subject matter experts to draw upon for support.  The architectural governance process needs to include a method of determining whether the architect truly understands the business domain.  Having a conceptual model expressed before the logical model is part of this process.
Just to make sure I understand,  your conceptual model is a set of (say ArchiMate) Business Objects?  Or is it a set of concepts?   If it's Business Objects, then I've found it can't be an Ontology (even lite) because an Ontology has relationship metatypes which are invalid for a Conceptual model of the real world.  The ontology informs the Conceptual Model but it isn't one.  As I said, it took me over a decade to get it.

ArchiMate (your nemesis  ;)) has the Meaning element which, in theory, could be used to hold the Ontological stuff.  We decided we needed a real onto-terminological model - so we don't use the Meaning Element.  We DID however, "pinch" the cloud shape for our Concept Element.  ;D

So, is your Conceptual Model objects or concepts - or something else?

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 13, 2016, 11:01:19 am
It could be a DFD-0 or a TOGAF solution overview or the Archimate introductory viewpoint.  Personally I favour DFDs and UML class models because they lend themselves better to other activities like OWASP application threat modelling.  You also can't take a knowledge model like BMM or EBMM, or any of the security frameworks and express it in Archimate.

There isn't really anything else you can do with a good Archimate model.  So in the end practising Archimate is just self-abuse.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 13, 2016, 11:19:54 am
Thanks, I think that clarifies things a bit for me.

I guess, ultimately, one could say I agree with you on ArchiMate.  We only really use it as a jumping off point to a more holistic modelling environment that encompasses some of the points you made - for example we're extending into BMM (and maybe EBMM).

Part of its utility for us is that more people "speak it" - though often not very well.  We provide them with a "Controlled Vocabulary" that leverages their language skills to produce more rigorous models.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 13, 2016, 10:18:33 pm
There is a risk of confusing 2 things:

1) what an ontology is
2) the languages created by standard makers to express ontologies

I don't particularly enjoy quoting Wikipedia, but the following is a good definition and saves me having to consult my Kindle: “An ontology is a formal naming and definition of the types, properties, and interrelationships of the entities that really or fundamentally exist for a particular domain of discourse”.

An ontology is essentially a controlled vocabulary describing a particular business domain and the interrelationships between item in the vocabulary. The interrelationships are not just generalizations, which in this case are really types; there are also associations and information flows. With regards to the later, a Delivery happens after Payment, and Payment happens after Purchase.

MOF, OWL, ArchiMate and IDEF5 are all languages that could be used to express ontologies. However, a class UML diagram can also be used to express an ontology.
Ontologies are not the languages used to express them. The languages are the means to an end, expressing an ontology.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 14, 2016, 07:07:48 am
MOF, OWL, ArchiMate and IDEF5 are all languages that could be used to express ontologies. However, a class UML diagram can also be used to express an ontology.
Ontologies are not the languages used to express them. The languages are the means to an end, expressing an ontology.

I'd love to see you try and model a disjoint in Archimate :-)
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 14, 2016, 07:34:20 am
I guess, ultimately, one could say I agree with you on ArchiMate.  We only really use it as a jumping off point to a more holistic modelling environment that encompasses some of the points you made - for example we're extending into BMM (and maybe EBMM).

Part of its utility for us is that more people "speak it" - though often not very well.  We provide them with a "Controlled Vocabulary" that leverages their language skills to produce more rigorous models.

The thing I notice about the LinkedIn Archimate forums is that that the majority of the answers given to people are wrong.  At a fundamental level, people don't understand the difference between behaviour and structure.  I'm not sure why it's always the first differentiation I make.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 14, 2016, 10:51:12 am
I guess, ultimately, one could say I agree with you on ArchiMate.  We only really use it as a jumping off point to a more holistic modelling environment that encompasses some of the points you made - for example we're extending into BMM (and maybe EBMM).

Part of its utility for us is that more people "speak it" - though often not very well.  We provide them with a "Controlled Vocabulary" that leverages their language skills to produce more rigorous models.

The thing I notice about the LinkedIn Archimate forums is that that the majority of the answers given to people are wrong.  At a fundamental level, people don't understand the difference between behaviour and structure.  I'm not sure why it's always the first differentiation I make.
My experience is that most people who "model' see it as a burden.  Consequently, they don't go to the trouble of attempting to understand the fundamentals.  That having been said, we're both of the view that ArchiMate is deficient; so maybe coming to that conclusion is the fundamental understanding required.  Once you've arrived there, you can more properly advise on where ArchiMate is not deficient.

Personally, I view learning ArchiMate as like learning Latin (or Ancient Greek - of which I did both), it helps me better to understand and use my own language (principally English).  If I use (and I often do) use terms that are derived from Latin or Greek, then I better understand how to use them properly in English.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Glassboy on April 14, 2016, 12:32:28 pm
Personally, I view learning ArchiMate as like learning Latin (or Ancient Greek - of which I did both), it helps me better to understand and use my own language (principally English).  If I use (and I often do) use terms that are derived from Latin or Greek, then I better understand how to use them properly in English.

I'd like to agree, but I can't.  Many of the element names appear to be cognates for real world or even TOGAF or UML concepts but aren't.  How exactly does an application service or an infrastructure service tell us about the real world?

What I do find useful about modelling in Archimate is that it allows me to find an incomplete model.  Mind you that being said I've never seen anyone join up a top-down model with a bottom-up model without it all falling apart badly in the application layer.
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Paolo F Cantoni on April 14, 2016, 02:12:11 pm
[SNIP]
Many of the element names appear to be cognates for real world or even TOGAF or UML concepts but aren't.
I agree this is a BIG problem.  Maybe we need the equivalent of Fowler's "Usage and abusage"?

Quote
How exactly does an application service or an infrastructure service tell us about the real world?
As I mentioned previously, the answer depends on your definition of Application.  By separating out the (conceptual) Application from the (physical) product you can relate the application side to the real world better.  Once you've got a real product, the infrastructure service tells you about how the product will REALLY interact with the other products.

Quote
What I do find useful about modelling in ArchiMate is that it allows me to find an incomplete model.  Mind you that being said I've never seen anyone join up a top-down model with a bottom-up model without it all falling apart badly in the application layer.
This is true...  I hope to be the first to sort this out.  ;)  It will require adjustments on both sides, but it must be possible since it really happens...  Wish me luck!

But you can't do it with standard ArchiMate.

Paolo
Title: Re: Developing a meta model and aplying it to an existing project
Post by: Modesto Vega on April 15, 2016, 09:33:26 pm
MOF, OWL, ArchiMate and IDEF5 are all languages that could be used to express ontologies. However, a class UML diagram can also be used to express an ontology.
Ontologies are not the languages used to express them. The languages are the means to an end, expressing an ontology.

I'd love to see you try and model a disjoint in Archimate :-)
You don't  ;)

I seem to have made a profession of modelling disjoints. Keep in mind disjoints are hindsight, while a well joined architecture is foresight. The difference between hindsight and foresight:  hindsight happens after the event, foresight before.

Disjointed architectures are architectures that already exist, they are not new designs. This is approaching the edge of consistency, similar to approaching the edge of chaos.

By the way the whole point of this thread was to understand what is involved in putting together an MDG to model disjoints. IMHO, you cannot model a disjoint using just one language, which in Sparkish, means multiple profiles.