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

Pages: 1 ... 54 55 [56] 57 58 ... 81
General Board / Re: Promotion of SO Enterprise-Architect tag
« on: October 09, 2014, 12:33:39 am »
Well I don't think it's quite fair to say that Sparx neglect this forum -- it is a user forum after all, which they host for free, and their representatives spend quite a bit of time answering questions here.

The forum is a place to discuss EA-related things, but it isn't an official way to get in touch with Sparx support, nor a way to send feature requests, and those (usually new users) who don't make that distinction, which is printed in bold on the forum's front page, tend to get frustrated.

That said, I do agree that for pure Q&A Stack Exchange is a better platform, and I do encourage others to go there and post questions. I certainly answer far more questions on SO than I do on this forum.

SO is mainly about programming, so "the best Stack Overflow questions have a bit of source code in them," but questions regarding "software tools commonly used by programmers" are also accepted. There is a UML tag as well for more generic notation type questions. (Quotes from

So come on down! The Chimp and I are ready to receive. :)


General Board / Re: Technical user sufficient for MySQL connection
« on: September 18, 2014, 08:27:26 pm »
First off, you are correct in that one database houses one EA project.

Yes, you can use a single technical DBMS user and Yes, you can still assign separate project user IDs for the different individuals (qwerty is wrong here).

The DBMS user is used to check database access. Read and write access is required for EA to work, even if you intend for the person to only be allowed read access to the models; this is because EA stores a lot more than just the models in the database.

In-project permissions, such as the permission to change models, generate documents, as well as locking of models to prevent concurrent-update issues, is done using EA's project user IDs. These are stored in the project and are not related to the DBMS user. You can import users from Active Directory, but all management of permissions is in-project (permissions are not stored in the AD).

Separately from the user import, you can configure the project to Accept Windows Authentication. If you do not, each user must authenticate with user name and password when they open the project. (This is the project user, not the DBMS user.)

If the project is configured for Windows Authentication, no user name / password prompt appears, provided that the logged-on Windows user is found among the in-project users.

The main thing in order for your option 1 to work is to ensure that EA uses the technical user when accessing the database. Having to do this every time you open a project (which you can do in the Connection tab of the Data Link Properties dialog, which opens after you select Connect to Server in the Open Project dialog), you can create an ODBC data source and distribute that.

As an alternative, I believe you can include it in the connection string which is stored in an .EAP shortcut to a database project. The .EAP file is in this case simply a text file with the ODBC connection string, wrapped in a little EA stuff. This might be less secure (the password might be stored in there), but if this is acceptable you can simply place such a shortcut .EAP file on a file share.

However, if you have the option of upgrading the DBMS I would do that, it's the least painful solution long-term. It should be noted here that you can transfer an EA project from one database to another, which transfers all the in-project users (since they are stored in the database) but not the DBMS user. So you could start with option 1 and then some while later switch to option 3 with a minimum of work (slightly more if you have used ODBC data sources).



General Board / Re: Creating a report - Actions under each partiti
« on: September 18, 2014, 07:41:02 pm »
I don't see how relationship matrices could help here, since they only show connectors. Other types of relationships, such as containment and diagram placement, are not shown.

Reusing partitions between diagrams the way you describe makes what you want to achieve difficult, because in order to find the actions you must look at the visual properties of their DiagramObjects and figure out if their position in the diagram falls within the bounds of the partition.

I recommend never to reuse partitions between diagrams, and to make sure that the actions are contained within their respective partitions in the project browser. This makes it easy to find the actions from a given partition.

The question then becomes, "if the partitions are each distinct elements, how do you find all actions that relate to system X or user Y?" That too is easy enough: partitions are in fact instance-type elements, so set their respective classifier to a component representing the system / actor representing the user / etc. You can also do a text search for all partitions with a certain name, but in order for that to work the modellers need to be very careful in naming their partitions properly; better in my view to use the classifier option.



General Board / Re: Possible to generate excel report instead of r
« on: June 27, 2014, 11:18:06 pm »
You can't get anything to Excel through the reporting / documentation functions.

What you can do is export (and import) to CSV, which Excel can then read. This export is much more primitive and can only output element information (not connectors, diagrams, operations or attributes), but if all you need is the basic information associated with all elements (name, notes, etc) this should be enough.

If you need more than that, you can look at the third-party extension eaDocx, I know that can do Excel.

Or as always you can roll your own with a script or an Add-In.


General Board / Re: Instance doesn't update from change in element
« on: June 26, 2014, 07:14:20 pm »
This all goes back to EA vs CM, and the core issue is branching.

You want two (or more) separate tracks of model development, with the ability to keep certain things common and to move changes between the tracks.

In source code management, this is everyday stuff. But while EA can manage package-level check-in, check-out and revert, it simply does not do branching.

My recommendation for version management in EA is to use the built-in baseline functionality rather than an external version control system like Subversion, certainly if you're working with a DBMS repository. Both work on the package level and both are based on XMI files, but baselines are stored within the EA repository and there is no external tool involved.

The main advantage is that baselines allow you to do visual diffing of model contents, which external version control doesn't. The main disadvantage is that package-vs-baseline status is not displayed in the project browser.

Baselines can also be imported/exported between projects, and changes from a baseline can be selectively merged into the project (importing a baseline is a separate activity from merging its contents). This is essentially what the reusable asset service introduced in EA 11 does.

This can be used as a way to achieve branching: copy the entire project and move baselines back and forth between them. I'm not aware of any way to achieve (robust) branching at anything lower than whole-project level, although the reusable asset service might be of help there -- I haven't used that in anger yet.

I have previously implemented the whole-project-branching strategy, and I have also (for a different client) built a solution based on tags and a lot of Add-In trickery. Another approach is to use Change elements extensively together with the Phase and Status fields, but have the components etc contain only the "as-is" version until some milestone where you go through the entire model and update it to become the new version (works fairly well for requirement models, but not for much else).

Either way, you can get to the "acceptable" level but it'll never be as slick as branching in a version control repository.

Where do I send my bill for $.02?


General Board / Re: Using EA v8 and EA v11 in parallel
« on: June 26, 2014, 01:22:48 am »
With RTF templates, EA 11 will happily generate documents from templates created in EA 8. But if someone in your EA 11-based team decides to use template fragments or virtual documents, those obviously won't work for your EA 8 team.

So again it comes down to making sure that the EA 11 team doesn't use any features (which store information in the repository) that are not supported in EA 8. If you can do that, the two can probably coexist pretty well. If not, you need to be prepared for productivity issues of the "it doesn't do that on my machine" variety.

Actual data corruption, I think, will be minimal. If an EA 8 user modifies an EA 11-created RTF template which has a reference to a template fragment, that template will probably break, but actual model contents are not likely to be particularly brittle. Other than enumerations. ;)

Any way you slice it, it's a project risk. I would definitely advise setting up a test repository and trying the coexistence thing there before you try it in a production environment. You're jumping three major releases and three minor ones, after all, and asking them to play nicely in the same sandbox.

My 2 cents'.


General Board / Re: Inheritance of Tagged Values between Stereotyp
« on: June 25, 2014, 05:47:17 pm »
Aaaah - brilliant! :)

I actually use something similar to this when I need to create a RefGUID tag which allows selection of a «procedure» or other Sparx-defined stereotype, using the «taggedValue» connector.

I create a "«profile» External Stereotype References" package, and place a "«stereotype» procedure" in that. No metaclass or anything, this profile is never exported to disk nor included in the MDG Technology.

This homegrown «stereotype» procedure can then be used with the «taggedValue» connector in my profiles, and it all works beatifically. The reference is written to the XML file even though the "reference" profile is a big fat phony.


General Board / Re: Inheritance of Tagged Values between Stereotyp
« on: June 25, 2014, 01:28:56 am »
Let's say you've got one ChildSt inheriting from BaseSt1 and BaseSt2. Your XML file will then contain

Code: [Select]
<Stereotype name="ChildSt" ...
  generalizes="BaseSt1" baseStereotypes="BaseSt1 BaseSt2"/>
In order for generalization between stereotypes in different profiles to work, you need to qualify the baseStereotypes reference. EA (10.0.1009) does not do this for you, so what you end up with is still a maintenance nightmare, albeit one with a slightly different monster (post-generation manual XML file editing).

You should also note that only one base stereotype is listed as generalizes. Exactly what effect that has I'm not sure. Possibly it controls which RefGUID tags the child may be used in (in this case, it could then be used in tags specifying BaseSt1 but not in tags specifying BaseSt2), but that's conjecture.

Ways around: I don't know of one, I'm afraid. Unless you can separate your stereotypes into completely separate inheritance hierarchies, I think you might be stuck. So it may be necessary to decide which evil is lesser: a single large profile, or duplication of tags in separate profiles. (Of course, within each profile you can set up the corresponding inheritance hierarchy to minimize the effect.)

As to that, and this is more in response to ZuluTen, having several different profiles in the same MDG Technology is not just possible, but usually a good idea (unless you run into an issue like above).

I have not had any good experiences placing packages inside a profile, but the other way around works just fine. So you wouldn't nest profiles inside each other, but place the different profiles in a single containing package. That package is only there for convenience in your MDG Technology project (you are developing your MDG Technology in a completely separate project, aren't you?), you never generate anything from it.

My MDG Technology projects typically contain a structure like this:
"MDG Technology name" (root node)
  |- Profiles
  |      |- «profile» UML Profile 1
  |      |- «profile» UML Profile 2
  |- Toolboxes
  |      |- «profile» Toolbox 1
  |      |- «profile» Toolbox 2
  |- Diagrams
  |      |- «profile» "MDG Technology name" (if there are only a small number of diagrams)
  |- Learning Center
  |      |- «profile» Learning Center Pane 1

... with additional levels as required; typically there may be some subdivision of toolboxes if there are a large number of diagrams. Only the «profile» packages are ever saved as profiles, the others are just structural sugar.
The model structure is mirrored in the directory structure on the disk, of course, which makes the MDG Technology creation process more convenient.

A word of warning: while moving stereotypes into separate profiles can usually be done in a production environment with little risk, shuffling diagram types between profiles cannot. This is because the stereotypes are only stored with their simple names, but the custom diagram type is stored as a qualified name inside each diagram's StyleEx column.



General Board / Re: Repository migration Oracle to SQL server
« on: January 20, 2014, 09:45:32 pm »
I'd rather go with Sparx's option than a third-party tool.
It might not be the fastest, but it's probably the safer bet since EA's transfer function presumably knows about any "smart" solutions employed in any particular database engine and can make sure everything gets moved the way it's supposed to.

General Board / Re: Updating Component Instances
« on: January 29, 2014, 04:08:15 am »
In component instances, ports are created automatically when you create one in the classifier component - check the project browser, it's there. In properties (which are also a kind of instance of a component), on the other hand, they are not.

In either case, in order to see the new ports in a diagram which holds a pre-existing component instance or property, you need to right-click it in the diagram, select Structural Elements (make sure you've switched on Show Owned/Inherited) and then fix the layout. This has to be done for each diagram that shows the instance/property.

With component instances, where the port is automatically created, you can also drag the new port from the project browser and drop it onto the instance in the diagram.



General Board / Re: How to get information about an element in 2 b
« on: January 24, 2014, 01:22:58 am »
It is a good question. Unfortunately, however, the answer is "no." Or rather, "very difficult."

You can use Project.DoBaselineCompare() and parse the result, but the result format isn't published so you'll essentially have to reverse-engineer it. Also, if the element has been moved from one baselined package to another it gets really tricky because you'll then have to start looking through the set of baselines for each such package in order to find the complete history.

It can be done, I'm sure, but it'll be pretty hard.


General Board / Re: Where is the JET 4.0 option stored?
« on: January 08, 2014, 10:58:37 pm »
Well I'll be doggoned - there it is. Thanks! :)

General Board / Where is the JET 4.0 option stored?
« on: January 08, 2014, 09:26:22 pm »
Hi all,

One of my clients repackages EA for internal distribution, and would like to set the JET 4.0 option as part of that package.

But I can't seem to find this option in the registry, nor in the AppData directory. Does anyone know where it's stored?



General Board / Re: Manage Tabulation-Data within EA
« on: December 03, 2013, 06:57:46 pm »
For completeness: simple row/column data can be imported using EA's CSV import. But if you don't want to turn this data into a model but keep it as a table of some sort, Geert's suggestion is your best bet.
However, to my knowledge at least, the embedded OLE objects cannot be displayed directly in a diagram (you must open the linked document first) and you can't access them through the API.

In terms of external links, there are two ways to do that; either with hyperlinks or with "File" links in elements.
Hyperlinks are diagram objects, so they are not visible in the browser and are deleted with the diagram.

"File" links are a list of file or hypertext references, available in the "Files" tab of most model elements' Properties dialog. You can associate any number of files/pages with any single element.
If you go this way, it's a very simple job to create an Add-In which automatically opens the first link in this list on double-click.

General Board / Re: Sparx deployment & database connection issues
« on: November 29, 2013, 03:07:13 am »

I provide on-site EA support for a multi-project, multi-user client, but they don't use Oracle so I don't have anything specific on that.

In general, EA gets unhappy if it loses the DB connection; you typically see this if you disconnect a laptop from the network and then reconnect.
It may or may not be able to reestablish contact, but the safe way is always to shut EA down and restart. If you're using lazy load the startup time is pretty acceptable.
I'm not aware of any in-EA settings that affect this, but you may be able to tweak something in the ODBC connection.
If your setup employs slow connections you might want to check out the WAN Optimizer, which is available as a download from this site.

In order to copy an entire model repository you use Project Transfer under Tools -- Data Management. [In EA parlance, one repository contains one project, which in turn holds a number of packages, elements and diagrams, ie the models, although "model" is a fuzzy term that I try to avoid.]
This allows you to clone EA repositories across database engines, and to/from .EAP files as well.
However, certain settings are per client, not per repository, and these obviously won't be transferred. This applies to most of the settings in the Options dialog, such as the web home page etc. Most of the settings in the Settings menu, on the other hand, are stored in the repository and so will be copied during a project transfer.

Setting up an EA modelling environment can be a subtle art in its way, and you need to take into account things like information security policies, CM policies, desired level of model reuse and of course how the models should be used (for reading only, or document generation, or code / schema generation, etc). But a simple setup shouldn't take more than a few hours even from scratch.

There are some basic admin guides on this site in the section.
Check out "Deployment of Enterprise Architect" and possibly "Version Control in Enterprise Architect".



Pages: 1 ... 54 55 [56] 57 58 ... 81