Developing a meta model and aplying it to an existing project

[Geert Bellekens]

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

Not sure if this applies to «DataModel»

Geert

[Glassboy]

<<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. 

[Paolo F Cantoni]

[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

[Glassboy]

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



the logical describes the attributes each has



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

[Geert Bellekens]

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

[Paolo F Cantoni]

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... 

Let battle commence!

Paolo

[Modesto Vega]

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. 

[Glassboy]

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.

[Paolo F Cantoni]

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... 

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

[Glassboy]

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.

[Paolo F Cantoni]

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

[Geert Bellekens]

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

[Paolo F Cantoni]

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

[Modesto Vega]

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.

[Paolo F Cantoni]

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