ArchiMate non-icon style rendering

[Paolo F Cantoni]

Why don't all ArchiMate elements have the ability to be represented in "rectangular" notation (iconstyle=false).

Should I report it as a bug/issue?

Paolo

[Sunshine]

I think its because of the way the base UML elements work. Some of them have the rectangular notation option and some don't. The Archimate Profile stereotypes are based UML elements and thus inherits that property. So Archimate stereotypes that inherit from UML elements like activity, actor etc have the rectangular notation but those that inherit from things like classes don't.
I suspect its a functional feature rather than a bug as such.

[Paolo F Cantoni]

I think its because of the way the base UML elements work. Some of them have the rectangular notation option and some don't. The Archimate Profile stereotypes are based UML elements and thus inherits that property. So Archimate stereotypes that inherit from UML elements like activity, actor etc have the rectangular notation but those that inherit from things like classes don't.
I suspect its a functional feature rather than a bug as such.

No, "it's a bug, ".  

Since Classes ONLY have rectangular notation, it is incumbent on the specialiser to provide rectangular notation.

While, in the specialisation process one can suppress certain features, you can't do that arbitrarily, otherwise you "break" the concept of specialisation.  Rectangular notation for elements inheriting from Class is one such.

Paolo

[Eve]

Actually, ArchiMate knows nothing about (UML) classes. The support of rectangle notation for some ArchiMate types stems not from an EA implementation viewpoint, but from what notations are defined in the specification.

To illustrate the point look at Table 1 in section 3.5. It's clear that not all types in ArchiMate are intended to have a rectangle notation.

[Paolo F Cantoni]

Hi Simon,

Actually, ArchiMate knows nothing about (UML) classes. The support of rectangle notation for some ArchiMate types stems not from an EA implementation viewpoint, but from what notations are defined in the specification.

To illustrate the point look at Table 1 in section 3.5. It's clear that not all types in ArchiMate are intended to have a rectangle notation.

Archimate DOES know about UML Classes, they are mentioned several times in the ArchiMate 2.0 specification.  

Table 1 in section 3.5 shows you elements have BOTH icon and non-icon representation; which have non-icon only and which have icon only representation.  I accept that that is the ArchiMate specification.

What I didn't understand before is that the (incorrectly named - as I've mentioned in previous posts) "rectangular notation" is Sparx EA - is really "compartmental notation".  Archimate has NO notion of compartments, only icon view and non-icon view.  In neither case is there provision for any additional surfacing of the internals of the element.

I guess my point is that given that compartmental view is the only way to easily surface the contents of an element (such as notes etc);  it should be a (additional) standard rendering for ALL Sparx elements, regardless of the specification of the language.

Thoughts, anyone?
Paolo

[Eve]

I disagree. ArchiMate doesn't know about UML. The writers of the spec do, and they use examples to aid the readers' understanding but ArchiMate is self contained and doesn't describe any of the types as extending UML types or describe itself as a profile for UML.

For the same reasons, as far as ArchiMate is concerned the elements don't have the internals that come from EA and the UML types EA uses as something to apply the ArchiMate notation to. That's why you don't get the compartments. As far as ArchiMate is concerned they don't exist, and when you're using ArchiMate you are using that language.

One of the great things about EA is that you can mix and match from a lot of modeling languages. Use ArchiMate where it best represents what you want to convey, use something else when it doesn't. If there isn't a language built-in, define one yourself.

[Paolo F Cantoni]

I disagree. ArchiMate doesn't know about UML. The writers of the spec do, and they use examples to aid the readers' understanding but ArchiMate is self contained and doesn't describe any of the types as extending UML types or describe itself as a profile for UML.

Accepted...

For the same reasons, as far as ArchiMate is concerned the elements don't have the internals that come from EA and the UML types EA uses as something to apply the ArchiMate notation to. That's why you don't get the compartments. As far as ArchiMate is concerned they don't exist, and when you're using ArchiMate you are using that language.

Accepted...

One of the great things about EA is that you can mix and match from a lot of modeling languages. Use ArchiMate where it best represents what you want to convey, use something else when it doesn't. If there isn't a language built-in, define one yourself.

While I accept the two paragraphs above, it still seems to me that notwithstanding that Archimate doesn't know about compartments, EA should still provide the Compartment Notation for all its elements.

Otherwise we're back in the long multi-year discussion that eventuated in the Notes Compartment baing added.  In my view "a picture is worth a thoushand words" UNTIL there are more than 6 boxes or twelve lines on the diagram.  Then, all bets are off...

You need to be able to surface the definitions which should be captured in the Notes compartment of the elements - when there is a need to.  So that he diagram can be more meaningful.

Paolo

[Eve]

Are you saying that you want compartments for Pseudo-States or Fork nodes? It seems to me that "all" wouldn't actually provide a benefit and that many times a linked note would be more clear than expanding to a note compartment.

Regardless, now that you're talking about note display on diagrams it seems like we've actually reached the problem you're attempting to solve.

The easiest solution is to create linked notes. If you really want it inline you can extend the ArchiMate types and apply the following shape script.

Code: [Select]

shape main
{
      layouttype="border";
      DrawParentShape();
      
      AddSubShape("padding","n");
      AddSubShape("notes", "center");
      
      shape padding
      {
            preferredheight=35;
      }
      
      shape notes
      {
            h_align="center";
            if(HasProperty("notes", ""))
            {
            }
            else
            {
                  MoveTo(0,0);
                  LineTo(100,0);
                  Println("notes");
                  Print("#notes#");
            }
      }
}
If you want the actual notes left aligned you'll need to add another subshape, you may also want to include the following check.

Code: [Select]

if(hasproperty("rectanglenotation","0"))
{
      // parent shape only
}
else
{
      // shape script from above
      // or define your own shape script for types that don't define rectangle notation
}
You'll be able to use the exact same shape script for most elements. The main exception being if you use it to add rectangle notation to types that don't provide it.

[Paolo F Cantoni]

Are you saying that you want compartments for Pseudo-States or Fork nodes? It seems to me that "all" wouldn't actually provide a benefit and that many times a linked note would be more clear than expanding to a note compartment.

Here, we must agree to differ.  While I concede that the use of compartmental view for pseudo-states and forks is restricted, I already have muttered that EA doesn't allow me to easily add the annotations I may have added to pseudo states.

I don't think it's the job of the tool to impose such restrictions.  you and I may agree that compartments for forks is silly, but that doesn't mean we'tre right...

Regardless, now that you're talking about note display on diagrams it seems like we've actually reached the problem you're attempting to solve.

Well, Notes is step 1... Features is step 2.  Then...

The easiest solution is to create linked notes.

I think embedded notes is what you mean here.  Linked Notes were the separate Notes object connected by notelinks to the main shape that started the disucssion about the Notes compartment.

What your script does is embed the Notes information within the shape.

This is essentially a work-around.  Causing us users to create yet more code (indeed in multiple instances) to emulate the functionality that already exists for many other elements.

This is an example of my aphorism - "it actually takes MORE work to be inconsistent".

If you really want it inline you can extend the ArchiMate types and apply the following shape script.

[size=18][SNIP][/size]

Why not just provide Compartmental view for everything - take the Icon (if any) stick it in the top right corner and give the user access to the whole underlying element?  The default Archimate non-icon view would be Compartmental view with NO compartments.

Still, many thanks for providing the work-around, I can use it in the interim.

Paolo