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

Pages: 1 2 [3] 4
updated with version details.

Hello,  I am hitting a performance/usabiltiy issue when I try to add and use an activity as an action (invocation) on an Activity Diagram.  In some scenarios EA closes unexpectedly.  In some cases EA just becomes unusable and I have to close it.

Is this a known issue? 

Version details:
Program Version: 12.0.1215 (Build:1215)

Registered Enterprise Architect (Corporate Edition)

Geert, Thank you for the response.

After a few controlled tests, I understand the rationale for the practice you shared.  It seems the protected boilerplate/instructional text changes a bit over time and use.

I'll follow the approach you mentioned.

In addition, I've found moving the checked section up/down via the arrow buttons sometimes resolves the issue. 

Thank you.

Totally missed the second option for 'Import MDG Technologoes to Model':

To be available to all users of the model, through the Resources window for the model

Followed the steps and working like a charm.

thank you.

Can someone share the recommend practice for deploying a MDG when the model is accessed via DBMS.

From the user guide, there are two methods:
  • Import MDG Technologies to Model
  • Access Remote Technologies

We have users who access the model two ways:
Method 1: Run from EA installed on local system
Method 2: Run remote desktop with EA UI launched on local system.

So I ruled out 'Import MDG Technologies to Model' as that involves a local path....and I did not want to change the EA installation used via remote desktop.

This leaves 'Access Remote Technologies'.  My observation is every user will have to apply the steps.  I just wanted to verify this was the common practice.

Updated: corrected terminology by changing MTS to MDG.

I am creating a User Template/Fragment to include a table of Tag Names & Values.

Problem is, selecting the section for 'Package/Element/Tagged Value' results in some boilerplate/instructional text that I cannot delete.

Any way to workaround this?

I am on EA 12.0.1215, Corporate Edition

General Board / Re: Book about MDG
« on: November 25, 2015, 05:01:31 pm »
I read through the sample and I think it provides helpful details I have not seen elsewhere.   So it is a good aid.

I had some initial input/ thoughts from the newbie perspective.  Once I get the full copy and give it a read I'll reach out to provide some personal input if you are interested.

General Board / Re: Significance of Root Nodes ?
« on: November 12, 2015, 04:51:06 pm »
At the view level I always place CIM/PIM/PSM and Sandbox.

Thanks for sharing, this is helpful.  This sounds like an appropriate outline for scenarios where MDA is applied.

General Board / Re: Significance of Root Nodes ?
« on: November 06, 2015, 06:17:59 pm »
My take away from EA literature is a Root/Model(s)/View(s) is a recommended practice to start with:

- Root
 + Model X
   + View A
   + View B
 + Model Y

This is supported by the following:

Models - a model is the highest conceptual level, representing a distinct and complete representation of all or some part of a modeled system.
A Project can contain multiple models.

Views are the second level within a model and define a specific viewpoint of the system being modeled - for example a Use Case view, a Requirements View or a Dynamic (behavioral) View.
Views are simply Packages that have an additional conceptual meaning.

I assume the usage of 'View' is intentionally consistent with ISO 42010, but as I understand it Views do not define a specific Viewpoint.  Instead Views conform to a Viewpoint (i.e. perspective) and a View does not define a Viewpoint in and of itself.  (Is this a doc bug Sparx?)

If you apply something like 4+1 you (theoretically) have 5 Views (as packages) per model.

This sounds like a decent way to start.  Rationale:  Minimal package hierarchy is easier to navigate and intuitive to use.  The views are based on industry standards.

I stumbled on this presentation on a projects use of EA which shares another approach:
I liked the idea of having diagrams nested under each use case, but not all diagrams nest so well (in my experience thus far) and this doesn't follow the 'view' convention.

I recently tried using the Systems Engineering Model

which is outlined like so:

This ended up being a bit cumbersome to navigate.   Note: Cumbersome to navigate does not mean don't do it.  I expect users utilize EA's 'Model View' feature to effectively navigate complex models.

I also observed the built in html export is per root node, so if this is important to you it should be taken into account.  In my case, I included all items we may want to export together under one root node.

In summary, three approaches are discussed in this comment:
1 Systems Engineering Model Structure
2 Sandia Labs Model Structure
3 Basic Model, View Structure

Today I am opting for #3 to try next.  The approach I am taking is each Model package represents a Viewpoint (see 42010 reference above) of the system and not a Project as in your example.   In general Views can be applicable to more than one Viewpoint, so this is not foolproof, but I am thinking this is good enough and a good place to start.

General Board / Re: Distributed team deployment and EA LITE Best c
« on: November 20, 2015, 07:27:25 pm »
I've found those not familiar with EA are happy to have a web site to view the model.

Be aware links from the project browser will change from export to export, there is no search and nearly all elements are clickable. So having descriptions for all elements and a very clear landing page with links to key parts of the model will be helpful.

Btw, does anyone have a way to automate the html report in a silent/unattended fashion suitable for a continuous integration type activity?

General Board / Re: Is there any solution for Docs Generator (RTF)
« on: November 20, 2015, 07:34:38 pm »
I've documented my approach, including an example model and use case template in this article: Tutorial: Generate complex documents from Enterprise Architect with a two-step semi-automated approach


Thanks Geert. Just read the report, have yet to try it out but reading it clarified how to configure some parameters of a virtual document.

General Board / Re: DBMS Backups to File
« on: November 12, 2015, 04:47:36 pm »
root cause: the security used for the DB is applied to the saved file, but the authentication method is not functional once you access the file.

Fix (Workaround):  Create user manually with Admin permissions and manually set their password.   Transfer to File, open file, use user/password which was created manually.

General Board / Re: DBMS Backups to File
« on: November 06, 2015, 06:25:31 pm »
So I successfully transfered DBMS to File.

When I open the file I am prompted for login/password which I wasn't expecting.

I have been unable to use my credentials to open the file.

Any pointers on this, for example, how to disable the security settings?

General Board / Re: DBMS Backups to File
« on: November 01, 2015, 04:23:29 pm »
Thank you Geert for confirming.   That is what I would expect.  

General Board / DBMS Backups to File
« on: October 31, 2015, 04:04:43 am »
Can someone verify the Project/Project Transfer process does not impact the 'source'?  

Use Case: Save DBMS backup to EAP file
Goal: The model owner wants to save a snapshot of the project saved as DBMS on periodic bases to have a redundant backup.

I was just going to use the 'Transfer Type' of 'DBMS to File', but wanted to make sure this process will keep the DBMS as-is.

Pages: 1 2 [3] 4