Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - adepreter

Pages: 1 [2] 3 4 ... 9
If you want to define it in the MDG, isn't simple to create a different diagram type and test the diagram type in the shape script?

Here is a resulting diagram in compact view mode (name of the diagram stereotype).

These diagrams are generated automatically following diagram templates that can also include auto legends.
- All the diagrams are complete
- Saving a lot of time and money
- All the diagrams have a consistent layout

   if (hasproperty("diagram.stereotype", "Compact View"))
   else if (hasproperty("diagram.stereotype", "Undecorated View"))

Dear Sparxters,
After changing diagram types using C# code equivalent to the VB Script below...

I noticed that when I make an EXISTING element composite, the default diagram type defined in the MDG is not applied.
It works only for new elements.

Any idea what is missing in the code below to apply the diagram type changes to existing elements?

option explicit
sub MigrateDiagramsStereotype (oldType, oldStereotype, newType, newStereotype)
   Dim sql

   Repository.EnsureOutputVisible "Script"
   Repository.ClearOutput "Script"

   ' SQL SERVER SYNTAX ONLY - Cannot be translated to Access as Cast expression does not work with Access
   sql = "update t_diagram " &_
        "set Diagram_Type = '" + newType + "'" &_
        ", StyleEx = cast(replace(cast(StyleEx as nvarchar(max)), 'MDGDgm=" + oldStereotype + "', 'MDGDgm=" + newStereotype + "') as ntext) " &_
        "where " &_
        "Diagram_Type = '" + oldType + "' AND " &_
        "StyleEx like '%MDGDgm=" + oldStereotype + "%'"
   Repository.Execute (sql)
end sub

sub main
      MigrateDiagramsStereotype "Logical",   "MyDiagramPage::MyDiagramStereoyype", "Logical", ""MyNewDiagramPage::MyNewDiagramStereoype"
end sub


Did this all start from adequate requirements? And from whom?

It seems (just a guess) to start from an assumption that it is a good idea to start mixing different languages that were not designed to work together, that have different semantics, different metamodels, different terminologies etc....

For people to effectively communicate and collaborate across several disciplines, they should better speak one language, and use one tool and one repository.
Teams can use one language that does everything they need or two that are exactly complementary if they need more.
Complementary OK. But there should not be any redundancy.

Also the term "metamodel view" sounds like a mix of concepts that does no make sense to me.
What my users need is the ability to create views based on a single language metamodel.
And to be able to create views, I, the framework author, need to be able to define Viewpoints, as defined e.g. in ISO 42010:
Hopefully, that is what diagram pages are about.

--- My users' requirements and my derived requirements ----

As a professional focusing on framework, language and tool authoring, these are some of the things my customers need.
Most things I could resolve myself. But there are areas where I would like to go further, and I can't due to EA limitations, as explained below.
And these limitations persist maybe because the EA development team seems to be focusing on requirements of obscure origin leading to these unusable language mixtures.

So here are mys users requirements and my derived framework author requirements:
- Modelling elements and connectors (MDG UML profile)
- Language Metamodel covering the entire language (as in Labnaf)
- Easy-to read yet formal language metamodel expressed using the end user modeling language itself (as in Labnaf)
- Pre-conditional (preventing from) and post-conditional model validation (validate after the fact) (as in Labnaf)
- Dynamic model validation based on the language metamodel that is expressed using the end user language (as in Labnaf)
- Quicklinks generated from the language metamodel (as in Labnaf)
- Viewpoints (MDG Diagram pages)
- Toolboxes (MDG Toolbox pages)
- Filters on the available items on the toolbox (------------ HOW?)
- Filters (that can be set on and off by the end user or he administrator) on the type of connectors an elements that can appear on a specific type of diagram (------------ HOW?)

- Ability to load/import and activate an MDG any time programmatically at runtime, when EA is already running (------------ HOW?)
- Ability to programmatically (re)load quick links in memory for an active MDG (------------ HOW?)
- And finally get rid of this EA bug that removes the "From"part of quick links for each diagram page that does not have the same name as the MDG

Hi Eve,
Thank you for your explanations.

Regarding requirements:
It must be simple.
My users want one single language that merges (not "integrates") standards.
It is one MDG created from scratch.
The quick links and the validation are generated from the metamodel expressed in the single language that everybody knows and shares.
I speak English French and Dutch but I am not trying to communicate using several languages in the same sentence :-)

Regarding the hierarchy of diagram types:
I must be simple.
I implemented the "several diagram types on several diagrams" approach as explained on this page from the Sparx doc.

However there is a bug in Sparx (see ref 19072645 where I also illustrate in a Word doc the structure of diagram types): When you create a diagram on a page that has a name that is different from the name of the MDG, then the "From" part of the quick links is lost.

Do you have any work around to suggest?

Thank you,

Thank you Eve,

Is it possible to create these views without constraints on the possible element connections?
Indeed I think the view is not the right place to express metamodel constraints, except in the case where your view represents code or configuration items.

For Strategy and Enterprise Architecture you need one single metamodel applied to one single language (not one metamodel per view).
In the toolbox you need to show the usual elements and connectors.
But one should not prevent users from adding, sometimes, some additonal elements and connectors that are not usual in that kind of view.

Also it is better to implement the language metamodel using the language itself.
So it can be used both for
- Metamodel documentation
- Dynamic model validation
For example this language metamodel is used both for dynamic model validation and documentation.

In a diagram profile, how can we group/categorize existing diagram types so that they appear in a tree browser a bit like in Archimate 3?

So that, with a perspective properly set, the Add Diagram window shows for example:

- Corporate Objectives
- Domain Goals
- ...
- Organization Landscape
- ...
- Application Landscape
- Application Interactions

Is there a way to automatically replace sql select content stored in list views and charts?

The traceability window is still ignoring MDG icons and this is confusing end users.

One generic way to solve it and to allow extensions at the same time is to provide an addin event that we can use to provide the icon that we need.
The icon could then also reflect the state of any element property or tagged value.

Thank you Paolo

Users are asking for a way to enter tagged values for a set of recurrent of a very long list of tagged values (longer than the window height).
As far as EA 14.1 is concerned, the specification manager is still very cumbersome for data entry.
It is also limited to the content of a package.

If I were you, I would rather simplify by changing my root packages into sub-packages.
Here is an example of a complex root package published to HTML:

It is easy to do. Here is something I did some time ago. You will need to tune it for your specific case.

1. Create a new single target package where you want your root packages to be moved to.

2. Using SQL Server Management Studio or equivalent, run some SQL to
a) change the package type for the root packages to be moved
UPDATE t_package set PackageFlags = NULL
WHERE t_package.Package_ID in (
   SELECT  Package_ID FROM t_package
   WHERE PackageFlags like 'isModel=1%'
   AND NOT (Name = 'XXXTRANSFER' or Name = 'XXXProjects')

b) move the selected root packages into the new single target package.
UPDATE t_package set Parent_ID =  {ID OF MY SINGLE PACKAGE}
WHERE t_package.Package_ID in (
   SELECT Package_ID FROM t_package
   WHERE Parent_ID = 0

Try first on a test database :-)

For some obscure reasons, some stereotypes defined in our MDG are mysteriously added to the list of UML Stereotypes in our shared repository.

As a result, when a new element or connector of that stereotype is created, Sparx uses the one defined in the repository instead of the one defined in the MDG.
Since the signature of these 2 stereotypes are different this has various impacts on the behavior of Sparx (execution of shapescripts, model validation...).

This situation happens notably when we change the type and/or stereotype of an element or connector in our MDG and then in the model repository. In that case, Sparx sometimes adds a new duplicate stereotype in the repository.

The architecture discipline requires frequent and dynamic updates to the metamodel.
Therefore having to rebuild and redeploy the mdg for each little change (as currently implemented by Sparx) is inadequate.

Therefore we are using a language metamodel, stored in the production repository, as language constraints.
When Sparx starts, an addin loads this metamodel and dynamically builds the language constraints in memory. These prevent users from creating the wrong connectors.
The exact same language metamodel is also used as documentation.

When the metamodel is changed in the repository, the validation rules are changed instantly.

Quicklinks are also generated automatically from this metamodel.
The same validation rules can also be loaded from the quicklinks.

Pages: 1 [2] 3 4 ... 9