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

Pages: [1] 2 3
1
General Board / Re: High level vs Lower level diagrams relationships
« on: July 09, 2019, 05:10:59 am »
Let me be more specific with a simple example. I work in the banking industry where we have a Centralized CIF (Customer Information File) system/component. This system gets updated daily online (real-time) and batch by multiple system. Let's take its interaction with our Core Banking system Temenos T24. These 2 systems exchange multiple files for different purposes (client info, products, etc.) at different frequencies.

At a high level, I want to represent the 2 systems with one or 2 relationship (one for batch and one for online/realtime. At that level, there is no detail (no frequency, type of information carried, etc)

At a lower level each of the high level interface is "decomposed" one or many detailed relationships where characteristic of the relationships are detailed (frequency for batch, type of information)

@Sunshine: What you are describing pretty much match what I'm trying to do. You're proposing to use the "Association" relationship for high level diagram (that was my option 3) and more specific relationship for lower-level. The difference in what you are proposing and what we are doing (at the moment, at least) is that we don't decompose our application components into finer application components. We are not there yet.

For now I've elected to use the out-of-the-box ArchiMate Dynamic relationships for the high level and specialized version of those  (that have some extra attributes) for the lower level.

Thanks for the feedback

2
General Board / Re: High level vs Lower level diagrams relationships
« on: July 06, 2019, 01:34:26 am »
The derivation rules for dynamic relationships as explain in ArchiMate spec is not what I'm after.

I just thought of another option that would not require any work. For my lower level relationship, I have specialized the ArchiMate Flow and Triggering relationship to add extra attribute (like frequency). The higher level relationships don't need those attributes. Using the out-the-box ArchiMate Flow and Triggering relationships seems a cheap way to satisfy my basic need (different type of relationships to model high vs low level relationships). I won't have the composite "relation" between the high level ArchiMate relationship ArchiMate dervived relationships but if we limit (by process) the ArchiMate relationship between two Application Components to one the relationship will be implicit. I will give it a try.

Thanks for the feedback!

3
General Board / High level vs Lower level diagrams relationships
« on: July 06, 2019, 12:49:11 am »
I am modeling the Application Layer of the enterprise using ArchiMate. I have high level view application landscape diagram showing the main application components and some relationship between them. I have more detailed/specific view by domain that shows the actual interfaces (represented by flow and triggering relationship) between them. I see the relationships in the higher level diagram as representing all the actual relationships in the lower level diagrams.

My question is how to model this?

Currently, I'm building the higher level view from the lower level relationship. I select one of the relationship and hide the other. This is not ideal as I cannot put anything in the attribute of the relationship because it will be everywhere the relationship is used.

Here are two options I'm considering:
  • Creating a new type of relationship to represent those relationship
  • Modifying the existing relationship type by adding an attribute to flag high level vs lower lever relationship
  • Using the "Association" relationship type as it is generic

Option 1: seem to be the cleaner.
Option 2: would require less work to put in plan but would need more work to differentiate between high and low level relationship
Option 3: no work to implement but "Association" is a structural relationship when we are really in the realm of dynamic relationships and may conflict with other Association relationship relationships.

Other options I should consider or thoughts on the problem?

Ideally, it would be some kind of "composite relationship" where the higher level relationship would represent all lower level actual relationship.
These relationships may represent

4
I have submitted a bug report and Sparx quickly responded:

"As you are aware  Enterprise Architect Lite is a free and read-only edition of Enterprise Architect with limited features.
If you can solve the issue by importing the MDG  manually, please continue using the workaround."



5
UPDATE

As I mentioned in 2 related post about Lite edition. This can be solved by importing the MDG Technology containing the Custom SQL to the user of Lite installation.

I thought that importing the MDG Technology into the model in the Corporate version would make it available in the Lite version but it's not the case.

Martin

6
Just found the problem. The MDG Technology I have defined was not deployed in the Lite Version. After importing it in the Lite version, it solved the problem.

What I don't understand is that in the Corporate version, I imported the Technology to the Model. I thought it would do it for both Corporate and Lite version.

Any idea on how to avoid importing the Technology individually to each Lite user?

Thanks

7
Just found the problem. The MDG Technology I have defined was not deployed in the Lite Version. After importing it in the Lite version, it solved the problem.

What I don't understand is that in the Corporate version, I imported the Technology to the Model. I thought it would do it for both Corporate and Lite version.

Any idea on how to avoid importing the Technology individually to each Lite user?

Thanks

8
I have define a Stereotype connector extending the Archimate3::ArchiMate_Flow. My stereotype also redefines Archimate3::ArchiMate_Flow.  I added a couple of attribute to my stereotype. I did not specify any shape script for it.

In Corporate it is shown as dotted line (as it should) but in Lite version it is shown with solid line.

If I use the Archimate3::ArchiMate_Flow connector it is shown in both version with dotted line.

Is the problem with my stereotype or Lite version.

I have posted a related problem with shape script that don't work in Lite version. Again this was for a Stereotype extending/redefines ArchiMate_ApplicationComponent.

Any idea what's the problem?

9
Automation Interface, Add-Ins and Tools / Shape Scripts and EA Lite
« on: May 16, 2019, 01:27:18 am »
I wrote some shape scripts for some Element Stereotypes and included everything in a MDG Technology.

They work fine in Corporate edition but not in EA Lite. I search the forum and found discussion in 2016 where the problem was reported and Sparx Representative said:
A third option is for read-only users to use EA Lite, which allows for display only. It's a free download, but IIRC it doesn't necessarily display everything the way the full client does. Specifically, I think it doesn't do shape scripts. I may be wrong on that, and if you don't know what shape scripts are you're probably not using them so it shouldn't be a problem.

The lite version should draw using the same shape scripts as other editions of EA.

Am I missing something?
Can someone confirm the current behavior?

Martin

10
Actually, it is almost there. The Lite use can create there own Custom SQL queries. I can copy and paste the MDG Technology query into the "My Search" queries of the Lite user.

Just thought that maybe we could push the queries to their "My Search" folder because we control the package that is installed. At worst, we just make the query definitions available and the user create them.

11
Hi,

I have developed Custom SQL queries that I have included in an MDG Technology. The user of the Corporate version have access to those queries but my user of EA Lite don't.

Is there a way to make those queries available to them?

Thanks,

Martin

12
I've build a query using the Query builder. My only criteria is a match to a specific Stereotype.
In the result set some Element have "Component" and others "Application Component" but in the Element Properties Window they all have Type=ApplicationComponent.
My Stereotype inherits (generalization) from ArchiMate_Application_Component.

Can someone explain this behavior?
What is the impact of having this situation?
Is there a way to change the Type? Design-->Element-->Edit-->Change Type is not an option as it only works with basic UML Type
- Not knowing, I was planning to recreate those Elements and redo the relationships as the volume is not that large

Any other advise?

Thanks,

UPDATE
I just realized that as soon as I touch the object (e.g: change Notes field, changing tagged values did not work) its Type in the result set of the Query is updated to ApplicationComponent. I still don't understand the behavior. It is as if the Type value is duplicated and synchronized on specific actions.
Martin


13
Hi,

I am to build a report for several Archimate diagrams. I use the Document Template Designer.

Basically, I want to have the diagram followed by the Elements and their properties and finally the relationships.

In the Diagram section I have selected Element and Connector but left their definition empty.
In the Element section, I have defined what information I want to report on ({Element.Name}, {Element.Type} {Element.Stereotype}, etc.) including some tagged values
In the Connector section, I have done the same ({Connector.Name}, {Connector.Type} {Connector.Stereotype}, etc.)

To my surprise, the Element are included in the report but nothing on the connector.

Anybody can explain that?

I've tried to add fields in the Connector section inside the Diagram section with some success but couldn't include source and target Element of the relationship. "{Connector.SourceColumns}" and "{Connector.TargetColumns}" do not return anything.

I've seen a post where it was proposed to use SQL Fragment to do this.

Any thought on how to report Connector information?


Martin



14
Update:
I should have read the history of Changes and fixes for Build 1427. (https://sparxsystems.com/products/ea/history.html)

•Added option to automatically maintain the list of available users based on Windows Active Directory or OpenID groups


We are also trying to make this works. We are using version 14.0.1423 and when I look at the "Security Users" screen it doesn't match the documentation.

The documentation has more options such as:
  • Allow 'Remember Me'
  • Accept OpenID Authentification
  • Restrict access to Windows & OpenID user only
  • Automatically create or modify Windows or OpenID users

When I read the documentation, I thought that by enabling the option "Automatically create or modify Windows or OpenID users", the EA group would be kept in synch with Active Directory groups.

Unfortunately, I don't have the option so I cannot try it. Anybody has the latest version? Are these options available?

15
General Board / Re: Shape Script Stereotypes and Instances
« on: February 20, 2019, 09:09:56 am »
Actually I do both a high level diagram showing only ArchiMate type/stereotype and an instantiation of it that provide the actual implementation. The later one using instances. It's like a UML deployment diagram.

I'm happy with the high level version that falls into Enterprise Architecture scope. On the other hand, other stakeholders need the implementation version and Sparx E.A. support both rather nicely. Much better than doing it in Visio.

As per my problem with the namespace always displaying. I traced it to the shape script I wrote. The drawing methods drawparentshape and drawnativeshape behave very differently. I understand that I should be using drawparentshape as I am extending non-UML Object types. I still don't fully understand the behavior but getting closer.

Thanks all!

Pages: [1] 2 3