Archi plugin/extension or complementary tool for detailed Data modeling ?

Started by rchevallier, March 20, 2018, 11:10:47 AM

Previous topic - Next topic

rchevallier

Archi (and archimate) is a great tool for EA modeling

However you cannot detail much the Business Object and Data Object with attributes, types, etc... to build conceptual/logical and maybe even physical data model linked to these concepts

Is there any plugin/extension available to do that? or another data modeling tool you recommend which import the Data Objects ? (Ideally open source and free but unfortunately good tools are rarely free, except Archi!)

Jean-Baptiste Sarrodie

Hi,

Quote from: rchevallier on March 20, 2018, 11:10:47 AM
However you cannot detail much the Business Object and Data Object with attributes, types, etc... to build conceptual/logical and maybe even physical data model linked to these concepts

You can add properties on each and every concept (element and attribute) in Archimate (and thus in Archi). Those are basic key/value pairs, so what is commonly done is to use the keys for Business/Data Object attributes names, and values for the meaning/description of those attributes.

The only real limitation is for multiplicity/cardinality, but to some extends, you can also use the semantic of some standard ArchiMate relationships like:

  • Specialization: which should be understood in fact as inheritage/generalization (the relationship should be read as "something is-a-specialization-of something-else")
  • Composition: should be used to depict a 1-N relation (ArchiMate states that an element can be composed by only one other element)
  • Aggregation: can be used to depict N-N relations when some concept "groups" other concepts
  • Association: can be use for other (often semantic only) relations.

For the moment there is no plugins for this specific purpose, but I often solve those issues by positionning connection's label on a known end (eg. the target) and using a label convention like "1 > 1..N" to show multiplicity.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

rchevallier

Thanks for the hint

The only limitation I see in this case is you don't see the detailed fields in the diagrams (or export/report diagrams) which would be a compact way to represent the information, you got the attribute list only in the properties pane. Or do I miss something ?

-R

JanC

This post consists of some interesting idea's. Using the label is certainly a good hint, something I did use myself. What I see though as a challenge is twofold
1) Having a diagram   A --- 1-n --- B  kind of implies that A has cardinality 1, but if you move B left of A the label will still read 1-n, thus   B --- 1-n --- A. Using 'target' does adres this issue to some extend, but you still have to be quite careful when drawing
2) One does not always want to show the label. In my experience you only need the cardinality sometimes

So I started to dig a little into the ArchiMate object model and did unfortunately not find a general solution. But as a relation can have properties one could create a specific solution using two properties such as SourceCardinality and TargetCardinality. I have not yet fully examined this approach, but have a fear that knowing what is source and what is target could be somewhat of a challenge. In particular I tend to prefer the Association relation, the Aggregation and Composition relations feel not always being appropriate. While the source/target problem can be managed, more challenging it seems to get this cardinality data now put into the model again out onto paper. I am using Jasper for this and are quite happy with the abilities to create custom reports. For this though I would not want to have all relations being printed at the end of the report. I would like to have that part of the view. A first look into the sources revealed though that you cannot retrieve the relations shown on a specific view.

Phil Beauvoir

Quote from: JanC on August 16, 2019, 18:12:05 PM
I would like to have that part of the view. A first look into the sources revealed though that you cannot retrieve the relations shown on a specific view.

If you mean to query all relations that are members of a View, then this will be added as a Jasper DataSource in the next version. See https://github.com/archimatetool/archi/issues/510#issuecomment-519843074
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

michel.wicky

The problem I see by using properties in an object/concept is that properties are a inside the object. Composed or elementary definition may not be reusable easily except they are modelized as object/concept that seem not very convenient (but possible). Managing a Data Dictionary, by example by using the Yourdon notation may be a very convenient and useful way to solve this. What do you think ?

JanC

Michel,

can you elaborate a little what you refer to? I do not fully understand what you mean. Isn't the root cause of the challenge here that ArchiMate as language does not know of a specific context of cardinality on relation types. That said the only option (for now) I see is to use the generic ArchiMate concept of properties to model this each and everyone on their own (and indeed inside the element instead as attributes of the element).

Jan

rchevallier

What I understand, it is interesting to model:

Business Object -- aggregation --> Elementary Business Info
or
Table -- aggregation --> field

The interest of using aggregation instead of composition is that the "same" field (resp. info) can be "shared" (ie is the same thing) among  Table (resp. Business Object). So you have a network graph and not a hierarchy

Using properties means you have implicitely a composition relation. the field/info belong only to a single container. And being not first class object, you can't model anything on them (add relations to other elements)

JanC

An aggregation relation is possible in ArchiMate ... I guess the real challenge in your scenario is to choose the 'right' types between you aggregate. Is 'Elementary Business Info' a kind of Business Object? If so, you may consider sub-typing the now fairly general 'Business Object' type with a property.

rchevallier

Yes I'm exploring this option now. It is just the presentation (graphic) will be less compact compared to a "classical" database modeling table representation.

michel.wicky

Using model to manage a data dictionnary is not the way I think. Two many constraints for no added value.
A global data dictionnary may be managed separately from model using a semantic language.
I recommend yourdon semantic that allow all constructions/combinations until elementary level in a very effective way.(http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_10.)
Elementary level may be the construct for information structure, business object definition, application object definition, ...
In this way data will defined once (at elentary level) and reused in many combinations (composition a reusable also).

An other way would that the properties may not be considered at element level but managed in/from a sharable through elements data dictionnary by example.

rchevallier

Yes, for a detailed data/business dictionary an Archimate Model is not the best implementation. An implementation of a detailed data dictionary and model with Yourdon or other notation is better

However in EA, you will need to link at the business (resp. application) level other concepts to the business (resp. data) objects
So at least you need to be able to share between dictionary and ea tool the list of objects, their macro definition and the main relation between those and use them in the EA model. At high level, the Archimate language seems good enough for that.





michel.wicky

I agree that using Archimate for models is good enough but you will also need to collect the details at the same time and to assume the whole life cycle. I would like to have such data dictionnary connected in some way to my data object at every level. This is a plus of tool like Enterprise Architect or Signavio and many others. I wonder  if it is so difficult by using jArchi plugin.